Исчезнут ли интерфейсы? Как ИИ-агенты меняют UX разработки

Опубликовано 16 июня, 2026 автором Sergey Bezpalov

Двадцать лет мы учились проектировать интерфейсы вокруг человека: кнопка здесь, форма там, wizard из пяти шагов. Сегодня разработчик открывает Cursor, формулирует задачу на естественном языке — и через час получает PR на десять тысяч строк. Интерфейс никуда не делся, но его роль изменилась: он стал пультом управления автономными исполнителями, а не рабочим столом, где вы сами кликаете каждый шаг.

Это не абстрактный тренд из презентаций вендоров. Это смена парадигмы, которую я вижу в продакшене: от «IDE + автодополнение» к «harness + агенты + ревью». И вопрос уже не «заменит ли ИИ разработчиков», а каким должен стать интерфейс, когда исполнителем становится агент, а человек — оператор, архитектор и контролёр качества.

Метафора водителя и автопилота

Полезная модель — не «робот vs человек», а водитель и автопилот.

Автопилот держит полосу, тормозит перед препятствием, паркуется. Но водитель выбирает маршрут, решает, ехать ли в объезд, и в критический момент перехватывает руль. В агентной разработке то же самое:

  • Водитель — вы: постановка цели, границы доступа, ревью результата, ответственность за прод.
  • Автопилот — агент: поиск контекста, правки файлов, запуск тестов, итерации до прохождения CI.

Плохой UX — когда система притворяется, что водителя нет: агент молча коммитит в main, и вы узнаёте об этом из алерта в 3 ночи. Хороший UX — когда перехват руля мгновенный и предсказуемый: план до старта, чекпоинты, diff, approve/reject, rewind.

Anthropic прямо формулирует эту смену роли: инженеры «фокусируются на архитектуре, продуктовом мышлении и непрерывной оркестрации — управлении несколькими агентами параллельно» (Claude Code). Cursor называет следующий рубеж «self-driving codebases» — но подчёркивает, что путь к нему лежит через harness, планирование и контроль (long-running agents).

Интерфейсы не исчезают. Они переезжают с уровня действий на уровень намерений и надзора.

Тренды и цифры: от пилотов к оркестрации

IDC Future of Work 2026

Прогнозы IDC рисуют картину, где агенты — не «коллеги», а инструменты, которыми владеет человек:

  • К 2026 году 40% ролей в G2000 будут включать прямое взаимодействие с ИИ-системами (IDC Future of Work 2026).
  • К 2027 году половина AI-enabled enterprise-приложений потребует новых позиций по governance, рискам и accountability.
  • Организации со зрелыми AI/Agentic CoE на 20% эффективнее конкурируют по инновациям и скорости.
  • AI-инструменты могут высвобождать более 40% типичного рабочего дня; у IT-специалистов — до 45% (Work Rewired).
  • 66% компаний сокращают найм на entry-level позиции при внедрении ИИ; 91% сообщают об изменении или частичной автоматизации ролей.

Для UI/UX это означает: интерфейсы entry-level задач (формы, мастера настройки, ручные wizards) сжимаются. Растёт спрос на панели оркестрации — где видно, что делают агенты, каков статус, где нужен human-in-the-loop.

FutureScape 2026: агентная экономика

В более широком прогнозе IDC FutureScape 2026:

  • К 2030 году 45% организаций будут оркестрировать агентов на уровне всего предприятия.
  • К 2028 году чистое seat-based pricing устареет: 70% вендоров перестроят модель ценности под «цифровой труд» агентов.
  • 70% CEO G2000 к 2026 году будут измерять ROI ИИ через рост, а не только через сокращение затрат.

Перевод на язык продуктов: вы платите не за «ещё одно место в IDE», а за compute агентов, параллельные сессии, длительность автономной работы, качество merge rate. Интерфейс должен показывать стоимость и риск так же прозрачно, как облачный биллинг показывает vCPU-часы.

Anthropic: «When AI builds itself»

В отчёте «When AI builds itself» (4 июня 2026) Anthropic привела цифры, которые год назад звучали бы как фантастика:

  • В мае 2026 года более 80% кода, мёржащегося в продакшен Anthropic, написано Claude (до research preview Claude Code в феврале 2025 — единицы процентов).
  • Во II квартале 2026 типичный инженер мёржит в 8 раз больше кода в день, чем в 2024-м.
  • Длина задачи, которую модель выполняет автономно и надёжно, раньше удваивалась раз в ~7 месяцев, теперь — раз в ~4 месяца.

Роль инженера сместилась с автора на директора и ревьюера: «большая часть кода пишется Claude, а инженер задаёт направление и проверяет, а не печатает сам». Это и есть смена UX на уровне индустрии: интерфейс обслуживает не набор текста, а постановку цели и контроль.

Архитектурно ценность переехала в harness — instructions, tools, permissions, checkpoints, subagents — а не в чат-окно. Это закреплено в продуктах: Claude Code — агентная система уровня проекта, а Claude Agent SDK (бывший Claude Code SDK) обобщает тот же harness на любые агенты с доступом к «компьютеру»: bash, файлы, MCP-интеграции.

Спектр интерфейсов: от чата к операторской

Полезно видеть не «старый vs новый» UI, а спектр зрелости:

  1. Copilot-слой — подсказки внутри привычного редактора; человек остаётся главным исполнителем.
  2. Agent mode — агент выполняет цепочку действий; человек ревьюит и корректирует.
  3. Delegated autonomy — агент работает часами/сутками; человек approve’ит план и merge.
  4. Fleet orchestration — несколько агентов параллельно; человек — диспетчер с политиками.

Большинство команд в 2026 году сидят между уровнями 2 и 3. Прыжок на 4 без governance — прямой путь к «151k lines PR, которые некому ревьюить». Отсюда и возрождение интерфейсов: не форм, а приборных панелей.

Три кейса: как меняется интерфейс

Cursor: от редактора к agent harness

Cursor эволюционировал от «умного автокомплита в VS Code» к agent harness — связке инструкций, инструментов и модели (agent best practices). Harness подстраивается под каждую frontier-модель: одна предпочитает grep, другая — semantic search; одна забывает линтер, другая — нет.

Что меняется в UX:

Было Стало
Редактор + inline suggestions Agent mode + Plan mode
Ручной выбор файлов Агент ищет контекст сам (grep, semantic search)
Один поток правок Параллельные агенты, long-running tasks на часы и дни
Diff как главный артефакт План → approve → выполнение → diff + тесты

Long-running agents в Cursor — показательный сдвиг: агенты работают 25–52+ часов, собирают PR на десятки и сотни тысяч строк, пользователь «закрывает ноутбук и возвращается к готовому решению» (long-running agents). Интерфейс здесь — не поле ввода кода, а дашборд делегирования: статус, план, approve, merge.

Cursor 3 и Design Mode идут дальше: визуальные подсказки в браузере — «укажи, нарисуй, проговори» — а агент правит код под капотом. UI снова становится важным, но на уровне намерения, не манипуляции виджетами.

Claude Code: мультиповерхностный harness

Claude Code — пример одного движка, многих поверхностей: terminal, VS Code, JetBrains, desktop, web, CI/CD, Slack, GitHub Actions (документация). CLAUDE.md, hooks, MCP и checkpoints работают везде одинаково.

