Perché un hotspot reindirizza il DNS prima che la VPN si connetta?
Un hotspot riscrive le interrogazioni sulla propria rete, e un endpoint con nome host viene risolto prima che esista qualsiasi tunnel. Tracciate quale resolver ha risposto a ogni query.
Unirsi a una rete alberghiera mette davanti a voi due decisioni DNS in momenti diversi: le interrogazioni che il dispositivo fa durante l'accesso e quelle effettuate una volta che il tunnel è attivo. Un hotspot può influenzare le prime tramite la rete che controlla. Le seconde dipendono dalla politica del client stesso, che è una cosa separata da esaminare.
Percorrete la connessione in ordine, dal primo lease DHCP all'interrogazione che ha risolto un nome privato. Allora due guasti che in un ticket di assistenza sembrano identici si separano nettamente: uno è avvenuto prima che esistesse il tunnel, l'altro al suo interno.
Cosa può e cosa non può toccare l'hotspot
La rete di accesso assegna un indirizzo di resolver via DHCP e può intercettare la porta 53 verso quell'indirizzo. Basta per rispondere a ogni interrogazione non protetta con un indirizzo di portale o una pagina di blocco. Basta anche per rompere un client VPN il cui endpoint è scritto come nome host.
Ciò che l'hotspot non può fare è leggere o riscrivere un'interrogazione una volta che viaggia dentro un tunnel stabilito, supponendo che il tunnel la trasporti davvero. L'intercettazione dipende dal vedere la domanda in chiaro.
Le interrogazioni escono comunque dal tunnel per motivi estranei all'hotspot: l'impostazione DNS sicuro del browser, una regola split-DNS che tiene un suffisso aziendale sul resolver locale, o un client configurato per escludere il DNS dal tunnel. Ognuna è una scelta lato client, e ognuna appare come interferenza dell'hotspot vista dall'esterno.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
L'interrogazione iniziale avviene prima che il tunnel esista
Un client a cui viene dato un nome host deve prima risolverlo, e in quell'istante nessun tunnel protegge l'interrogazione. Se l'hotspot risponde con un indirizzo di portale, la negoziazione fallisce o si blocca. Se risponde con nulla, il client segnala un errore di nome e il tunnel non parte mai. Ciascuno dei due esiti spiega un registro del tunnel vuoto che altrimenti sembra innocuo.
I sistemi operativi eseguono anche i propri controlli di connettività e la scoperta del portale, descritti nelle RFC 8910 e RFC 8952, e quelle richieste escono prima che qualsiasi VPN sia attiva. Vederle in un registro proxy è un comportamento atteso e non la prova di una fuga.
La soluzione pratica è dare al client un endpoint che non richieda alcuna interrogazione. Quando è impossibile, completate prima l'accesso e connettetevi dopo.
Scoprite quale resolver ha risposto
Chiedete al sistema e non al browser, ed eseguite l'interrogazione due volte: una attraverso qualunque resolver il dispositivo usi ora, una contro un indirizzo fisso.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Una risposta del primo comando diversa dalla terza vi dice che il resolver locale restituisce qualcos'altro, ed è ciò che fa un hotspot che reindirizza. Un guasto della terza insieme a un successo della prima indica il portale: il resolver locale ha servito un indirizzo di accesso mentre la porta 53 in uscita veniva scartata. I timeout su entrambe significano che la rete scarta il DNS finché l'autenticazione non è completa.
Ripetete dopo la connessione e confrontate. Una risposta in cache sopravvive alla transizione, quindi svuotate la cache o interrogate un nuovo nome per la seconda osservazione.
Mantenete le interrogazioni successive sul percorso che intendevate
Un profilo a tunnel completo che cattura anche il DNS è la soluzione più semplice: ogni interrogazione di ogni applicazione va al resolver che il tunnel impone, e la rete locale vede solo traffico cifrato. Dimostratelo risolvendo un nome interno e uno pubblico dopo la connessione, poi confrontando entrambe le risposte con ciò che il resolver del tunnel restituisce da solo.
Lo split-DNS richiede un elenco di domini scritto con intenzione: suffissi aziendali attraverso il tunnel, tutto il resto in locale, e nessuna sovrapposizione tra i due.
Il DNS sicuro del browser sta fuori da quella politica, quindi se deve essere disattivato perché il profilo si comporti in modo prevedibile, disattivatelo per quel profilo e non per la macchina. Fatelo nelle impostazioni del browser, non modificando il resolver di sistema, così la modifica sarà visibile la prossima volta. Annotate la risposta, il resolver e la fase di connessione su una riga per test. Un rapporto che dice che il DNS ha fallito sul Wi-Fi dell'hotel descrive un sintomo con almeno tre cause diverse.