Errore DNS o problema MTU? Dove si ferma davvero la richiesta

Due errori producono la stessa frase dell'utente: il sito non funziona. Avvengono su livelli diversi, e la differenza decide cosa cambiate. Un errore di risoluzione del nome si ferma prima che esista qualsiasi connessione. Un errore di dimensione del pacchetto avviene dopo che il nome è stato risolto e dopo che l'handshake è completato, per questo la pagina inizia a caricarsi e poi si blocca. Trovate lo stadio prima di trovare l'impostazione.

Due errori su livelli diversi

La risoluzione trasforma un nome in un indirizzo, e nient'altro nella connessione può iniziare finché non riesce. I problemi di MTU del percorso arrivano più tardi, quando un pacchetto più grande del limite di un collegamento viene scartato e il mittente non ne viene mai informato. Uno è una ricerca; l'altro è un errore di consegna che compare solo sopra una certa dimensione.

I sintomi differiscono in un modo che potete osservare senza alcuno strumento. Un errore DNS è immediato e costante: il browser dice che il server non è raggiungibile. Un errore MTU è parziale: la pagina inizia, alcune risorse arrivano, e una risposta grande o un caricamento si blocca.

Se il vostro sintomo è parziale, smettete di guardare il DNS.

Stadio 1: il nome si risolve almeno

Usate gli strumenti di ricerca della piattaforma con il nome host esatto che usa l'applicazione. Un nome privato in ufficio può richiedere un resolver interno, e il DNS sicuro del browser può comportarsi diversamente dal resolver del sistema operativo, quindi i due possono non essere d'accordo sullo stesso nome.

Chiedete al resolver che userebbe il sistema operativo, poi confrontate:

dig +short vpn.example.com
dig +short vpn.example.com @10.0.0.53

Se la risoluzione fallisce, il problema è quella politica e la sua raggiungibilità. Non inviate nomi privati a resolver pubblici arbitrari solo per ottenere un confronto, perché il confronto stesso divulga i nomi che volevate tenere interni.

Stadio 2: dove si ferma il trasferimento

Se il nome si risolve e la connessione inizia, annotate dove si ferma l'operazione. Una pagina che viene disegnata e poi si blocca su una risorsa, un caricamento che muore in un punto costante o un download grande che non finisce mai mentre le richieste piccole funzionano sono tutti sintomi a forma di dimensione. Una risposta che non inizia affatto ha un'altra forma.

Tenete fissi l'endpoint e la destinazione dell'applicazione mentre confrontate, altrimenti state misurando due variabili insieme. Altri motivi restano possibili in questo stadio: errori del servizio, perdita, comportamento del filtro e riconnessioni del tunnel producono tutti stalli.

Uno stallo riproducibile vale più di dieci aneddotici.

Perché l'MTU danneggia solo dopo l'handshake

L'handshake TCP usa pacchetti piccoli, quindi riesce su un percorso che non può portare un segmento a dimensione piena. L'errore compare quando il mittente invia un pacchetto grande con il bit di non frammentazione, un collegamento lo scarta e il messaggio ICMP che avrebbe segnalato il limite non arriva mai perché un filtro se l'è mangiato. Il mittente riprova la stessa dimensione e il trasferimento si blocca.

Per questo il sintomo dipende dalla dimensione ed è riproducibile invece che casuale. Spiega anche perché fare ping all'host non dimostra nulla, dato che un piccolo eco ICMP può attraversare un percorso che non porterà un carico a dimensione piena. Sondate la dimensione da entrambe le estremità del percorso se potete. Un limite che compare solo in una direzione è un'asimmetria di instradamento e non un MTU di tunnel.

Sondate la dimensione esplicitamente invece di dedurla:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Cambiate un livello, poi dimostratelo

Per i nomi, cambiate la politica del resolver e rieseguite la stessa ricerca. Per la dimensione, usate la procedura MTU con i valori originali annotati e un ripristino pronto, perché limitare l'MSS senza conoscere l'MTU reale del tunnel scambia uno stallo con un altro.

Una pagina che carica una volta dopo aver cambiato diverse impostazioni non identifica la riparazione. Cambiate una cosa, rieseguite la stessa prova e tenete il risultato accanto al primo stadio fallito che avete annotato.

È quel registro che impedisce a DNS, dimensione dei pacchetti e autenticazione di diventare un mucchio di aggiramenti permanenti che nessuno sa spiegare. Provare con un IP grezzo è un buon esempio di scorciatoia che cambia l'identità TLS, e disattivare la verifica del certificato per far riuscire un confronto non è una diagnosi.