SoftEther SecureNAT: DHCP und NAT sind zwei Entscheidungen

SecureNAT betreibt einen virtuellen DHCP und einen virtuellen NAT, und beide können einzeln scheitern. Prüfen Sie das Lease, dann den Weg nach draußen und den Resolver, bevor Sie den Hub beschuldigen.

SecureNAT ist ein einziges Kontrollkästchen, das zwei Dienste einschaltet, und darin liegt die Quelle der meisten Verwirrung darüber. Ein virtueller DHCP-Server übergibt dem Client eine Adresse, eine Maske, ein Gateway und oft einen Resolver. Ein virtuelles NAT leitet Pakete über dieses Gateway hinaus weiter und nutzt dabei den eigenen Netzwerk-Stack des Serverhosts. Beide stehen in der Konfiguration nebeneinander und scheitern unabhängig voneinander: Ein Client kann ein perfektes Lease und keinen funktionierenden Weg haben oder einen funktionierenden Weg mit Einstellungen, die auf den falschen Resolver zeigen. Prüfen Sie sie als zwei Entscheidungen, und die Diagnose wird kurz.

Zwei Dienste hinter einem Kontrollkästchen

Die virtuelle DHCP-Seite beantwortet eine Konfigurationsfrage: Welche Einstellungen erhält dieser Client innerhalb dieses virtuellen Hubs. Die virtuelle NAT-Seite beantwortet eine Weiterleitungsfrage: Wenn ein Client ein Paket an eine Adresse außerhalb des Hubs sendet, übersetzt und leitet der Server es dann weiter. Das Erste ist lokal für den Hub und braucht kein vorgelagertes Netz. Das Zweite hängt ganz vom Host ab.

Die virtuelle Host-Schnittstelle gehört zur ersten Entscheidung, nicht zur zweiten. Ihre Adresse, standardmäßig oft so etwas wie 192.168.30.1, ist das Gateway, das der DHCP-Dienst anbietet. Sie ist nicht die öffentliche Listener-Adresse des Servers, und die Verwechslung beider erzeugt Firewall-Regeln und Client-Einstellungen, die auf eine Maschine zielen, die es in diesem Netz nicht gibt.

Entscheidung 1: wer die Adresse liefert

Ist der virtuelle DHCP aktiviert, sollten Clients ein Lease aus dem von Ihnen konfigurierten Pool erhalten, mit der virtuellen Host-Schnittstelle als Gateway und dem Resolver, den Sie angegeben haben. Prüfen Sie das Lease statt den Statustext des Clients, denn „verbunden“ beschreibt den Tunnel und nicht die Adresszuweisung:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Zwei Fehlermodi lohnt es sich zu kennen, bevor Sie irgendetwas anderes debuggen. Ein Client mit einer übrig gebliebenen statischen Adresse aus einem früheren Entwurf behält sie und ignoriert das Lease, was so aussieht, als weigere sich DHCP zu antworten. Und eine zweite DHCP-Quelle in einem gebrückten Segment konkurriert um dieselben Clients, was sporadische Adressen und eine Support-Warteschlange erzeugt, die das Problem nicht reproduzieren kann.

Überlappende Pools gehören ebenfalls hierher. Wenn der virtuelle DHCP-Pool das LAN-Subnetz des Hosts oder den Pool eines anderen Hubs überlappt, erhält der Client eine Adresse, die mehrdeutig geroutet wird, und jeder spätere Test ist nicht aussagekräftig.

Entscheidung 2: wer über das virtuelle Gateway hinaus weiterleitet

Mit aktiviertem virtuellem NAT wird ausgehender Verkehr aus dem Hub vom Server übersetzt und über die Routing-Tabelle des Hosts gesendet. Das heißt, die Weiterleitungskette lautet: Client zum virtuellen Gateway, virtuelles NAT zum Host-Stack, Host-Stack zu seiner Standardroute. Jedes Glied kann ausfallen, ohne die anderen zu berühren, und die Fehlermerkmale unterscheiden sich.

