Настройка VPN за NAT: практические сценарии и решения

Зачем нужен NAT и почему он мешает VPN

NAT (Network Address Translation) — это механизм, который позволяет нескольким устройствам в локальной сети использовать один публичный IP-адрес. Он повсеместно применяется в домашних роутерах, офисных маршрутизаторах и у провайдеров. Однако NAT создает серьезные препятствия для VPN-соединений, особенно для входящих подключений.

Когда VPN-сервер находится за NAT, внешние клиенты не могут напрямую инициировать соединение, потому что публичный IP-адрес принадлежит NAT-устройству, а не самому серверу. Для протоколов вроде IPSec, которые используют несколько портов и протоколов, проблема усугубляется: кроме стандартного UDP-порта 500 для IKE, нужны протоколы ESP (IP-протокол 50) и AH (IP-протокол 51), а также UDP-порт 4500 для NAT-Traversal (NAT-T).

Понимание того, как NAT взаимодействует с VPN, — первый шаг к правильной настройке. В этой статье мы рассмотрим типичные сценарии: офисные сети за NAT-маршрутизатором, домашние серверы за провайдерским NAT и облачные VPN-шлюзы, где NAT используется для разрешения конфликтов адресов.

Основы IPSec и NAT-Traversal

IPSec — это набор протоколов для защиты IP-трафика. Он работает в двух фазах: фаза 1 (IKE) устанавливает защищенный канал и аутентифицирует стороны, фаза 2 создает туннель для данных. Для этого используются UDP-порт 500 (IKE) и протоколы ESP/AH.

Проблема в том, что NAT изменяет IP-адреса и порты, что нарушает целостность IPSec-пакетов. ESP, например, не имеет портов и шифрует весь пакет, поэтому NAT не может корректно транслировать его без специальных механизмов. Для решения этой проблемы был разработан NAT-Traversal (NAT-T).

NAT-T инкапсулирует ESP-пакеты в UDP-дейтаграммы с портом 4500, что позволяет им проходить через NAT. При этом IKE-пакеты также переносятся на порт 4500 после обнаружения NAT. Для работы NAT-T необходимо, чтобы на NAT-устройстве были открыты UDP-порты 500 и 4500, а также разрешен протокол ESP (IP-протокол 50) и AH (IP-протокол 51), если он используется.

Большинство современных VPN-устройств поддерживают NAT-T автоматически, но иногда его нужно включить вручную. Например, на межсетевых экранах Zyxel USG обход NAT включен по умолчанию, но на удаленном устройстве эта опция должна быть активирована тоже.

Типы NAT и их влияние на VPN

Не все NAT одинаковы. Разные типы NAT по-разному обрабатывают входящие соединения, что критически важно для VPN. Различают:

Full Cone NAT — внешний адрес и порт фиксированы, и любой внешний хост может отправить пакет на этот адрес. Это идеальный вариант для VPN-сервера.
Restricted Cone NAT — принимает пакеты только от тех внешних хостов, которым устройство само отправляло пакеты.
Port Restricted Cone NAT — похож на Restricted, но также проверяет порт источника.
Symmetric NAT — для каждого нового соединения создается уникальное сопоставление адресов и портов, что делает невозможным прием входящих подключений без предварительной отправки пакета.

Для организации VPN-сервера за NAT наиболее благоприятен Full Cone NAT. Symmetric NAT, напротив, почти всегда требует использования промежуточного сервера с публичным IP (VPS) или технологии UDP hole punching.

Определить тип NAT можно с помощью STUN-клиента. Например, на роутере с OpenWRT команда stun stun.sipnet.ru покажет характеристики NAT. Если в выводе указано "Independent Mapping" и "Independent Filter", это Full Cone NAT — хорошая новость для VPN.

Настройка IPSec Site-to-Site VPN за NAT-маршрутизатором

Рассмотрим классический сценарий: два офиса, каждый за своим NAT-маршрутизатором, нужно соединить их VPN-туннелем. В качестве примера возьмем межсетевые экраны Zyxel USG, но принципы применимы к любому оборудованию.

На каждом устройстве создается правило Site-to-Site VPN с помощью мастера настройки. В мастере указываются:

Имя правила (1-31 буквенно-цифровой символ, чувствительно к регистру).
IP-адрес защищенного шлюза — это публичный IP-адрес удаленного офиса (WAN).
Pre-Shared Key (PSK) — общий секретный ключ длиной 8-32 символа.
Локальная политика — диапазон IP-адресов локальной сети.
Удаленная политика — диапазон IP-адресов удаленной сети.