Интерфейс здесь фрактальный:

  • Оператор пишет цель в терминале.
  • Наблюдатель смотрит лог tool calls и diff.
  • Арбитр жмёт approve на опасные команды, /rewind на чекпоинт.
  • Оркестратор запускает subagents и background tasks параллельно.

Anthropic явно разделяет plan и execution: «пустить агента сразу в код — часто значит решить не ту задачу» (best practices). Plan Mode — это UI-контракт между человеком и автопилотом.

С Claude Opus 4.8 появился режим dynamic workflows: Claude планирует работу и запускает сотни параллельных subagents в одной сессии, сам верифицирует результат и докладывает. Заявленный сценарий — миграции масштаба codebase «на сотни тысяч строк от старта до merge», где планкой выступает существующий test suite. Интерфейс при этом — не редактор, а пульт диспетчера: цель, бюджет усилий (high/xhigh/max), статус, верификация.

Devin: agent-native IDE в облаке

Devin 2.0 от Cognition — противоположный полюс той же тенденции: интерфейс построен вокруг агента, а не вокруг локального редактора (Devin 2.0).

Ключевые элементы UX:

  • Параллельные сессии — несколько Devin в изолированных cloud VM.
  • Interactive Planning — правка плана до автономного старта.
  • Embedded IDE + terminal + browser — вы вмешиваетесь в любой момент: Cmd+I, Cmd+K, takeover сессии.
  • Devin Search / Devin Wiki — агентная навигация по codebase вместо ручного tree view.

Devin показывает модель «полностью облачного автопилота»: вы не настраиваете окружение — вы наблюдаете и перехватываете в знакомых инструментах. Для enterprise это ближе к операторской панели, чем к классической IDE.

А в июне 2026 Cognition сделала следующий шаг — Devin Desktop (наследник купленного Windsurf): IDE превращается в командный центр для управления несколькими агентами — локальными и облачными (обзор). Ключевое — поддержка Agent Client Protocol (ACP), открытого стандарта от Zed («LSP для ИИ-агентов»), уже принятого JetBrains, Google и GitHub. В одном Kanban-дашборде рядом с нативным Devin работают Codex CLI, Claude Agent, OpenCode и любые ACP-совместимые агенты, разделяя контекст через project-level Spaces. Формулировка авторов точна: «IDE становится консолью управления, а разработчик — командиром флота агентов».

Аргументы ЗА исчезновения «классических» интерфейсов

1. Сдвиг абстракции. Пользователь описывает что нужно, а не как кликать. Меньше форм — больше intent-based UI.

2. Агент как универсальный адаптер. Один чат (или голос) заменяет десятки экранов: агент сам ходит в API, CLI, браузер. MCP и tool use — новый «glue layer» вместо кастомных интеграционных UI.

3. Параллелизм. Человек не масштабируется на 5 refactor одновременно; пять агентов — да. Интерфейс будущего — мультиплексор задач, а не один монолитный wizard.

4. Длинный горизонт. Long-running agents доказали: задачи на сутки+ — норма. UI «сессии на 15 минут» устаревает; нужны async dashboards, уведомления, resume.

5. Экономика seat-based UI. IDC прогнозирует крах чистого per-seat pricing. Когда ценность — в агент-часах, интерфейс оптимизируют под throughput агентов, а не под плотность кнопок.

Аргументы ПРОТИВ: почему интерфейсы не исчезнут

1. Ответственность остаётся у человека. IDC: агенты «не понимают intent, нюансы и институциональные цели». UI согласования, audit trail и approve — не опция, а compliance.

2. Контекст конечен. Даже у лучших агентов деградация при переполнении context window — измеримая проблема. Нужны UI для управления контекстом: rules, @file, планы, новые сессии.

3. Ошибки масштабируются. Один неверный клик — одна ошибка. Один неверный план агента — тысяча строк мусора. Интерфейсы снижения риска (diff, sandbox, auto-review) станут только важнее. Cursor 3.6 (29 мая 2026) показал, как это выглядит: Auto-review превращает автономию «из тумблера в регулятор» (блог). Каждый вызов Shell/MCP/Fetch проходит трёхступенчатый фильтр — allowlist, sandbox, classifier-субагент, который решает: выполнить, попробовать иначе или спросить человека. Управляется natural-language инструкциями в .cursor/permissions.json. Это и есть новый UI: не кнопка «разрешить всё», а политика как код.

4. Тактильность и пространственное мышление. Дизайнеры, SRE, сетевые инженеры думают диаграммами, топологиями, таймлайнами. Чат плохо заменяет canvas, Grafana, topology map. Design Mode в Cursor — признание этого: визуальный слой никуда не делся.

5. Доверие и калибровка. Anthropic строит Claude Code с explicit permissions и прозрачным окружением — потому что «чёрный ящик в облаке» не продаётся в regulated industries.

6. Legacy и гетерогенность. 80% enterprise-работы — не greenfield в Cursor, а ковыряние COBOL, FortiGate, Exchange, CUCM. Там UI вендора останется; агент — надстройка, не замена.

Прогноз на 3–5 лет (2026–2030)

2026–2027: гибрид «IDE + agent panel» станет стандартом. Как сейчас Git panel обязателен, так станет Agent panel: планы, параллельные runs, стоимость, статус CI. Роль «agent harness engineer» выделится из DevOps и platform teams.

2027–2028: multi-agent orchestration UI и открытые протоколы. Специализированные агенты (plan / edit / test / security review) координируются harness-ом — Cursor уже описывает это как «будущее AI-assisted engineering» (agent harness), а Claude Opus 4.8 запускает сотни subagents в одной сессии. Параллельно вызревает стандартизация: ACP (как LSP для агентов) обещает развязать «любой агент × любой редактор». Интерфейс — дирижёрская стойка, не один чат; и она перестаёт быть проприетарной.

2028–2029: intent-first поверхности для нетехнических ролей. PM, аналитик, support lead ставят задачи агентам на естественном языке; инженер — на уровне политик, ревью и архитектурных constraints. «Low-code» эволюционирует в low-intent с жёстким governance.

2029–2030: selective disappearance. Исчезнут процедурные UI (мастера миграции, ручные codegen wizards, часть admin consoles). Останутся observability UI (кто что делегировал агенту), policy UI (что агенту можно), exception UI (где человек обязан).

Полное «безынтерфейсное» ПО — маркетинговый крайний случай. Реалистичный сценарий — перераспределение пикселей: меньше кнопок «Сделать шаг 3», больше «Цель / Границы / Статус / Перехват».

Что делать уже сейчас: actionable insights

Для разработчиков

  1. Освойте plan-before-execute: Plan Mode в Cursor, plan в Claude Code — не ритуал, а страховка от дорогих промахов.
  2. Держите rules и CLAUDE.md/AGENTS.md как код: это persistent UI для агента.
  3. Думайте сессиями: одна задача — один агент; длинный чат = шум в контексте.
  4. Учитесь ревьюить diff быстрее, чем писать код: это новый bottleneck.

Для продуктовых дизайнеров

  1. Проектируйте три слоя: intent input → progress/observability → intervention (pause, edit plan, rewind).
  2. Не прячьте стоимость и риск: сколько агент-часов, какие файлы тронуты, какой blast radius.
  3. Визуальные инструменты (canvas, browser preview, диаграммы) останутся; чат их не заменит, а свяжет с кодом.

