Telefon kann die Seite nicht öffnen: Prüfen Sie die Listen-Adresse

Der Laptop liefert die Seite unter localhost aus, das Telefon tritt demselben VPN bei, und der Browser auf dem Telefon meldet, dass die Website nicht erreichbar ist. Am Tunnel ist noch nichts falsch, denn der Tunnel befördert nur Pakete. Ein Entwicklungsserver, der an die Loopback-Schnittstelle gebunden ist nimmt niemals eine Verbindung an, die an etwas anderes adressiert ist, deshalb ist die erste Stelle zum Nachsehen der lauschende Socket und nicht das VPN.

Arbeiten Sie den Socket, die Bind-Einstellung, die Firewall-Regel und die URL in dieser Reihenfolge durch.

Der Socket beantwortet eine engere Frage

Ein Listener, der auf 127.0.0.1 angelegt wurde, nimmt Verkehr vom Rechner selbst an und weist alles ab, was auf einer anderen Adresse eintrifft. Ein Listener auf der Wildcard-Adresse nimmt auf jeder lokalen Schnittstelle an, einschließlich der VPN-Schnittstelle, was weiter ist, als die meisten Entwicklungsumgebungen brauchen. Ein Listener, der an eine bestimmte VPN-Adresse gebunden ist, ist die engste sinnvolle Option, und er funktioniert nur, solange diese Adresse existiert.

Daraus folgen zwei Namensfallen. Im Browser des Telefons bedeutet localhost das Telefon, nicht den Laptop. Die Wildcard-Adresse ist ein Bind-Wert und nichts, was man in eine URL tippt. Wer mit einem von beidem testet, meldet einen Fehler, an dem das Netzwerk nie beteiligt war.

IPv6 fügt einen dritten Fall hinzu, denn ein Socket kann IPv4 und IPv6 annehmen, je nach Optionen, die leicht übersehen werden. Lesen Sie die Adressfamilie in der Auflistung. Ein Wildcard-Eintrag für eine Familie beschreibt die andere nicht.

Lesen Sie die Listen-Adresse

Untersuchen Sie den Socket, bevor Sie die Konfiguration ändern. Lokale Adresse, Port und besitzender Prozess zusammen zeigen, ob der Server überhaupt vom VPN aus erreichbar ist.

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

Eine lokale Adresse von 127.0.0.1 entscheidet die Frage: Keine Firewall-Änderung hilft, weil die Anwendung nicht auf der VPN-Schnittstelle lauscht. Wildcard oder die VPN-Adresse bedeutet, dass der Socket in Ordnung ist und die nächste Grenze gilt.

Bestätigen Sie auch den besitzenden Prozess, denn ein fremder Dienst auf einem gängigen Port kann die Tabelle korrekt aussehen lassen, während der beabsichtigte Server nie gestartet ist. Gleichen Sie den Pfad der ausführbaren Datei ab, nicht nur den Namen. Ein veralteter Prozess aus einem früheren Lauf ist ein häufiger Hochstapler.

Ändern Sie das Bind über die Anwendung

Verwenden Sie die dokumentierte Listen-Adress-Option des Frameworks und starten Sie den Prozess neu. Gehört dem Laptop die private Adresse 10.77.0.1, wird die URL des Telefons zu http://10.77.0.1:8080/ und diese Adresse muss durch das VPN geroutet werden; sonst ändert sich nichts am Aufbau.

Fügen Sie Windows keine beliebigen Adressen hinzu und ändern Sie nicht das Gateway, um ein Bind zu erzwingen. Diese Änderungen überleben die Debugging-Sitzung und überraschen die nächste Person. Ein Server, der gestartet wird, bevor die VPN-Adresse existiert, kann ebenfalls beim Bind scheitern, deshalb ist die Startreihenfolge bei einer flüchtigen Schnittstelle wichtig. Geben Sie ihm einen neuen Versuch oder starten Sie ihn nach dem Tunnel. Ein Bind-Fehler beim Booten sieht am nächsten Morgen genau wie ein Firewall-Problem aus.

Bei HTTPS halten Sie den Dienst-Hostnamen und die Zertifikatsprüfung intakt. Eine Zertifikatswarnung auf einer rohen Adresse ist ein Namensproblem und kein Schritt zum Wegklicken, und privates DNS muss mit dem gewählten Listener übereinstimmen.

Öffnen Sie eine Regel, nicht das ganze Netz

Sobald der Socket auf der VPN-Adresse annimmt, entscheidet die Firewall, ob die Anfrage ankommt. Beschränken Sie die Regel auf diese Anwendung, dieses Protokoll, diesen lokalen Port und die autorisierte entfernte Quelle, und prüfen Sie, welches Profil auf dem VPN-Adapter aktiv ist.

Verwenden Sie die Quelladresse, die Windows tatsächlich sieht, einschließlich jeder Übersetzung, die das Gateway vornimmt, denn eine Regel für die ursprüngliche Client-Adresse passt nicht auf eine übersetzte.

Eine Seite, die lädt und einen Anwendungsfehler zeigt, ist ein Fortschritt: HTTP-Ablehnung ist ein anderer Fehler als keine TCP-Verbindung, und die nächste Untersuchung gehört zur Zugriffsrichtlinie der Anwendung, nicht zum Netz.

Beenden Sie damit, die Seite vom vorgesehenen Telefon anzufordern und zu bestätigen, dass ein ausgeschlossenes Gerät sie weiterhin nicht erreicht. Ein funktionierender Listener mit einer Regel, die alles zulässt, ist nicht dasselbe Ergebnis.