Почему трафик филиалов тормозит через ЦОД и как исправить это с помощью Identity‑First
Классическая корпоративная сеть строится по иерархической схеме: Access → Distribution → Core → Firewall → Internet. Такая модель долгое время оставалась удобной и предсказуемой: филиалы передавали трафик в центральный офис, а там единая система безопасности проверяла соединения и выпускала их в интернет.
Однако облачные приложения, SaaS-сервисы, удалённая работа и распределённая инфраструктура сделали этот подход менее эффективным. Сегодня маршрут всё чаще определяется не только IP-адресом назначения, но и тем, кто именно инициировал соединение, к какому приложению он обращается и какие политики применяются к его учетной записи. Такой подход называют Identity‑First.
Рассмотрим типичную ситуацию. У компании есть центральный офис в Москве, где расположен основной межсетевой экран и организован выход в интернет. Филиал находится в Екатеринбурге. Когда сотрудник филиала обращается к облачному сервису, его трафик сначала проходит через корпоративный канал до Москвы, затем обрабатывается центральным firewall и только после этого выходит в интернет.
При задержке около 35 мс между Екатеринбургом и Москвой полный путь туда и обратно занимает примерно 70 мс. С учетом обработки на межсетевом экране итоговая задержка может достигать 80 мс - для обычного веб-сервиса это еще приемлемо. Но после включения SSL-инспекции ситуация меняется: дополнительное расшифрование, проверка и повторное шифрование трафика увеличивают задержку примерно до 150 мс. В результате облачные приложения начинают заметно "подвисать", а интерактивные системы реагируют с задержкой.
Почему прямой обход firewall не решает проблему
Очевидная идея - отправить трафик к облачным ресурсам напрямую из филиала с помощью Policy-Based Routing. Для этого создают отдельный access-list, выделяют адреса нужных сервисов и направляют их в локальный интернет-шлюз.
На практике такой вариант часто нарушает симметрию соединения. Запрос пользователя может выйти напрямую из Екатеринбурга, а ответ вернуться другим маршрутом - например, через центральный офис или другой интернет-канал. Следующий пакет той же сессии снова может пойти через Москву.
Для stateful firewall это означает, что устройство видит только часть соединения. Таблица состояний перестает соответствовать реальному прохождению пакетов, возникают сбросы сессий, проблемы с NAT и нестабильная работа приложений. Чтобы компенсировать ситуацию, администраторы ослабляют проверки обратного пути, включая Unicast Reverse Path Forwarding в режиме loose. Но это увеличивает поверхность атаки и усложняет контроль маршрутов.
Иными словами, прямой интернет без изменения общей архитектуры способен устранить задержку, но одновременно создать проблемы с безопасностью, диагностикой и отказоустойчивостью.
От туннелирования всего трафика к передаче политик
Ключевой вопрос заключается в следующем: действительно ли весь пользовательский трафик необходимо вести через ЦОД?
Во многих случаях в центр нужно передавать не сами данные, а политику доступа и контекст пользователя. Для этого можно использовать SD-WAN Fabric совместно с ZTNA. Агент на рабочей станции устанавливает защищенный туннель не до московского офиса, а до ближайшей точки присутствия провайдера - например, до PoP в Казани.
Вместо того чтобы принимать решения исключительно по IP-адресу, пограничный узел учитывает:
- идентификатор пользователя;
- сертификат и его поле SAN;
- группу в каталоге;
- тип устройства;
- состояние endpoint;
- категорию приложения;
- требования к инспекции и журналированию.
Такой подход позволяет разделить маршруты по смыслу трафика. Если приложение имеет метку `SaaS-FastPath`, соединение выпускается в интернет непосредственно из ближайшего PoP. Если сервис относится к категории `Corporate-Critical`, например SAP или внутренняя база данных, трафик передается через защищенный IPsec-туннель в ЦОД, но не обязательно проходит через тот же перегруженный периметровый firewall. Он может направляться непосредственно к нужному сервисному сегменту или Service Mesh.
В результате пользователи получают короткий маршрут к облачным ресурсам, а критичные внутренние приложения сохраняют централизованный контроль.
Как может выглядеть реализация на PoP
Для построения тестового PoP можно использовать Linux-хост, FRRouting и nftables. Агент на рабочей станции маркирует потоки, например через cgroups или собственный механизм классификации. На шлюзе эти метки используются для выбора отдельной таблицы маршрутизации.
Условная логика принятия решения выглядит так:
```python
from pyroute2 import IPRoute
ip = IPRoute()
def select_route(app_tag):
if app_tag == "SaaS-FastPath":
return 100
if app_tag == "Corporate-Critical":
return 200
return 300
```
В реальной системе дополнительно проверяются пользователь, устройство, сертификат, время доступа и состояние защитных средств. После классификации пакет попадает в соответствующую таблицу:
- таблица 100 - локальный выход в интернет;
- таблица 200 - туннель в ЦОД;
- таблица 300 - карантинный или ограниченный маршрут.
На практике решение может реализовываться через nftables marks, policy routing, VRF и динамически обновляемые правила. Важно, что маршрутизация становится следствием политики, а не набором статических исключений.
DNS как элемент управления маршрутом
В такой архитектуре DNS превращается из обычного справочного сервиса в важный компонент сетевой политики. Вместо единственного DNS-сервера в центральном офисе филиалам предоставляют локальный кеширующий резолвер - например, CoreDNS или dnsmasq. Он взаимодействует с центральным контроллером политик и учитывает расположение пользователя, тип устройства и назначение запроса.
Для разных категорий сервисов DNS может возвращать разные адреса:
- локальный адрес ближайшего PoP;
- адрес корпоративного прокси;
- внутренний адрес приложения;
- специальную точку входа для ZTNA;
- адрес сервиса, доступный только через защищенный туннель.
Пример базовой конфигурации CoreDNS может выглядеть так:
```text
.:53 {
log
errors
cache 30
view branch {
expr incidr(client_ip, 10.20.0.0/16)
forward . 10.20.10.10
}
view corporate {
expr incidr(client_ip, 10.30.0.0/16)
forward . 10.30.10.10
}
}
```
DNS не заменяет полноценную маршрутизацию и контроль доступа, но помогает выбрать правильную точку входа. Основные гарантии безопасности должны оставаться на уровне туннеля, identity-политик и проверки состояния устройства.
Что происходит при отказе PoP
Распределенная архитектура требует заранее продумать отказоустойчивость. Если ближайший PoP становится недоступен, агент должен автоматически переключиться на резервную точку. При этом важно сохранить состояние активных соединений, иначе пользователи столкнутся с массовым разрывом сессий.
Для этого применяются:
- два PoP в разных площадках;
- anycast или управляемые DNS-ответы;
- синхронизация таблиц состояний;
- короткие интервалы обнаружения отказа;
- резервные туннели;
- повторная аутентификация без участия пользователя.
Если сохранение stateful-сессии невозможно, следует обеспечить быстрый и предсказуемый повторный запуск соединения. Особенно это важно для видеоконференций, терминальных сессий и долгих TCP-подключений.
SSL-инспекция без лишней деградации
Полная расшифровка всего HTTPS-трафика в центральном ЦОД создает значительную нагрузку. Помимо задержки, возникают требования к производительности криптографических модулей, хранению журналов и обработке исключений.
В Identity‑First-модели SSL-инспекцию можно распределить по точкам присутствия и применять только там, где это оправдано политикой. Например, финансовые системы и неизвестные категории сайтов проверяются полностью, а доверенные корпоративные SaaS-платформы проходят через облегченный контроль.
При этом необходимо учитывать:
- сертификаты и доверенные центры;
- приложения с certificate pinning;
- персональные данные;
- требования законодательства;
- исключения для медицинских и платежных сервисов;
- корректное журналирование решений.
Инспекция не должна превращаться в универсальный механизм, который одинаково обрабатывает весь трафик независимо от риска.
Почему важен именно идентификатор пользователя
IP-адрес описывает точку подключения, но почти ничего не говорит о контексте доступа. Один и тот же адрес может использоваться несколькими сотрудниками с разными полномочиями, а ноутбук пользователя способен перемещаться между филиалом, домом и публичной сетью.
Identity‑First учитывает более точные признаки:
- учетную запись;
- роль и принадлежность к группе;
- устройство и его соответствие требованиям;
- способ аутентификации;
- уровень доверия к сессии;
- конкретное приложение;
- время и географию подключения.
Это позволяет отказаться от чрезмерно широких сетевых разрешений. Пользователю предоставляется доступ не "в подсеть", а к конкретному приложению на основании подтвержденной личности и текущего контекста.
Контроль и наблюдаемость
Распределение маршрутов между PoP, ЦОД и прямым интернетом усложняет диагностику. Поэтому необходимо централизованно собирать:
- решения policy engine;
- DNS-запросы и ответы;
- события установления туннелей;
- изменения маршрута;
- данные об отказах и переключениях;
- сведения о пользователе и устройстве;
- результаты SSL-проверок.
Журналы должны связывать сетевое событие с конкретной учетной записью и приложением. Тогда специалист видит не просто запись "соединение с IP-адресом разорвано", а понятную цепочку: пользователь, устройство, политика, выбранный PoP, причина отказа и конечный сервис.
Как переходить к новой архитектуре
Полностью перестраивать сеть за один этап рискованно. Рациональнее начать с пилотной зоны:
1. выбрать один филиал и ограниченный набор SaaS-приложений;
2. определить базовые задержки и показатели отказов;
3. установить агент на тестовые устройства;
4. развернуть два PoP;
5. настроить классификацию приложений;
6. включить локальный выход только для низкорисковых сервисов;
7. проверить работу резервных маршрутов;
8. сравнить результаты с централизованной схемой.
После этого можно постепенно расширять перечень приложений и пользователей. Критичные корпоративные системы при этом оставляют на прежнем маршруте до завершения тестирования.
Итог
Проблема медленного трафика филиалов возникает не только из-за пропускной способности каналов. Часто ее причина - архитектура, в которой весь трафик принудительно проходит через центральный ЦОД, даже если конечный сервис находится в облаке рядом с пользователем.
Попытка исправить это отдельными PBR-правилами способна нарушить симметрию маршрутов, состояние firewall и требования безопасности. Более устойчивый вариант - перенести принятие решений на уровень идентичности, приложения и контекста.
В Identity‑First-модели агент направляет трафик к ближайшему PoP, локальный DNS помогает выбрать нужную точку входа, а policy engine определяет дальнейший маршрут. Облачные приложения получают короткий путь, внутренние сервисы сохраняют контролируемый доступ, а безопасность перестает зависеть только от IP-адресов и статических маршрутов.