После создания правила важно настроить Peer ID Type как Any, чтобы устройство не проверяло идентификатор удаленного пира — это упрощает соединение за NAT.

Далее на NAT-маршрутизаторе, который стоит перед межсетевым экраном, необходимо настроить проброс портов и протоколов:

UDP-порт 500 — для IKE.
UDP-порт 4500 — для NAT-T.
IP-протокол 50 (ESP) — для данных.
IP-протокол 51 (AH) — если используется.

В интерфейсе Zyxel это делается через раздел Configuration > Network > NAT, где создается правило для входящего интерфейса с указанием оригинального IP и транслируемого адреса назначения. Также нужно убедиться, что политики безопасности разрешают VPN-трафик.

Проверка и устранение неполадок IPSec-туннеля

После настройки VPN-туннеля необходимо проверить его работоспособность. В Zyxel USG это делается в разделе Configuration > VPN > IPSec VPN > VPN Connection, где можно нажать кнопку Connect. Если статус показывает connected, туннель установлен.

Дополнительно можно проверить счетчики входящих и исходящих байтов в Monitor > VPN Monitor > IPSec. Если трафик идет, туннель работает.

Самый простой тест — выполнить ping с компьютера в одном офисе на компьютер в другом. Например, с ПК за ZyWALL/USG в штаб-квартире: ping 192.168.20.33.

Если туннель не устанавливается, проверьте:

Одинаковые ли настройки фазы 1 на обоих устройствах: PSK, алгоритмы шифрования, метод аутентификации, группа Диффи-Хеллмана, тип ID.
Одинаковые ли настройки фазы 2: протокол, инкапсуляция, шифрование, аутентификация, PFS.
Разрешают ли политики безопасности трафик IPSec (UDP 500, UDP 4500, ESP, AH).
Включен ли NAT-T на обоих устройствах.

В журналах устройства (Monitor > Log) можно увидеть сообщения об ошибках. Если фаза 1 завершена, но фаза 2 не устанавливается, проблема скорее всего в несоответствии политик фазы 2.

VPN-сервер за провайдерским NAT: обход без белого IP

Домашние пользователи часто сталкиваются с ситуацией, когда провайдер использует NAT (CGNAT), и получить белый IP-адрес невозможно или дорого. Тем не менее, можно организовать VPN-сервер, если тип NAT позволяет.

В статье на Хабре описан эксперимент, где автору удалось запустить OpenVPN-сервер за провайдерским NAT. Ключевым моментом было использование STUN-клиента для определения внешнего IP-адреса и порта, а также поддержание UDP-сессии с помощью собственного OpenVPN-клиента.

Алгоритм выглядит так:

Запустить STUN-клиент на локальном порту (например, 11111), чтобы узнать внешний IP и порт.
Отправить эти данные себе на почту или через другой сервис.
Запустить OpenVPN-сервер, слушающий тот же порт.
Запустить OpenVPN-клиент на том же компьютере, подключившись к внешнему адресу — это создаст и поддержит UDP-сессию в NAT.
С любого другого устройства (например, смартфона) подключиться к этому же внешнему адресу и порту.

Этот метод работает только при определенных типах NAT — как минимум Full Cone или Restricted Cone. Если NAT симметричный, такой трюк не сработает. В статье отмечается, что на LTE-модеме с Port Dependent Filter запустить систему не удалось.

Для автоматизации процесса автор написал скрипт, который периодически определяет внешний адрес, запускает сервер и отправляет уведомление по почте. Это позволяет поддерживать VPN-доступ к домашней сети без аренды VPS.

Использование NAT для разрешения конфликтов IP-адресов в VPN

В корпоративных сетях часто возникает проблема перекрывающихся IP-подсетей. Например, две ветви используют диапазон 10.30.0.0/24, и при подключении к центральному офису возникает конфликт маршрутов. В таких случаях применяется NAT на VPN-шлюзе.

Microsoft Azure Virtual WAN предоставляет возможность настройки статических и динамических правил NAT для VPN-шлюза. Это позволяет преобразовывать IP-адреса до того, как трафик попадет в туннель, устраняя конфликты.

Статический NAT использует фиксированное сопоставление "один к одному": например, 10.30.0.0/24 преобразуется в 172.30.0.0/24. Это просто и предсказуемо, но требует, чтобы размеры подсетей совпадали.

Динамический NAT (или NAPT) позволяет нескольким внутренним адресам использовать меньший пул внешних адресов, назначая порты динамически. Это более гибко, но требует, чтобы трафик инициировался из внутренней сети, и не подходит для BGP-пиринга, если IP-адрес пира попадает в диапазон NAT.

