O teléfono non abre a páxina: revise a dirección de escoita

O portátil serve a páxina en localhost, o teléfono únese á mesma VPN e o navegador do teléfono informa de que non se pode acceder ao sitio. Aínda non hai nada mal no túnel, porque o túnel só entrega paquetes. Un servidor de desenvolvemento ligado á interface de loopback nunca acepta unha conexión dirixida a outra cousa, así que o primeiro lugar onde mirar é o socket de escoita, non a VPN.

Repase o socket, a opción de ligazón, a regra da devasa e o URL, nesa orde.

O socket responde a unha pregunta máis estreita

Un escoitador creado en 127.0.0.1 acepta o tráfico da propia máquina e rexeita todo o que chega a outra dirección. Un escoitador na dirección comodín acepta en todas as interfaces locais, incluída a da VPN, o que é máis amplo do que necesitan a maioría das contornas de desenvolvemento. Un escoitador ligado a unha dirección VPN concreta é a opción útil máis estreita, e só funciona mentres esa dirección exista.

De aí derívanse dúas trampas de nomenclatura. No navegador do teléfono, localhost significa o teléfono, non o portátil. A dirección comodín é un valor de ligazón, non algo que se escriba nun URL. Quen probe con calquera das dúas notificará un fallo no que a rede nunca interveu.

IPv6 engade un terceiro caso, porque un socket pode aceptar IPv4 e IPv6 segundo opcións fáciles de pasar por alto. Lea a familia de direccións na listaxe. Unha entrada comodín para unha familia non describe a outra.

Lea a dirección de escoita

Inspeccione o socket antes de cambiar a configuración. A dirección local, o porto e o proceso propietario xuntos identifican se o servidor é alcanzable desde a 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

Unha dirección local de 127.0.0.1 resolve a cuestión: ningún cambio na devasa axudará, porque a aplicación non escoita na interface da VPN. Unha comodín ou a dirección da VPN significa que o socket está ben e que se aplica a seguinte fronteira.

Confirme tamén o proceso propietario, porque un servizo alleo nun porto común pode facer que a táboa pareza correcta mentres o servidor previsto nunca arrancou. Coincida a ruta do executábel, non só o nome. Un proceso obsoleto dunha execución anterior é un impostor frecuente.

Cambie a ligazón a través da aplicación

Use a opción documentada de dirección de escoita do framework e reinicie o proceso. Se o portátil posúe a dirección privada 10.77.0.1, o URL do teléfono pasa a ser http://10.77.0.1:8080/ e esa dirección debe encamiñarse a través da VPN; nada máis da configuración cambia.

Non engada direccións arbitrarias a Windows nin altere a pasarela para forzar unha ligazón. Eses cambios sobreviven á sesión de depuración e sorprenden á seguinte persoa. Un servidor iniciado antes de que exista a dirección da VPN tamén pode fallar ao ligar, así que a orde de arranque importa para unha interface transitoria. Délle un reintento ou inícieo despois do túnel. Un fallo de ligazón ao arrancar parece exactamente un problema de devasa á mañá seguinte.

Para HTTPS, manteña intactos o nome de host do servizo e a validación do certificado. Un aviso de certificado nunha dirección crua é un problema de nomenclatura, non un paso que se pulsa, e o DNS privado ten que concordar co escoitador que escolleu.

Abra unha regra, non toda a rede

Unha vez que o socket acepta na dirección da VPN, a devasa decide se a petición chega. Limite a regra a esta aplicación, este protocolo, este porto local e a fonte remota autorizada, e confirme que perfil está activo no adaptador da VPN.

Use a dirección de orixe que Windows ve realmente, incluída calquera tradución que faga a pasarela, porque unha regra escrita para a dirección orixinal do cliente non coincidirá cunha traducida.

Unha páxina que carga e mostra un erro da aplicación é progreso: o rexeitamento HTTP é un fallo distinto da ausencia de conexión TCP, e a seguinte investigación corresponde á política de acceso da propia aplicación, non á rede.

Remate solicitando a páxina desde o teléfono previsto e confirmando que un dispositivo excluído segue sen poder alcanzala. Un escoitador que funciona cunha regra que o admite todo non é o mesmo resultado.