Selhání DNS, nebo problém s MTU? Kde se požadavek skutečně zastaví

Dvě selhání dají od uživatele stejnou větu: stránka nefunguje. Dějí se na různých vrstvách a ten rozdíl určuje, co změníte. Selhání překladu jména se zastaví dřív, než existuje jakékoli spojení. Selhání velikosti paketu přichází po přeložení jména a po dokončení handshaku, a proto se stránka začne načítat a pak zamrzne. Najděte fázi dřív, než najdete nastavení.

Dvě selhání na různých vrstvách

Překlad mění jméno na adresu a nic dalšího ve spojení nemůže začít, dokud se to nepovede. Problémy s MTU cesty nastávají později, když je paket větší než limit nějakého spoje zahozen a odesílatel se to nikdy nedozví. Jedno je vyhledávání; druhé je selhání doručení, které se objeví jen nad určitou velikostí.

Příznaky se liší způsobem, který můžete pozorovat bez jakýchkoli nástrojů. Selhání DNS je okamžité a stálé: prohlížeč řekne, že server nelze najít. Selhání MTU je částečné: stránka začne, některé prostředky dorazí a velká odpověď nebo nahrávání se zasekne.

Pokud je váš příznak částečný, přestaňte se dívat na DNS.

Fáze 1: přeloží se jméno vůbec

Použijte nástroje pro vyhledávání na platformě s přesným názvem hostitele, který aplikace používá. Soukromé jméno v kanceláři může vyžadovat interní překladač a vlastní zabezpečené DNS prohlížeče se může chovat jinak než překladač operačního systému, takže se oba mohou na stejném jménu neshodnout.

Zeptejte se překladače, který by použil operační systém, a pak porovnejte:

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

Pokud překlad selže, problém je v této politice a její dostupnosti. Neposílejte soukromá jména na náhodné veřejné překladače jen kvůli srovnání, protože srovnání samo prozradí jména, která jste chtěli udržet interní.

Fáze 2: kde se přenos zastaví

Pokud se jméno přeloží a spojení začne, zaznamenejte, kde se operace zastaví. Stránka, která se vykreslí a pak zamrzne na jednom prostředku, nahrávání, které umře v konzistentním bodě, nebo velké stahování, které nikdy neskončí, zatímco malé požadavky fungují, jsou všechny příznaky tvaru velikosti. Odpověď, která vůbec nezačne, má jiný tvar.

Při srovnávání držte koncový bod i cíl aplikace pevně, jinak měříte dvě proměnné najednou. V této fázi zůstávají možné i jiné příčiny: chyby služby, ztráty, chování filtru a opětovná připojení tunelu všechny vytvářejí zaseknutí.

Jedno opakovatelné zaseknutí má větší cenu než deset anekdotických.

Proč MTU škodí až po handshaku

TCP handshake používá malé pakety, takže uspěje i na cestě, která neunese segment plné velikosti. Selhání se objeví, když odesílatel vyšle velký paket s bitem zákazu fragmentace, spoj ho zahodí a zpráva ICMP, která by limit oznámila, nikdy nedorazí, protože ji filtr sežral. Odesílatel pak zkusí stejnou velikost a přenos se zasekne.

Proto je příznak závislý na velikosti a opakovatelný, ne náhodný. Také to vysvětluje, proč ping hostitele nic nedokazuje, protože malé ICMP echo projde cestou, která neunese payload plné velikosti. Změřte velikost z obou konců cesty, pokud můžete. Limit, který se objeví jen v jednom směru, je asymetrie směrování, ne MTU tunelu.

Změřte velikost výslovně, místo abyste ji odvozovali:

ping -M do -s 1472 203.0.113.20
tracepath 203.0.113.20

Změňte jednu vrstvu a pak to dokažte

U jmen změňte politiku překladače a spusťte stejné vyhledávání znovu. U velikosti použijte postup pro MTU se zaznamenanými původními hodnotami a připraveným návratem, protože omezení MSS bez znalosti skutečného MTU tunelu mění jedno zaseknutí za druhé.

Stránka, která se jednou načte po změně několika nastavení, neprozradí, co byla oprava. Změňte jednu věc, spusťte stejný test znovu a výsledek uložte vedle první zaznamenané neúspěšné fáze.

Právě tento záznam brání tomu, aby se DNS, velikost paketů a autentizace proměnily v hromadu trvalých obcházek, kterou nikdo nedokáže vysvětlit. Testování přes surovou IP je dobrým příkladem zkratky, která mění identitu TLS, a vypnutí ověřování certifikátu, aby srovnání vyšlo, není diagnóza.