GCP HA VPN отклоняет FortiGate: тип локального ID не совпадает
Google сравнивает идентичность, которую заявляет FortiGate, а не только предварительно общий ключ. Локальный ID типа FQDN не проходит эту проверку, хотя журнал всё ещё говорит об аутентификации.
AUTHENTICATION_FAILED из Google Cloud HA VPN обычно отправляет людей обратно к предварительно общему ключу, и ключ обычно верный. Туннель встаёт на фазе 1, потому что Google сравнивает ещё и другое: идентичность, которую партнёр заявляет во время обмена IKE. На FortiGate эта идентичность может сменить тип без того, чтобы кто-то правил адрес. Читайте журнал как несовпадение идентичности после того, как ключ ввели повторно дважды.
Одна ошибка, две проверки
IKE проверяет партнёра в два отдельных шага. Предварительно общий ключ доказывает, что обе стороны владеют одним секретом, а заявленная идентичность сообщает отвечающей стороне, кем партнёр себя представляет. Google сравнивает эту идентичность с тем партнёром, с которым он настроен. Если оставить как есть, FortiGate отправляет идентичность на основе адреса, выведенную из его исходящего интерфейса, и сравнение проходит незаметно.
Оба шага попадают в одну и ту же корзину в журнале, что объясняет знакомый цикл: ключ перенабирают четыре раза, прежде чем кто-то прочитает полезную нагрузку идентичности.
Что FortiGate кладёт в полезную нагрузку идентичности
Проблема начинается, когда кто-то задаёт локальный ID чтобы стороны договорились. Новые сборки FortiOS помечают эту идентичность как полное доменное имя, даже когда введённое значение — адрес с точками. Поэтому Google получает идентичность FQDN, ожидая адрес, и отклоняет сеанс. В сообщении не сказано, какая половина не прошла, поэтому отчёт читается как сбой аутентификации.
Воспроизведите это один раз с включённой отладкой IKE и прочитайте полезную нагрузку идентичности, которую межсетевой экран действительно отправляет.
В том же проходе подтвердите три дешёвых факта: версию IKE у обеих сторон, точный ключ вместе с невидимыми конечными символами и адрес партнёра, которого ожидает Google. Они отвечают на разные вопросы, а совпадающий ключ ничего не говорит об идентичности.
Варианты и чего стоит каждый
Каждый выход исправляет свой слой, и ни один не доступен для всех развёртываний.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
Исправление идентичности на межсетевом экране — самый чистый ответ там, где прошивка позволяет выбрать тип и сохранить значение. Поле есть в одних сборках и заполняет тип неверно в других, поэтому проверяйте свою версию, а не полагайтесь на примечания к выпуску.
Маршрутизируемый публичный адрес на интерфейсе переговоров — задокументированный обход, потому что тогда идентичность по умолчанию совпадает с ожидаемой Google и переопределение не нужно. Именно туда приходит большинство развёртываний, если экран вообще может удерживать такой адрес.
Завершение на партнёре, который проверяет то, что вы выдаёте, — это изменение топологии. Относитесь к этому как к проектному решению, а не как к обходу с более дружелюбным описанием.
Когда NAT убирает один вариант
За NAT выход через публичный адрес исчезает, а то, что остаётся, зависит от поведения прошивки, которое вы не контролируете. Это момент осознанно выбрать между обновлением, переносом партнёра или принятием другой облачной конечной точки. Это три разных бюджета, и случайный выбор одного — так временный обход превращается в архитектуру. Запишите выбор и его причину рядом с туннелем.
Прежде чем что-либо из этого трактовать, подтвердите состояние туннеля на стороне Google и то, что IKE просто не отбрасывается по пути. Отброшенный пакет завершается по таймауту; он не даёт отказа.
Что записать, пока это работает
Запишите тип идентичности, её значение, версию прошивки и адрес партнёра, которые действовали, когда туннель поднимался в последний раз. Обновление прошивки может снова изменить значение по умолчанию, и следующий сбой будет выглядеть точно как несовпадение ключа. Если идентичность хранится рядом с ключом и адресом партнёра, следующий человек начинает с дешёвых проверок.
Эта запись — ещё и единственный способ узнать, нужен ли обход после следующего обновления.