Одна и та же подсеть на обоих концах: сопоставьте удалённый LAN со свободным диапазоном

Дом и офис используют одну и ту же 192.168.1.0/24, поэтому у запроса к 192.168.1.1 есть два возможных ответа, и клиент выбирает один, не спрашивая. Перенумерация работающей офисной сети редко бывает популярной, а адреса маршрутизатора часто зашиты в принтеры, камеры и документацию. Сопоставление адресов на стороне клиента может вместо этого представить удалённую сеть под свободным диапазоном, а часть хоста может остаться той же, так что 192.168.1.20 выглядит как 10.203.41.20. Загвоздка в том, что его реализуют только некоторые клиенты и что для обратного пути оно не делает ничего.

Два взгляда на один и тот же хост

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

Локальные устройства дома сохраняют свои адреса 192.168.1.x, и в этом смысл упражнения. Принтер в соседней комнате остаётся доступным, а офис появляется под диапазоном, который не конфликтует.

Порядок аргументов — вся хитрость

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

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

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

Сопоставление не создаёт обратный путь

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

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

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

Имена и полезные нагрузки переживают трансляцию

Имя хоста, разрешающееся в настоящий 192.168.1.20, отправляет браузер на локальное устройство вместо удалённого, что бы ни говорила таблица маршрутизации. Ответ частного DNS должен указывать на диапазон, видимый клиенту, а сертификат TLS по-прежнему несёт имя, которого ожидает приложение. Проверяйте по имени, а не по адресу, потому что адрес может работать, пока имя тихо разрешается в неверную сторону. Когда удалённый шлюз обслуживает и эту зону, его собственные записи тоже нуждаются в диапазоне, видимом клиенту.

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

Три проверки перед обязательством

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

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

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