OpenVPN mssfix: wêrom't ien klient fêst rint by grutte oerdrachten
mssfix skriuwt de TCP-segmintgrutte oer dy't yn 'e tunnel oankundige wurdt. It feroaret UDP net, en de wearde betsjut allinnich wat jo ferzje seit.
Ien laptop rint fêst by uploads troch de tunnel, wylst elk oar apparaat op deselde server bliuwt wurkjen. Dat patroan wiist nei ien paad, net nei de serverkonfiguraasje, en it is de gewoane yngong ta de mssfix-fraach. De opsje kin helpe, mar allinnich foar de TCP-ferbiningen dy't er echt oerskriuwt. It kennen fan it berik hâldt jo tsjin om in wurkjende server te feroarjen om ien klient te rêden.
Wat de opsje oerskriuwt
mssfix bewurket de maksimale segmintgrutte dy't yn TCP-hânskoddsjes oankundige wurdt dy't troch de tunnel geane, sadat de stjoerende kant segminten kiest dy't yn it ynkapsele budzjet passe. It wurket op 'e hânskodding, wat betsjut dat in ferbining dy't foar de feroaring iepene is de ûnderhannele wearde hâldt.
It ferlytset gjin UDP-datagrammen en it set de MTU fan 'e tunnel net. Twa ferskillende problemen jouwe itselde symptoom: in TCP-stjoerder dy't de paadlimyt negearret, en in paad dat grutte pakketten fan elke grutte stilwei weismyt. mssfix pakket it earste oan en docht neat foar it twadde.
Dat ferskil ferklearret de teloarstellende eksperiminten. In lytsere wearde ynstelle op in paad mei in swart gat feroaret de segmintgrutte, mar net it weismiten dat folget, dus de oerdracht mislearret op in oar punt.
It berik is TCP binnen de tunnel
Allinnich TCP-ferkear wurdt oerskreaun. In QUIC-sesje, in spultsje of in applikaasje dy't grutte UDP-datagrammen stjoert, hâldt syn eigen pakketgruttes, en as dat de oerdrachten binne dy't fêstrinne, heart de oplossing earder by de MTU fan 'e tunnel of it paad. Lês hokker protokol de mislearjende oerdracht brûkt foardat jo nei in TCP-opsje gripe, want de ferkearde laach hat syn eigen oplossing.
De rjochting is ek fan belang. In kliïntynstelling beynfloedet it ferkear dat dy klient de tunnel yn stjoert, wylst de server de streamen dekt dy't er nei klienten trochstjoert. As allinnich ynkommende downloads fêstrinne, is de klintaardige wearde net it hiele ferhaal.
It getal en it kaaiwurd binne net oerdraachber
De mienskipferzje fan OpenVPN 2.6 akseptearret in opsjoneel kaaiwurd nei de wearde. Mei mtu beskriuwt it getal de bûtenste pakketgrutte ynklusyf IP- en UDP-kopteksten; sûnder dat folget it argumint in oare boekhâldkonvinsje. In rigel dy't tusken ferzjes kopiearre wurdt beskriuwt dêrom net itselde pakketbudzjet. Sjoch nei de hânliedingsside dy't mei de build komt dy't jo echt rinne, ynstee fan in tutorial foar in oare útjefte.
De syntaksis sjocht der sa út:
mssfix 1400 mtuBehannelje 1400 as in plakhâlder, net as in oanbefelling foar jo paad. Lied de wearde ôf fan it metten paad en de ynkapseling dy't echt brûkt wurdt, en tink derom dat klienten op âldere ferzjes of oare ymplemintaasjes it kaaiwurd ôfwize of oars ynterpretearje kinne.
Befêstigje it earst op 'e iene klient
Mjit it paad fan 'e mislearjende masine foardat jo wat feroarje. In lading dy't it paad sûnder fragmintaasje drage kin is it getal dat jo sykje:
ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1De earste probe past in pakket fan 1500 byte as de 28 byte kopteksten tafoege wurde. As it mislearret mei in fragmintaasjeflater en de lytsere slagget, leit de brûkbere grutte earne tusken harren, en de tunnelkosten geane der boppeôf.
Werhelje dan de oerdracht dy't fêstrûn, op in nije ferbining, en fergelykje. As de iene klient better wurdt wylst de oaren ûnoantaaste bliuwe, hawwe jo it berik fan it probleem fûn. As elke klient fêst rint, is de serveraardige wearde dejinge om te besjen. Gjin fan beide resultaten rjochtfeardiget in feroaring op hardware dy't nea yn it mislearjende paad wie.