FortiGate hinter NAT: local-gw, localid und die öffentliche IP

Ein FortiGate hinter NAT kann 10.0.0.2 auf seiner WAN-Schnittstelle besitzen, während das Internet es als 198.51.100.40 darstellt, und beide Zahlen sind real. Die Adresse, an die das Gerät bindet, und die Identität, die es während der IKE-Authentifizierung sendet, sind getrennte Entscheidungen, in getrennten Feldern, für getrennte Adressaten. NAT schreibt die äußere Adressierung unterwegs um; es schreibt eine authentifizierte Identität nicht in das um, was der entfernte Peer erwartet. Die meisten Fehler in Phase 1 entstehen bei dieser Form dadurch, dass der richtige Wert ins falsche Feld gesetzt wird.

Drei Werte, drei Eigentümer

Beginnen Sie damit, die drei Werte und ihren jeweiligen Eigentümer zu benennen. local-gw ist die Adresse, die das FortiGate als Quelle für IKE auf seiner externen Schnittstelle verwendet, und sie muss eine Adresse sein, die das Gerät tatsächlich besitzt. Der öffentliche Endpunkt ist die Adresse des NAT-Geräts und gehört demjenigen, der die Übersetzung durchführt. Die IKE-Identität ist eine Zeichenkette, die der Peer mit seiner eigenen Konfiguration abgleicht, und sie muss keineswegs eine IP-Adresse sein.

Die Feldnamen liegen nah genug beieinander, um zum Vertauschen zu verleiten, und das ist die Falle. localid und localid-type beschreiben die Identifikation; local-gw beschreibt die lokale Bindung.

Ein Beispiel macht den Unterschied konkret. Öffnen Sie auf dem FortiGate config vpn ipsec phase1-interface, dann set interface "wan1" und set local-gw 10.0.0.2 — eine Adresse, die die Box besitzt, und genau das lässt den IKE-Socket erfolgreich binden. Lassen Sie local-gw auf 0.0.0.0, wird die Schnittstellenadresse verwendet, was meist dasselbe ist, aber weniger explizit. Setzen Sie local-gw nicht auf 198.51.100.40, denn das Gerät besitzt diese Adresse nicht, und der Socket wird nicht daran binden. Zwei Werte auf dem Papier gleich aussehen zu lassen ist keine Konfiguration.

Schritt 1: Wählen Sie die Identität, die der Peer akzeptiert

Nun die Identität, eine andere Entscheidung. set localid nimmt den Wert, den der Peer vergleicht, und set localid-type sagt dem FortiGate, wie er zu interpretieren ist: eine Adresse, ein FQDN, ein Benutzer-FQDN oder eine Schlüssel-ID. Mit auto leitet das Gerät sie ab, typischerweise aus der Adresse der ausgehenden Schnittstelle, also genau dem Wert, den ein NAT-Gerät gerade ändern wird.

Diese Ableitung ist der Grund, warum eine explizite Identität in dieser Topologie wichtig ist. Erwartet der Peer eine Adressidentität, setzen Sie localid-type address und localid auf die öffentliche Adresse, die der Peer sieht, und bestätigen Sie dann, dass der Peer diesen Wert als Identität akzeptiert und nicht als Routing-Ziel. Erwartet der Peer einen FQDN, verwenden Sie localid-type fqdn und den Namen, mit dem er konfiguriert wurde. Prüfen Sie mit diagnose vpn ike gateway list, was tatsächlich gesendet wurde; das zeigt den Gateway-Zustand und die verwendeten Bezeichner, nicht das, was Sie eingeben wollten. Gehen Sie nicht davon aus, dass eine Identitätstyp-Option eine beliebige nicht-lokale Adresse akzeptiert; prüfen Sie zuerst die dokumentierte Semantik der Version.

Schritt 2: Leiten Sie UDP 500 und 4500 an das Gerät weiter

