Perché alcuni siti falliscono solo con la VPN attiva?

Che un solo sito fallisca mentre tutto il resto si carica dimostra che il tunnel trasporta traffico, e questo restringe il problema più di quanto molti si aspettino. Tre osservazioni ordinano il resto: se hai ricevuto una risposta HTTP, se il nome host è stato risolto in un indirizzo e se le richieste piccole passano mentre quelle grandi si bloccano. Indovinare la VPN prima di avere quelle risposte di solito sposta il guasto invece di risolverlo.

Affronta le osservazioni in ordine, perché un sito che ha risposto non può anche aver fallito la risoluzione. Se non si carica proprio nulla, sei nel ramo sbagliato e valgono i controlli per connesso ma senza Internet.

Lascia che il messaggio d'errore scelga il ramo

Un rifiuto, una verifica antibot o una pagina di errore significano che il servizio ha risposto, quindi i pacchetti hanno raggiunto un'applicazione e sono tornati. Questo sposta la domanda sulla politica di accesso del sito, che può pesare l'indirizzo di uscita, l'account o schemi di richiesta che non pubblica. Un guasto della risoluzione dei nomi non ha mai raggiunto il sito, e l'indirizzo è la prima cosa da ispezionare. Un timeout sta nel mezzo: qualcosa è stato inviato e nulla lo ha confermato.

Gli avvisi sui certificati appartengono a un quarto ramo. Significano che la connessione è stata servita da qualcosa la cui identità il browser non poteva verificare, cioè un proxy dalla tua parte o una vera discrepanza che non dovresti superare con un clic. Trattalo come una questione di fiducia, non di instradamento.

Un sito che risponde non ha dimostrato un tunnel rotto

Quando la risposta è una pagina di blocco, confronta la stessa pagina attraverso una seconda uscita lasciando browser e macchina invariati. Se il risultato segue l'indirizzo di uscita, il sito tratta quell'indirizzo diversamente, e nessuna configurazione del client lo farà cambiare idea. Se il blocco segue invece il browser, la causa sta in un'estensione, in un proxy salvato o in un'impostazione del resolver. Due prove separano queste spiegazioni a poco prezzo.

I guasti solo del browser sono abbastanza comuni da testarli presto. Una pagina che si carica in un browser supportato e fallisce in un altro indica stato del profilo, un blocco dei contenuti o DNS cifrato configurato dentro il browser stesso. Le indicazioni di Chrome sul DNS sicuro spiegano dove si trova quell'impostazione, e cambiarla tramite il controllo previsto batte il ripristino del dispositivo.

Quando si bloccano solo i trasferimenti grandi, guarda la dimensione dei pacchetti

Una pagina che disegna l'intestazione e poi si blocca ha una firma diversa da una pagina che non parte mai. Le risposte piccole possono passare mentre un carico di dimensione piena viene scartato da qualche parte che non può segnalarlo al mittente, ed è così che appare un guasto di MTU del percorso visto da un browser. Confronta una richiesta minuscola e una grande verso lo stesso host prima di teorizzare sul filtraggio. La scoperta dell'MTU del percorso dovrebbe apprendere la dimensione minima del collegamento lungo il percorso, e dipende da riscontri ICMP che le reti filtrate scartano abitualmente.

Verifica quell'ipotesi con una scansione di dimensioni invece di un singolo ping. Un guasto che inizia a una dimensione di carico costante è una prova forte, mentre un guasto che si sposta non lo è.

Conferma la correzione sulla richiesta che ha fallito

Riprova l'operazione originale, non la home page, perché un guscio in cache può essere disegnato mentre la chiamata API dietro un accesso fallisce ancora. I comandi sotto separano risoluzione dei nomi, richiesta piccola e richiesta grande verso lo stesso host. Sostituisci nome host e percorso con quelli della richiesta che si è davvero rotta.

dig +short www.example.com
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{size_download}\n' https://www.example.com/assets/app.js
ping -M do -s 1400 -c 3 203.0.113.20

Se la risposta di dig differisce da quella usata dal browser, il resolver è la variabile, e l'impostazione DNS del browser è il punto da guardare. Se la richiesta piccola restituisce uno stato mentre la grande si blocca, lavora sul ramo della dimensione dei pacchetti. Se entrambe vanno in timeout, il percorso di uscita e il modo in cui il sito tratta quell'indirizzo tornano sul tavolo.

Mantieni la modifica che ha fatto riuscire la richiesta originale e annulla il resto. Un mucchio di modifiche simultanee a browser, resolver e client ti lascia incapace di dire quale contava.