Il filtro DNS tramite VPN ha bloccato il caricamento di un sito: leggete la risposta
Un resolver filtrante può bloccare un solo nome mentre il tunnel funziona. Leggete il tipo di risposta, scoprite chi possiede il resolver e cambiate solo ciò che controllate.
Un nome fallisce mentre il tunnel è attivo, e il browser lo chiama errore di rete, quando la causa reale è la risposta DNS che il resolver ha restituito. Un resolver filtrante può trattenere, rifiutare o riscrivere un solo nome e lasciare funzionanti tutte le altre query. Il tunnel trasporta la query; il resolver decide la risposta. Esaminate quella risposta prima di toccare le impostazioni di crittografia.
Il tunnel è attivo, quindi la crittografia non è il sospetto
Lo stato della connessione vi dice se i pacchetti si muovono, non se un nome si risolve. La risoluzione è una query verso il server con cui il client è configurato, e una politica lì può rispondere a un dominio in modo diverso da tutti gli altri. Dal lato del browser tutte quelle risposte si fondono in un errore generico, per questo la spia di stato dimostra così poco.
Annotate prima tre cose: il resolver usato dal client, il codice di risposta del nome che fallisce e la stessa query per un nome che dovrebbe funzionare. Interrogate il resolver direttamente con dig example.com @10.20.0.1 e leggete la riga di stato, non il messaggio del browser. Se il nome di controllo si risolve e quello che fallisce restituisce una risposta di politica, la prova è completa. Se entrambi falliscono, il filtro non è ancora coinvolto.
Quattro risposte, quattro proprietari diversi
Un resolver filtrante non ha un solo modo di dire no, e la forma del rifiuto indica un passo successivo diverso. Annotate il codice di risposta, perché il browser riscrive tutti e quattro in qualcosa che suona come una connessione interrotta.
| Answer | What it points at |
|---|---|
| NXDOMAIN | The name is withheld: a policy entry or a zone decision removed it |
| Refused | The resolver declines to answer; usually an access or policy rule |
| Replacement address | A redirect to a block page or sinkhole you can query and inspect |
| No answer at all | Weakest evidence: reachability, load or routing, not necessarily policy |
Confrontate la risposta con la tabella prima di attribuire qualcosa al tunnel. Un rifiuto e un nome trattenuto significano entrambi che il resolver ha preso una decisione, mentre il silenzio significa che la query non ha mai ricevuto risposta. Questa differenza decide se inseguite un proprietario di politica o un percorso di rete.
Due browser possono seguire due politiche
Un browser che porta con sé il proprio resolver cifrato non deve usare il server che il sistema operativo distribuisce, quindi può ignorare la politica per cui è stato costruito il tunnel. Due browser sulla stessa macchina dissentono allora sullo stesso nome host, e nessuno dei due è guasto. Verificate a quale resolver è legata ogni applicazione prima di definire il filtro incoerente.
Quando entrambe le applicazioni usano il resolver del tunnel e solo una fallisce, la differenza è nell’applicazione, non nel DNS. Annotate l’indirizzo del resolver per applicazione, perché quel dettaglio sparisce quando la finestra si chiude.
Cambiate ciò che possedete, escalate ciò che non possedete
Il passo successivo dipende da chi possiede il resolver verso cui puntate. Uno che gestite voi stessi è una funzione che potete leggere e configurare: controllate l’opzione di filtro documentata e le sue eccezioni, poi consentite il singolo nome. Uno che gestisce il vostro datore di lavoro o provider è un ticket con il dominio, la risposta esatta e l’ora.
Non sostituite mai con un resolver pubblico per forzare l’apertura del sito, perché i nomi privati smettono di risolversi e una politica deliberata smette di applicarsi. La modifica ristretta mantiene anche la prova intatta, così il proprietario può confrontare il vostro rapporto con i suoi registri. Dopo la modifica, ripetete il test originale dell’applicazione invece di una query da una shell.
Una pagina di blocco non è un certificato fidato
Una pagina sostitutiva che presenta il proprio certificato solleverà un avviso di identità HTTPS, e il reindirizzamento non rende valido quel certificato. Non fateci clic sopra solo perché il tunnel è attivo; l’avviso è una decisione di fiducia separata che deve comunque essere corretta.
La diagnosi si chiude quando il nome che fallisce restituisce una risposta di politica e un nome di controllo ne restituisce una normale attraverso lo stesso resolver. A quel punto la riparazione è un cambio di politica, non di tunnel, e i RFC 1035 codici di risposta sono ciò che citate nel rapporto. Tenete insieme entrambi i nomi e le risposte; è tutto il caso.