L'ordinador portàtil serveix la pàgina a localhost, el telèfon s'uneix al mateix VPN i el navegador del telèfon informa que no es pot arribar al lloc. Encara no hi ha res malament amb el túnel, perquè el túnel només lliura paquets. Un servidor de desenvolupament lligat a la interfície de loopback no accepta mai una connexió adreçada a qualsevol altra cosa, així que el primer lloc on cal mirar és el sòcol d'escolta, no el VPN.

Reviseu el sòcol, el paràmetre de bind, la regla del tallafoc i l'URL, en aquest ordre.

El sòcol respon una pregunta més estreta

Un oient creat a 127.0.0.1 accepta el trànsit de la mateixa màquina i refusa tot el que arriba a una altra adreça. Un oient a l'adreça comodí accepta a totes les interfícies locals, inclosa la del VPN, cosa que és més àmplia del que necessiten la majoria d'entorns de desenvolupament. Un oient lligat a una adreça VPN concreta és l'opció útil més estreta, i només funciona mentre aquesta adreça existeix.

D'això se'n deriven dues trampes de nomenclatura. Al navegador del telèfon, localhost vol dir el telèfon, no l'ordinador portàtil. L'adreça comodí és un valor de bind, no una cosa per escriure en un URL. Qui provi amb qualsevol de les dues reportarà un error que mai no va implicar la xarxa.

IPv6 afegeix un tercer cas, perquè un sòcol pot acceptar IPv4 i IPv6 segons opcions fàcils de passar per alt. Llegiu la família d'adreces del llistat. Una entrada comodí per a una família no descriu l'altra.

Llegiu l'adreça d'escolta

Inspeccioneu el sòcol abans de canviar la configuració. L'adreça local, el port i el procés propietari identifiquen plegats si el servidor és abastable des del VPN.

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

Una adreça local de 127.0.0.1 resol la qüestió: cap canvi al tallafoc no ajudarà, perquè l'aplicació no escolta a la interfície del VPN. Una comodí o l'adreça del VPN vol dir que el sòcol està bé i que s'aplica la següent frontera.

Confirmeu també el procés propietari, perquè un servei no relacionat en un port comú pot fer que la taula sembli correcta mentre el servidor previst mai no s'ha iniciat. Coincidiu la ruta de l'executable, no només el nom. Un procés obsolet d'una execució anterior és un impostor freqüent.

Canvieu el bind a través de l'aplicació

Utilitzeu l'opció d'adreça d'escolta documentada pel framework i reinicieu el procés. Si l'ordinador portàtil té l'adreça privada 10.77.0.1, l'URL del telèfon passa a ser http://10.77.0.1:8080/ i aquesta adreça s'ha d'encaminar a través del VPN; res més de la configuració no canvia.

No afegiu adreces arbitràries a Windows ni altereu la passarel·la per forçar un bind. Aquests canvis sobreviuen a la sessió de depuració i sorprenen la persona següent. Un servidor iniciat abans que existeixi l'adreça del VPN també pot fallar en el bind, així que l'ordre d'inici importa per a una interfície transitòria. Doneu-li un reintent o inicieu-lo després del túnel. Una fallada de bind a l'arrencada sembla exactament un problema de tallafoc l'endemà al matí.

Per a HTTPS, manteniu intactes el nom d'amfitrió del servei i la validació del certificat. Un avís de certificat en una adreça crua és un problema de nomenclatura, no un pas per clicar, i el DNS privat ha de concordar amb l'oient que heu triat.

Obriu una regla, no tota la xarxa

Un cop el sòcol accepta a l'adreça del VPN, el tallafoc decideix si la petició arriba. Limiteu la regla a aquesta aplicació, aquest protocol, aquest port local i la font remota autoritzada, i confirmeu quin perfil és actiu a l'adaptador del VPN.

Useu l'adreça d'origen que Windows veu realment, incloent-hi qualsevol traducció que faci la passarel·la, perquè una regla escrita per a l'adreça original del client no coincidirà amb una de traduïda.

Una pàgina que carrega i mostra un error d'aplicació és progrés: el rebuig HTTP és una fallada diferent de la manca de connexió TCP, i la investigació següent pertany a la política d'accés de l'aplicació, no a la xarxa.

Acabeu demanant la pàgina des del telèfon previst i confirmant que un dispositiu exclòs encara no hi pot arribar. Un oient que funciona amb una regla que ho admet tot no és el mateix resultat.

Articles relacionats