Testen Sie die zweite Entscheidung mit etwas, das den Hub verlassen muss, nicht mit etwas Lokalem darin. Das Anpingen des virtuellen Gateways beweist das erste Glied und nichts weiter:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Wenn Namensauflösung funktioniert, aber Verbindungen zu einer öffentlichen Adresse scheitern, befinden Sie sich in der Weiterleitungskette und nicht im DHCP. Wenn beides scheitert, prüfen Sie zuerst den Resolver, denn ein Resolver, der als unerreichbare interne Adresse ausgeliefert wird, lässt einen funktionierenden Weg völlig kaputt aussehen.

SecureNATs Weiterleitung wird vom Serverprozess implementiert, nicht vom Kernel-Weiterleitungspfad, den Sie mit einer Bridge nutzen würden. Das ist bequem und langsamer als Bridging, und es bedeutet auch, dass die Firewall-Regeln und Routing-Entscheidungen des Hosts weiterhin für den übersetzten Verkehr gelten. Das virtuelle NAT umgeht die Richtlinie des Hosts nicht; es nutzt sie.

Der eigene Weg des Hosts ist eine dritte Sache

Alles oben setzt voraus, dass der Serverhost das Ziel erreichen kann. Ein Host ohne funktionierende Upstream-Route, mit restriktiver Ausgangsrichtlinie oder mit einer Adressfamilie, die er nicht hat, scheitert an der zweiten Entscheidung, so korrekt die Hub-Konfiguration auch ist. Prüfen Sie den Host für sich, außerhalb des Tunnels, bevor Sie sein Scheitern SoftEther zuschreiben.

SecureNAT ist auch keine Berechtigung, jedes am Server angeschlossene Netz zu erreichen. Es übersetzt und leitet Verkehr weiter, der es erreicht; zu entscheiden, was der Host erreichen darf, bleibt Aufgabe von Firewall und Routing des Hosts, und ein Entwurf, der sich zum Gewähren von Zugriff auf den Tunnel verlässt, ist eine schlechte Regel davon entfernt, zu viel zu gewähren.

Adressfamilien verdienen eine eigene Prüfung. Ein funktionierendes IPv4-DHCP-Beispiel belegt nicht, dass jede IPv6-Fähigkeit in Ihrem Build vorhanden ist, lesen Sie deshalb das Handbuch für die Version, die Sie tatsächlich betreiben, bevor Sie Dual-Stack-Verhalten versprechen. Der SecureNAT-Abschnitt des Handbuchs behandelt die virtuellen NAT- und DHCP-Funktionen für die aktuelle Version.

Prüfen Sie jede Entscheidung mit ihrem eigenen Test

Nehmen Sie die erste Entscheidung mit einer Lease-Prüfung an: Adresse im Pool, Gateway gleich der virtuellen Host-Schnittstelle, Resolver der von Ihnen konfigurierte. Nehmen Sie die zweite mit einer ausgehenden Anfrage vom Client plus einem Blick auf die NAT-Tabelle auf dem Server an, denn eine steigende Sitzungszahl ist der einzige direkte Beleg dafür, dass Übersetzung stattfindet und nicht nur aktiviert ist.

Halten Sie die Trennung dann in der Design-Notiz fest: welche Komponente die Adresse liefert, welche Komponente weiterleitet und über welche Host-Schnittstelle der Verkehr hinausgeht. Wenn ein Neustart das Verhalten ändert, sagt Ihnen diese Notiz, welche der drei Sie prüfen müssen, statt alles neu zu starten und zu hoffen, dass das Symptom weiterwandert.

Eine weitere Entscheidung gehört in den Eintrag, auch wenn Sie sie heute nicht treffen: SecureNAT und eine lokale Bridge sind unterschiedliche Entwürfe für denselben Hub, und ein Hub, der beides braucht, ist ein Hub, der einen anderen Plan braucht. Entscheiden Sie bewusst, schreiben Sie auf, warum, und die nächste Person muss es nicht aus einer laufenden Konfiguration zurückentwickeln.

Ähnliche Artikel