Telefone não abre a página: verifique o endereço de escuta

O laptop serve a página em localhost, o telefone entra na mesma VPN e o navegador do telefone informa que o site não pode ser alcançado. Ainda não há nada de errado com o túnel, porque o túnel apenas entrega pacotes. Um servidor de desenvolvimento vinculado à interface de loopback nunca aceita uma conexão endereçada a outra coisa, então o primeiro lugar a examinar é o socket de escuta, e não a VPN.

Percorra o socket, a configuração de vinculação, a regra de firewall e a URL, nessa ordem.

O socket responde a uma pergunta mais estreita

Um listener criado em 127.0.0.1 aceita tráfego da própria máquina e recusa tudo o que chega em outro endereço. Um listener no endereço curinga aceita em todas as interfaces locais, inclusive na interface da VPN, o que é mais amplo do que a maioria das configurações de desenvolvimento precisa. Um listener vinculado a um endereço de VPN específico é a opção útil mais estreita, e só funciona enquanto esse endereço existir.

Duas armadilhas de nomenclatura decorrem disso. No navegador do telefone, localhost significa o telefone, não o laptop. O endereço curinga é um valor de vinculação e não algo para digitar numa URL. Quem testar com qualquer um dos dois relatará uma falha que nunca envolveu a rede.

O IPv6 acrescenta um terceiro caso, porque um socket pode aceitar IPv4 e IPv6 dependendo de opções fáceis de ignorar. Leia a família de endereços na listagem. Uma entrada curinga para uma família não descreve a outra.

Leia o endereço de escuta

Inspecione o socket antes de alterar a configuração. O endereço local, a porta e o processo proprietário juntos identificam se o servidor é alcançável a partir da 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

Um endereço local 127.0.0.1 resolve a questão: nenhuma alteração de firewall ajudará, porque a aplicação não está escutando na interface da VPN. Um endereço curinga ou o endereço da VPN significa que o socket está bom e que a próxima fronteira se aplica.

Confirme também o processo proprietário, pois um serviço não relacionado numa porta comum pode fazer a tabela parecer correta enquanto o servidor pretendido nunca iniciou. Compare o caminho do executável, não apenas o nome. Um processo antigo de uma execução anterior é um impostor frequente.

Altere a vinculação pela aplicação

Use a opção de endereço de escuta documentada pelo framework e reinicie o processo. Se o laptop possui o endereço privado 10.77.0.1, a URL do telefone passa a ser http://10.77.0.1:8080/ e esse endereço precisa ser roteado pela VPN; nada mais na configuração muda.

Não adicione endereços arbitrários ao Windows nem altere o gateway para forçar uma vinculação. Essas mudanças sobrevivem à sessão de depuração e surpreendem a próxima pessoa. Um servidor iniciado antes de o endereço da VPN existir também pode falhar em vincular, então a ordem de inicialização importa para uma interface transitória. Dê a ele uma nova tentativa ou inicie-o depois do túnel. Uma falha de vinculação na inicialização parece exatamente um problema de firewall na manhã seguinte.

Para HTTPS, mantenha o nome do host do serviço e a validação do certificado intactos. Um aviso de certificado num endereço bruto é um problema de nomenclatura, não uma etapa para clicar, e o DNS privado tem de concordar com o listener escolhido.

Abra uma regra, não a rede inteira

Assim que o socket aceitar no endereço da VPN, o firewall decide se o pedido chega. Restrinja a regra a esta aplicação, a este protocolo, a esta porta local e à origem remota autorizada, e confirme qual perfil está ativo no adaptador da VPN.

Use o endereço de origem que o Windows realmente vê, incluindo qualquer tradução que o gateway faça, porque uma regra escrita para o endereço original do cliente não corresponderá a um endereço traduzido.

Uma página que carrega e mostra um erro de aplicação é progresso: a rejeição HTTP é uma falha diferente de nenhuma conexão TCP, e a próxima investigação pertence à política de acesso da própria aplicação, e não à rede.

Termine pedindo a página a partir do telefone pretendido e confirmando que um dispositivo excluído ainda não consegue alcançá-la. Um listener a funcionar com uma regra que admite tudo não é o mesmo resultado.