VPN-MTU-Mythen: firwat Är Pakete schrumpfen a wou de Platz higeet

Een erzielt Iech, de VPN "verléiert Pakete wéinst MTU", Dir setzt den Tunnel op 1400, an den Transfert geet erëm. Dëst Resultat fillt sech wéi eng Diagnos un. Meeschtens ass et en Zoufall an der Arithmetik: Dir hutt eng Zuel gewielt, déi kleng genuch ass, fir ënner eng Grenz ze passen, déi Dir ni identifizéiert hutt, an Dir wäert déi selwecht Grenz erëm op dem nächsten Netz mat engem anere Budget fannen.

Zwee Mythen verursaache meeschtens dovun. Dee fir is, datt den MTU vun der Tunnelschnittstell den MTU vum Wee ass. Dee zweeten, datt Enkapsuléierung "eng Kapp" kascht an datt PPPoE näischt kascht, wat et wäert ass ze zielen. Béid si falsch op eng Manéier, déi d'Zuel, déi Dir wielt, wëllkürlech ausgesäit, obwuel se tatsächlech bestëmmt ass.

Mythe ee: den MTU vum Tunnel ass den MTU vum Wee

De Wäert, deen Dir op enger Tunnelschnittstell setzt, ass eng lokal Verspriechen iwwer de gréisste banneschte Pak, deen d'Implantatioun no ënnen iwwergëtt. D'real Kapazitéit vum Wee ass eng Eegenschaft vun all Verbindung tëscht Iech an dem wäitem Enn, an se kann sech änneren, wann eng Route sech ännert, wann eng mobil Verbindung iwwergëtt oder wann den Trafik eng aner Peering hëlt. Eng gesat 1500 seet Iech, wat Ären Host baut, net wat d'Netz dréit.

D'Wee-MTU-Entdeckung existéiert, fir déi zwee ze versöhnen, an se hänkt vu Feedback of. Bei IPv4 sollt en Router, deen e Pak vu voller Gréisst net ka viruleeden, eng ICMP-Noriicht "fragmentation needed" schécken, an de Sender senkt seng Schätzung. Bei IPv6 ass d'Gläichwäerteg eng Packet Too Big-Noriicht, a Router fragmentéieren iwwerhaapt net am Transit. Wann dëse Feedback gefiltert gëtt, produzéiert de Sender weider Paketen, déi de Wee net ka droen, an näischt seet him firwat.

Mythe zwee: Enkapsuléierung kascht eng Kapp

Zielt déi baussenzeg Schichten éierlech. Eng baussenzeg IP-Kapp ass 20 Byte bei IPv4 oder 40 bei IPv6. UDP-Enkapsuléierung fir NAT-Duerchgang füügt 8 derbäi. De Tunnelprotokoll füügt seng eege Kapp derbäi, en Initialiséierungsvektor oder Nonce, Padding bis zur Block- oder Ausriichtungsgrenz vum Chiffre, en Trailer an en Integritéitsprüfungswäert. Ofhängeg vum Protokoll an dem Chiffre läit de Total bequem an den Zénger Byte, ier de banneschte Pak iwwerhaapt ufänkt.

Dann zitt nach eng Kéier d'Käpp vum banneschte Pak selwer of. En TCP-Segment am Tunnel dréit seng eege 20-Byte IP-Kapp an 20-Byte TCP-Kapp, an den MSS vum TCP ofgeleet vum MTU, net vun der nomineller Notzlaascht vum Tunnel. Dofir kann ping mat enger méi klenger Notzlaascht geléngen, während en Dateitransfert hänkt: d'Instrumenter testen verschidden Saachen, an nëmmen eng vun hinnen übt en TCP-Segment vu voller Gréisst aus.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Den éischte Kommando mellt den agestellten Tunnel-MTU. Déi zwee Proben schécken eng Notzlaascht vun 1472 Byte, wat mat 28 Byte IPv4- an ICMP-Käpp e Pak vun 1500 Byte ass, an dann eng méi kleng. Wann déi grouss Pro fällt komplett aus an déi kleng geléngt, hutt Dir e Gréisst-ofhängege Feeler an net e allgemenge Routingproblem.

