DNS-fout of MTU-probleem? Waar het verzoek echt stopt

Twee fouten leveren bij de gebruiker dezelfde zin op: de site werkt niet. Ze treden op verschillende lagen op, en dat verschil bepaalt wat je wijzigt. Een fout in de naamresolutie stopt voordat er enige verbinding bestaat. Een fout in de pakketgrootte gebeurt nadat de naam is opgelost en nadat de handshake is voltooid, daarom begint de pagina te laden en blijft hij daarna hangen. Vind de fase voordat je de instelling vindt.

Twee fouten op verschillende lagen

Resolutie maakt van een naam een adres, en niets anders in de verbinding kan beginnen voordat dat lukt. Problemen met de MTU van het pad ontstaan later, wanneer een pakket groter dan de limiet van een schakel wordt weggegooid en de afzender daar nooit van hoort. Het ene is een opzoeking; het andere is een afleveringsfout die alleen boven een bepaalde grootte verschijnt.

De symptomen verschillen op een manier die je zonder gereedschap kunt waarnemen. Een DNS-fout is onmiddellijk en consistent: de browser zegt dat de server niet kan worden gevonden. Een MTU-fout is gedeeltelijk: de pagina begint, sommige bronnen komen binnen, en een groot antwoord of een upload blijft hangen.

Als je symptoom gedeeltelijk is, stop dan met naar DNS te kijken.

Fase 1: wordt de naam überhaupt opgelost

Gebruik de opzoekhulpmiddelen van het platform met precies de hostnaam die de toepassing gebruikt. Een particuliere naam op kantoor kan een interne resolver vereisen, en de eigen beveiligde DNS van een browser kan zich anders gedragen dan de resolver van het besturingssysteem, dus de twee kunnen het oneens zijn over dezelfde naam.

Vraag de resolver die het besturingssysteem zou gebruiken, en vergelijk dan:

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

Als de resolutie mislukt, ligt het probleem in dat beleid en de bereikbaarheid ervan. Stuur particuliere namen niet naar willekeurige openbare resolvers alleen om een vergelijking te krijgen, want de vergelijking lekt zelf de namen die je intern wilde houden.

Fase 2: waar de overdracht stopt

Als de naam wordt opgelost en de verbinding begint, noteer waar de bewerking stopt. Een pagina die wordt weergegeven en dan op één bron blijft hangen, een upload die op een vast punt sterft, of een grote download die nooit klaar komt terwijl kleine verzoeken werken, zijn allemaal symptomen met de vorm van grootte. Een antwoord dat helemaal niet begint, heeft een andere vorm.

Houd het eindpunt en de bestemming van de toepassing vast terwijl je vergelijkt, anders meet je twee variabelen tegelijk. Andere oorzaken blijven in deze fase mogelijk: servicefouten, verlies, filtergedrag en herverbindingen van de tunnel veroorzaken allemaal stilstand.

Één herhaalbaar stilstand is meer waard dan tien anekdotische.

Waarom MTU pas na de handshake schaadt

Een TCP-handshake gebruikt kleine pakketten, dus hij slaagt op een pad dat geen segment van volledige grootte kan dragen. De fout verschijnt wanneer de afzender een groot pakket met de niet-fragmenteer-bit verstuurt, een schakel het weggooit, en het ICMP-bericht dat de limiet zou hebben gemeld nooit aankomt omdat een filter het heeft opgegeten. De afzender probeert dan dezelfde grootte opnieuw en de overdracht stopt.

Daarom is het symptoom grootteafhankelijk en herhaalbaar in plaats van willekeurig. Het verklaart ook waarom ping naar de host niets bewijst, omdat een kleine ICMP-echo een pad kan oversteken dat geen volledige lading draagt. Meet de grootte vanaf beide uiteinden van het pad als je kunt. Een limiet die alleen in één richting verschijnt, is een routingasymmetrie en geen tunnel-MTU.

Meet de grootte expliciet in plaats van haar af te leiden:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Wijzig één laag en bewijs het

Voor namen wijzig je het resolverbeleid en voer je dezelfde opzoeking opnieuw uit. Voor grootte gebruik je de MTU-procedure met de oorspronkelijke waarden genoteerd en een terugdraaiing klaar, want MSS beperken zonder de echte MTU van de tunnel te kennen, ruilt één stilstand voor een andere.

Een pagina die één keer laadt nadat meerdere instellingen zijn gewijzigd, wijst de reparatie niet aan. Wijzig één ding, voer dezelfde test opnieuw uit, en houd het resultaat naast de eerste vastgelegde mislukte fase.

Die registratie is wat voorkomt dat DNS, pakketgrootte en authenticatie een hoop permanente omwegen worden die niemand kan uitleggen. Testen via een ruwe IP is een goed voorbeeld van een snelkoppeling die de TLS-identiteit wijzigt, en het uitschakelen van certificaatverificatie om een vergelijking te laten slagen is geen diagnose.