GCP HA VPN visszautasítja a FortiGate-et: nem egyezik a helyi ID típusa
A Google azt az identitást hasonlítja össze, amelyet a FortiGate állít, nem csupán az előre megosztott kulcsot. Az FQDN típusú helyi ID elbukik ezen az ellenőrzésen, miközben a napló még hitelesítést ír.
A Google Cloud HA VPN AUTHENTICATION_FAILED hibája általában visszaküldi az embereket az előre megosztott kulcshoz, és a kulcs rendszerint helyes. Az alagút az 1-es fázisban áll meg, mert a Google még valamit összehasonlít: azt az identitást, amelyet a partner az IKE-csere során állít. FortiGate-en ez az identitás típust válthat anélkül, hogy bárki szerkesztene egy címet. Ha a kulcsot kétszer újra megadták, olvassa a naplót identitás-eltérésként.
Egy hiba, két ellenőrzés
Az IKE két külön lépésben ellenőrzi a partnert. Az előre megosztott kulcs bizonyítja, hogy mindkét fél ugyanazt a titkot birtokolja, az állított identitás pedig megmondja a válaszolónak, kinek mondja magát a partner. A Google ezt az identitást a konfigurált partnerhez hasonlítja. Magára hagyva a FortiGate a kimenő interfészéből származtatott, címalapú identitást küld, és az összehasonlítás észrevétlenül átmegy.
Mindkét lépés ugyanabba a vödörbe kerül a naplóban, ami megmagyarázza azt a jól ismert hurkot, hogy a kulcsot négyszer újra beírják, mielőtt bárki elolvasná az identitás hasznos terhét.
Mit tesz a FortiGate az identitás hasznos terhébe
A baj akkor kezdődik, amikor valaki beállít egy helyi ID-t hogy a két oldal megegyezzen. Az újabb FortiOS-verziók ezt az identitást teljesen minősített tartománynévként jelölik meg, akkor is, ha a beírt érték pontokkal tagolt cím. A Google tehát FQDN-identitást kap, miközben címet vár, és elutasítja a munkamenetet. Az üzenet semmit sem mond arról, melyik fél hibázott, ezért a jelentés hitelesítési hibaként olvasható.
Reprodukálja egyszer bekapcsolt IKE-hibakereséssel, és olvassa el azt az identitás hasznos terhet, amelyet a tűzfal valóban kibocsát.
Ugyanebben a menetben erősítsen meg három olcsó tényt: a két fél által használt IKE-verziót, a pontos kulcsot a láthatatlan záró karakterekkel együtt, és azt a partner-címet, amelyet a Google vár. Ezek külön kérdésekre válaszolnak, és az egyező kulcs semmit sem mond az identitásról.
Lehetőségek, és mennyibe kerül mindegyik
Minden kijárat más réteget javít, és egyik sem elérhető minden telepítéshez.
| 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 |
Az identitás javítása a tűzfalon a legtisztább válasz ott, ahol a firmware engedi a típus kiválasztását és az érték megtartását. A mező egyes verziókban létezik, másokban rosszul tölti ki a típust, ezért tesztelje a saját verzióját, ne bízzon a kiadási jegyzetekben.
Az egyeztető interfészen lévő útvonalazható nyilvános cím a dokumentált megoldás, mert akkor az alapértelmezett identitás megegyezik azzal, amit a Google vár, és nincs szükség felülírásra. Ide jut a legtöbb telepítés, ha a tűzfal egyáltalán tud ilyen címet tartani.
Olyan partneren lezárni, amely érvényesíti azt, amit előállít, topológiaváltozás. Kezelje tervezési döntésként, nem pedig barátságosabb leírású megoldásként.
Amikor a NAT eltávolít egy lehetőséget
NAT mögött a nyilvános címes kijárat eltűnik, és ami marad, az olyan firmware-viselkedéstől függ, amelyet nem irányít. Ez az a pont, ahol tudatosan kell választani a frissítés, a partner áthelyezése vagy egy másik felhővégpont elfogadása között. Ez három különböző költségvetés, és az egyik véletlen kiválasztása az, ahogy egy ideiglenes megoldás architektúrává válik. Írja le a választást és annak okát az alagút mellé.
Mielőtt bármit értelmezne ebből, erősítse meg az alagút állapotát a Google oldalán, és azt, hogy az IKE-t nem egyszerűen eldobják útközben. Az eldobott csomag időtúllépéssel megszűnik; nem hoz létre visszautasítást.
Mit rögzítsen, amíg működik
Jegyezze fel az identitás típusát, értékét, a firmware-verziót és a partner-címét, amelyek érvényben voltak az alagút utolsó feljövetelekor. A firmware-frissítés ismét megváltoztathatja az alapértelmezést, és a következő hiba pontosan kulcseltérésnek fog látszani. Ha az identitás a kulcs és a partner-címe mellett tárolódik, a következő ember az olcsó ellenőrzésekkel kezdi.
Ez a feljegyzés az egyetlen módja annak is, hogy tudja, szükség van-e még a megoldásra a következő frissítés után.