Telefoon kan de pagina niet openen: controleer het luisteradres
Een pagina die antwoordt op localhost kan alleen aan loopback gebonden zijn. Lees het socketadres, dan de firewallregel en de URL die de telefoon echt gebruikt.
De laptop serveert de pagina op localhost, de telefoon sluit zich bij dezelfde VPN aan, en de browser op de telefoon meldt dat de site niet bereikbaar is. Aan de tunnel is nog niets mis, want de tunnel levert alleen pakketten. Een ontwikkelserver die aan de loopback-interface is gebonden accepteert nooit een verbinding die aan iets anders is gericht, dus de eerste plek om te kijken is de luisterende socket en niet de VPN.
Werk de socket, de bind-instelling, de firewallregel en de URL af, in die volgorde.
De socket beantwoordt een smallere vraag
Een listener die op 127.0.0.1 is gemaakt, accepteert verkeer van de machine zelf en weigert alles wat op een ander adres binnenkomt. Een listener op het jokertekenadres accepteert op elke lokale interface, inclusief de VPN-interface, wat breder is dan de meeste ontwikkelopstellingen nodig hebben. Een listener die aan één specifiek VPN-adres is gebonden, is de smalste bruikbare optie, en die werkt alleen zolang dat adres bestaat.
Daaruit volgen twee naamvallen. In de browser op de telefoon betekent localhost de telefoon, niet de laptop. Het jokertekenadres is een bind-waarde en niet iets om in een URL te typen. Wie met een van beide test, meldt een storing die nooit met het netwerk te maken had.
IPv6 voegt een derde geval toe, omdat een socket IPv4 en IPv6 kan accepteren afhankelijk van opties die makkelijk over het hoofd worden gezien. Lees de adresfamilie in de lijst. Een jokertekenvermelding voor de ene familie beschrijft de andere niet.
Lees het luisteradres
Inspecteer de socket voordat je de configuratie wijzigt. Het lokale adres, de poort en het eigenaarsproces bepalen samen of de server überhaupt vanaf de VPN bereikbaar is.
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
Een lokaal adres van 127.0.0.1 beslecht de vraag: geen enkele firewallwijziging helpt, want de applicatie luistert niet op de VPN-interface. Een jokerteken of het VPN-adres betekent dat de socket in orde is en dat de volgende grens geldt.
Bevestig ook het eigenaarsproces, want een niet-gerelateerde dienst op een gangbare poort kan de tabel er correct laten uitzien terwijl de bedoelde server nooit is gestart. Vergelijk het pad van het uitvoerbare bestand, niet alleen de naam. Een oud proces van een eerdere run is een veelvoorkomende bedrieger.
Wijzig de bind via de applicatie
Gebruik de gedocumenteerde luisteradresoptie van het framework en herstart het proces. Als de laptop het privéadres 10.77.0.1 bezit, wordt de URL van de telefoon http://10.77.0.1:8080/ en moet dat adres via de VPN worden gerouteerd; verder verandert er niets aan de opstelling.
Voeg geen willekeurige adressen toe aan Windows en wijzig de gateway niet om een bind af te dwingen. Die wijzigingen overleven de debugsessie en verrassen de volgende persoon. Een server die start voordat het VPN-adres bestaat, kan ook niet binden, dus de startvolgorde is van belang voor een tijdelijk interface. Geef hem een nieuwe poging of start hem na de tunnel. Een bind-fout bij het opstarten ziet er de volgende ochtend precies uit als een firewallprobleem.
Houd bij HTTPS de servicenaam en de certificaatvalidatie intact. Een certificaatwaarschuwing op een kaal adres is een naamprobleem, geen stap om weg te klikken, en private DNS moet overeenkomen met de listener die je hebt gekozen.
Open één regel, niet het hele netwerk
Zodra de socket op het VPN-adres accepteert, bepaalt de firewall of het verzoek aankomt. Beperk de regel tot deze applicatie, dit protocol, deze lokale poort en de geautoriseerde externe bron, en bevestig welk profiel actief is op de VPN-adapter.
Gebruik het bronadres dat Windows werkelijk ziet, inclusief elke vertaling die de gateway uitvoert, want een regel die voor het oorspronkelijke clientadres is geschreven, past niet op een vertaald adres.
Een pagina die laadt en een applicatiefout toont, is vooruitgang: HTTP-weigering is een ander falen dan geen TCP-verbinding, en het volgende onderzoek hoort bij het toegangsbeleid van de applicatie zelf en niet bij het netwerk.
Sluit af door de pagina vanaf de bedoelde telefoon op te vragen en te bevestigen dat een uitgesloten apparaat er nog steeds niet bij kan. Een werkende listener met een regel die alles toelaat, is niet hetzelfde resultaat.