Der Gateway hostet seine eigene Admin-Seite: innere oder öffentliche Adresse

Eine Admin-Seite antwortet von einem Telefon über Mobilfunk und läuft von einem Laptop, der dem VPN beigetreten ist, in eine Zeitüberschreitung. Am Tunnel ist nichts kaputt, weil die Anfrage nie in ihn hineingelangt. Der Hostname wird auf die öffentliche Adresse des Gateways aufgelöst, und diese Adresse ist nur von außerhalb des Tunnels erreichbar, den er beendet. Das zu beheben heißt, dem Dienst einen privaten Einstieg zu geben, statt den äußeren Endpunkt zu verschieben.

Die Seite lädt von außen und nicht durch den Tunnel

Es werden zwei verschiedene Anfragen verglichen. Über Mobilfunk erreicht der Browser die öffentliche Adresse direkt. Von innerhalb des Tunnels wird derselbe Name auf dieselbe öffentliche Adresse aufgelöst, und das Paket muss nun durch den Tunnel hinaus, um eine Adresse auf der eigenen fernen Seite des Tunnels zu erreichen. Derselbe Name, dieselbe Adresse, zwei sehr verschiedene Positionen.

Eine Zielroute wählt eine Adresse, nicht einen Port. Nichts in der Routing-Tabelle weiß, dass Port 443 für Administration und Port 1194 der Transport ist, also werden beide als dasselbe Ziel behandelt.

Deshalb funktioniert die Seite manchmal und manchmal nicht, je nachdem welchen Namen und welches Netz der Client benutzt hat. Es ist ein Pfadproblem und kein Authentifizierungsproblem. Beide Clients authentifizieren sich einwandfrei.

Halten Sie den äußeren Endpunkt erreichbar

Full-Tunnel-Profile brauchen eine Ausnahmeroute für den VPN-Endpunkt, und OpenVPNs redirect-gateway-Option dokumentiert genau das: Der entfernte Endpunkt behält eine Route über das bereits vorhandene Gateway, damit der Tunnel nicht in sich selbst routet. Entfernt man diese Ausnahme, folgt der verschlüsselte Transport dem Tunnel, was die Sitzung in einer Schleife beendet. Diese Ausnahme ist der Grund, warum die Endpunktadresse von innerhalb des Tunnels erreichbar bleibt.

Die Folge ist, dass die öffentliche Adresse vom Client aus erreichbar bleibt, weshalb eine Browseranfrage an diese Adresse dieselbe Ausnahme befolgen und hinausgehen kann, ohne in den Tunnel zu gelangen. Die Ausnahme tut ihre Arbeit, und der Name richtet den Schaden an.

Lesen Sie die Routenentscheidung statt der Schnittstellenliste, bevor Sie etwas ändern. Die Befehle unten geben die Entscheidung statt des Inventars aus. Führen Sie sie von dem Client aus, der versagt hat.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Wenn die Abfrage die Endpunktroute über das physische Gateway zeigt, ist das Verhalten korrekt, und die Admin-Seite wird einfach auf den falschen Pfad geschickt. Das ist der Punkt, an dem die Namensauflösung zur Lösung wird.

Geben Sie dem Dienst einen privaten Namen

Der Dienst braucht einen Namen, der sich innerhalb des Tunnels auf die Adresse des Gateways auflöst, während die Zertifikats- und Hostnamen-Semantik erhalten bleibt, die die Anwendung erwartet. Ein privater Zoneneintrag für den Administrationsnamen ist die übliche Antwort, und er lässt den Transportnamen unberührt.

Richten Sie den Transportnamen nicht auf die innere Adresse um, weil der nächste Tunnelaufbau dann versuchen würde, eine Adresse zu erreichen, die nur innerhalb eines Tunnels existiert. Dieser Fehler ergibt ein VPN, das genau einmal funktioniert.

Prüfen Sie auch beide Adressfamilien, denn ein zurückgelassener AAAA-Eintrag kann den Browser dorthin schicken, wo der private Plan nie gegriffen hat.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Passen Sie die Richtlinie an, wo der Prozess läuft

Ein nativer Prozess, der auf dem Gateway lauscht, wird über den lokalen Eingabepfad erreicht, also entscheiden die Eingabekette und die Socket-Bindung, ob die Anfrage angenommen wird. Weiterleitungsregeln und IP-Weiterleitung bringen einen lokalen Listener nicht dazu, zu antworten. Erlauben Sie die Tunnelquellen in der Eingaberichtlinie und bestätigen Sie, dass der Prozess an eine Adresse gebunden ist, die der Tunnel erreichen kann.

Ein Container, der auf einem Host-Port veröffentlicht ist, folgt einem anderen Pfad, weil das Paket zielübersetzt und weitergeleitet wird. Diese Anfrage trifft auf die Weiterleitungsrichtlinie des Hosts und Dockers eigene Regeln, weshalb ein funktionierender nativer Listener neben einem Container bestehen kann, der denselben Port verweigert.

Die Startreihenfolge ist in beiden Fällen wichtig, weil eine Bindung an eine Adresse, die erst erscheint, nachdem der Tunnel hochkommt, beim Booten stillschweigend fehlschlägt.

Prüfen Sie privaten Zugriff und einen verweigerten öffentlichen Pfad

Stellen Sie eine frische benannte Anfrage von einem autorisierten Client, wobei die eigenen Identitätsprüfungen der Anwendung intakt bleiben. Versuchen Sie dann denselben Dienst von außerhalb des Tunnels und bestätigen Sie, dass er nicht antwortet. Ein privater Name ist eine Bequemlichkeit und keine Einschränkung, und ein Listener, der noch an die öffentliche Adresse gebunden ist, ist noch exponiert. Diese letzte Prüfung ist die, die die meisten Reviews überspringen.

Lesen Sie die Bindungen und den Filterzustand statt den Hostnamen, den die Nutzer bekommen haben. Exposition ist eine Eigenschaft des Sockets und nicht des Namens. Diese Unterscheidung überlebt jede DNS-Änderung.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Wenn die innere Anfrage die Seite zurückgibt und die äußere Anfrage in eine Zeitüberschreitung läuft, hat der Dienst einen bewussten privaten Pfad, und der Transport bleibt erreichbar. Wenn die äußere Anfrage weiterhin antwortet, müssen der Listener oder ein veröffentlichter Container-Eintrag eingegrenzt werden, bevor jemand den Dienst als nur intern beschreibt.