OpenVPN mssfix: hvorfor én klient går i stå ved store overførsler

Én laptop går i stå ved uploads gennem tunnelen, mens alle andre enheder på samme server bliver ved med at virke. Det mønster peger på én vej, ikke på serverkonfigurationen, og det er den sædvanlige indgang til mssfix-spørgsmålet. Valget kan hjælpe, men kun for de TCP-forbindelser, det faktisk omskriver. At kende dets rækkevidde forhindrer dig i at ændre en fungerende server for at redde én klient.

Hvad valget omskriver

mssfix redigerer den maksimale segmentstørrelse, der annonceres i TCP-håndtryk, som passerer gennem tunnelen, så afsendersiden vælger segmenter, der passer i det indkapslede budget. Det virker på håndtrykket, hvilket betyder, at en forbindelse, der blev åbnet før ændringen, beholder den værdi, den forhandlede.

Det krymper ikke UDP-datagrammer, og det sætter ikke tunnelens MTU. To forskellige problemer giver det samme symptom: en TCP-afsender, der ignorerer vejgrænsen, og en vej, der lydløst dropper store pakker i enhver størrelse. mssfix løser det første og gør intet for det andet.

Den forskel forklarer de skuffende eksperimenter. At sætte en mindre værdi på en vej med sort hul ændrer segmentstørrelsen, men ikke det drop, der følger, så overførslen fejler på et andet punkt.

Rækkevidden er TCP inde i tunnelen

Kun TCP-trafik omskrives. En QUIC-session, et spil eller et program, der sender store UDP-datagrammer, beholder sine egne pakkestørrelser, og hvis det er de overførsler, der går i stå, hører rettelsen hjemme ved tunnelens eller vejens MTU i stedet. Læs, hvilken protokol den fejlende overførsel bruger, før du griber efter et TCP-valg, for det forkerte lag har sin egen rettelse.

Retningen betyder også noget. En klientindstilling påvirker den trafik, klienten sender ind i tunnelen, mens serveren dækker de strømme, den videresender mod klienterne. Hvis kun indgående downloads går i stå, er værdien på klientsiden ikke hele historien.

Tallet og nøgleordet er ikke portable

Fællesskabsversionen af OpenVPN 2.6 accepterer et valgfrit nøgleord efter værdien. Med mtu beskriver tallet den ydre pakkestørrelse inklusive IP- og UDP-headere; uden det følger argumentet en anden regnskabskonvention. En linje, der kopieres mellem versioner, beskriver derfor ikke det samme pakkebudget. Slå op på den manualside, der følger med det build, du faktisk kører, i stedet for en vejledning til en anden udgivelse.

Syntaksen ser sådan ud:

mssfix 1400 mtu

Behandl 1400 som en pladsholder, ikke som en anbefaling til din vej. Udled værdien fra den målte vej og den indkapsling, der faktisk bruges, og husk, at klienter på ældre versioner eller andre implementeringer kan afvise eller fortolke nøgleordet anderledes.

Bekræft på den ene klient først

Mål vejen fra den fejlende maskine, før du ændrer noget. En nyttelast, som vejen kan bære uden fragmentering, er det tal, du leder efter:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

Den første sondering passer til en pakke på 1500 byte, når de 28 byte headere er lagt til. Hvis den fejler med en fragmenteringsfejl, og den mindre lykkes, ligger den brugbare størrelse et sted imellem dem, og tunnelens overhead trækkes fra oven.

Gentag derefter den overførsel, der gik i stå, på en ny forbindelse, og sammenlign. Hvis den ene klient forbedres, mens de andre er urørte, har du fundet problemets rækkevidde. Hvis alle klienter går i stå, er værdien på serversiden den, der skal gennemgås. Ingen af de to resultater retfærdiggør en ændring på hardware, der aldrig var på den fejlende vej.