SoftEther SecureNAT: DHCP и NAT — два отдельных решения

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

Две службы за одним флажком

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

Виртуальный интерфейс хоста относится к первому решению, а не ко второму. Его адрес, часто по умолчанию что-то вроде 192.168.30.1, — это шлюз, который предлагает служба DHCP. Это не публичный адрес прослушивания сервера, и смешение этих двух порождает правила межсетевого экрана и настройки клиента, нацеленные на машину, которой в этой сети нет.

Решение 1: кто выдаёт адрес

Если виртуальный DHCP включён, клиенты должны получать аренду из настроенного вами пула, со шлюзом в виде виртуального интерфейса хоста и с тем резолвером, который вы указали. Смотрите на аренду, а не на текст состояния клиента, потому что «подключено» описывает туннель, а не назначение адреса:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

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

Решение 2: кто пересылает за виртуальный шлюз

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

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

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

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

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

Собственный путь хоста — это третья вещь

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

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

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

Проверяйте каждое решение его собственным тестом

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

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

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