IPIP yn WireGuard: de ekstra 20 bytes dy't nimmen budgettearre hie

Lytse pings geane de hiele dei troch de tunnel, de SSH-banner komt oan, en dan fret de sesje op it stuit dat in bestânsoerdracht begjint. Dat patroan wiist op in bytebudzjet dat op 'e ferkearde laach teld is, wêr't de bûtenste tunnel op syn eigen overhead ôfmjitte waard en nimmen de binnenste ôfluts. In nêst IPIP-pakket is foar WireGuard gewoan noch in IP-pakket, en dêrom krekt ferbrûkt it bytes dy't jo nea reservearre hawwe. De korreksje is rekkenjen, en it past yn trije opdrachten en ien tabel.

It symptoom dat it ferriedt

Fragmintaasjeproblemen kundigje har oan troch grutte, nea troch adressen. Jo peer antwurdet in oere lang op in 56-byte ping en wurdt dan stil by 1400 bytes wylst de tunnel oerbliuwt en gjin rûte feroare is. De hânskudding past, it earste folsleine TCP-finster net, en de oerdracht stûket sekonden neidat it sûn like.

Mjit it plafond foardat jo eat bewurkje, want in net mjitten plafond is ien dy't jo twa kear efterfolgje sille. Stjoer ien probe ûnder de fertochte grutte mei de do-not-fragment-bit oan, ping -M do -s 1000 10.9.0.2, en werhelje it dan by in grutte dy't jo al witte te grut is. As de omslach de grutte fan 'e payload folget wylst de bestimming itselde bliuwt, docht routing syn wurk en mist der in kop yn it budget.

Tel elke kop ien kear, op 'e goede laach

Begjin by de lytste MTU op it paad en net by de tunnelinterface, want de muorre sit boppe beide einen. WireGuard besteget 60 bytes oan in IPv4-bûtenferfier: 20 foar IP, 8 foar UDP en 32 foar syn eigen kop, en 80 bytes as dat ferfier IPv6 is. In 1420-byte wg0 hâldt 20 bytes speling ûnder de 1440 dy't in paad fan 1500 bytes wier leverje kin, en dêrom past it sifer dat fan in wiki kopiearre is hjir noch altyd. Tekenje de hiele stapel op it diagram, want wa't de MTU dêrnei feroaret, kiest oars in nij rûn getal en erft jo bug.

De fyfde rige is wêr't budgetten misgeane, want de 1400 bytes dy't in nêstinterface draacht, befetsje al de eigen 40 bytes koppen fan it oarspronklike pakket. Allinne 1360 fan dy bytes berikke it proses dat it bestân lêst. Behandelje 1400 as applikaasje-payload, sa't elk diagram sûnder dy kolom jo útnoeget, en it binnenste apparaat einiget 40 bytes te roy yn 'e mjitte fan in muorre dy't net ferhuze is.

Set de twa MTU's apart

De drager en it nêstapparaat binne aparte objekten, dus elk hat syn eigen wearde nedich. Pas se yn dizze folchoarder ta, want it nêstapparaat erft neat fan 'e drager:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

De regel dy't it ûnthâlden wurdich is: binnenste MTU = bûtenste MTU - 20 as it pakket dat de IPIP-tunnel draacht IPv4 is, en - 40 sadree't ien fan beide kanten fan it binnenste pakket IPv6 is, want de nêstkop groeit fan 20 bytes nei 40. Neat oars heart yn dy ôflûk. De overhead fan WireGuard is al bestege doe't jo 1420 keazen, en it twa kear rekkenje levert in tunnel op dy't perfekt wurket en stadich bliuwt salang't nimmen him mjit. In útrôl wêrby't beide apparaten in rûne 1400 drage, is de fingerprint fan krekt dy flater.

IPv6 oan ien fan beide kanten fan it nêstpakket makket elk sifer hjirboppe ûnjildich, dus berekkenje op 'e nij ynstee fan in getal fan in ferlykbere side te kopiearjen. De ôflutsen koppen binne 40 bytes elk sadree't IPv6 yn it bûtenste paad of yn it oarspronklike datagram ferskynt, en it payloadsifer falt krekt safolle.

De firewallregel dy't jo wierskynlik net nedich hawwe

Tusken twa WireGuard-peers is it iennige op 'e tried UDP, dus in ynkommende regel foar protokol 4, it nûmer dat RFC 2003 oan IPv4-yn-IPv4-ynkapseling jout, makket it nêstpaad noch, noch hâldt it it libben. De IPIP-kop libbet binnenyn de fersifere payload, wêr't gjin rânemuur him sjocht. Protokol 4 dochs iepenje levert neat op njonken noch in tastiene wei nei de host.

Belied dat de boarnen en bestimmingen fan it oarspronklike pakket neamt, heart nei de dekapsulaasje, op 'e tunnelinterfaces en yn 'e routingtabel. Set it dêr en de râneregel kin ticht bliuwe.

Wat WireGuard eins falidearret

AllowedIPs beoardielet de boarne fan it pakket dat WireGuard draacht, en wat it draacht is it IPIP-ynkapsle pakket. In tastiene IPIP-boarne wurdt akseptearre sels as de kop binnen in host neamt dêr't jo leaver net nei routearje soene. De oarspronklike boarne is dus net wat de peer foar jo kontrolearre hat, en dat binnenste pear adressen hat syn eigen hanthavening nedich nei de dekapsulaasje.

De wrapper leveret routingstruktuer, net in twadde laach kryptografy. IPIP ekstra beskerming neame binnen WireGuard beskriuwt in oar ûntwerp.

Ferifiearje mei in ljedder, net mei ien ping

Probearje grutten dy't de berekkene grins oan beide kanten oerstekke, en befêstigje dan wat de kernel fan beide apparaten tinkt. Mei 1360 bytes payload plus 40 bytes koppen dy't 1400 meitsje, past it earste echo hjirûnder en sit it twadde ien byte foarby it plafond:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

In skjinne passaazje ûnder it plafond en in mislearring by de earste grutte derboppe betsjutte dat it rekkenjen fan útein oant útein stiet. Rin dan de oerdracht dy't oarspronklik fêstsette opnij, want in syntetyske probe bewiist it budget en seit neat oer de eigen skriuwgrutten fan 'e stjoerder. As it nêstpaad noch altyd brekt by in grutte dy't jo bewiisd hawwe dat er past, besjoch dan de dekapsulaasje en rûtes fan it fiere einpunt foardat jo noch tsien bytes fan 'e MTU ôfsnije.