FortiGate за NAT: local-gw, localid и публичный IP

FortiGate за NAT может владеть 10.0.0.2 на своём интерфейсе WAN, хотя интернет представляет его как 198.51.100.40, и оба числа реальны. Адрес, к которому привязывается устройство, и идентификатор, который оно отправляет при аутентификации IKE, — это разные решения, принятые в разных полях для разных адресатов. NAT переписывает внешнюю адресацию по пути, но не переписывает аутентифицированный идентификатор в то, что ожидает удалённый партнёр. Большинство сбоев фазы 1 в такой схеме происходит из-за того, что правильное значение ставят в неправильное поле.

Три значения, три владельца

Начните с того, чтобы назвать три значения и владельца каждого. local-gw — это адрес, который FortiGate использует как источник IKE на внешнем интерфейсе, и он должен быть адресом, которым устройство действительно обладает. Публичный адрес — это адрес устройства NAT, и им владеет тот, кто выполняет трансляцию. Идентификатор IKE — это строка, которую партнёр сравнивает со своей конфигурацией, и она вовсе не обязана быть IP-адресом.

Имена полей достаточно близки, чтобы провоцировать подмену, и в этом ловушка. localid и localid-type описывают идентификацию; local-gw описывает локальную привязку.

Пример делает различие конкретным. На FortiGate откройте config vpn ipsec phase1-interface, затем set interface "wan1" и set local-gw 10.0.0.2 — адрес, которым владеет устройство, и именно это позволяет сокету IKE успешно привязаться. Оставьте local-gw на 0.0.0.0, и будет использоваться адрес интерфейса, что обычно то же самое, но менее явно. Не задавайте local-gw равным 198.51.100.40, потому что устройство не владеет этим адресом и сокет к нему не привяжется. Сделать два значения одинаковыми на бумаге — это не конфигурация.

Шаг 1: выберите идентификатор, который примет партнёр

Теперь идентификатор, а это другое решение. set localid принимает значение, которое партнёр будет сравнивать, а set localid-type сообщает FortiGate, как его толковать: адрес, FQDN, пользовательский FQDN или ключевой ID. С auto устройство выводит его, обычно из адреса исходящего интерфейса, а это именно то значение, которое устройство NAT собирается изменить.

Именно этот вывод и объясняет, почему в данной топологии важен явный идентификатор. Если партнёр ожидает адресный идентификатор, задайте localid-type address и localid равными публичному адресу, который увидит партнёр, а затем убедитесь, что партнёр принимает это значение как идентификатор, а не как цель маршрутизации. Если партнёр ожидает FQDN, используйте localid-type fqdn и имя, с которым он был настроен. Проверьте, что фактически отправлено, командой diagnose vpn ike gateway list, которая показывает состояние шлюза и используемые идентификаторы, а не то, что вы собирались ввести. Не предполагайте, что опция типа идентификатора принимает произвольный нелокальный адрес; сначала проверьте документированную семантику выпуска.

Шаг 2: перенаправьте UDP 500 и 4500 на устройство

Третье значение принадлежит устройству NAT, и именно его люди забывают проверить. Публичный адрес должен перенаправлять UDP 500 и UDP 4500 на FortiGate, потому что обнаружение NAT-T и следующий за ним инкапсулированный ESP оба зависят от прихода этих портов. Эта схема предполагает взаимно однозначное сопоставление; разделение одного публичного адреса по портам между несколькими партнёрами — это другая топология с другими ограничениями.

Подтвердите перенаправление захватом, а не надеждой: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 показывает, приходят ли пакеты и уходят ли ответы.

Google Cloud VPN документирует NAT один-к-одному с NAT-T как поддерживаемую схему для партнёра за NAT, и именно это ограничение нужно учитывать, если удалённая сторона — шлюз Cloud VPN. Разделение один-ко-многим или по портам — это не та же поддерживаемая топология, и никакая локальная настройка идентификатора этого не меняет. Если удалённая сторона — другое устройство, его собственная документация определяет, что оно примет как идентификатор и терпит ли транслированный адрес партнёра. Прочитайте это, прежде чем менять локальное поле, потому что локальная сторона не может согласовать правило, которое удалённая сторона не реализует.

Шаг 3: проверьте, что не решает фаза 1

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

Поэтому проверяйте послойно. get vpn ipsec tunnel details показывает, поднят ли туннель и какие селекторы согласованы, а несовпадение между настроенной удалённой подсетью и согласованным селектором — это проблема маршрутизации в костюме фазы 2. execute vpn ike gateway clear принудительно запускает пересогласование, поэтому вы проверяете текущую конфигурацию, а не сеанс, установленный до вашего последнего изменения. Затем отправьте трафик на хост в удалённом префиксе и убедитесь, что счётчики двигаются, потому что поднятый туннель, который ничего не пропускает, выглядит так же, как рабочий, пока вы не проверите.

Держите три значения в одном месте в заметках: локальный адрес, которым владеет устройство, публичный адрес, который представляет устройство NAT, и строку идентификатора, которую ожидает партнёр. Они меняются по разным причинам и в разное время.

Перенумерация устройства NAT — не повод трогать local-gw на FortiGate, а смена идентификатора — не повод что-либо перенумеровывать. Смешивать эти две вещи — это способ перестроить рабочий туннель во время несвязанного окна обслуживания. Руководство Cloud VPN по NAT — это справка по поддерживаемой топологии на той стороне.

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