Для технических менеджеров

  1. Заложите Agentic CoE или хотя бы playbook: IDC связывает зрелость с +20% к инновациям.
  2. Пересмотрите онбординг junior’ов: если entry-level задачи уходят агентам, junior должен учиться оркестрации и ревью, а не только синтаксису.
  3. Введите политики: какие репозитории автономны, где обязателен human approve, как логируются agent actions.
  4. Метрики: не «строк кода в день», а merge rate, defect escape, time-to-recovery после agent PR.

Для архитекторов

  1. Treat harness as platform: tools, permissions, MCP, sandbox — это ваш следующий integration layer.
  2. Проектируйте системы agent-legible: структура репо, тесты, docs — это тоже UX, только для машины.
  3. Не смешивайте автопилот и прод без рубильника: feature flags, canary, auto-review — часть интерфейса безопасности.

Заключение

Интерфейсы не исчезают — они меняют хозяина. Раньше UI обслуживал пальцы человека; теперь всё чаще обслуживает глаза и решения человека, пока агенты работают руками. Метафора водителя и автопилота здесь точная: выигрывает не тот, кто спит за рулём, а тот, кто умеет ставить маршрут, видеть приборную панель и вовремя перехватить управление.

Cursor, Claude Code и Devin — три варианта одной ставки: harness важнее чата. IDC и практика 2026 года говорят то же: агенты — инструменты, а не коллеги; ценность — в оркестрации, governance и скорости с человеком в контуре ответственности.

Следующие три года определят, станет ли «agent panel» таким же обязательным, как панель Git. Мой прогноз: да. А исчезнут — разве что интерфейсы, которые заставляли вас делать вручную то, что агент уже умеет делегировать. При условии, что вы остались водителем, а не пассажиром с закрытыми глазами.

Источники

Рубрика: Software, AI | Метки: , | Оставить комментарий

3CX AI Edition: встроенный ИИ и интеграции в одной платформе

Опубликовано 14 июня, 2026 автором Sergey Bezpalov

Телефония с ИИ перестала быть экспериментом. Вендоры либо встраивают модели в платформу, либо продают отдельные «AI add-on» с внешними API и сюрпризами в биллинге. 3CX Enterprise / AI Edition — пример первого подхода: ИИ, контакт-центр и интеграции упакованы в одну редакцию, а не размазаны по маркетплейсу.

Для архитектора UC это интересно не маркетингом «самая низкая цена в отрасли», а моделью связки: голос → транскрипция → аналитика → CRM/BI → автоматизация. Интеграции downstream проработаны хорошо; upstream к LLM — нет: OpenRouter и custom providers в UI не предусмотрены. Ниже — что входит в AI Edition, где схема сильная и где обрывается.

Для кого эта редакция

3CX позиционирует AI Edition для среднего и крупного бизнеса с большим потоком вызовов, распределёнными командами и требованиями к непрерывности. Лицензирование — по числу одновременных вызовов (SC), а не по количеству пользователей. Для IT-администратора без глубокого телеком-бэкграунда это плюс: одна годовая подписка, функции без скрытых надстроек.

Развёртывание — на выбор:

  • 3CX Hosted (управляемый хостинг вендора)
  • собственное облако
  • on-premise

Последний пункт критичен для финансов, здравоохранения и любой среды, где голосовые данные не должны уходить в публичное облако без явного решения.

Стек AI-функций: не один «чат-бот», а цепочка

На странице AI Edition и в релизах V20 Update 8 (agentic AI) 3CX описывает не разрозненные фичи, а конвейер обработки коммуникаций:

Слой Что делает Зачем архитектору
ИИ-секретарь / receptionist Принимает входящие, маршрутизирует, отвечает на типовые вопросы Снижает нагрузку на операторов и IVR-деревья
ИИ-агенты (OpenAI) Первая линия, голосовая почта, резюме звонков, sentiment Автономные сценарии без постоянного присмотра человека
ИИ ПА (personal assistant) Персональный ассистент для сотрудника Не только для call center — для всей организации
Транскрипция + диаризация Текст разговора с разделением по спикерам Точный call log, compliance, поиск по записям
Резюме и анализ настроения Сжатие длинных разговоров, оценка тона клиента QA, обучение, эскалация проблемных кейсов
ИИ-аналитика Отчёты, дашборды, мониторинг в реальном времени SLA, удовлетворённость, эффективность команд

Важный архитектурный момент: агенты в Update 8 получили Knowledge Sources — базы знаний из Admin Console, привязанные к конкретному агенту. Это уже не «подключили GPT и надеемся», а retrieval-augmented сценарий внутри АТС: агент тянет корпоративные факты во время звонка или чата.

По умолчанию для OpenAI-сервисов указан gpt-5-mini (баланс цена/качество для типичных PBX-нагрузок); модель можно сменить вручную.

Транскрипция: облако, свой движок, GPU

Здесь 3CX показывает зрелую двухконтурную модель — редкость среди SMB/Mid-market PBX:

  1. 3CX Cloud Transcription — быстрый старт, минимум инфраструктуры.
  2. Transcription Engine Server — отдельный Linux-хост (on-prem или private cloud), ставится командой из Admin Console (Admin → Integrations → Transcription). Требует Enterprise/AI и 16SC+.

Локальный движок рассчитан на Nvidia GPU с ≥24 GB VRAM (в community обсуждают RTX 40xx/ADA, L4 на грани, в перспективе — ARM/GB10). Автообновление сервера транскрипции — по расписанию (воскресенье, 01:00 по времени сервера).

Альтернативы в экосистеме: OpenAI Whisper, Google Cloud Speech API — для тех, кто уже стандартизировал провайдера распознавания.

Вывод для проектирования: можно начать с облака, а при росте требований к конфиденциальности переключить контур на свой Transcription Engine, не меняя АТС. Голос остаётся в периметре, а downstream-интеграции (CRM, BI) продолжают получать те же метаданные.

Интеграции: почему это хороший эталон

Именно блок интеграций на странице AI Edition — то, что стоит смотреть архитектору. 3CX не ограничивается «есть REST API», а называет конкретные точки стыковки в корпоративном ландшафте:

Голос (3CX PBX)
    │
    ├─► Microsoft Teams Direct Routing
    ├─► CRM (нативные коннекторы + API)
    ├─► Power BI
    ├─► Grafana
    ├─► PostgreSQL (хранилище CDR/метаданных)
    ├─► MS 365 / Google Workspace
    ├─► Live Chat, WhatsApp, SMS
    └─► Call Flow Designer + API → автоматизация процессов

Что из этого особенно полезно

Microsoft Teams Direct Routing — голос остаётся на 3CX, Teams получает номера и маршрутизацию. Для гибридных сред (SFB/Lync-наследие, M365, но своя АТС) это привычный паттерн; AI-слой накладывается на тот же SIP-транк.

Power BI и Grafana — готовые векторы для операционной и executive-аналитики: не экспорт CSV раз в неделю, а поток событий вызовов, очередей, sentiment. Для контакт-центра это закрывает разрыв между «телефония работает» и «руководство видит KPI».

