Frakte ei fast indrepakke på 1,500 byte gjennom ein VPN

Du har eit krav som ikkje bøyer seg: den andre sida må ta imot den same 1,500-byte IP-pakka som sendaren legg ut, inkludert headarar. Ein tunnel kan ikkje pakke den pakka pluss si eiga framing inn i ei andre 1,500-byte IP-pakke, så noko i designet må gje etter. Rekkjefølgja nedanfor er den eg brukar i eit endringsvindauge: skriv bytebudsjettet, prov kva underlaget faktisk kan bera, vel deretter nøyaktig éin transportmekanisme og stadfest indrepakka på den andre sida.

Skriv bytebudsjettet før du redigerer ein profil

Innkapsling legg til byte på fleire lag, og summen er ein eigenskap ved profilen din og ikkje ein konstant du kan slå opp. Adressefamilie, val av siffer, transportprotokoll og kvart komprimering- eller framing-val flyttar talet, og difor er ein subtraksjon kopiert frå ein annan utrulling verdilaus som budsjett. Start med det indre kravet, legg til den målte overheaden per pakke for din eigen konfigurasjon, og skriv den resulterande ytre storleiken på endringssaka før nokon redigerer ei fil.

To tal avgjer designet: den største ytre pakka vegen ber utan fragmentering, og dei ekstra byta som innkapslinga di treng. Når det første er mindre enn det andre pluss 1,500, må eitt av dei endrast. Valet vert då smalt og ikkje kreativt, og difor skriv eg ned båe tala før eg diskuterer alternativ. Ingenting på tunnellaget komprimerer dei byta bort, og ingen einskild MTU-heiltal fjernar kravet du fekk.

Sonder underlaget med do-not-fragment-ping

Mål vegen i staden for å stole på grensesnittet sin MTU, fordi den minste lenkja i den ytre vegen er den som tel. På Linux, -M do set do-not-fragment-biten og -s tek ICMP-nyttelasta, så ei ramme på 1,500 byte svarar med 1,472 byte nyttelast når 20 byte IP-header og 8 byte ICMP-header er trekte frå. Auk nyttelasta til sonden feilar, og hopp deretter til ein jumbo-storleik for å sjå om vegen ber ho i det heile.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Ein veg som passerer 1,472 og feilar på 8,972 kan ikkje bera ei indrepakke på 1,500 byte pluss overhead i éi einskild ytre pakke. Det er svaret du trengde før du opna VPN-konfigurasjonen. Det avgjer òg kva av dei to neste seksjonane som gjeld for deg, så hald dei to sonderesultata ved endringssaka. Å gjette her kostar eit vedlikehaldsvindauge, fordi ein tunnel som rapporterer at han er up ikkje fortel deg noko om den største pakka vegen vil godta.

Auk MTU-en til vegen berre der kvart hopp er samd

Jumbo-rammer er ein ende-til-ende-eigenskap, ikkje ei innstilling du slår på på dei to endepunkta du tilfeldigvis kontrollerer. Kvar svitsj, ruter og leverandøroverlevering på den ytre vegen må vere samd om den større storleiken, og eitt einskild hopp på 1,500 byte vil stille forkaste pakka du nettopp gjorde større. Å auke berre grensesnittet lokalt er den klassiske halvenda som får tunnelen til å sjå øydelagd ut medan underlaget stille slepp.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Endre grensesnittet, og sonder deretter den same vegen på nytt før du endrar noko anna. Viss sonden framleis feilar, rull tilbake med ip link set dev eth1 mtu 1500 og gå over til fragmentering i staden for å krangle med ein leverandør om ei lenkje du ikkje eig.

Bruk tunnelfragmentering når underlaget ikkje kan vekse

Ein støtta fragmenteringsmekanisme under indrepakka lèt fleire ytre pakker bera éi indrepakke, og det andre tunnelendepunktet set dei saman att før det leverer originalen til stakken. Community OpenVPN sitt UDP-fragmentval er éin implementasjon av den ideen, og det er ikkje det same som vanleg IP-fragmentering av den ytre pakka. Båe peer må køyre ein versjon som støttar formatet, og datastien må vere den du trur: OpenVPN 3-klientar og kjerneakselererte datakanalar har ulike grenser, så ein profil som fungerer på éin klient kan feile på ein annan.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Vanleg ytre fragmentering er det andre alternativet, og det er det svakare. IPv6-rutarar fragmenterer ikkje ei vidaresend pakke i det heile, så ei for stor ytre pakke døyr berre, og sendaren får vite det først viss den relevante ICMPv6-meldinga overlever vegen. Fragment inviterer òg til filtrering og tapforsterking, og difor behandlar eg dette som ein reserve og ikkje ein plan.

Ein straumbasert ytre berar omgår storleiksspørsmålet ved å segmentere sin eigen bytestraum, og den rekonstruerte indrepakka kan framleis vere 1,500 byte. Det er eit transportval med sin eigen kostnad, inkludert den kjende åtferda til TCP inne i TCP, så ta det medvite og ikkje som ein biverknad av ein MTU-diskusjon.

Stadfest at indrepakka kjem fram uendra

Verifisering er ikkje eit vellukka handshake. Ta opp på tunnelgrensesnittet i båe endar og samanlikn storleiken og innhaldet i pakka applikasjonen faktisk sende med den den andre sida tok imot.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Viss opptaket viser den fullstore indrepakka i den andre enden, fungerer transportvalet, og det som står att er å dokumentere det. Viss det ikkje viser noko medan tunnelen rapporterer at han er up, vert den ytre pakka forkasta ein stad mellom endepunkta, noko som sender deg tilbake til sonden og ikkje til sifferinnstillingane.

Skriv tre ting i endringssaka før du lukkar ho: det målte ytre budsjettet, mekanismen du valde, og kommandoen som prova at indrepakka overlevde. Den neste personen som rører denne tunnelen treng alle tre, og ingen av dei kan rekonstruerast frå konfigurasjonsfila åleine.