Кто на самом деле отвечает на выделенном адресе VPN?

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

Путь пакета за адресом

Партнёр отправляет IKE на выданный ему адрес, по UDP 500 или по UDP 4500, когда задействовано прохождение через NAT. Устройство, владеющее этим адресом на пути, либо принимает датаграмму локально и отвечает на неё, либо передаёт её дальше в другое место. Это единственные две возможности, и всё остальное в этой статье следует из того, какая из них верна.

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

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

Модель A: адресом владеет шлюз

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

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

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

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

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

Модель B: его транслирует устройство выше по пути

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

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

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

Идентичность — это не внешний адрес

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

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

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

Примите схему, наблюдая за одним соединением

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

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

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