A laptop a localhoston szolgálja ki az oldalt, a telefon ugyanahhoz a VPN-hez csatlakozik, és a telefon böngészője azt jelzi, hogy az oldal nem érhető el. Az alagúttal még nincs semmi baj, mert az alagút csak csomagokat továbbít. A loopback interfészhez kötött fejlesztői kiszolgáló soha nem fogad el más címre irányított kapcsolatot, ezért elsőként a figyelő socketet kell megnézni, nem a VPN-t.

Vegye sorra a socketet, a bind beállítást, a tűzfal-szabályt és az URL-t, ebben a sorrendben.

A socket szűkebb kérdésre válaszol

Az 127.0.0.1-en létrehozott figyelő elfogadja a gépről érkező forgalmat, és elutasít mindent, ami más címre érkezik. A wildcard címen lévő figyelő minden helyi interfészen elfogad, beleértve a VPN interfészt is, ami szélesebb, mint amire a legtöbb fejlesztői környezetnek szüksége van. Az egy adott VPN-címhez kötött figyelő a legszűkebb hasznos lehetőség, és csak addig működik, amíg az a cím létezik.

Ebből két elnevezési csapda következik. A telefon böngészőjében a localhost a telefont jelenti, nem a laptopot. A wildcard cím bind-érték, nem valami, amit URL-be kell írni. Aki bármelyikkel tesztel, olyan hibát jelent, amelyben a hálózat egyáltalán nem vett részt.

Az IPv6 egy harmadik esetet ad hozzá, mert a socket a könnyen figyelmen kívül hagyott beállításoktól függően fogadhat IPv4-et és IPv6-ot. Olvassa ki a címcsaládot a listából. Az egyik család wildcard bejegyzése nem írja le a másikat.

Olvassa ki a figyelési címet

Vizsgálja meg a socketet, mielőtt módosítja a konfigurációt. A helyi cím, a port és a birtokló folyamat együtt megmutatja, hogy a kiszolgáló egyáltalán elérhető-e a VPN-ből.

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

Az 127.0.0.1 helyi cím eldönti a kérdést: semmilyen tűzfal-módosítás nem segít, mert az alkalmazás nem figyel a VPN interfészen. A wildcard vagy a VPN-cím azt jelenti, hogy a socket rendben van, és a következő határ érvényes.

Erősítse meg a birtokló folyamatot is, mert egy gyakori porton futó, nem kapcsolódó szolgáltatás helyesnek tüntetheti fel a táblázatot, miközben a szándékolt kiszolgáló soha nem indult el. A futtatható fájl útvonalát egyeztesse, ne csak a nevét. Egy korábbi futásból maradt elavult folyamat gyakori csaló.

Módosítsa a bindot az alkalmazáson keresztül

Használja a keretrendszer dokumentált figyelési cím beállítását, és indítsa újra a folyamatot. Ha a laptop birtokolja a 10.77.0.1 privát címet, a telefon URL-je http://10.77.0.1:8080/ lesz, és ezt a címet a VPN-en keresztül kell irányítani; a beállításban semmi más nem változik.

Ne adjon hozzá tetszőleges címeket a Windowshoz, és ne módosítsa az átjárót a bind kikényszerítéséhez. Ezek a változtatások túlélik a hibakeresési munkamenetet, és meglepik a következő embert. Egy VPN-cím létezése előtt indított kiszolgáló is meghiúsulhat a bindban, ezért egy átmeneti interfésznél számít az indítási sorrend. Adjon neki új próbálkozást, vagy indítsa el az alagút után. A bind meghiúsulása rendszerindításkor másnap reggel pontosan tűzfalproblémának látszik.

HTTPS esetén tartsa érintetlenül a szolgáltatás hosztnevét és a tanúsítvány ellenőrzését. A tanúsítványfigyelmeztetés nyers címen elnevezési probléma, nem átkattintandó lépés, és a privát DNS-nek meg kell egyeznie a választott figyelővel.

Egy szabályt nyisson meg, ne az egész hálózatot

Amint a socket elfogad a VPN-címen, a tűzfal dönti el, hogy megérkezik-e a kérés. Szűkítse a szabályt erre az alkalmazásra, erre a protokollra, erre a helyi portra és az engedélyezett távoli forrásra, és erősítse meg, melyik profil aktív a VPN-adapteren.

Azt a forrás címet használja, amelyet a Windows valóban lát, beleértve az átjáró által végzett bármilyen fordítást, mert az eredeti klienscímre írt szabály nem fog egyezni a lefordítottal.

Az az oldal, amely betöltődik és alkalmazáshibát mutat, előrelépés: a HTTP-elutasítás más hiba, mint a TCP-kapcsolat hiánya, és a következő vizsgálat az alkalmazás saját hozzáférési szabályához tartozik, nem a hálózathoz.

Fejezze be azzal, hogy a szándékolt telefonról kéri az oldalt, és megerősíti, hogy egy kizárt eszköz továbbra sem éri el. Egy működő figyelő mindent beengedő szabállyal nem ugyanaz az eredmény.

Kapcsolódó cikkek