Split tunneling под нагрузкой: переключаем четырёх клиентов с full-tunnel на раздельную маршрутизацию

После того как в начале марта мы разбирались с перегрузкой VPN-концентраторов, стало понятно: лицензии расширили, железо добавили, но трафик всё равно продолжает расти. Потому что дело уже не только в числе сессий - дело в том, что через корпоративный VPN теперь идёт весь трафик: Teams, Zoom, YouTube, Windows Update, облачные диски, браузерные вкладки с котиками. Всё это до единого байта транзитирует через офисный интернет-канал, который проектировался под сотню человек в офисе, а не под пятьсот дома.

Следующий очевидный шаг - split tunneling. Через тоннель гоним только то, что реально должно идти через тоннель: корпоративные подсети, внутренние сервисы, AD-трафик. Всё остальное - напрямую с домашнего интернета пользователя.

У нас сейчас четыре клиента в очереди на этот переход. Прошли через все четыре - фиксируем что из этого вышло.

Почему full-tunnel вообще был включён

У каждого клиента была своя историческая причина. У одного - требование ИБ-отдела: «весь трафик должен фильтроваться через корпоративный прокси», принятое несколько лет назад. У другого - default-настройка вендора, которую никто не трогал при внедрении. У третьего - compliance-требование: запись интернет-трафика сотрудников через DLP. У четвёртого - искреннее убеждение что так безопаснее.

Реальные последствия удалёнки заставили пересмотреть каждую из этих позиций. Когда полоса на шлюзе 500 Мбит/с, а суммарный трафик 300 подключённых сотрудников начинает упираться в этот потолок - разговор про YouTube через корпоративный прокси становится очень конкретным.

Что пошло через тоннель, что нет

Первый и главный вопрос при проектировании split tunneling - граница: что включить в корпоративный маршрут. Ответ у каждого клиента свой, но логика одинаковая.

В тоннель идут: корпоративные подсети (RFC 1918, но конкретные диапазоны клиента), маршруты до внутренних сервисов - AD, DNS, файловые серверы, ERP, внутренние сайты на corp-домене, почтовые серверы если on-premise. Туда же - если есть - маршруты до партнёрских сетей через site-to-site VPN.

Напрямую идёт всё остальное: публичный интернет целиком. Teams и Zoom работают через домашний канал пользователя, Microsoft 365 - тоже, Windows Update - тоже.

Отдельный вопрос - DNS. В full-tunnel режиме DNS-резолвер обычно тоже корпоративный, и split DNS (разные ответы для внутренних и внешних имён) работал автоматически. При split tunneling нужно явно настроить: DNS-суффиксы корпоративного домена резолвятся через корпоративный DNS (через тоннель), всё остальное - через публичный резолвер или ISP. Если это не настроить - пользователи не смогут ходить на внутренние ресурсы по имени. Забывают об этом примерно в половине случаев при самостоятельной настройке.

Как настраивали на практике

Три из четырёх клиентов - на Cisco AnyConnect с ASA или FTD. Четвёртый - FortiClient с FortiGate.

AnyConnect / ASA - Group Policy. Split tunneling настраивается в Group Policy через атрибуты split-tunnel-policy и split-tunnel-network-list. Создаём ACL со списком корпоративных подсетей, в политике группы указываем режим tunnelspecified и ссылаемся на этот ACL. Клиент получает маршруты при подключении автоматически. Изменение применяется без переустановки клиента - только переподключение сессии.

Для Split DNS в AnyConnect: в той же Group Policy атрибут split-dns с перечислением DNS-суффиксов. Суффиксы corp.example.ru, example.local - через корпоративный DNS, остальное - наружу.

FortiClient / FortiGate. Здесь split tunneling - это галочка в SSL VPN Portal: Enable Split Tunneling. Маршруты задаются в разделе Routing Address - список адресов/подсетей которые пойдут через тоннель. DNS настраивается отдельно в том же портале.

На FortiGate оказалась интересная особенность: при включении split tunneling перестал работать доступ к ресурсам в DMZ одного из клиентов. Оказалось - маршрут до DMZ-подсети был унаследован от default route в full-tunnel режиме и не попал в явный список. Добавили подсеть DMZ - всё заработало. Вот почему при составлении списка маршрутов важно не просто взять «корпоративные RFC 1918 подсети», а пройтись по реальной топологии сети и включить всё что нужно.

ИБ-вопрос: что потеряли

Это вопрос который ИБ-отделы задают первым, и правильно делают. При full-tunnel трафик пользователя проходил через корпоративный прокси с контентной фильтрацией, DLP, логированием. При split tunneling всё что идёт напрямую - невидимо для корпоративных средств контроля.

Честный ответ: да, часть видимости потеряна. Что с этим делать - зависит от требований клиента.

У клиента с DLP-требованием мы пошли на компромисс: через тоннель гонятся не только корпоративные подсети, но и облачные сервисы где хранятся чувствительные данные (SharePoint Online, корпоративный OneDrive, внутренняя CRM в облаке). Для этого добавили в маршруты IP-диапазоны этих сервисов - не самое элегантное решение, потому что IP Microsoft меняются, но на период карантина - рабочий вариант. Публичный же трафик (новостные сайты, YouTube, прочее) из DLP-охвата выпал, и это было явно задокументировано и согласовано с клиентом.

У клиента с требованием «весь трафик через прокси» решили иначе: поставили Cisco Umbrella (DNS-based filtering) на конечные устройства. Политики фильтрации работают независимо от того идёт трафик через VPN или нет, потому что применяются на уровне DNS до установки соединения. Не стопроцентная замена прокси, но основные угрозы - фишинг, malware domains, категорийная фильтрация - покрывает.

Мониторинг после переключения

После включения split tunneling неизбежно посыпятся заявки «у меня что-то не работает». Нужно понимать быстро: это следствие изменения маршрутизации или что-то несвязанное.

Полезные вещи которые настроили:

• Логи AnyConnect - при подключении клиент пишет полученные маршруты. Если пользователь жалуется что не может попасть на внутренний ресурс - первый шаг смотреть лог AnyConnect: получил ли маршрут до нужной подсети.
• Мониторинг загрузки шлюза - именно ради этого всё затевалось. Throughput на ASA/FortiGate должен упасть ощутимо. Если не упал - значит что-то не так с конфигурацией или пользователи не переподключились.
• Тестовые пользователи перед массовым переключением. У всех четырёх клиентов сначала переводили одну-две тестовые учётки, прогоняли по списку внутренних ресурсов, и только потом катили на всех.

Результат

Нагрузка на шлюзы после переключения упала заметно у всех четырёх клиентов - у кого-то в разы, у кого-то не так драматично (зависит от того насколько у них сотрудники были «интернет-тяжёлыми» в рабочее время). Жалоб на недоступность внутренних ресурсов после первого дня не осталось - все маршруты закрыли.

Управляем этим в рамках managed-сопровождения, так что изменения в топологии сети добавляем в маршруты централизованно - клиентам не нужно думать об этом самим.

Интереснее вопрос с ИБ-компромиссами: у двух клиентов из четырёх разговор про Umbrella или аналог переходит из теоретического в практический. Раньше прокси закрывал тему, теперь нужно что-то на эндпоинте. Это отдельная работа, но в условиях карантина - пока в приоритете «работает», а «защищено как раньше» - следующий шаг.