Der dritte Wert gehört dem NAT-Gerät, und er ist derjenige, den man zu prüfen vergisst. Der öffentliche Endpunkt muss UDP 500 und UDP 4500 an das FortiGate weiterleiten, weil NAT-T-Erkennung und das folgende gekapselte ESP beide darauf angewiesen sind, dass diese Ports ankommen. Dieses Design setzt eine Eins-zu-eins-Zuordnung voraus; portbasiertes Teilen einer einzigen öffentlichen Adresse unter mehreren Peers ist eine andere Topologie mit anderen Grenzen.

Bestätigen Sie die Weiterleitung mit einem Mitschnitt statt mit einer Hoffnung: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 zeigt, ob Pakete ankommen und ob Antworten hinausgehen.

Google Cloud VPN dokumentiert Eins-zu-eins-NAT mit NAT-T als unterstützte Anordnung für einen Peer hinter NAT, und das ist die Einschränkung, gegen die zu entwerfen ist, wenn die Gegenseite ein Cloud VPN-Gateway ist. Eins-zu-viele oder portbasiertes Teilen ist nicht dieselbe unterstützte Topologie, und kein lokales Identitätstuning ändert das. Ist die Gegenseite ein anderes Gerät, definiert deren eigene Dokumentation, was sie als Identität akzeptiert und ob sie eine übersetzte Peer-Adresse duldet. Lesen Sie das, bevor Sie ein lokales Feld ändern, denn die lokale Seite kann keine Regel aushandeln, die die Gegenseite nicht umsetzt.

Schritt 3: Prüfen Sie, was Phase 1 nicht löst

NAT-Traversal bringt den Tunnel hoch, Identitätseinigkeit entscheidet, ob der Peer ihn akzeptiert, und das Routing des inneren Präfixes entscheidet, was tatsächlich passiert. Eine korrekte lokale ID kann keine fehlende statische Route und keinen fehlenden Traffic-Selector liefern.

Prüfen Sie also schichtweise. get vpn ipsec tunnel details zeigt, ob der Tunnel steht und welche Selektoren ausgehandelt wurden, und eine Abweichung zwischen dem konfigurierten entfernten Subnetz und dem ausgehandelten Selektor ist ein Routing-Problem im Phase-2-Kostüm. execute vpn ike gateway clear erzwingt eine Neuverhandlung, sodass Sie die aktuelle Konfiguration testen und nicht eine Sitzung, die vor Ihrer letzten Änderung aufgebaut wurde. Senden Sie dann Verkehr zu einem Host im entfernten Präfix und bestätigen Sie, dass sich die Zähler bewegen, denn ein Tunnel, der steht und nichts durchlässt, sieht identisch aus wie ein funktionierender, bis Sie nachsehen.

Halten Sie die drei Werte an einer Stelle in Ihren Notizen: die lokale Adresse, die das Gerät besitzt, den öffentlichen Endpunkt, den das NAT-Gerät darstellt, und die Identitätszeichenkette, die der Peer erwartet. Sie ändern sich aus unterschiedlichen Gründen und zu unterschiedlichen Zeiten.

Eine Umnummerierung des NAT-Geräts ist kein Grund, local-gw des FortiGate anzufassen, und eine Identitätsänderung ist kein Grund, irgendetwas umzunummerieren. Beides zu vermischen ist der Weg, wie ein funktionierender Tunnel während eines unabhängigen Wartungsfensters neu aufgebaut wird. Die Cloud VPN NAT-Anleitung ist die Referenz für die unterstützte Topologie auf jener Seite.

Der Test, der die Sache entscheidet, ist langweilig und schnell: Machen Sie einen Mitschnitt auf der externen Schnittstelle, bestätigen Sie, dass UDP 500 und 4500 vom Peer ankommen, bestätigen Sie, dass die Identität im IKE-Austausch dem entspricht, worauf der Peer konfiguriert war, und bestätigen Sie dann, dass die ausgehandelten Selektoren die Subnetze abdecken, die Ihnen wichtig sind. Scheitert die erste Prüfung, ist das NAT-Gerät der Verdächtige. Scheitert die zweite, sind es die Identitätsfelder. Scheitert die dritte, war weder NAT noch Identität jemals das Problem.