Mythe dräi: PPPoE gëtt Iech nach ëmmer propper 1500

Eng konventionell PPPoE-Zougangsverbindung dréit keen 1500-Byte IP-Pak. D'PPPoE-Kapp plus d'PPP-Protokollfeld huelen 8 Byte an der Ethernet-Kader, wat 1492 fir de IP-Pak léisst. Dat ass déi traditionell Grenz, déi an RFC 2516 beschriwwen ass. Wann Dir e VPN iwwer sou eng Verbindung bedreift, kënnt den Iwwerkapp vum Tunnel aus dësen 1492, net aus 1500.

RFC 4638 definéiert e Wee, fir eng méi grouss PPP-Notzlaascht auszehandelen, wann souwuel den Zougangskonzentrator wéi och d'Ausrüstung vum Client et ënnerstëtzen, dofir beweist "dës Verbindung benotzt PPPoE" eleng keng bestëmmt Zuel. Eng lokal Astellung kann en Zwëschenapparat net forcéieren, e Pak unzehuelen, fir deen en ni konfiguréiert gouf, also ass d'nëtzlech Fro, wat d'Verbindung tatsächlech ausgehandelt huet, net wat d'Etikett seet.

Firwat de Feeler selektiv ausgesäit

Datt kleng Ufroen ze maachen an grouss Transfere stoe bleiwen ass d'klassesch Ënnerschrëft vun engem Schwaarze Lach am Wee-MTU. Den Handshake, d'DNS-Ufro an den API-Uriff passen all; den Massentransfert produzéiert Segmenter vu voller Gréisst, déi op enger Verbindung stierwen, an d'ICMP-Noriicht, déi de Probleem sollt mellen, kënnt ni un. D'Verbindung gesäit gutt aus an den Download hänkt, wat d'Leit op de Server amplaz op de Wee kucke léisst.

En zweeten, verwandten Feeler ass dräi Zuelen ze verwiesselen: den Interface-MTU, den TCP-MSS an dem Protokoll seng eege Fragmentéierungs- oder Padding-Astellung. MSS-Clamping op engem Router schreift den annoncéierten MSS ëm, sou datt de Sender méi kleng Segmenter baut; et ännert den Tunnel-MTU net an hëlleft dem UDP-Trafik net. Alle dräi déi selwecht Zuel ze ginn, well se verbonne schéngen, ass de Wee, wéi eng guttgemengt Ännerung eng funktionéierend Astellung zerbriechen.

Wat ännere, a watfir en Uerdnung

Fänkt mat Beweiser un. Bestätegt mat den Proben uewen, datt de Feeler gréisst-ofhängeg ass, an fënnt déi klengst Gréisst, déi duerchgeet, an déi gréisst, déi fällt. Iwwerpréift den reellen MTU vun der Zougangsverbindung, ier Dir den Tunnel beschëllegt; eng PPPoE-Verbindung begrenzt de Budget, ier Ären VPN se beréiert. Notéiert d'Originalwäerter, sou datt d'Ännerung ka réckgängeg gemaach ginn.

Da gitt déi klengst Upassung un, déi de Client dokumentéiert. Vill Cliente bidden en Tunnel-MTU plus eng MSS-Korrekturoptioun, an d'MSS-Optioun ass dacks dee besseren Hiewel fir TCP, well se de Sender erreecht, ouni all Pak ze verklengeren. Testt déiselwecht Destinatioun an deiselwechten Transfert nach eng Kéier, a notéiert d'Zuelen, op déi Dir Iech gesat hutt. En Tunnelwäert, deen op engem Zougangsnetz funktionéiert, ass keng universell Konstant, an de nächste Site wäert säin eegene Budget hunn.