PostgreSQL — явный акцент на свой data plane: метаданные звонков в реляционном хранилище, откуда их подхватывают ETL, дашборды или внутренние ML-пайплайны.

API + Call Flow Designer — low-code для маршрутизации и high-code для кастомных workflow (webhook, синхронизация с тикет-системой, триггеры по sentiment).

Схема напоминает то, как современные AI-ready сайты строят слои robots.txt → llms.txt → Schema.org: здесь аналог — PBX → транскрипция/агенты → структурированные данные → корпоративные системы. Разница в том, что источник — живой голос, а не HTML.

Чего не хватает: OpenRouter и custom AI providers

Интеграции с CRM, BI и Teams у 3CX проработаны хорошо. Слой выбора LLM-провайдера — нет. Это заметный архитектурный разрыв, если вы привыкли к паттерну вроде OpenRouter: один OpenAI-compatible endpoint, маршрутизация между моделями и вендорами, failover, оптимизация стоимости.

На странице AI Edition звучит «без надстроек или внешних API», но для встроенных ИИ-агентов реальность другая: в Admin Console (Admin → Integrations → AI) настраивается только прямой OpenAI API — secret key, выбор моделей (gpt-realtime для звонков, gpt-5o-mini для текста), Knowledge Sources через экосистему OpenAI. Поля для custom base URL нет.

В форуме 3CX это уже обсуждали: запрос на свой endpoint (типичный кейс — Azure OpenAI) получил ответ «пока только OpenAI direct, пожелание зафиксировали». То есть ни OpenRouter, ни Azure OpenAI, ни Anthropic/Groq/Mistral не являются first-class опциями в AI Agent wizard.

Голос (3CX PBX)
    │
    ├─► CRM / BI / Teams / PostgreSQL     ✓ нативно
    │
    └─► LLM-провайдер
            ├─► OpenAI (прямой API)      ✓ из коробки
            ├─► OpenRouter.ai            ✗ нет
            ├─► Azure OpenAI             ✗ нет (запрос в roadmap)
            └─► свой on-prem LLM         ✗ только через обходной путь

Почему это важно архитектору:

  • Vendor lock-in на inference. Все агенты, RAG и биллинг Knowledge Sources завязаны на один OpenAI project/key. Мульти-тенантным интеграторам приходится заводить отдельный ключ на каждого клиента — иначе общий пул документов между инстансами (обсуждение на форуме).
  • Нет cost routing. Нельзя отправить простые FAQ на дешёвую модель, а сложный screening — на дорогую. OpenRouter как раз решает это одним API; 3CX — нет.
  • Нет graceful degradation. При деградации OpenAI или смене модели (Update 8 уже требует вручную авторизовать новые модели в ключе) вы не переключитесь на резервного провайдера из UI.
  • Realtime-ограничение. Для голосовых агентов 3CX опирается на gpt-realtime — модели, которых нет в каталоге OpenRouter. Даже гипотетический proxy не закроет весь стек «из коробки».

Обходной путь — не интеграция, а отдельный проект. Для полностью своей модели остаётся Call Control API: внешнее приложение перехватывает вызовы, само гоняет STT → LLM → TTS и может смотреть куда угодно — OpenRouter, локальный Ollama, корпоративный endpoint. Но это свой voice bot поверх АТС, а не настройка агента в Admin Console за десять минут. Аудиострим в CFD не отдаётся — только SIP-клиент или API-оркестрация.

Для сравнения: в типичном AI-стеке (IDE, CI, внутренние боты) OpenRouter уже стандарт — один ключ, десятки моделей, предсказуемый биллинг. 3CX AI Edition интегрируется с корпоративным периметром отлично, но слой inference остаётся монолитным. Пока 3CX не добавит custom AI providers (хотя бы OpenAI-compatible base URL + выбор модели из списка), архитекторы с multi-vendor стратегией закладывают либо жёсткую зависимость от OpenAI, либо параллельную разработку на Call Control API.

Контакт-центр и UC «вокруг» AI

AI Edition включает не только ИИ, но и расширенный call center: отчёты, wallboards, отслеживание настроения, права на старт/стоп записи, резервирование (failover + standby license). Для глобальных команд — видео до 250 участников на сессию, встроенный MCU (локальный MCU — лицензия 32SC+).

Каналы сообщений (Live Chat, WhatsApp, SMS) идут в той же платформе — агенты и аналитика не привязаны только к PSTN/SIP.

Лицензии и апдейты: на что смотреть перед апгрейдом

Линейка редакций у 3CX сейчас в движении (V20 Update 8):

  • PRO — телефония и коллаборация без полного AI-стека
  • Enterprise / AI — агенты, расширенная аналитика, интеграции
  • Enterprise Plus — для предсказуемых объёмов транскрипции и compliance (8/16/24 SC)

Перед обновлением стоит сверить: объём SC, требования к on-prem транскрипции, авторизацию новых моделей OpenAI в ключе API (миграция с устаревших моделей — вручную).

Когда имеет смысл, а когда нет

Имеет смысл, если:

  • высокий объём входящих и нужна автоматизация первой линии без отдельного CCaaS;
  • нужен единый вендор для голоса, чатов, видео и AI-аналитики;
  • compliance требует локальной транскрипции или чёткого data residency;
  • уже есть или планируется стек Teams + Power BI + CRM — 3CX заявляет нативные стыки.

Скептически смотреть, если:

  • организация уже глубоко в Microsoft Teams Phone / Copilot и не хочет второй голосовой платформы;
  • AI нужен точечно (только summary встреч) — полная AI Edition может быть избыточной;
  • нет GPU-инфраструктуры для local transcription, а облачный контур запрещён политикой — придётся закладывать CAPEX или ENT+ с облачной квотой 3CX;
  • нужна мульти-провайдерная LLM-стратегия (OpenRouter, Azure OpenAI, on-prem) — встроенные агенты этого не дают, только прямой OpenAI или свой код на Call Control API.

Итог

3CX AI Edition — не «ещё один GPT-бот в IVR», а попытка встроить agentic AI в ядро АТС и сразу вывести результат в привычные корпоративные системы. Для архитектора UC ценность — в целостной карте интеграций downstream: от Direct Routing в Teams до PostgreSQL и Grafana.

Слабое место — upstream к LLM: нет OpenRouter, нет custom providers, нет смены inference-вендора без обхода через Call Control API. Эталонная схема интеграций обрывается на границе «чья модель отвечает в трубку».

Полезно использовать эту страницу как чек-лист при проектировании любой voice+AI платформы: где транскрибируем, где храним, кто потребляет метаданные, кто поставляет LLM и можно ли сменить провайдера без переписывания агентов. Даже если финальный выбор — не 3CX, вопросы останутся те же.

Ссылки

 

Рубрика: Unified Communications, 3CX, AI | Метки: , , , | Оставить комментарий

Как оптимизировать сайт и блог под AI

Опубликовано 14 июня, 2026 автором Sergey Bezpalov

Двадцать лет мы оптимизировали сайты под Google. Пора учиться объяснять их машинам, которые читают сайт вместо человека.

Поисковик показывал человеку десять синих ссылок — дальше человек думал сам. AI-агент так не делает: он читает страницу, понимает её и сразу отвечает пользователю или принимает решение — кого порекомендовать, к кому обратиться, что закупить. Если агент вас не понял — вы не «ниже в выдаче», вас просто нет в ответе.

