Где заканчивается VPN вашего сайта, решает, что именно проверяется

Туннель между площадками скрывает деталь, которая решает весь проект проверки: точное устройство, на котором внутренний пакет появляется в открытом виде. Всё до этой точки видит ESP, а всё после неё видит обычный IP, который может поймать правило. Поставьте границу не туда, и межсетевой экран, за который вы заплатили, превращается в маршрутизатор с лицензией. Разбор ниже сначала рисует линию и только потом спрашивает, какое устройство должно ею владеть.

Проведите линию там, где пакет перестаёт быть зашифрованным

В режиме туннеля исходный пакет шифруется и упаковывается в новый внешний заголовок IP, адресованный шлюзу партнёра. Этот внешний пакет несёт протокол 50 для ESP, поэтому любое устройство между двумя шлюзами может его маршрутизировать, не читая внутренние адреса. Первое устройство, которое расшифровывает, — это граница безопасности, и оно же первое, которое может применить политику к внутреннему потоку. Всё ниже этой точки — обычная маршрутизация.

Отметьте на схеме три вещи: внешнюю конечную точку, которая пропускает ESP, защищённые сети, названные в политике, и следующий переход, который совершает расшифрованный пакет. Если эти три не на одном устройстве, вам нужно проектировать передачу, а не единую точку контроля.

RFC 4301 называет расшифровывающее устройство шлюзом безопасности и рассматривает его политику как часть границы. Это более полезная рамка, чем категория продукта, потому что устройство является границей тогда, когда оно держит политику, а не тогда, когда в его спецификации написано «межсетевой экран».

Межсетевой экран как терминатор: одно устройство, одна точка политики

Когда межсетевой экран завершает туннель, вышестоящему маршрутизатору остаётся только доставить ему ESP. Экран проверяет подлинность партнёра, расшифровывает и затем применяет свои обычные правила к внутреннему пакету на пути к VLAN серверов. Так появляется одно место для чтения политики и одно место для чтения журналов, чего обычно и требует аудит.

Проверяйте два разрешения отдельно. Разрешить IKE и ESP к устройству — это не то же правило, что разрешить удалённой площадке добраться до сервера, и экран, который принимает туннель, блокируя внутренний поток, с дальнего конца выглядит в точности как сломанный туннель.

Цена в том, что экран теперь стоит на пути всего трафика площадки, поэтому его пропускная способность, лимиты сессий и поведение при отказе становятся поведением самого туннеля. Подбирайте его под суммарные потоки площадки, а не под профиль удалённого доступа, для которого его, возможно, купили.

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

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

Это та неисправность, которую нужно искать в существующей сети: два маршрута к одному префиксу, один через экран и один прямой, и прямой выигрывает по длине префикса или метрике. Туннель по-прежнему пропускает трафик, а проверки, в которую вы верите, не происходит.

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

Задайте обоим кандидатам одни и те же пять вопросов

Короткий опросный лист лучше матрицы функций, потому что каждый вопрос соответствует линии на схеме. Спросите каждого кандидата:

• Какие версии IKE, какие методы аутентификации партнёров и модели маршрутизации эта версия действительно поддерживает?
• Где допускается ESP и где разрешён или запрещён расшифрованный поток?
• Как локальные узлы узнают удалённые префиксы, а как противоположная сторона узнаёт ваши?
• Какую пропускную способность, число сессий и поведение при отказе должна выдерживать конечная точка при реальной нагрузке?
• Кто отвечает за учётные данные партнёра, политику и путь восстановления, когда сломано именно туннель?

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

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

Проверьте путь захватом, а не схемой

Схема описывает замысел, а захват описывает поведение, поэтому подтвердите, какой интерфейс несёт ESP, а какой — внутренний поток, прежде чем верить любому из них.

tcpdump -ni wan0 esp
tcpdump -ni lan0 host 10.60.4.20
ip xfrm policy list

Если первый захват показывает приходящий ESP, а второй — внутренний пакет на стороне LAN, точка расшифровки там, где вы думаете. Если внутренний пакет появляется на сегменте в обход экрана, маршрутизация неверна, что бы ни говорил текст политики. Список xfrm тогда показывает, какие селекторы установлены и в каком направлении.

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