OpenVPN mssfix: kvifor éin klient stoppar ved store overføringar
mssfix skriv om TCP-segmentstorleiken som blir annonsert inne i tunnelen. Det endrar ikkje UDP, og verdien tyder berre det versjonen din seier.
Éin laptop stoppar ved opplastingar gjennom tunnelen medan kvar andre eining på same tenar held fram med å verke. Det mønsteret peikar på éin veg, ikkje på tenarkonfigurasjonen, og det er den vanlege inngangen til mssfix-spørsmålet. Alternativet kan hjelpe, men berre for TCP-tilkoplingane det faktisk skriv om. Å kjenne rekkevidda hindrar deg i å endre ein fungerande tenar for å redde éin klient.
Kva alternativet skriv om
mssfix redigerer den maksimale segmentstorleiken som blir annonsert i TCP-handtrykk som passerer gjennom tunnelen, slik at avsendersida vel segment som passar i det innkapsla budsjettet. Det verkar på handtrykket, noko som tyder at ein tilkopling som vart opna før endringa, held på verdien ho forhandla fram.
Det krympar ikkje UDP-datagram og set ikkje MTU-en til tunnelen. To ulike problem gir same symptom: ein TCP-avsendar som ignorerer veggrensa, og ein veg som stille droppar store pakkar i kvar einaste storleik. mssfix handsamar det første og gjer ingenting for det andre.
Den skilnaden forklarer dei skuffande eksperimenta. Å setje ein mindre verdi på ein veg med svart hol endrar segmentstorleiken, men ikkje droppet som følgjer, så overføringa feilar på eit anna punkt.
Rekkevidda er TCP inne i tunnelen
Berre TCP-trafikk blir skriven om. Ein QUIC-økt, eit spel eller eit program som sender store UDP-datagram held på sine eigne pakkestorleikar, og om det er dei overføringane som stoppar, høyrer rettinga heime ved MTU-en til tunnelen eller vegen i staden. Les kva protokoll den feilande overføringa brukar før du grip etter eit TCP-alternativ, for det gale laget har si eiga retting.
Retninga tyder også noko. Ei klientinnstilling påverkar trafikken som klienten sender inn i tunnelen, medan tenaren dekkjer straumane han videresender mot klientane. Om berre inngåande nedlastingar stoppar, er verdien på klientsida ikkje heile historia.
Talet og nøkkelordet er ikkje portable
Fellesskapsversjonen av OpenVPN 2.6 godtar eit valfritt nøkkelord etter verdien. Med mtu skildrar talet den ytre pakkestorleiken inkludert IP- og UDP-hovud; utan det følgjer argumentet ein annan rekneskapskonvensjon. Ei linje som blir kopiert mellom versjonar skildrar derfor ikkje same pakkebudsjettet. Sjå oppslagssida som følgjer med bygget du faktisk køyrer, i staden for ein rettleiar for ei anna utgåve.
Syntaksen ser slik ut:
mssfix 1400 mtu
Behandle 1400 som ein plasshaldar, ikkje som ei tilråding for vegen din. Lei ut verdien frå den målte vegen og innkapslinga som faktisk blir brukt, og hugs at klientar på eldre versjonar eller andre implementasjonar kan avvise eller tolke nøkkelordet annleis.
Stadfest på den eine klienten først
Mål vegen frå den feilande maskina før du endrar noko. Ei nyttelast som vegen kan bere utan fragmentering, er talet du leitar etter:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1
Den første sonden passar i ein pakke på 1500 byte når dei 28 byta hovuda blir lagde til. Om han feilar med ein fragmenteringsfeil og den mindre lykkast, ligg den brukbare storleiken ein stad imellom, og tunneloverheaden blir dregen frå ovan.
Gjenta deretter overføringa som stoppa, på ein ny tilkopling, og samanlikn. Om den eine klienten blir betre medan dei andre er urørde, har du funne rekkevidda til problemet. Om alle klientar stoppar, er verdien på tenarsida den som må gjennomgåast. Ingen av dei to resultata rettferdiggjer ei endring på maskinvare som aldri var på den feilande vegen.