DNS-feil eller MTU-problem? Kvar førespurnaden faktisk stoppar

To feil gjev den same setninga frå ein brukar: nettstaden verkar ikkje. Dei skjer på ulike lag, og skilnaden avgjer kva du endrar. Ein namneoppløysingsfeil stoppar før noka tilkopling finst. Ein pakkestorleiksfeil skjer etter at namnet er løyst opp og etter at handtrykket er fullført, difor byrjar sida å lasta og heng så. Finn stadiet før du finn innstillinga.

To feil på ulike lag

Oppløysing gjer eit namn om til ei adresse, og ingenting anna i tilkoplinga kan byrja før det lukkast. Problem med MTU-en på vegen kjem seinare, når ein pakke som er større enn grensa til eit eller anna samband vert kasta, og avsendararen aldri får vita det. Det eine er eit oppslag; det andre er ein leveringsfeil som berre syner seg over ein viss storleik.

Symptomskilnaden er slik at du kan sjå han utan verktøy. Ein DNS-feil er augneblinkleg og konsistent: nettlesaren seier at tenaren ikkje finst. Ein MTU-feil er delvis: sida byrjar, nokre ressursar kjem inn, og eit stort svar eller ei opplasting stoppar.

Viss symptomet ditt er delvis, slutt å sjå på DNS.

Fase 1: vert namnet i det heile løyst opp

Bruk oppslagsverktøya til plattforma med det nøyaktige vertsnamnet programmet brukar. Eit privat namn på kontoret kan krevja ein intern oppløysar, og nettlesaren sin eigen trygge DNS kan oppføra seg annleis enn oppløysaren til operativsystemet, så dei to kan vera usamde om same namnet.

Spør oppløysaren operativsystemet ville brukt, og samanlikn deretter:

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

Viss oppløysinga feilar, ligg problemet i den policyen og tilgjengelegheita hans. Ikkje send private namn til tilfeldige offentlege oppløysarar berre for å få ein samanlikning, for samanlikninga lek sjølv namna du ville halda interne.

Fase 2: kvar overføringa stoppar

Viss namnet vert løyst opp og tilkoplinga byrjar, noter kvar operasjonen stoppar. Ei side som vert vist og deretter heng på éin ressurs, ei opplasting som døyr på eit fast punkt, eller ei stor nedlasting som aldri vert ferdig medan små førespurnader verkar, er alle storleiksforma symptom. Eit svar som ikkje byrjar i det heile, har ei anna form.

Hald endepunktet og målet til programmet fast medan du samanliknar, elles måler du to variablar samstundes. Andre årsaker er framleis mogelege på dette stadiet: tenestefeil, tap, filteråtferd og attilkoplingar av tunnelen gjev alle stans.

Éin stans som kan gjentakast er verdt meir enn ti anekdotiske.

Kvifor MTU berre skadar etter handtrykket

Eit TCP-handtrykk brukar små pakkar, så det lukkast på ein veg som ikkje kan bera eit segment i full storleik. Feilen syner seg når avsendararen sender ein stor pakke med ikkje-fragmenter-biten sett, eit samband kastar han, og ICMP-meldinga som ville ha rapportert grensa aldri kjem fram fordi eit filter åt henne. Avsendararen prøver så same storleik på nytt, og overføringa stoppar.

Difor er symptomet storleiksavhengig og kan gjentakast i staden for å vera tilfeldig. Det forklarer òg kvifor ping mot verten ikkje provar noko, fordi eit lite ICMP-ekko kan krysse ein veg som ikkje vil bera ei nyttelast i full storleik. Mål storleiken frå begge endar av vegen viss du kan. Ei grense som berre syner seg i éi retning, er ein ruteasymmetri og ikkje ein tunnel-MTU.

Mål storleiken eksplisitt i staden for å utleia han:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Endra eitt lag, og prov det

For namn, endra oppløysarpolicyen og køyr det same oppslaget på nytt. For storleik, bruk MTU-prosedyren med dei opphavlege verdiane noterte og ei tilbakerulling klar, fordi å stramma MSS utan å kjenna den reelle MTU-en til tunnelen byter ein stans mot ein annan.

Ei side som lastar éin gong etter at fleire innstillingar er endra, identifiserer ikkje reparasjonen. Endra éin ting, køyr den same testen på nytt, og hald resultatet ved sida av det fyrste feilande stadiet du noterte.

Den registreringa er det som hindrar DNS, pakkestorleik og autentisering i å verta ein haug med permanente omvegar som ingen kan forklara. Å testa med rå IP er eit godt døme på ein snarvveg som endrar TLS-identiteten, og å slå av sertifikatverifisering for å få ei samanlikning til å lukkast er ikkje ein diagnose.