VPN-ping fungerar men webbplatsen hänger sig: kontrollera storleken

Ekosvaren kommer in, fjärrskrivbordet fungerar och webbläsaren står på en tom sida tills den ger upp. Två förklaringar passar det mönstret, och de är inte varianter av ett problem: en policy som aldrig tillät tjänsten, eller paket som slutar passa när överföringen växer. Ekosvaret utesluter ingen av dem.

Gå från den minsta frågan till den största och skriv ned vad varje steg faktiskt bevisade.

Ett ekosvar besvarar en mycket mindre fråga

Ett ekosvar säger att IP-stacken på målet besvarade en ICMP-förfrågan från din källa. Det säger ingenting om huruvida det finns en TCP-lyssnare på porten du behöver, om en policy tillåter den porten, eller om målvärden filtrerar trafik oberoende av gatewayen. En gateway som tillåter en tjänst kan släppa en annan medan båda målen svarar på ping. Läs svaret som ett faktum om ett paket och en riktning.

Bekräfta målet och tjänstens port innan du tolkar något annat. Adressen du testade och adressen applikationen använder är ibland olika poster, och ett namn som löses upp till två adresser gör det sannolikt.

Ta reda på om anslutningen började

En anslutning som avvisas direkt är ett svar från lyssnaren eller policyn: något svarade och sa nej. En anslutning som öppnas och sedan stoppar när data börjar röra sig pekar på storlek. En anslutning som aldrig fullbordar handskakningen beror oftast på policy eller routing och ser ut som en tidsgräns snarare än en avvisning.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Anteckna vilket av de tre du observerade innan du rör MTU-inställningarna. Att ändra en tunnelstorlek för att reparera en avvisad anslutning slösar bort ändringen och döljer den verkliga orsaken ett tag.

Mät storleken med ett angivet tal

När stoppet dyker upp under last, testa en paketstorlek med don't-fragment-biten satt och ange aritmetiken så att resultatet betyder något. På Linux med iputils ger en nyttolast på 1392 byte plus ICMP-huvudet på 8 byte och IPv4-huvudet på 20 byte ett inre paket på exakt 1420 byte. Ange den aritmetiken i ärendet, eftersom en bar ping som når gatewayen inte bevisar något om en applikation.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Båda sonderna är mätpunkter, inte rekommendationer för en tunnelstorlek. Om ICMP filtreras någonstans på vägen säger en tidsgräns ingenting om storleken, eftersom filtrering och ett för stort paket ser likadana ut från klienten. En framgång säger heller ingenting om den motsatta riktningen eller om ett annat mål.

Räkna med den yttre vägen

Inkapsling lägger till sina egna huvuden, så paketet på ledningen är större än paketet du mätte inne i tunneln. Skillnaden mellan de två är det som gör en fungerande liten förfrågan och en misslyckad stor möjliga samtidigt.

IPv4:s upptäckt av vägens MTU bygger på återkoppling om paket som inte kan vidarebefordras utan fragmentering, och IPv6 använder Packet Too Big-meddelanden. IPv4-specifikationen beskriver den mekanismen. Att filtrera återkopplingen förstör avsändarens förmåga att lära och lämnar den att skicka om paket som aldrig kommer att passa. Därför kan en fungerande liten förfrågan och en misslyckad stor leva så bekvämt sida vid sida.

Ändra ett tal och testa applikationen igen

Sänk tunnelns MTU, eller begränsa den maximala segmentstorleken för TCP, och upprepa sedan det ursprungliga applikationstestet i stället för sonden. En sond som lyckas efter ändringen och en applikation som fortfarande hänger sig är ett annat problem med en liknande form, och bara applikationstestet skiljer dem åt.

Behåll aritmetiken i ändringsposten: den uppmätta storleken, den overhead du antog och det värde du satte. Den som granskar det senare kan kontrollera antagandet i stället för att härleda det på nytt från en skärmbild av en ping.

Om applikationen fungerar vid varje storlek du provade, sluta justera tal och titta på policyn som skiljer den fungerande tjänsten från den misslyckade.