NAT на сервере VPN или на роутере? Работают оба варианта

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

Миф: маршрут клиента создаёт выход

Принудительное туннелирование — это политика на стороне клиента: она решает, что трафик идёт на адаптер VPN, а не на физический. Документация Microsoft по маршрутизации VPN описывает это разделение и принудительное поведение, и это утверждение о таблице маршрутов клиента, а не о правилах пересылки сервера. С точки зрения клиента туннель — это место, где живёт интернет; с точки зрения шлюза пакет пришёл с адреса, о котором никто выше никогда не слышал. Ни одна из сторон не настроена неправильно сама по себе, и поэтому сбой выглядит для человека у ноутбука как сломанный сервер.

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

Сначала нарисуйте обратный путь

Запишите путь с реальными адресами, прежде чем трогать любую настройку, и отметьте на нём две возможные точки трансляции. Эта лаборатория использует пул VPN 10.70.0.0/24 с одним клиентом на 10.70.0.37, адрес LAN сервера 172.16.40.10, роутер на 172.16.40.1 и публичный выход 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

Вариант A: трансляция на сервере VPN

Здесь сервер транслирует источник клиента в свой адрес LAN, прежде чем передать пакет роутеру, а роутер применяет свою обычную трансляцию на выходе. На ответе сопоставление роутера восстанавливает адрес сервера, а сопоставление сервера восстанавливает адрес клиента. Две трансляции с состоянием подряд — это нормально и выполнимо при условии, что обе записаны; роутеру никогда не нужен маршрут к пулу, и в этом привлекательность такой схемы.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Используйте эти чтения, чтобы увидеть, что у сервера уже есть, вместо того чтобы предполагать наличие NAT. Скопированное из блога правило masquerade в Linux — не конфигурация Windows, а разрешение в брандмауэре хоста для прослушивателя VPN — не та же политика, что разрешение пересылать запрос клиента дальше. Подтвердите роль пересылки сервера на его собственной панели управления, а затем посмотрите на трансляцию отдельно, потому что эти две вещи часто включаются разными частями развёртывания.

Вариант B: перенести пул на роутер

Во второй схеме сервер пересылает настоящий адрес источника клиента, и роутер транслирует его. Это оставляет пул клиентов видимым на краю, что помогает, если именно роутер является местом политики трафика, журналирования или проверки. Это также означает, что роутеру нужен обратный маршрут для 10.70.0.0/24, указывающий на 172.16.40.10, плюс интернет-политика, которая действительно включает этот префикс; правило, написанное для подсети LAN, молча не распространяется на пул.

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

Сделайте DNS, IPv6 и приёмку явными

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

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

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