El teléfono no abre la página: revise la dirección de escucha

El portátil sirve la página en localhost, el teléfono se une a la misma VPN y el navegador del teléfono informa de que no se puede acceder al sitio. Todavía no hay nada mal en el túnel, porque el túnel solo entrega paquetes. Un servidor de desarrollo ligado a la interfaz de loopback nunca acepta una conexión dirigida a otra cosa, así que el primer lugar donde mirar es el socket de escucha, no la VPN.

Repase el socket, la opción de enlace, la regla del cortafuegos y la URL, en ese orden.

El socket responde a una pregunta más estrecha

Un escucha creado en 127.0.0.1 acepta el tráfico de la propia máquina y rechaza todo lo que llega a otra dirección. Un escucha en la dirección comodín acepta en todas las interfaces locales, incluida la de la VPN, lo que es más amplio de lo que necesitan la mayoría de los entornos de desarrollo. Un escucha ligado a una dirección VPN concreta es la opción útil más estrecha, y solo funciona mientras esa dirección exista.

De ahí se derivan dos trampas de nomenclatura. En el navegador del teléfono, localhost significa el teléfono, no el portátil. La dirección comodín es un valor de enlace, no algo que se escriba en una URL. Quien pruebe con cualquiera de las dos notificará un fallo en el que la red nunca intervino.

IPv6 añade un tercer caso, porque un socket puede aceptar IPv4 e IPv6 según opciones fáciles de pasar por alto. Lea la familia de direcciones en el listado. Una entrada comodín para una familia no describe la otra.

Lea la dirección de escucha

Inspeccione el socket antes de cambiar la configuración. La dirección local, el puerto y el proceso propietario juntos identifican si el servidor es alcanzable desde la 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 dirección local de 127.0.0.1 zanja la cuestión: ningún cambio en el cortafuegos ayudará, porque la aplicación no escucha en la interfaz de la VPN. Una comodín o la dirección de la VPN significa que el socket está bien y que se aplica la siguiente frontera.

Confirme también el proceso propietario, porque un servicio ajeno en un puerto común puede hacer que la tabla parezca correcta mientras el servidor previsto nunca arrancó. Coincida la ruta del ejecutable, no solo el nombre. Un proceso obsoleto de una ejecución anterior es un impostor frecuente.

Cambie el enlace a través de la aplicación

Use la opción documentada de dirección de escucha del framework y reinicie el proceso. Si el portátil posee la dirección privada 10.77.0.1, la URL del teléfono pasa a ser http://10.77.0.1:8080/ y esa dirección debe enrutarse a través de la VPN; nada más de la configuración cambia.

No añada direcciones arbitrarias a Windows ni altere la puerta de enlace para forzar un enlace. Esos cambios sobreviven a la sesión de depuración y sorprenden a la siguiente persona. Un servidor iniciado antes de que exista la dirección de la VPN también puede fallar al enlazar, así que el orden de arranque importa para una interfaz transitoria. Delé un reintento o inícielo después del túnel. Un fallo de enlace al arrancar parece exactamente un problema de cortafuegos a la mañana siguiente.

Para HTTPS, mantenga intactos el nombre de host del servicio y la validación del certificado. Un aviso de certificado en una dirección cruda es un problema de nomenclatura, no un paso que se pulsa, y el DNS privado tiene que concordar con el escucha que eligió.

Abra una regla, no toda la red

Una vez que el socket acepta en la dirección de la VPN, el cortafuegos decide si la petición llega. Limite la regla a esta aplicación, este protocolo, este puerto local y la fuente remota autorizada, y confirme qué perfil está activo en el adaptador de la VPN.

Use la dirección de origen que Windows ve realmente, incluida cualquier traducción que haga la puerta de enlace, porque una regla escrita para la dirección original del cliente no coincidirá con una traducida.

Una página que carga y muestra un error de la aplicación es progreso: el rechazo HTTP es un fallo distinto de la ausencia de conexión TCP, y la siguiente investigación corresponde a la política de acceso de la propia aplicación, no a la red.

Termine solicitando la página desde el teléfono previsto y confirmando que un dispositivo excluido sigue sin poder alcanzarla. Un escucha que funciona con una regla que lo admite todo no es el mismo resultado.