Un nuovo client hotspot bloccato su «Ottieni indirizzo IP» non è un guasto della VPN

Un telefono si unisce all'hotspot, resta su «Ottieni indirizzo IP» e alla fine si arrende. La conclusione naturale è che la VPN del telefono interferisca con il DNS, così le persone iniziano a modificare resolver e regole aggiunte. È la fase sbagliata. Il client non ha mai ricevuto un indirizzo locale, e senza uno non ha gateway, né resolver, né nulla da inoltrare, quindi nessuna impostazione VPN sul telefono host può spiegare il guasto. Associazione, assegnazione dell'indirizzo locale e inoltro sono tre fasi separate, e solo l'ultima coinvolge il tunnel.

Le tre fasi, e in quale ti trovi

Prima viene l'associazione: il client si unisce alla rete wireless dell'hotspot. Una password errata, una discrepanza WPA3 o un problema di compatibilità radio falliscono qui, e il client di solito lo dice. Secondo viene l'assegnazione dell'indirizzo: per IPv4 il client chiede un lease e riceve un indirizzo più le impostazioni locali del gateway, mentre IPv6 di solito usa gli annunci del router invece di DHCP, come descrive la documentazione AOSP sul tethering. Terzo viene l'accesso verso l'esterno: il telefono host inoltra il traffico consentito verso il percorso a monte che ha scelto, che può essere o non essere il suo tunnel.

La dicitura sul client ti dice la fase. Bloccato sull'ottenimento di un indirizzo è la seconda fase, prima che qualsiasi pacchetto esca verso internet. Connesso, con un indirizzo, ma nulla si carica è la terza fase, dove contano instradamento, nomi e copertura del tunnel. Diagnosticare la terza fase mentre il client è bloccato nella seconda è come un problema di lease di cinque minuti diventa un pomeriggio di modifiche DNS.

Il mito: una VPN instradata trasforma il DHCP locale in una richiesta remota

Un tunnel instradato sposta i pacchetti IP per le destinazioni che seleziona. Una scoperta DHCP è una trasmissione sul segmento dell'hotspot stesso, e il servizio di tethering sul telefono risponde localmente, ed è per questo che il client può ottenere un indirizzo mentre il tunnel è attivo. Solo un progetto deliberatamente bridged o relayato invia quello scambio altrove, e si tratta di un'altra configurazione con un'altra firma di guasto.

Quindi «il server VPN non risponde al DHCP» non è una diagnosi, è un errore di modello. Il broker locale è sul telefono. Se smette di rispondere, le ragioni sono locali: il servizio di tethering, il limite di client, il pool di lease o un client che non ha mai completato correttamente l'associazione. Nessuna di queste vive dal lato remoto del tunnel.

Che cosa dimostra davvero un client esistente che funziona

Se un portatile già connesso funziona ancora mentre il nuovo telefono no, l'hotspot e il percorso a monte sono in linea di massima vivi. Quel confronto è utile e non è prova di quale componente sia in colpa, perché il client funzionante potrebbe semplicemente trattenere un lease precedente alla modifica e rinnovarlo in silenzio.

Vale la pena controllare due limiti locali mentre sei lì. L'hotspot serve un pool di lease finito e un limite di client configurabile, quindi un dispositivo che si è unito e si è addormentato può trattenere un indirizzo mentre uno nuovo aspetta. E un client che ricorda una configurazione statica di un'altra rete non chiederà affatto un lease, il che dall'esterno sembra identico e si corregge sul client, non sul telefono.

Mantieni il confronto locale e reversibile

Su un dispositivo in cui la policy lo consente, confronta una singola unione di un nuovo client con il tunnel inattivo e poi attivo, mantenendo hotspot e client altrimenti invariati. Annota le versioni del telefono e del client, il profilo selezionato e la fase esatta che ha fallito. Su un telefono gestito, chiedi il confronto approvato invece di disattivare l'applicazione per ottenere un test più pulito.

Un guasto del lease coerente e dipendente dal tunnel è una prova utile su una policy locale o un'interazione implementativa. Non è una licenza per svuotare ogni regola di inoltro e NAT del dispositivo. Quelle regole proteggono traffico non correlato, e un'accettazione ampia dell'inoltro non spiega perché un servizio DHCP locale abbia smesso di rispondere.

Non coprire un lease mancante con un indirizzo statico indovinato. Una configurazione statica deliberata richiede la sottorete reale, il gateway, il piano di allocazione e un controllo delle collisioni. Cambiare il DNS del client non fornisce nulla di tutto ciò, e lascia il dispositivo successivo con lo stesso guasto.

Che cosa non dimostra un lease

Ottenere un indirizzo dimostra l'ammissione alla rete locale, non la protezione da parte del tunnel del telefono. Una volta che il client ha un lease, valuta il percorso a valle da solo: il traffico del client passa davvero attraverso il telefono, le risoluzioni avvengono dove ti aspetti, e l'indirizzo esterno corrisponde all'uscita che intendevi? Sono domande della terza fase e meritano un proprio test invece di essere piegate nell'unione.

Affronta le fasi in ordine e il guasto smette di spostarsi. Un client bloccato sull'ottenimento di un indirizzo è una questione locale di tethering; un client con un indirizzo e senza pagine è una questione di inoltro o di nomi; un client con pagine e l'uscita sbagliata è una questione di copertura del tunnel. Tenerli separati è la maggior parte del debug.