Il telefono non apre la pagina: controllate l'indirizzo di ascolto

Il portatile serve la pagina su localhost, il telefono si unisce alla stessa VPN e il browser del telefono segnala che il sito non è raggiungibile. Nulla è ancora sbagliato nel tunnel, perché il tunnel consegna solo pacchetti. Un server di sviluppo legato all'interfaccia di loopback non accetta mai una connessione indirizzata ad altro, quindi il primo posto da guardare è il socket in ascolto, non la VPN.

Esaminate il socket, l'impostazione di bind, la regola del firewall e l'URL, in quest'ordine.

Il socket risponde a una domanda più stretta

Un listener creato su 127.0.0.1 accetta il traffico della macchina stessa e rifiuta tutto ciò che arriva su un altro indirizzo. Un listener sull'indirizzo wildcard accetta su ogni interfaccia locale, compresa quella della VPN, il che è più ampio di quanto serva alla maggior parte degli ambienti di sviluppo. Un listener legato a un indirizzo VPN specifico è l'opzione utile più stretta, e funziona solo finché quell'indirizzo esiste.

Ne derivano due trappole di denominazione. Nel browser del telefono, localhost indica il telefono, non il portatile. L'indirizzo wildcard è un valore di bind, non qualcosa da digitare in un URL. Chi prova con uno dei due segnalerà un guasto in cui la rete non è mai entrata in gioco.

IPv6 aggiunge un terzo caso, perché un socket può accettare IPv4 e IPv6 a seconda di opzioni facili da trascurare. Leggete la famiglia di indirizzi nell'elenco. Una voce wildcard per una famiglia non descrive l'altra.

Leggete l'indirizzo di ascolto

Ispezionate il socket prima di modificare la configurazione. L'indirizzo locale, la porta e il processo proprietario insieme indicano se il server è raggiungibile dalla 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

Un indirizzo locale 127.0.0.1 risolve la questione: nessuna modifica al firewall aiuterà, perché l'applicazione non ascolta sull'interfaccia della VPN. Wildcard o l'indirizzo della VPN significa che il socket è a posto e che vale il confine successivo.

Confermate anche il processo proprietario, perché un servizio estraneo su una porta comune può far sembrare corretta la tabella mentre il server previsto non è mai partito. Confrontate il percorso dell'eseguibile, non solo il nome. Un processo obsoleto di un'esecuzione precedente è un impostore frequente.

Cambiate il bind tramite l'applicazione

Usate l'opzione documentata di indirizzo di ascolto del framework e riavviate il processo. Se il portatile possiede l'indirizzo privato 10.77.0.1, l'URL del telefono diventa http://10.77.0.1:8080/ e quell'indirizzo deve essere instradato attraverso la VPN; nient'altro nella configurazione cambia.

Non aggiungete indirizzi arbitrari a Windows e non modificate il gateway per forzare un bind. Queste modifiche sopravvivono alla sessione di debug e sorprendono la persona successiva. Un server avviato prima che esista l'indirizzo VPN può anche non riuscire a fare il bind, quindi l'ordine di avvio conta per un'interfaccia transitoria. Dategli un nuovo tentativo o avviatelo dopo il tunnel. Un errore di bind all'avvio sembra esattamente un problema di firewall la mattina dopo.

Per HTTPS, mantenete intatti il nome host del servizio e la convalida del certificato. Un avviso di certificato su un indirizzo grezzo è un problema di denominazione, non un passaggio da cliccare, e il DNS privato deve concordare con il listener scelto.

Aprite una regola, non tutta la rete

Una volta che il socket accetta sull'indirizzo della VPN, il firewall decide se la richiesta arriva. Limitate la regola a questa applicazione, questo protocollo, questa porta locale e la sorgente remota autorizzata, e confermate quale profilo è attivo sull'adattatore VPN.

Usate l'indirizzo di origine che Windows vede davvero, compresa qualsiasi traduzione operata dal gateway, perché una regola scritta per l'indirizzo originale del client non corrisponderà a uno tradotto.

Una pagina che si carica e mostra un errore dell'applicazione è un progresso: un rifiuto HTTP è un guasto diverso dall'assenza di connessione TCP, e l'indagine successiva riguarda la politica di accesso dell'applicazione, non la rete.

Concludete chiedendo la pagina dal telefono previsto e confermando che un dispositivo escluso non riesce ancora a raggiungerla. Un listener funzionante con una regola che ammette tutto non è lo stesso risultato.