Warum die Adresse Ihres VPN-Tunnels keinen eingehenden Port öffnet
Eine Tunneladresse identifiziert Ihren Client gegenüber Peers, die dorthin routen können, und erzeugt nie einen Listener. Prüfen Sie die Bindung, die Rückroute und dann die Richtlinie.
Stellen Sie eine Verbindung zum Büro-VPN her, starten Sie einen kleinen Dienst auf Port 8443, schicken Sie die Tunneladresse an einen Kollegen und beobachten Sie, wie die Verbindung fehlschlägt, während der Client weiterhin „verbunden“ meldet. Am Tunnel ist nichts defekt: Die Adresse wurde vergeben, die Sitzung steht, und die Pakete, die die Antwort tragen würden, werden schlicht nie zugelassen. Arbeiten Sie die drei Prüfungen unten in dieser Reihenfolge ab und bleiben Sie bei der stehen, die fehlschlägt, denn jede hat eine andere Korrektur und nur eine davon betrifft das VPN.
Beginnen Sie damit, wo der Socket tatsächlich gebunden ist
Bevor irgendetwas geroutet wird, muss etwas auf einer Adresse lauschen, die der Aufrufer erreichen kann. Entwicklungsserver sind der übliche Übeltäter, denn viele binden standardmäßig an Loopback und akzeptieren nur Verbindungen, die auf derselben Maschine entstehen. Eine Tunneladresse ändert diese Bindung nicht, und das Betriebssystem wird die Verbindung ablehnen, lange bevor das VPN überhaupt beteiligt ist.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Lesen Sie die Spalte der lokalen Adresse statt des Zustands. 127.0.0.1:8443 bedeutet nur Loopback, und die Korrektur ist eine Bindung an 0.0.0.0 oder an die Tunneladresse selbst. 0.0.0.0:8443 akzeptiert auf allen Schnittstellen, was weiter reicht, als die meisten beabsichtigen, wenn die Maschine auch eine öffentliche Adresse hat; 10.64.7.15:8443 ist die schmale Variante, die nur dort lauscht, wo der Kollege sie erreicht. Achten Sie in derselben Ausgabe auf den Prozessnamen, denn eine übrig gebliebene Instanz aus einem früheren Test ist ein häufiger Grund, warum der Port offen aussieht und mit falschem Inhalt antwortet.
Fragen Sie dann, ob etwas zu dieser Adresse routen kann
Eine Tunneladresse ist nur für Peers sinnvoll, die dafür konfiguriert sind, dieses Präfix in den Tunnel zu schicken. Die Maschine des Kollegen hat ihre eigene Tabelle, und ohne eine Route für das Tunnel-Subnetz geht das Paket zum Standardgateway und stirbt an einer Stelle, die von der Existenz der Adresse nichts weiß. Das ist eine Routing-Frage auf der Seite des Aufrufers, keine Berechtigung auf Ihrer Seite.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Der Server zwischen den beiden Clients zählt genauso. Im üblichen Fernzugriffsdesign öffnet jeder Client eine ausgehende Verbindung zum Gateway, und das Gateway hält den Zustand für diese Flows, sodass Antworten auf einem Pfad zurückkommen, den es bereits kennt. Eine Verbindung von einem Client zu einem anderen ist ein neuer Flow, den das Gateway annehmen und weiterleiten muss, und viele Installationen deaktivieren das bewusst, um Clients voneinander isoliert zu halten. Consumer-VPN-Dienste isolieren standardmäßig; Unternehmensgateways erlauben es manchmal gruppenweise.
Prüfen Sie die Richtung, bevor Sie etwas am Host ändern. Wenn die Tunneladresse vom Gateway selbst antwortet, aber nicht von einem Peer, ist die Client-zu-Client-Einstellung des Gateways der Unterschied, und keine Bearbeitung der lokalen Firewall ersetzt sie.
Finden Sie schließlich die Richtlinie, die den Flow erlaubt
Zwischen einem gerouteten Paket und einem antwortenden Dienst liegen drei Richtlinienebenen: die Weiterleitungsentscheidung des VPN-Servers, die Host-Firewall und jede Cloud-Sicherheitsgruppe vor der Instanz. Alle drei müssen übereinstimmen, und sie scheitern auf unterschiedliche Weise, weshalb das Symptom in der Tabelle oben nützlicher ist als die Fehlermeldung im Browser.
Die Host-Firewall ist die Ebene, die man nach einer erfolgreichen Bindung vergisst, denn eine Regel, die den Port auf der LAN-Schnittstelle erlaubt, erlaubt ihn nicht automatisch auf der Tunnelschnittstelle. Schnittstellengebundene Regeln sind korrektes Design und zugleich die übliche Ursache eines Dienstes, der aus dem Büro funktioniert und von zu Hause nicht. Lesen Sie den Geltungsbereich der Regel statt ihre Portnummer.
Stateful Filtering erklärt den umgekehrten Fall. Eine ausgehende Verbindung von Ihrem Laptop erzeugt Zustand, und Antworten darauf werden ohne eingehende Regel zugelassen. Die Verbindung des Kollegen ist ein völlig neuer Flow ohne Zustand dahinter, braucht also eine ausdrückliche Freigabe. Diese Asymmetrie ist der ganze Grund, warum eine funktionierende Browsersitzung auf Ihrer eigenen Maschine nichts darüber aussagt, ob der Dienst von außen erreichbar ist.
Wenn eine Prüfung fehlschlägt, ändern Sie das Design statt den Tunnel
Wenn die Anforderung ist, dass ein Kollege Ihren lokalen Dienst öffnet, ist die ehrliche Antwort meist ein Mechanismus für eingehenden Zugriff. Ein Reverse-SSH-Tunnel ist der kleinste: Ihre Maschine verbindet sich ausgehend zu einem Host, den der Kollege bereits erreicht, und der Listener existiert auf diesem Host.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Das Relay braucht GatewayPorts clientspecified in seiner SSH-Serverkonfiguration, sonst bindet der weitergeleitete Listener auf dem Relay an Loopback, und der Kollege trifft dieselbe Ablehnung wie zuvor. Für alles, was länger als einen Nachmittag hält, ist ein Lastverteiler oder Ingress mit Health-Check und Zertifikat für den veröffentlichten Namen das bessere Werkzeug, und ein Standort-zu-Standort-Tunnel mit Routen für beide Subnetze die richtige Antwort, wenn zwei Netze wirklich miteinander sprechen müssen.
Jedes dieser Designs macht die Exposition ausdrücklich, und das ist der Punkt. Ein VPN bewegt Pakete zwischen Netzen, für die Sie ohnehin autorisiert waren; es veröffentlicht keinen Dienst und macht aus einem Laptop keinen ins Internet gerichteten Host. Zu entscheiden, welche der drei Ebenen zu ändern ist, ist die Aufgabe, und der Tunnel ist selten eine davon.