Когда NAT внутри VPN «сеть — сеть» оправдывает своё место

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

Решите, какой адрес переписывается

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

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

Порядок селекторов тоже важен. Выбор и трансляция политики IPsec происходят на определённых этапах, поэтому селектор, написанный для адресов до трансляции, может никогда не совпасть с пакетом на том этапе, который вы предполагали. Проверяйте установленную политику, а не ту, которую собирались установить, потому что они расходятся именно тогда, когда правило принимает один компонент, а другой игнорирует:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Следите за полезной нагрузкой и обратным путём

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

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

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

Сравните это с перенумерацией площадки

Перенумерация одной конфликтующей площадки полностью убирает сопоставление и оставляет план адресов, который можно читать без таблиц трансляции. Это операционно дорого: записи DNS, статические назначения, правила брандмауэра и каждый задокументированный адрес должны меняться вместе. Затраты возникают один раз, в запланированное окно, с ясным конечным состоянием. То, что вы покупаете, — способность прочитать дамп пакетов годы спустя без таблицы поиска.

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

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

Докажите оба направления реальным сеансом

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

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

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

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