IPIP binnen WireGuard: de extra 20 bytes die niemand had begroot

Kleine pings gaan de hele dag door de tunnel, de SSH-banner komt binnen en dan bevriest de sessie op het moment dat een bestandsoverdracht begint. Dat patroon wijst op een bytebudget dat op de verkeerde laag is geteld, waar de buitenste tunnel op zijn eigen overhead is gedimensioneerd en niemand de binnenste heeft afgetrokken. Een genest IPIP-pakket is voor WireGuard gewoon weer een IP-pakket, en juist daarom verbruikt het bytes die u nooit heeft gereserveerd. De correctie is rekenwerk, en het past in drie commando's en één tabel.

Het symptoom dat het verraadt

Fragmentatieproblemen kondigen zich aan via grootte, nooit via adressen. Uw peer antwoordt een uur lang op een 56-byte ping en wordt dan stil bij 1400 bytes terwijl de tunnel overeind blijft en geen route is veranderd. De handshake past, het eerste volledige TCP-venster niet, en de overdracht stokt seconden nadat hij gezond leek.

Meet het plafond voordat u iets aanpast, want een ongemeten plafond is er een die u twee keer zult najagen. Stuur één probe onder de vermoede grootte met de do-not-fragment-bit gezet, ping -M do -s 1000 10.9.0.2, en herhaal die dan op een grootte waarvan u al weet dat die te groot is. Wanneer de omslag de grootte van de payload volgt terwijl de bestemming onveranderd blijft, doet routing zijn werk en ontbreekt er een header in het budget.

Tel elke header één keer, op de juiste laag

Begin bij de kleinste MTU op het pad en niet bij de tunnelinterface, want de muur staat stroomopwaarts van beide uiteinden. WireGuard besteedt 60 bytes aan een IPv4-buitentransport: 20 voor IP, 8 voor UDP en 32 voor zijn eigen header, en 80 bytes wanneer dat transport IPv6 is. Een wg0 van 1420 bytes houdt 20 bytes speling onder de 1440 die een pad van 1500 bytes werkelijk kan leveren, en daarom past het getal dat van een wiki is gekopieerd hier nog steeds. Teken de hele stapel op het diagram, want wie hierna de MTU wijzigt, kiest anders een nieuw rond getal en erft uw bug.

De vijfde rij is waar budgetten misgaan, want de 1400 bytes die een geneste interface draagt, bevatten al de eigen 40 bytes headers van het oorspronkelijke pakket. Slechts 1360 van die bytes bereiken het proces dat het bestand leest. Behandel 1400 als applicatiepayload, waartoe elk diagram zonder die kolom u uitnodigt, en het binnenste apparaat eindigt 40 bytes te ruimhartig tegenover een muur die niet is verschoven.

Stel de twee MTU's afzonderlijk in

De drager en het geneste apparaat zijn afzonderlijke objecten, dus elk heeft zijn eigen waarde nodig. Pas ze in deze volgorde toe, want het geneste apparaat erft niets van de 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 die het onthouden waard is: binnenste MTU = buitenste MTU - 20 wanneer het pakket dat de IPIP-tunnel draagt IPv4 is, en - 40 zodra een kant van het binnenste pakket IPv6 is, omdat de geneste header van 20 bytes naar 40 groeit. Niets anders hoort in die aftrekking. De overhead van WireGuard is al besteed toen u 1420 koos, en die twee keer in rekening brengen levert een tunnel op die perfect werkt en traag blijft zolang niemand hem meet. Een uitrol waarin beide apparaten een ronde 1400 dragen, is de vingerafdruk van precies die fout.

IPv6 aan weerszijden van het geneste pakket maakt elk getal hierboven ongeldig, dus herbereken in plaats van een getal van een vergelijkbare site te kopiëren. De afgetrokken headers zijn elk 40 bytes zodra IPv6 in het buitenste pad of in het oorspronkelijke datagram verschijnt, en het payloadgetal daalt precies evenveel.

De firewallregel die u waarschijnlijk niet nodig heeft

Tussen twee WireGuard-peers is het enige op de draad UDP, dus een inkomende regel voor protocol 4, het nummer dat RFC 2003 aan IPv4-in-IPv4-inkapseling toekent, maakt het geneste pad niet en houdt het niet in leven. De IPIP-header leeft binnen de versleutelde payload, waar geen edge-firewall hem ziet. Protocol 4 alsnog openzetten levert niets op buiten één extra toegestane weg naar de host.

Beleid dat de bronnen en bestemmingen van het oorspronkelijke pakket noemt, hoort na de decapsulatie, op de tunnelinterfaces en in de routetabel. Zet het daar neer en de edgeregel kan dicht blijven.

Wat WireGuard werkelijk valideert

AllowedIPs beoordeelt de bron van het pakket dat WireGuard draagt, en wat het draagt is het IPIP-ingekapselde pakket. Een toegestane IPIP-bron wordt geaccepteerd, zelfs wanneer de header binnenin een host noemt die u liever niet zou routen. De oorspronkelijke bron is dus niet wat de peer voor u heeft gecontroleerd, en dat binnenste adrespaar heeft na de decapsulatie zijn eigen handhaving nodig.

De wrapper levert routeringsstructuur, geen tweede laag cryptografie. IPIP extra bescherming noemen binnen WireGuard beschrijft een ander ontwerp.

Verifieer met een ladder, niet met één ping

Probeer groottes die de berekende grens aan beide kanten overschrijden, en bevestig dan wat de kernel over beide apparaten denkt. Met 1360 bytes payload plus 40 bytes headers die 1400 maken, past de eerste echo hieronder en zit de tweede één byte voorbij het 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

Een schone doorgang onder het plafond en een fout bij de eerste grootte erboven betekenen dat het rekenwerk van begin tot eind klopt. Herhaal daarna de overdracht die oorspronkelijk vastliep, want een synthetische probe bewijst het budget en zegt niets over de schrijfgroottes van de afzender zelf. Als het geneste pad nog steeds breekt bij een grootte waarvan u heeft bewezen dat die past, onderzoek dan de decapsulatie en routes van het verre uiteinde voordat u nog tien bytes van de MTU afhaalt.