Два сайта, одна подсеть: постройте отдельное представление псевдонимов для каждого

Два клиентских сайта используют 192.168.50.0/24, и удалённому инженеру нужно попасть к принтеру по одному и тому же адресу на каждом из них. Никакой трюк маршрутизации не решает эту неоднозначность сам по себе. Каждому сайту нужен отдельный взгляд на адреса, и шлюз должен выбрать сайт из этого представления, прежде чем что-либо пересылать.

В плане четыре части: префиксы псевдонимов, оба направления перевода, политика наложения и имена. Каждая должна согласовываться с остальными.

Выберите один префикс псевдонима на сайт

Назначьте каждому сайту целый префикс псевдонима, который не принадлежит никому другому в среде. План для двух сайтов может сопоставить 192.168.50.0/24 сайта A с 172.21.10.0/24, а идентичную локальную сеть сайта B — с 172.21.20.0/24. Проверьте кандидатов по каждой участвующей сети, включая облачные VPC и другие пулы VPN. Частное адресное пространство разделяют все организации, поэтому то, что диапазон относится к RFC 1918, ничего не говорит о его свободности здесь.

Публикуйте псевдоним, а не исходную подсеть, для удалённых пользователей. Исходный диапазон остаётся локальным фактом.

Переводите в обоих направлениях

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

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

Точный этап, на котором применяются политика, селекторы и маршруты, различается между IPsec на основе политик, туннелями на основе маршрутов и другими продуктами. Проектируйте под тот, который вы эксплуатируете.

Проведите план через наложение

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

Публикация всей подсети шире публикации одной службы. Если нужны только несколько машин или портов, держите правила доступа уже сопоставления.

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

Исправьте имена, которые видит каждый вызывающий

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

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

Записывайте и проверяйте по каждому сайту

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

Именно этот перечень сохраняет различие, когда появляется третий сайт с той же LAN по умолчанию. Руководство по IPsec NAT на основе политик описывает одну конкретную модель перевода; оно не является контрактом для каждой платформы.