Хорошая новость: новый сайт не нужен. Нужно навести порядок в нескольких слоях, и работают они только вместе.

Как оптимизировать сайт и блог под AI — инфографика

Три слоя: привратник, путеводитель, паспорт

Коротко суть:

  • robots.txt — решает, кого пускать и куда; указывает путь к sitemap.xml. Ссылку на llms.txt можно оставить в комментарии для людей, но боты комментарии не читают — это не директива.
  • llms.txt — человекочитаемая выжимка в корне сайта: кто вы, услуги, контакты, главные страницы. Поисковик ползёт по всему сайту и догадывается. Агенту вы даёте готовую карту.
  • Микроразметка Schema.org / JSON-LD — машинный паспорт страницы: не «красивый текст про компанию», а структурно — организация, контакты, услуги и связи между ними. Без неё агент догадывается. С ней — знает.

Привратник впускает и открывает карту обхода, путеводитель объясняет смысл, паспорт подтверждает факты. Уберите любой слой — цепочка рвётся.

Честная оговорка: llms.txt — стандарт молодой, скорее emerging convention, чем утверждённая норма, и не все боты читают его одинаково. Но стоит он полчаса работы, а вреда не несёт — поэтому в моём чек-листе он есть.

1. База: делайте контент понятным

Никакой robots.txt не спасёт страницу, которую не понять ни человеку, ни машине.

  • Одна страница — одна главная тема.
  • Чёткий H1, логичные H2/H3, короткие абзацы.
  • Прямые ответы, определения, списки, FAQ.
  • Автор, дата публикации и дата обновления.
  • Источники, контакты, страница «О нас», редакционная политика.

2. Структура сайта

  • ЧПУ-URL, хлебные крошки, canonical, sitemap.xml.
  • Семантический HTML: <header>, <main>, <article>, <nav>, <footer>.
  • Связанные материалы и внутренняя перелинковка.
  • Не прячьте важный текст только в JavaScript.
  • Мобильная версия и скорость загрузки — обязательны.

3. robots.txt — правила обхода

Файл в корне сайта управляет доступом ботов к разделам и указывает путь к карте сайта:

User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

# Ссылка на описание для LLM
# https://example.com/llms.txt

Канонического способа сослаться на llms.txt из robots.txt пока нет: директива Sitemap: работает только для sitemap.xml, а строка с # https://.../llms.txt — комментарий для людей и документирования, боты её игнорируют. Полезно оставить её в файле как напоминание редактору, но не ждите, что crawler найдёт llms.txt через robots.txt.

4. llms.txt — краткая карта сайта для LLM

Файл в корне (/llms.txt) помогает кратко объяснить назначение сайта, важные разделы, документацию, контакты и ключевые материалы.

Пример:

# Example Site
Описание: Блог и база знаний по AI и SEO.
Разделы: /blog/, /docs/, /faq/
Ключевые материалы: /guide/ai-seo
Контакты: /contact/
Обновлено: 2026-06-02

Включите: краткое описание проекта, целевую аудиторию, основные разделы, ссылки на лучшие материалы, контакты, политику и дату последнего обновления.

llms.txt не заменяет sitemap.xml: sitemap — полный машинный список URL для обхода, llms.txt — курированная человекочитаемая выжимка смысла (кто вы, ключевые страницы). Они дополняют друг друга: sitemap помогает найти всё, llms.txt — быстро понять главное.

5. Микроразметка / Schema.org

JSON-LD — предпочтительный формат. Рекомендуемые типы:

Тип страницы Schema.org
Блог Article, BlogPosting
FAQ FAQPage
Инструкции HowTo
Компания Organization
Автор Person
Навигация BreadcrumbList
Общие страницы WebPage

Минимальный шаблон для статьи:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "...",
  "description": "...",
  "author": { "@type": "Person", "name": "..." },
  "datePublished": "2026-06-14T15:26:32+03:00",
  "dateModified": "2026-06-14T15:26:32+03:00",
  "mainEntityOfPage": "URL"
}

Google рекомендует полный ISO 8601 с временем и часовым поясом, а не только дату YYYY-MM-DD.

6. Что особенно любят AI-системы

  • Краткие summary-блоки в начале материала.
  • Термин → определение → пример.
  • Списки, таблицы, чек-листы.
  • Q&A и блоки «Коротко» / TL;DR.
  • Alt-текст у изображений и подписи к иллюстрациям.
  • Транскрипты для видео и аудио.

7. Управление AI-ботами

Проверяйте правила для конкретных user-agent. Решите, что индексировать, а что нет. Блокируйте приватные, тестовые и дублирующие разделы. Регулярно пересматривайте robots.txt — список ботов растёт.

Примеры user-agent для управления: GPTBot, Google-Extended, ClaudeBot, PerplexityBot, CCBot.

8. Чек-лист перед публикацией

  • [ ] Понятный title и H1
  • [ ] Summary и FAQ на месте
  • [ ] Автор и дата обновления указаны
  • [ ] Schema.org / JSON-LD внедрена
  • [ ] sitemap.xml обновлён
  • [ ] robots.txt настроен
  • [ ] llms.txt подготовлен
  • [ ] Внутренняя перелинковка есть

Итог

Сайт остаётся прежним для людей. Просто теперь его понимают и машины. В мире, где подрядчика всё чаще выбирает агент, а не человек, — это уже не «приятно иметь», а гигиена.

Формула: хороший контент + понятная структура + robots.txt + llms.txt + schema.org = сайт, который понимают и люди, и AI.

Подходит для блогов, корпоративных сайтов, документации, интернет-магазинов и баз знаний.

Артефакт для агента: сгенерируйте llms.txt за 15 минут

Теория выше — теперь практика. Собрал пакет, который читатель может отдать
своему AI-агенту (Cursor, Claude, ChatGPT и др.) и получить черновик
llms.txt + подсказку для robots.txt под свой сайт.

Скачать пакет: llms-generator.zip

Внутри:

Файл Для чего
SKILL.md Cursor Agent Skill — пошаговый workflow
PROMPT.md Универсальный промпт для любого чата
template-llms.txt Пустой шаблон
example-llms.txt Живой пример (blog.bezpalov.com/llms.txt)
README.md Краткая инструкция

Cursor

  1. Распакуйте архив.
  2. Скопируйте SKILL.md (и шаблоны) в .cursor/skills/generate-llms-txt/ вашего проекта.
  3. В чате: @generate-llms-txt создай llms.txt для https://мой-сайт.ru

Claude / ChatGPT / другой агент

  1. Откройте PROMPT.txt или PROMPT.md из архива.
  2. Подставьте URL, тип сайта, язык и аудиторию.
  3. Вставьте в чат → сохраните вывод как llms.txt → выложите в корень сайта.

Агент сам изучит sitemap и навигацию, отберёт ключевые страницы и выдаст
фрагмент для robots.txt. Проверьте URL вручную перед публикацией — агент
не заменяет здравый смысл.

Материал ранее опубликован в LinkedIn.

Рубрика: Quick Tip, AI | Метки: , , | Оставить комментарий

Как смартфоны «понимают», что Wi-Fi требует авторизации: разбор Captive Portal

