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 просто не відкидається по дорозі. Відкинутий пакет завершується за тайм-аутом; він не дає відмови.
Що записати, поки це працює
Запишіть тип ідентичності, її значення, версію прошивки та адресу партнера, які діяли, коли тунель підіймався востаннє. Оновлення прошивки може знову змінити значення за замовчуванням, і наступний збій виглядатиме точно як незбіг ключа. Коли ідентичність збережено поруч із ключем і адресою партнера, наступна людина починає з дешевих перевірок.
Цей запис також єдиний спосіб дізнатися, чи потрібен обхід після наступного оновлення.