GCP HA VPN odrzuca FortiGate: typ lokalnego ID się nie zgadza
Google porównuje tożsamość, którą deklaruje FortiGate, a nie tylko wstępnie współdzielony klucz. Lokalny ID typu FQDN nie przechodzi tej kontroli, choć log nadal mówi o uwierzytelnianiu.
AUTHENTICATION_FAILED z Google Cloud HA VPN zwykle odsyła ludzi do wstępnie współdzielonego klucza, a klucz zazwyczaj jest poprawny. Tunel zatrzymuje się w fazie 1, ponieważ Google porównuje też coś innego: tożsamość, którą partner deklaruje podczas wymiany IKE. Na FortiGate ta tożsamość może zmienić typ, choć nikt nie edytuje adresu. Czytaj log jako niezgodność tożsamości, gdy klucz został wpisany ponownie dwa razy.
Jedna awaria, dwie kontrole
IKE weryfikuje partnera w dwóch osobnych krokach. Wstępnie współdzielony klucz dowodzi, że obie strony mają ten sam sekret, a zadeklarowana tożsamość mówi odpowiadającemu, za kogo partner się podaje. Google porównuje tę tożsamość z partnerem, z którym został skonfigurowany. Pozostawiony sam sobie FortiGate wysyła tożsamość opartą na adresie, wyprowadzoną z interfejsu wychodzącego, i porównanie przechodzi, zanim ktokolwiek to zauważy.
Oba kroki trafiają do tego samego koszyka w logu, co wyjaśnia znany cykl przepisywania klucza cztery razy, zanim ktokolwiek przeczyta ładunek tożsamości.
Co FortiGate umieszcza w ładunku tożsamości
Problem zaczyna się, gdy ktoś ustawia lokalny ID aby obie strony się zgodziły. Najnowsze kompilacje FortiOS oznaczają tę tożsamość jako w pełni kwalifikowaną nazwę domeny, nawet gdy wpisana wartość jest adresem z kropkami. Google otrzymuje więc tożsamość FQDN, oczekując adresu, i odrzuca sesję. Nic w komunikacie nie mówi, która połowa zawiodła, więc raport czyta się jako błąd uwierzytelniania.
Odtwórz to raz z włączonym debugowaniem IKE i przeczytaj ładunek tożsamości, który zapora faktycznie wysyła.
W tym samym przebiegu potwierdź trzy tanie fakty: wersję IKE używaną przez obie strony, dokładny klucz wraz z niewidocznymi końcowymi znakami oraz adres partnera, którego oczekuje Google. Odpowiadają na różne pytania, a pasujący klucz nic nie mówi o tożsamości.
Opcje i ile każda kosztuje
Każde wyjście naprawia inną warstwę i żadne nie jest dostępne dla każdego wdrożenia.
| 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 |
Poprawienie tożsamości na zaporze to najczystsza odpowiedź tam, gdzie firmware pozwala wybrać typ i zachować wartość. Pole istnieje w niektórych kompilacjach, a w innych wypełnia typ źle, więc testuj swoją wersję, zamiast ufać informacjom o wydaniu.
Trasowalny adres publiczny na interfejsie negocjacyjnym to udokumentowane obejście, ponieważ wtedy domyślna tożsamość pasuje do tego, czego oczekuje Google, i nie trzeba żadnego nadpisania. Tam trafia większość wdrożeń, jeśli zapora w ogóle może utrzymać taki adres.
Zakończenie na partnerze, który waliduje to, co produkujesz, jest zmianą topologii. Traktuj to jako decyzję projektową, a nie obejście z milszym opisem.
Gdy NAT usuwa jedną opcję
Za NAT wyjście przez adres publiczny znika, a to, co zostaje, zależy od zachowania firmware, którego nie kontrolujesz. To moment, by świadomie wybrać między aktualizacją, przeniesieniem partnera a akceptacją innego punktu końcowego chmury. To trzy różne budżety, a wybór jednego przez przypadek sprawia, że tymczasowe obejście staje się architekturą. Zapisz wybór i jego powód obok tunelu.
Zanim cokolwiek z tego zinterpretujesz, potwierdź stan tunelu po stronie Google i to, że IKE nie jest po prostu wyrzucany po drodze. Wyrzucony pakiet kończy się przekroczeniem czasu; nie daje odrzucenia.
Co zapisać, dopóki działa
Zapisz typ tożsamości, jej wartość, wersję firmware i adres partnera, które obowiązywały przy ostatnim podniesieniu tunelu. Aktualizacja firmware może znów zmienić wartość domyślną, a następna awaria będzie wyglądać dokładnie jak niezgodność klucza. Gdy tożsamość jest zapisana obok klucza i adresu partnera, następna osoba zaczyna od tanich kontroli.
Ten zapis to także jedyny sposób, by wiedzieć, czy obejście jest jeszcze potrzebne po następnej aktualizacji.