Azure Standort-zu-Standort-VPN mit Peer hinter NAT: Checkliste

Arbeiten Sie diese Prüfungen der Reihe nach ab und halten Sie bei der ersten an, die fehlschlägt. Die meisten Meldungen, Azure unterstütze ein Gerät hinter NAT nicht, entpuppen sich als Peer-Adresse, die Azure nicht erreicht, oder als Tunnel, der nie von der richtigen Seite aus initiiert wird. Der äußere Transport und das innere Routing sind zwei verschiedene Probleme, und ihre Vermischung kostet einen Nachmittag. Jeder Schritt unten liefert eine Beobachtung, die Sie an jemand anderen weitergeben können.

Schritt 1: Bestätigen Sie, dass der Peer überhaupt hinter NAT sitzt

Vergleichen Sie die Adresse an der WAN-Schnittstelle des Geräts mit der Adresse, die Azure dafür sieht. Weichen sie voneinander ab, übersetzt etwas, und dieser Übersetzer ist jetzt Teil Ihres VPN-Designs. Fragen Sie den Anbieter, ob die Zuordnung statisch oder geteilt ist, denn eine geteilte Zuordnung ändert, worauf Sie sich verlassen können. Ein Gerät mit privater WAN-Adresse und ohne Weiterleitung ist ein anderer Fall als eines hinter einem Carrier-Grade-NAT mit stabiler öffentlicher Zuordnung.

Stimmen die beiden Adressen überein, halten Sie hier an: NAT ist nicht Ihr Problem, und der Rest dieser Liste hilft nicht.

Notieren Sie beide Adressen und das Modell des Übersetzers im Ticket. Diese eine Zeile erspart die nächste Fragerunde, warum der konfigurierte Peer nicht antwortet.

Schritt 2: Einigen Sie sich, wer initiiert

Die Azure VPN Gateway FAQ nennt NAT-T-Unterstützung und ergänzt, dass das lokale Gerät den IPsec-Tunnel initiieren sollte, wenn es hinter NAT sitzt. Das passt dazu, wie zustandsbehaftete Übersetzung funktioniert, denn der Übersetzer hält eine Zuordnung, weil das innere Gerät das erste Paket gesendet hat. Wenn Azure initiieren soll und nichts eintrifft, was diese Zuordnung erzeugt, kommt der Tunnel nie zustande.

Konfigurieren Sie den Peer so, dass ein Nur-Antwortender-Fehler offensichtlich ist, und prüfen Sie, ob das Gerät von selbst erneut versucht oder einen Auslöser braucht. Manche Geräte bauen einen Tunnel erst auf, wenn interessanter Verkehr erscheint, was so lange in Ordnung ist, bis der interessante Verkehr eine Zustandssonde ist, die nie kommt.

Beobachten Sie den IKE-Austausch auf dem Gerät während einer manuellen Initiierung; Stille dort ist eine Antwort des Routings oder der Firewall, keine Antwort von Azure.

Schritt 3: Bringen Sie die Peer-Adresse in Ordnung

Azure braucht eine erreichbare öffentliche Adresse für den Peer im Objekt des lokalen Netzwerkgateways, normalerweise die öffentliche Adresse des Übersetzers statt der inneren Adresse des Geräts. Die Identität, mit der sich das Gerät authentifiziert, ist ein separates Feld und darf sich von der Adresse, die Azure anwählt, legitim unterscheiden. Halten Sie beides auseinander, denn ein Vertauschen erzeugt einen Authentifizierungsfehler, der genau wie ein NAT-Problem aussieht.

Ändert sich die öffentliche Adresse, muss sich dieses Objekt mitändern. Ein Name, der auf eine veraltete Adresse auflöst, ist schlechter als eine statische Adresse, die Sie von Hand aktualisieren müssen.

Notieren Sie alle drei Werte: lokale Adresse des Geräts, übersetzte öffentliche Adresse, konfigurierte Peer-Identität.

Schritt 4: Öffnen Sie nur die Ports, die NAT-T braucht

NAT-T trägt ESP innerhalb von UDP, und RFC 3948 beschreibt diese Kapselung mit Port 4500, der nach der ersten Aushandlung über Port 500 verwendet wird. Ihre Firewall und der Übersetzer müssen beide den Austausch und seinen Rückverkehr zulassen. Ein unbeteiligter TCP-Port zu erlauben beweist nichts über diesen Pfad, und eine Regel, die ausgehend erlaubt, aber nicht die Antwort, scheitert weiterhin.

Eine statische eingehende Portweiterleitung ist nicht automatisch nötig, wenn der Peer initiiert und der Übersetzer Zustand hält. Nötig wird sie, wenn die Zuordnung instabil ist oder wenn etwas auf dem Pfad den Zustand aggressiv verfallen lässt.

Zeichnen Sie einmal auf beiden Seiten des Übersetzers auf; der Unterschied in der Kapselung ist sofort sichtbar.

Schritt 5: Trennen Sie äußeren Transport vom inneren Routing

Ein Tunnel, der aufgebaut wird und nichts transportiert, ist ein Routingproblem, kein NAT-T-Problem. Die Standorte brauchen weiterhin kompatible Verkehrsselektoren, passende Adressräume, Zugriffsregeln und einen Rückweg für die Anwendungsnetze. Nichts davon liefert ein erfolgreicher IKE-Austausch.

Nutzen beide Standorte überlappende private Bereiche, ist Übersetzung innerhalb des Tunnels ein eigenes Design mit eigenen Regeln. Nummerieren Sie kein Subnetz neu, nur weil das äußere Gateway zufällig hinter einem Heimrouter sitzt.

Klassifizieren Sie den Fehler nach Stufe, bevor Sie etwas ändern, und behalten Sie diese Klassifizierung im Ticket, damit die nächste Person dort anfängt, wo Sie aufgehört haben.