Varför en VPN hänger sig vid stora överföringar men inte vid små

En sida laddas, ett ping lyckas och en filkopia hänger på samma punkt varje gång. Det mönstret pekar på paketstorlek snarare än bandbredd eller inloggningsuppgifter. Inkapsling lägger till byte i varje paket, så en nyttolast som fick plats på den ursprungliga vägen kan överskrida gränsen när den går genom en tunnel. I de här samtalen kallas tre olika tal MTU, och att blanda ihop dem leder till en inställning som reparerar en applikation och förstör en annan.

Tre tal som folk kallar MTU

Gränssnitts-MTU är den konfigurerade gränsen för ett paket på den länken. Vägens MTU är den minsta gränsen längs rutten, och den upptäcks i stället för att konfigureras. TCP MSS är den nyttolaststorlek som en motpart uppger att den kan ta emot, och den härleds från de andra två i stället för att vara en egen fysisk gräns.

En tunnel har ett inre och ett yttre perspektiv. Det yttre paketet bär det inkapslade plus de huvuden protokollet behöver, så den användbara inre storleken är mindre än den yttre vägen tillåter. Vägen till VPN-servern skiljer sig också från serverns väg till målet.

Upptäckt av vägens MTU låter en avsändare lära sig den fungerande storleken, men det beror på att återkoppling kommer fram. När en mellanliggande enhet filtrerar de relevanta ICMP-meddelandena fortsätter avsändaren att skicka paket som aldrig fullbordas, och det är det klassiska svarta hålet. Symtomet är särpräglat när man känner till det: handskakningen lyckas, den första nyttolasten i full storlek försvinner och anslutningen återställs eller hänger sig till slut. Ingenting i applikationens logg ser ut som ett nätverksproblem.

Undersök vägen med en nyttolast du kontrollerar

Ett test är bevis om en väg och en storlek, inte en rekommenderad inställning. Använd en värd som svarar och ändra bara nyttolastens storlek.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

Det första kommandot skickar ett Linux-test med fragmentering avstängd och en nyttolast på 1372 byte, och det andra gör samma sak på Windows där nyttolasten sätts med -l. Ett svar betyder att den storleken överlevde vägen. Ett meddelande om att fragmentering behövs är informativt, medan en timeout är tvetydig eftersom värden eller en mellanliggande enhet helt enkelt kan släppa ICMP.

Trappa ner storleken i några steg i stället för binärsökning till byten. Du försöker fastställa om det finns ett storlekstak, inte att publicera ett tal för varje nätverk. Talet du hittar gäller för den här vägen, detta protokoll och denna adressfamilj.

IPv4 och IPv6 fragmenterar olika, så ett testresultat från den ena familjen säger ingenting om den andra. Testa den familj applikationen faktiskt använder.

MSS-clamping hjälper bara TCP

I TCP förhandlas den effektiva nyttolasten under handskakningen, och en router på vägen kan skriva ner det värdet så att båda ändarna skickar mindre segment. Det är vad MSS-clamping gör, och det fungerar utan att röra klienten alls.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

Den första regeln klämmer den annonserade MSS till vägens MTU för vidarebefordrade TCP-handskakningar, och den andra visar tunnelgränssnittets egen MTU så att du kan jämföra den med vad vägen tillåter. Clamping är den minst ingripande åtgärden för en TCP-applikation som hänger sig efter handskakningen.

För UDP gör den ingenting. En röst- eller spelklient som skickar stora datagram ignorerar en MSS-inställning helt, eftersom det inte finns någon handskakning att skriva om. Om applikationen som misslyckas använder UDP, titta i stället på klientens egna val för paketstorlek. De två protokollen misslyckas olika och repareras med olika verktyg, därför hör protokollet hemma i ärendets första mening.

OpenVPN exponerar alternativ som tun-mtu, mssfix och fragmenteringsrelaterade inställningar, och deras beteende beror på versionen och på om datakanalen är AEAD. Läs handboken för den version som används och ändra ett alternativ i taget.

Ändra en enda stödd inställning och upprepa båda körningarna

Behåll den ursprungliga profilen, ändra ett enda stött värde och upprepa både den lilla begäran som fungerade och den stora överföringen som misslyckades. Om bara den stora ändras jagade du storlek. Om båda ändras flyttade något annat med den.

Ett lägre värde kan lindra symtomet men lägger till overhead, så det minsta möjliga talet är inte målet. Målet är en storlek som vägen bär pålitligt med minst spill. Notera värdet, vägen och klientversionen i ärendet, för samma tal använt någon annanstans är en gissning.

Om samma profil fungerar från ett annat betrott nätverk, behåll den skillnaden i diagnosen i stället för att förklara klienten lagad. Variabeln som ändrades är vägen, och vägen är vad testet mätte.