Опубликовано 6 апреля, 2026 автором Sergey Bezpalov

Вступление

Вы когда-нибудь подключались к Wi-Fi в кафе или аэропорту, и телефон сам открывал браузер со страницей входа? Или наоборот — подключались, а интернета нет, но и страница не появляется?

За этим стоит технология Captive Portal. А ключевую роль в её обнаружении играют несколько специальных URL, которые «зашиты» в каждую операционную систему. В этой статье разберем, как они работают, какие именно адреса используют iPhone, Android и Windows, и почему HTTPS иногда всё ломает.

Как это работает: «приманка» для сети

Когда ваш телефон или ноутбук подключается к новой Wi-Fi, он не показывает вам страницу входа сразу. Сначала он делает незаметный фоновый запрос по одному из зарезервированных адресов (например, http://captive.apple.com/hotspot-detect.html).

  • Идеальный сценарий: Сервер возвращает код 204 No Content (или короткую строку вроде Success). Устройство думает: «Интернет есть, портала нет». Браузер не открывается.
  • Сценарий с порталом: Роутер перехватывает запрос и вместо кода 204 возвращает 302 Redirect (перенаправление) на страницу авторизации. Устройство понимает: «Ага, трафик перехвачен! Нужно открыть браузер и показать эту страницу пользователю».

📱 Секретные URL от производителей

Теперь — главное. Вот какие конкретно адреса «зашиты» в самые популярные устройства. Ваш список оказался абсолютно верным, я лишь добавлю контекст.

URLВладелецГде используетсяЧто ожидает устройство
http://captive.apple.com/hotspot-detect.htmlAppleiPhone, iPad, MacТекст Success (код 200)
http://connectivitycheck.gstatic.com/generate_204GoogleAndroid, ChromebookКод 204
http://www.google.com/generate_204GoogleWindows, старые версии Chrome, скриптыКод 204
http://cp.cloudflare.com/generate_204CloudflareАльтернативный URL, некоторые роутеры и приложенияКод 204
http://edge-http.microsoft.com/captiveportal/generate_204MicrosoftEdge BrowserКод 204

Почему именно HTTP, а не HTTPS? Это ключевой момент. Для проверки используется незашифрованный HTTP. Почему? Представьте: портал пытается подменить ответ для HTTPS-запроса. Это потребовало бы поддельного сертификата, и браузер выдал бы страшную ошибку безопасности, а не окно входа. Поэтому проверка всегда идет по HTTP, а окно портала открывается по любому протоколу.

🖥 А что насчет других систем?

Ваш список покрывает 90% мобильных устройств. Но есть и другие:

  • Microsoft Windows: http://www.msftconnecttest.com/connecttest.txt
  • Mozilla Firefox: http://detectportal.firefox.com/success.txt
  • Fedora / Linux: http://fedoraproject.org/static/hotspot.txt
  • Ubuntu / Linux: http://connectivity-check.ubuntu.com

🔧 Практическое применение (для администраторов)

Знание этих URL решает две реальные задачи:

  1. Диагностика проблем. Если вы подозреваете, что сеть перехватывает трафик там, где не должна, попробуйте в браузере открыть http://captive.apple.com/hotspot-detect.html. В нормальной сети вы увидите Success. Если видите что-то другое (или перебросило на другую страницу) — значит, портал активен.
  2. Настройка белых списков (whitelist). Если вы управляете корпоративным роутером или шлюзом с каптивным порталом, обязательно добавьте все эти домены в исключения (bypass). Устройства должны получать чистый ответ 204 без перехвата. Иначе они «зациклятся»: телефон будет думать, что портал не отпускает, и не даст пользователю нормальный доступ.

💡 Главный вывод

Эти маленькие URL — не просто технические детали. Это «язык», на котором ваше устройство договаривается с сетью: «Ты портал или нет?». Понимая этот механизм, вы сможете легче отлаживать проблемы с Wi-Fi, настраивать гостевые сети и даже «обманывать» систему в некоторых публичных сетях, подставляя свои заглушки.

А теперь проверьте себя: откройте в браузере по очереди каждый из этих адресов. Что вы видите? Если Success или пустую страницу — ваш интернет работает чисто.

P.S. Если у вас есть свой сервер, вы можете разместить файл generate_204 или hotspot-detect.html и использовать его в качестве пользовательского теста подключения. Главное правило — он должен отвечать быстро и без редиректов.

Рубрика: Networks | Метки: | Оставить комментарий

Конвертация PFX-сертификата в CRT и KEY

Опубликовано 24 августа, 2024 автором Sergey Bezpalov

PFX (PKCS#12) удобен для переноса: сертификат и ключ в одном зашифрованном файле. На сервере чаще нужны отдельные .crt и .key. OpenSSL решает это за две команды.

Что понадобится

  • OpenSSL в PATH
  • PFX-файл с сертификатом и ключом
  • Пароль от PFX

Извлечь сертификат

openssl pkcs12 -in certificate2024.pfx -clcerts -nokeys -out example_com.crt

Флаг -clcerts берёт клиентский сертификат; -nokeys исключает ключ из вывода.

Извлечь приватный ключ

Два шага (если нужен отдельный расшифрованный ключ):

openssl pkcs12 -in certificate2024.pfx -nocerts -out server.key
openssl rsa -in server.key -out example_com.key

Один шаг (ключ сразу без шифрования на диске — только на доверенной машине):

openssl pkcs12 -in certificate2024.pfx -nodes -nocerts -out example_com.key

Результат

Файл Содержимое
example_com.crt Сертификат (PEM)
example_com.key Приватный ключ (PEM)

Импортируйте пару в веб-сервер или балансировщик. Храните .key с минимальными правами (chmod 600), не кладите в Git.

На практике

Если nginx ругается на «key values mismatch» — в PFX мог быть промежуточный CA, а не leaf. Добавьте -clcerts при извлечении cert или проверьте цепочку через openssl pkcs12 -in file.pfx -info -noout.

Рубрика: Quick Tip | Метки: , , , | Оставить комментарий

Конфигурирование Right To Use на оборудовании Cisco

Опубликовано 16 июля, 2024 автором Sergey Bezpalov

Чтобы использовать Right To Use (RTU) лицензию на коммутаторах или маршрутизаторах Cisco, выполните следующие шаги:

Активируйте нужную лицензию:

Введите команду license right-to-use activate {ipbase | ipservices | lanbase} {all | evaluation all} [slot slot-number] [acceptEULA] для активации нужной вам лицензии. Например, чтобы активировать лицензию IP Services для всех слотов, введите license right-to-use activate ipservices all acceptEULA.

Перезагрузите устройство:

После активации лицензии перезагрузите устройство или линию карты с помощью команды reload [LINE | at | cancel | in | slot stack-member-number | standby-cpu]. Например, для перезагрузки второго слота введите reload slot 2.

После перезагрузки проверьте статус лицензий с помощью команды show license right-to-use summary. Это покажет, какие лицензии были активированы и их состояние.

Cisco Doc | LearnDuty

Рубрика: Cisco, Hardware, Quick Tip | Метки: , , | Оставить комментарий

Интеграция 3CX и Cisco Communication Manager

Опубликовано 10 декабря, 2023 автором Sergey Bezpalov

Задача

Организация двустороннего транка между Cisco CM и 3CX с прозрачной передачей номеров вызывающего и вызываемого посредством промежуточного шлюза (Cisco ISR с функционалом CME/UBE).

Агенда

10001 — Bridge number/id in 3CX

1xxx — Dial plan in Cisco UCM

2xxx — Dial plan 3CX system

10.0.1.2 — Voice router / gateway

10.0.2.2 — Cisco UCM

10.0.3.2 — 3CX

Проверено на Cisco ISR 2921, SW: «c2900-universalk9-mz.SPA.157-3.M8.bin«

Пример конфигурации 

!
class-map match-any voip-med
 match protocol rtp
class-map match-any voip-sig
 match protocol sip
!
policy-map policy-voip
 class voip-med
  set dscp ef
 class voip-sig
  set dscp af41
!

!
interface FastEthernet0/0
 description VoIP Network
 ip address 10.0.1.2 255.255.255.0
 service-policy output policy-voip
!

!
voice service voip
 ip address trusted list
  ipv4 10.0.2.2 255.255.255.255
  ipv4 10.0.3.2 255.255.255.255
 srtp fallback
 allow-connections sip to sip
 supplementary-service h450.12
 no supplementary-service sip moved-temporarily
 supplementary-service media-renegotiate
 redirect ip2ip
 signaling forward none
 sip
  min-se 600 session-expires 600
  header-passing
  error-passthru
  registrar server
  asserted-id pai
  history-info
  midcall-signaling passthru
  privacy-policy passthru
  privacy-policy send-always
!
voice class codec 1
 codec preference 1 g722-64
 codec preference 2 g711alaw
 codec preference 3 g711ulaw
 codec preference 4 g729r8
!

!
voice class sip-profiles 1
 request INVITE sip-header From modify "sip:....@10.0.1.2" "sip:10001@10.0.1.2"
 request INVITE sip-header Contact modify "sip:....@10.0.1.2" "sip:10001@10.0.1.2"
!

!
dial-peer voice 1000 voip
 description = CUCM =
 destination-pattern ^1...
 rtp payload-type comfort-noise 13
 session protocol sipv2
 session target ipv4:10.0.2.2
 incoming called-number .T
 voice-class codec 1
 no voice-class sip early-offer forced
 voice-class sip options-keepalive
 voice-class sip pass-thru content sdp
 dtmf-relay rtp-nte
 ip qos dscp cs3 signaling
 no vad
!

!
dial-peer voice 2000 voip
 description = 3CX =
 destination-pattern ^2...
 rtp payload-type comfort-noise 13
 session protocol sipv2
 session target ipv4:10.0.3.2
 incoming called-number .T
 voice-class codec 1
 no voice-class sip asserted-id
 no voice-class sip early-offer forced
 voice-class sip profiles 1
 voice-class sip options-keepalive
 voice-class sip pass-thru content sdp
 dtmf-relay rtp-nte
 ip qos dscp cs3 signaling
 no vad
!

!
sip-ua
 credentials username 10001 password 123P realm 3CXPhoneSystem
 authentication username 10001 password 123P realm 3CXPhoneSystem
 timers connect 1000
 timers register 300
 registrar 1 ipv4:10.0.3.2 expires 3600
!
Параметры моста на 3CX

Note: GitHub Gist

Рубрика: 3CX, Cisco, Hardware, Software, Unified Communications | Метки: , , | Оставить комментарий

Сброс настроек телефонов Snom

Опубликовано 20 августа, 2023 автором Sergey Bezpalov

Телефон «завис» после провижининга или нужно вернуть заводские настройки без веб-интерфейса — у Snom есть аппаратный Rescue Mode.

Модели: D3xx, D7xx, 7xx, MP.

Сброс через Rescue Mode

  1. Перезагрузите телефон: наберите **## или выключите/включите питание.
  2. Сразу после включения удерживайте #, пока не появится меню Rescue Mode.
  3. Выберите пункт:
  4. 1 — сброс настроек (factory reset)
  5. 2 — восстановление прошивки/конфига по сети

После сброса телефон снова запросит провижининг с вашей PBX (3CX, Asterisk и т.д.).

Если меню не появляется

  • Отпускайте клавиши только после появления экрана загрузки — на разных прошивках окно короткое.
  • Проверьте, что клавиатура не в режиме блокировки (на desk phones с паролем admin).

Ссылки

Рубрика: Quick Tip, Snom | Метки: , | Оставить комментарий

Как использовать прокси в CentOS / RHEL

Опубликовано 8 октября, 2022 автором Sergey Bezpalov

Корпоративный прокси без единой точки настройки — каждый инструмент тянет пакеты сам. Ниже минимальный набор: переменные окружения для всех сессий и отдельные конфиги для dnf, curl и wget.

Формат URL прокси: всегда с протоколом, например http://proxy.example.com:3128/ или https://proxy.example.com:3128/.

Системные переменные (все пользователи)

Создайте /etc/profile.d/proxy.sh:

MY_PROXY_URL="http://proxy.example.com:3128/"

export HTTP_PROXY="$MY_PROXY_URL"
export HTTPS_PROXY="$MY_PROXY_URL"
export FTP_PROXY="$MY_PROXY_URL"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export ftp_proxy="$FTP_PROXY"
export NO_PROXY="localhost,127.0.0.1,.local"
export no_proxy="$NO_PROXY"

Примените в текущей сессии:

source /etc/profile.d/proxy.sh

dnf / yum

Добавьте в /etc/dnf/dnf.conf (или /etc/yum.conf на старых системах):

proxy=http://proxy.example.com:3128/

curl

Файл ~/.curlrc (или /etc/curlrc для всех):

proxy = http://proxy.example.com:3128/

wget

В /etc/wgetrc раскомментируйте или добавьте:

http_proxy = http://proxy.example.com:3128/
https_proxy = http://proxy.example.com:3128/
ftp_proxy = http://proxy.example.com:3128/

Проверка

Внешний IP должен совпадать с выходом прокси:

curl -s http://icanhazip.com
wget -qO- http://icanhazip.com

Если ответ — ваш прямой IP, прокси не подхватился: проверьте echo $HTTPS_PROXY и синтаксис URL.

Заметка

На RHEL 8+ с systemd некоторые сервисы игнорируют /etc/profile.d. Для unit-файлов задайте Environment=HTTP_PROXY=... в drop-in или используйте systemctl set-environment.

Рубрика: Linux, Quick Tip | Метки: | Оставить комментарий

Многофакторная авторизация Azure в среде Cisco и FortiGate

Опубликовано 26 мая, 2022 автором Sergey Bezpalov

VPN с одним паролем в 2022-м уже не проходил аудит — а прямой «FortiGate → Azure MFA» без промежуточного RADIUS-сервера в экосистеме Microsoft не существует. Рабочая схема, которую я разворачивал не раз: FortiGate как NAS, Cisco ISE как policy/RADIUS proxy, два Microsoft NPS с Azure MFA Extension, AD для первого фактора, Azure MFA для второго. Ниже — пошаговый runbook без воды.

Архитектура

Схема взаимодействия Cisco ISE и Azure MFA

Цепочка запросов:

  1. VPN-клиент отправляет credentials на FortiGate.
  2. FortiGate шлёт RADIUS Access-Request на Cisco ISE.
  3. ISE проксирует запрос на Microsoft NPS (можно зарегистрировать два NPS для HA).
  4. NPS проверяет логин/пароль в Active Directory (первичная аутентификация).
  5. NPS через Azure MFA Extension инициирует второй фактор; Azure MFA общается с пользователем напрямую (Authenticator, SMS, звонок).
  6. При успехе Access-Accept идёт обратно: NPS → ISE → FortiGate → клиент получает туннель.

Два NPS лучше ставить в разные ДЦ — если один падает, RADIUS продолжает работать через второй. На ISE оба регистрируются как external RADIUS servers.

Общая логика Azure MFA: документация Microsoft.

Что понадобится

Компонент Минимум
Azure AD Лицензии с MFA (или Security Defaults / P1/P2)
Windows Server 2× NPS в разных ДЦ (можно VM)
Cisco ISE PSN с RADIUS; лицензия Advantage или выше
FortiGate SSL-VPN или IPsec VPN, RADIUS client
Сеть FortiGate → ISE → NPS: UDP/1812 (auth), при accounting — 1813

Шаг 1. Azure AD и MFA

  1. В Azure Portal → Azure Active Directory → Security → MFA — включите MFA для нужных пользователей (per-user или через Conditional Access).
  2. Убедитесь, что учётные записи VPN-пользователей синхронизированы (Azure AD Connect) или созданы в cloud-only AD.
  3. Зарегистрируйте методы MFA (Microsoft Authenticator предпочтительнее SMS).

Без зарегистрированного метода второй фактор зависнет — пользователь получит reject или timeout.

Шаг 2. Microsoft NPS + Azure MFA Extension

На каждом сервере NPS (повторить на втором):

2.1. Роль NPS

Install-WindowsFeature NPAS -IncludeManagementTools

2.2. Azure MFA NPS Extension

  1. Скачайте NPS Extension for Azure MFA с сайта Microsoft.
  2. Установите на сервер NPS.
  3. Запустите конфигурацию от имени администратора:
cd 'C:\Program Files\Microsoft\Azure MFA\Config'
.\AzureMfaNpsExtn.ps1

Скрипт запросит credentials Azure AD (Global Admin или Application Admin) и зарегистрирует extension.

2.3. RADIUS clients (FortiGate / ISE)

В NPS → RADIUS Clients and Servers → RADIUS Clients добавьте:

Client Secret Назначение
IP Cisco ISE (PSN) общий secret ISE проксирует запросы от FortiGate
IP FortiGate (опционально) тот же или отдельный если ISE не проксирует, а FortiGate бьёт напрямую

В типовой схеме клиентом NPS является ISE, не FortiGate.

2.4. Политики NPS

  1. Connection Request Policies — разрешить запросы от ISE (Calling Station ID / Client Friendly Name).
  2. Network Policies — аутентификация через Windows Authentication (AD), grant access.
  3. В Azure MFA Extension registry (HKLM\SOFTWARE\Microsoft\AzureMfa) проверьте BypassMFADUoT и REQUIRE_USER_MATCH — для VPN обычно REQUIRE_USER_MATCH=1.

Перезапустите службу Network Policy Server после установки extension.

Шаг 3. Cisco ISE

3.1. External RADIUS servers (NPS)

Administration → Network Resources → External RADIUS Servers:

Поле Значение
Name NPS-DC1, NPS-DC2
Host IP каждого NPS
Shared Secret тот же, что в NPS RADIUS Clients
Authentication Port 1812
Timeout 30–60 сек (MFA!)
Connection Attempts 2–3

Добавьте оба сервера в RADIUS Server Sequence для failover.

3.2. Network Device (FortiGate)

Work Centers → Network Access → Network Devices:

  • Name: FGT-VPN
  • IP Address: management/source IP FortiGate для RADIUS
  • Shared Secret: secret для FortiGate ↔ ISE
  • Device Type: Fortinet:FortiGate

3.3. Policy Set

Создайте Policy Set для VPN/RADIUS:

  1. Conditions: Device IP Equals FGT-VPN (или RADIUS Service-Type).
  2. Authentication Policy → Use → External RADIUS Server Sequence (NPS).
  3. Authorization — профиль доступа (VLAN, dACL, или PermitAccess для VPN).

В Live Logs → RADIUS включите мониторинг до первого успешного логина.

Шаг 4. FortiGate

4.1. RADIUS server

config user radius
    edit "ISE-RADIUS"
        set server "10.x.x.x"
        set secret ENC <encrypted>
        set auth-type pap
    next
end

auth-type — pap или mschapv2 в зависимости от того, что принимает ISE/NPS. Для большинства VPN-клиентов MS-CHAPv2; если ISE настроен на PAP proxy — используйте PAP.

4.2. User group

config user group
    edit "VPN-RADIUS"
        set member "ISE-RADIUS"
    next
end

4.3. VPN portal / IPsec

VPN → SSL-VPN Settings (или IPsec tunnel):

  • Authentication/Portal Mapping или Peer Options → группа VPN-RADIUS.
  • Убедитесь, что клиент запрашивает username/password (не certificate-only, если MFA на user credentials).

Шаг 5. Таймауты — критично для MFA

По умолчанию FortiGate ждёт ответ RADIUS 5 секунд. Push в Authenticator занимает 15–60 секунд — без правки таймаута VPN стабильно падает с timeout.

Параметр remoteauthtimeout на FortiGate

GUI: System → Settings → remoteauthtimeout → 60–90 (диапазон 1–300, default 5).

CLI:

config system global
    set remoteauthtimeout 90
end

Согласуйте таймауты на всех звеньях:

Узел Параметр Рекомендация
FortiGate remoteauthtimeout 60–90 сек
Cisco ISE External RADIUS timeout ≥ 60 сек
NPS не ниже FortiGate default часто достаточен
VPN-клиент idle timeout не обрывать до завершения MFA

Проверка

  1. FortiGate: diagnose debug application radiusd -1 + diagnose debug enable — видны Access-Request/Accept.
  2. ISE: Live Log — запрос от FGT, proxy к NPS, result Accept/Reject.
  3. NPS: Event Viewer → Custom Views → Server Roles → Network Policy and Access Services.
  4. Azure: Sign-in logs — MFA requirement satisfied.

Тестовый сценарий: пользователь с зарегистрированным Authenticator → VPN login → push → Accept → туннель up.

Типовые проблемы

Симптом Куда смотреть
Timeout через ~5 сек remoteauthtimeout на FortiGate
Access-Reject без MFA NPS policy, AD credentials, extension не running
MFA не приходит пользователь не enrolled; проверьте Azure MFA Extension logs
ISE видит запрос, NPS — нет shared secret, firewall UDP/1812, wrong NAS IP
Работает через один NPS, второй — нет RADIUS Server Sequence priority, secret на втором NPS

Итог

Схема не самая короткая, зато переиспользует ISE как единую точку policy для VPN и проводного доступа, а Azure MFA остаётся там, где ему место — на NPS Extension. Главный практический вывод: увеличьте RADIUS timeout на FortiGate до 90 секунд до первого теста, иначе будете отладку MFA проводить вслепую.

Рубрика: Azure, Cisco, Fortinet, Microsoft, Office 365, Security | Метки: , , , , , , , , , , | Оставить комментарий