DNS-fejl eller MTU-problem? Hvor stopper anmodningen faktisk

To fejl giver den samme sætning fra en bruger: siden virker ikke. De sker på forskellige lag, og forskellen afgør, hvad du ændrer. En navneopløsningsfejl stopper, før der findes nogen forbindelse. En pakkestørrelsesfejl sker, efter navnet er opløst, og efter håndtrykket er gennemført, og derfor begynder siden at indlæse og hænger så. Find stadiet, før du finder indstillingen.

To fejl på forskellige lag

Opløsning gør et navn til en adresse, og intet andet i forbindelsen kan begynde, før det lykkes. Problemer med stiens MTU opstår senere, når en pakke, der er større end et eller andet links grænse, bliver kasseret, og afsenderen aldrig får besked. Det ene er et opslag; det andet er en leveringsfejl, der kun viser sig over en vis størrelse.

Symptomerne adskiller sig på en måde, du kan observere uden værktøj. En DNS-fejl er øjeblikkelig og ensartet: browseren siger, at serveren ikke kan findes. En MTU-fejl er delvis: siden begynder, nogle ressourcer kommer igennem, og et stort svar eller en upload går i stå.

Hvis dit symptom er delvist, så stop med at kigge på DNS.

Fase 1: bliver navnet overhovedet opløst

Brug platformens opslagsværktøjer med det præcise værtsnavn, som applikationen bruger. Et privat navn på kontoret kan kræve en intern resolver, og browserens egen sikre DNS kan opføre sig anderledes end operativsystemets resolver, så de to kan være uenige om det samme navn.

Spørg den resolver, operativsystemet ville bruge, og sammenlign så:

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

Hvis opløsningen fejler, er problemet den politik og dens rækkevidde. Send ikke private navne til tilfældige offentlige resolvere bare for at få en sammenligning, for sammenligningen lækker selv de navne, du prøvede at holde interne.

Fase 2: hvor stopper overførslen

Hvis navnet opløses, og forbindelsen begynder, så noter, hvor handlingen stopper. En side, der vises og derefter hænger på en ressource, en upload, der dør på et fast punkt, eller en stor download, der aldrig bliver færdig, mens små anmodninger virker, er alle størrelsesformede symptomer. Et svar, der slet ikke begynder, har en anden form.

Hold endepunktet og applikationens destination fast, mens du sammenligner, ellers måler du to variable på én gang. Andre årsager er stadig mulige på dette stadium: servicefejl, tab, filteradfærd og genopkoblinger af tunnelen giver alle stop.

Et stop, der kan gentages, er mere værd end ti anekdotiske.

Hvorfor MTU først skader efter håndtrykket

Et TCP-håndtryk bruger små pakker, så det lykkes på en sti, der ikke kan bære et segment i fuld størrelse. Fejlen viser sig, når afsenderen udsender en stor pakke med do-not-fragment-bitten sat, et link kasserer den, og den ICMP-besked, der ville have rapporteret grænsen, aldrig ankommer, fordi et filter spiste den. Afsenderen prøver så samme størrelse igen, og overførslen går i stå.

Derfor er symptomet størrelsesafhængigt og gentageligt i stedet for tilfældigt. Det forklarer også, hvorfor ping af værten ikke beviser noget, fordi et lille ICMP-ekko kan krydse en sti, der ikke vil bære en nyttelast i fuld størrelse. Mål størrelsen fra begge ender af stien, hvis du kan. En grænse, der kun viser sig i én retning, er en routingasymmetri og ikke en tunnel-MTU.

Mål størrelsen eksplicit i stedet for at udlede den:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Skift ét lag, og bevis det så

For navne: skift resolverpolitikken og kør det samme opslag igen. For størrelse: brug MTU-proceduren med de oprindelige værdier noteret og en tilbagerulning klar, fordi stramning af MSS uden at kende tunnelens reelle MTU bytter ét stop for et andet.

En side, der indlæses én gang efter flere ændrede indstillinger, identificerer ikke reparationen. Skift én ting, kør den samme test igen, og gem resultatet ved siden af det første fejlstadie, du noterede.

Den registrering er det, der forhindrer DNS, pakkestørrelse og godkendelse i at blive en bunke permanente omveje, som ingen kan forklare. Test via rå IP er et godt eksempel på en genvej, der ændrer TLS-identitet, og at slå certifikatverifikation fra for at få en sammenligning til at lykkes er ikke en diagnose.