Трафик VPN-клиента и состояние межсетевого экрана: внешний и внутренний поток

Рукопожатие VPN завершается, клиент получает адрес, а служба за шлюзом по-прежнему отклоняет соединение. Межсетевой экран часто делает ровно то, что ему велено. Он разрешил внешний поток туннеля, а это другой пакет, нежели декапсулированное соединение приложения. Отсюда два решения: какой поток вы разрешаете и отслеживает ли граница состояние вообще.

Пока вы не разделите эти две вещи, любое изменение правила — догадка.

Межсетевой экран видит два разных пакета

До декапсуляции межсетевой экран видит трафик, адресованный конечной точке VPN: внешний поток UDP к слушателю. После декапсуляции пересылаемый пакет несёт внутренний адрес клиента и назначение службы.

Разрешение для внешнего потока не даёт прав на пересылаемое соединение TCP. Их могут оценивать в разных цепочках, на разных интерфейсах и с разными адресами после трансляции.

Сравните захваты из равноценных позиций с обеих сторон. Захват на краю туннеля и захват на сервере показывают разные кортежи для одного и того же сеанса.

Первое решение: разрешить туннель или службу

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

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

Запишите оба правила отдельно. Правило туннеля и правило службы отказывают по-разному и отлаживаются разными доказательствами. Когда одно отказывает, вы знаете, какой уровень проверять первым.

Второе решение: с отслеживанием состояния или без него на каждой границе

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

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

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

Проверьте обратный путь при той же политике

Отправьте новый запрос от клиента к службе, затем проверьте счётчики прямого и обратного направления на каждой границе. Убедитесь, что ответ идёт по ожидаемому пути, особенно если задействована трансляция.

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