В Azure Virtual WAN правила NAT настраиваются в параметрах VPN-шлюза. Можно задать режим IngressSnat (для входящего трафика) или EgressSnat (для исходящего). Также есть опция Enable BGP Translation, которая автоматически объявляет преобразованные префиксы через BGP, упрощая настройку маршрутизации.

Практические примеры настройки NAT-правил в Azure Virtual WAN

Рассмотрим два примера из документации Microsoft Azure.

Пример 1: Две ветви с одинаковыми подсетями, BGP.

Есть две ветви (Site1 и Site2) с адресным пространством 10.30.0.0/24. Чтобы подключить их к Azure, для Site1 создается статическое правило NAT:

Имя: ingressRule01
Тип: статический
Режим: IngressSnat
Внутреннее сопоставление: 10.30.0.0/24
Внешнее сопоставление: 172.30.0.0/24
Подключение: Link A

Включается BGP Translation. При этом IP-адрес BGP-пира на локальном устройстве должен быть изменен на адрес из внешнего сопоставления (например, 172.30.0.132 вместо 10.30.0.132).

Пример 2: Без BGP, статическая маршрутизация.

Если ветвь не использует BGP, то после создания правила NAT необходимо вручную изменить Private Address Space для VPN-сайта на диапазон после NAT (172.30.0.0/24). Это нужно, чтобы VPN-шлюз знал, куда направлять трафик.

В обоих случаях важно помнить: для статического NAT размеры подсетей должны совпадать, а для динамического NAT IP-адрес BGP-пира не должен входить в диапазон до NAT.

Часто задаваемые вопросы о VPN и NAT

В этом разделе собраны ответы на типичные вопросы, возникающие при настройке VPN за NAT.

Вопросы и ответы

Что такое NAT-Traversal и зачем он нужен для VPN?

NAT-Traversal (NAT-T) — это расширение протокола IPSec, которое позволяет ESP-пакетам проходить через NAT-устройства. NAT изменяет IP-адреса и порты, что нарушает целостность IPSec-пакетов. NAT-T инкапсулирует ESP в UDP-пакеты с портом 4500, что делает их совместимыми с NAT. Без NAT-T IPSec-туннель не сможет установиться, если одна из сторон находится за NAT.

Какие порты и протоколы нужно пробросить для IPSec VPN?

Для работы IPSec VPN необходимо разрешить на NAT-устройстве:

UDP-порт 500 — для IKE (фаза 1).
UDP-порт 4500 — для NAT-T (инкапсуляция ESP).
IP-протокол 50 (ESP) — для передачи данных.
IP-протокол 51 (AH) — если используется AH (редко).

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

Можно ли запустить VPN-сервер за провайдерским NAT без белого IP?

Да, в некоторых случаях можно. Если ваш провайдер использует NAT типа Full Cone или Restricted Cone, вы можете определить внешний IP-адрес с помощью STUN и поддерживать UDP-сессию, отправляя пакеты наружу. Например, можно запустить OpenVPN-клиент на том же компьютере, что и сервер, чтобы открыть порт в NAT. Однако при симметричном NAT это не сработает — потребуется VPS или облачный сервис.

В чем разница между статическим и динамическим NAT для VPN?

Статический NAT использует фиксированное сопоставление "один к одному" между внутренними и внешними адресами. Он прост и предсказуем, но требует одинакового размера подсетей. Динамический NAT (NAPT) позволяет нескольким внутренним адресам использовать общий пул внешних адресов с динамическим назначением портов. Он более гибок, но требует, чтобы трафик инициировался изнутри, и не подходит для BGP-пиринга, если IP пира входит в диапазон NAT.

Как проверить, работает ли IPSec-туннель за NAT?

Проверьте статус туннеля в интерфейсе управления VPN-устройства. Если статус connected, туннель установлен. Также можно выполнить ping с компьютера в одной сети на компьютер в другой. Дополнительно проверьте счетчики трафика в мониторинге VPN. Если туннель не поднимается, изучите журналы на предмет ошибок фазы 1 или фазы 2.

Что делать, если VPN-туннель не устанавливается из-за NAT?

Убедитесь, что на NAT-устройстве проброшены все необходимые порты и протоколы (UDP 500, UDP 4500, ESP, AH). Проверьте, включен ли NAT-T на обоих VPN-устройствах. Также проверьте, совпадают ли настройки фаз 1 и 2 на обеих сторонах. Если используется динамический NAT, убедитесь, что селекторы трафика настроены как "any-to-any", а не на основе политик.