L2TP/IPsec через NAT: что на самом деле ломается и почему

Утверждение, что NAT ломает L2TP/IPsec, верно наполовину и потому бесполезно. Трансляция адресов — это нормально, NAT traversal существует именно для того, чтобы её пережить, и миллионы клиентов ежедневно подключаются из-за роутера. Ломается конкретный этап конкретного обмена: IKE не получает ответа, инкапсулированный туннель отбрасывается политикой, разрешающей только один протокол, или сопоставление трансляции истекает, пока туннель простаивает. Когда вы знаете, на каком вы этапе, исправление обычно сводится к одному правилу или keepalive, а не к новой схеме VPN.

Миф — это неправильный вопрос

Полезный вопрос не «ломает ли это NAT», а «какая часть обмена транслируется и что делает с ней устройство, выполняющее трансляцию». L2TP/IPsec — многоуровневый протокол: IKE ведёт переговоры, ESP защищает, а L2TP несёт PPP внутри этой защиты. Трансляция адресов по-разному влияет на каждый уровень, и признаки сбоя можно различить, если смотреть на этап переговоров, а не на окно ошибки.

Роутер, который успешно работает в вебе, доказывает лишь то, что TCP с трансляцией порта источника работает. Он ничего не говорит о UDP 500, UDP 4500 или протоколе 50, а именно от этих трёх вещей зависит данное развёртывание.

Этап 1: IKE вообще должен получить ответ

Первый обмен идёт к отвечающей стороне на UDP 500. Если ответ не приходит, остальное не важно: предварительно разделённый ключ, предложение и учётные данные остаются непрочитанными. Следите за запросом и ответом, а не делайте вывод из тайм-аута клиента:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

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

ESP — это IP-протокол, а не порт TCP или UDP, и обычная трансляция адресов портов не имеет поля порта, которое можно переписать. Поэтому NAT traversal переносит защищённую полезную нагрузку в UDP 4500: инкапсуляция даёт транслирующему устройству то, что оно умеет транслировать. Как только это происходит, правило межсетевого экрана, написанное только для UDP 500, разрешит переговоры и отбросит туннель, что даёт запутанный результат: журнал показывает успешную фазу 1 и никакого трафика.

Сам обмен IKE тоже может перейти на UDP 4500 после обнаружения NAT, что удивляет тех, кто разрешил 500 и ничего больше. Разрешите оба порта в обе стороны на пути и помните, что межсетевой экран с состоянием удерживает поток только пока видит трафик.

Протокол 50 по-прежнему важен на путях без трансляции и на путях, где промежуточное устройство настроено его разрешать. Если вы диагностируете исключением, отключите гипотезу, а не добавляйте правила пачками: разрешите 500, 4500 и ESP, убедитесь, что туннель поднимается, а затем удалите то, что оказалось лишним. Правило, которое никто не может объяснить, — это правило, которое никто не удалит, когда оно станет причиной следующего сбоя. Запишите сужение в журнал изменений вместе с этапом, который оно исправило, чтобы следующий инженер начинал с ваших доказательств, а не с того же эмпирического правила.

Этап 3: сопоставление истекает, и туннель умирает

Транслирующее устройство хранит состояние для пересылаемых потоков, и у этого состояния есть время жизни. Туннель L2TP/IPsec передаёт мало трафика, когда им никто не пользуется, поэтому простаивающий туннель может пережить своё сопоставление и перестать получать обратный трафик. Клиент остаётся уверен, что подключён, сервер ничего не видит, и первый симптом обычно — тайм-аут приложения, а не ошибка VPN.

Обнаружение мёртвого партнёра и keepalive NAT существуют именно для этого, и обе стороны должны быть готовы их отправлять. Если ваш сервер находится за трансляцией, требование на стороне Windows — это документированный параметр реестра, который заставляет сервер предполагать инкапсуляцию UDP для своих исходящих пакетов; без него отвечающая сторона отправляет ESP, которое транслирующее устройство не может сопоставить обратно. Это вопрос настройки сервера, а не клиента.

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

Хостинг за NAT оператора — это другая проблема

Если вы хотите разместить сервер L2TP/IPsec дома и достучаться до него снаружи, требуется незапрошенная входящая достижимость, и это не то, что даёт NAT traversal. NAT оператора перед вашим роутером означает, что нет порта, который можно пробросить и стать достижимым, потому что публичный адрес общий, а сопоставление только исходящее.

Никакой флажок IPsec pass-through этого не меняет, и никакая настройка клиента это не компенсирует. Поддерживаемые ответы — это действительно достижимый адрес, размещённая конечная точка или архитектура, в которой каждый участник устанавливает исходящее соединение. Спецификация инкапсуляции UDP решает проблему трансляции для существующих потоков; она не создаёт входящий путь там, где оператор его не предлагает.

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