OpenVPN mssfix: hvorfor én klient stopper ved store overføringer
mssfix skriver om TCP-segmentstørrelsen som annonseres inne i tunnelen. Det endrer ikke UDP, og verdien betyr bare det versjonen din sier.
Én laptop stopper ved opplastinger gjennom tunnelen mens hver andre enhet på samme server fortsetter å virke. Det mønsteret peker på én vei, ikke på serverkonfigurasjonen, og det er den vanlige inngangen til mssfix-spørsmålet. Alternativet kan hjelpe, men bare for TCP-tilkoblingene det faktisk skriver om. Å kjenne rekkevidden hindrer deg i å endre en fungerende server for å redde én klient.
Hva alternativet skriver om
mssfix redigerer den maksimale segmentstørrelsen som annonseres i TCP-håndtrykk som passerer gjennom tunnelen, slik at avsendersiden velger segmenter som passer i det innkapslede budsjettet. Det virker på håndtrykket, noe som betyr at en tilkobling som ble åpnet før endringen, beholder verdien den forhandlet frem.
Det krymper ikke UDP-datagrammer, og det setter ikke tunnelens MTU. To forskjellige problemer gir samme symptom: en TCP-avsender som ignorerer veigrensen, og en vei som stille dropper store pakker i enhver størrelse. mssfix håndterer det første og gjør ingenting for det andre.
Den forskjellen forklarer de skuffende eksperimentene. Å sette en mindre verdi på en vei med svart hull endrer segmentstørrelsen, men ikke droppet som følger, så overføringen feiler på et annet punkt.
Rekkevidden er TCP inne i tunnelen
Bare TCP-trafikk skrives om. En QUIC-økt, et spill eller et program som sender store UDP-datagrammer beholder sine egne pakkestørrelser, og hvis det er de overføringene som stopper, hører rettelsen hjemme ved tunnelens eller veiens MTU i stedet. Les hvilken protokoll den feilende overføringen bruker før du griper etter et TCP-alternativ, for det gale laget har sin egen rettelse.
Retningen betyr også noe. En klientinnstilling påvirker trafikken som den klienten sender inn i tunnelen, mens serveren dekker strømmene den videresender mot klientene. Hvis bare inngående nedlastinger stopper, er verdien på klientsiden ikke hele historien.
Tallet og nøkkelordet er ikke portable
Fellesskapsversjonen av OpenVPN 2.6 godtar et valgfritt nøkkelord etter verdien. Med mtu beskriver tallet den ytre pakkestørrelsen inkludert IP- og UDP-hoder; uten det følger argumentet en annen regnskapskonvensjon. En linje som kopieres mellom versjoner beskriver derfor ikke det samme pakkebudsjettet. Se oppslagsiden som følger med bygget du faktisk kjører, i stedet for en veiledning for en annen utgivelse.
Syntaksen ser slik ut:
mssfix 1400 mtu
Behandle 1400 som en plassholder, ikke som en anbefaling for veien din. Utled verdien fra den målte veien og innkapslingen som faktisk brukes, og husk at klienter på eldre versjoner eller andre implementasjoner kan avvise eller tolke nøkkelordet annerledes.
Bekreft på den ene klienten først
Mål veien fra den feilende maskinen før du endrer noe. En nyttelast som veien kan bære uten fragmentering, er tallet du leter etter:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1
Den første sonden passer i en pakke på 1500 byte når de 28 byte hodene legges til. Hvis den feiler med en fragmenteringsfeil og den mindre lykkes, ligger den brukbare størrelsen et sted imellom, og tunnelens overhead trekkes fra oven.
Gjenta deretter overføringen som stoppet, på en ny tilkobling, og sammenlign. Hvis den ene klienten blir bedre mens de andre er urørt, har du funnet problemets rekkevidde. Hvis alle klienter stopper, er verdien på serversiden den som må gjennomgås. Ingen av de to resultatene rettferdiggjør en endring på maskinvare som aldri var på den feilende veien.