OpenVPN op PPPoE: link-mtu, tun-mtu of mssfix ferleegje?

Pings antwurdzje, DNS lost op, en elke side dy't in folslein segmint nedich hat, hinget. Op in oansluting dy't syn eigen ynkapseling tafoeget, ferliest it paad stil in pear tsientallen bytes budzjet, en in profyl skreaun foar suver Ethernet bliuwt pakketten freegje dy't de line net drage kin. De ferbining is net stadich; se smyt krekt de pakketten fuort dy't der ta dogge.

Trije opsjes kinne dit oplosse, en se wurkje op ferskate lagen. It ferkearde kieze docht of neat of makket de tunnel op in nije manier breekber, dus de kar begjint by wat it paad eins stipet.

Trije knoppen, trije ferskate lagen

link-mtu is it bûtenste budzjet: de fersifere lading plus de OpenVPN-kop, de UDP-kop en de bûtenste IP-kop. It beskriuwt wat de masine ferlit, en dêrom is it it getal dat it fysike paad beheint.

tun-mtu is it binnenste budzjet: de ynterface dy't jo ferkear sjocht. It is krekt de oerhead fan de tunnel grutter as wat it paad drage kin, en OpenVPN liedt it normaal ôf ynstee fan jo te twingjen it yn te stellen.

mssfix is in hiel oar meganisme. It skriuwt de maksimale segmintgrutte oer dy't by TCP-hânskearen oankundige wurdt, sadat TCP-pearen segminten kieze dy't nei de ynkapseling passe. It feroaret de MTU fan de ynterface net en hat gjin effekt op UDP.

As jo link-mtu eksplisyt ynstelle, lûkt OpenVPN syn eigen oerhead derôf om de binnenste MTU te liede. Dy oerhead is gjin fêste konstante; it hinget ôf fan de syffer en autentikaasje, en dêrom kin in wearde kopiearre fan in forum ferkeard wêze op in oar profyl. As jo sawol link-mtu as tun-mtu ynstelle, jouwe jo de klient twa tsjinstridige ynstruksjes.

Mjit it paad foardat jo in getal kieze

Mjit fan de fysike ynterface, net fan binnen de tunnel, en tink deroan dat ping de lading rapportearret, net de pakketgrutte. Foegje 28 bytes ta foar de IPv4- en ICMP-koppen foardat jo de lading mei in frame fan 1500 bytes fergelykje, en hâld dy korreksje yn 't sin as in tsjinhinger in oar getal rapportearret.

Op in Linux-klient ferbiedt ping -M do -s 1472 fragmintaasje en mislearret as it pakket te grut is. Ferleegje de lading oant it trochgiet, foegje dan 28 ta om de MTU fan it paad te krijen. PPPoE kostet 8 bytes, dus 1492 is normaal op DSL. DS-Lite en guon mobile paden kostje 40 of mear, en it antwurd is meastal leger as de nominale linkfaasje suggerearret.

As elke ping-grutte slagget mar grutte oerdrachten noch altyd hingje, fertink dan in swart gat ynstee fan in simpele gruttelimyt. In ICMP-berjocht oer nedige fragmintaasje wurdt earne op it paad filtere, dus de stjoerder leart nea te krimpen, en allinnich de streamen dy't in grut segmint nedich hawwe merke it.

Behein earst TCP, ferlytsje de tunnel dêrnei

TCP-hânskearen binne it iennige dat mssfix oanrekket, wat it meastal de minst yngeande kontrôle makket om earst te besykjen. Set it wat ûnder it echte budzjet fan it paad, stjoer deselde wearde fan de server sadat beide kanten iens binne, en test in grutte download opnij. As de hingjen ferdwynt, wie it probleem de TCP-segmintgrutte, en hoecht der neat oars te feroarjen.

Ferleegje de binnenste MTU as it beynfloede ferkear gjin TCP is. In UDP-tsjinst, in tunnel yn 'e tunnel of in applikaasje dy't folsleine datagrammen stjoert, sil nei in MSS-beheining noch altyd mislearje, om't neat syn pakketgrutte oerskriuwt. Ferleegje tun-mtu foar dat gefal, of stel link-mtu yn en lit de klient de binnenste wearde liede, mar nea beide.

Gryp net nei de âlde fragmintaasje-opsje. It spjalte pakketten yn 'e tunnel, foege oerhead ta en is om goede redenen ferâldere; moderne OpenVPN ferwachtet dat it paad sekuer beskreaun wurdt.

Wêrom lytse mjittingen bliuwe wurkjen

DNS-fragen, ICMP-echos en TCP-hânskearen binne allegear fier ûnder de grutte dy't mislearret. De tunnel liket dêrom sûn yn elke snelle test, wylst TLS-hânskearen en HTTP-antwurden stil mislearje. Krekt dy kombinaasje, in wurkjende traceroute en in browser dy't hingje bliuwt by it earste grutte antwurd, is it sinjaal om nei te sykjen. Gryp nei in mjitting fan folsleine grutte foardat jo nei in nij profyl gryp.

Ferifiearje mei it ferkear dat mislearre. Helje in grutte side op, stjoer in UDP-datagram fan folsleine grutte as dat de beynfloede tsjinst is, en werhelje fan in twadde klient op in oare oansluting. Skriuw de metten MTU fan it paad en de wearde dy't jo keazen op, want de folgjende persoan dy't it profyl oanrekket, behannelet it getal oars as willekeurich.

Nim de binnenste MTU noait ûnder 1280 as IPv6 oer de tunnel rint, want dat is it minimum dat elke IPv6-keppeling drage moat. In lytsere MTU is in feit oer it paad, gjin prestaasje-ynstelling om op gefoel te stimmen.