IPIP an der WireGuard: déi extra 20 Bytes, déi kee budgetéiert hat

Kleng Pinge ginn de ganzen Dag duerch den Tunnel, den SSH-Banner kënnt un, an dann fréiert d'Sessioun an deem Moment, wou en Dateitransfer ufänkt. Dëst Muster weist op e Bytebudget, deen op der falscher Schicht gezielt gouf, wou den äusseren Tunnel fir seng eege Overhead gemooss gouf an keen den inneren ofgezunn huet. En ageschachtelten IPIP-Paket ass fir WireGuard just en aneren IP-Paket, an dofir verbraucht en Bytes, déi Dir ni reservéiert hutt. D'Korrektur ass Arithmetik, an si passt an dräi Kommandoen an eng Tabell.

D'Symptom, dat et verroden

Fragmentatiounsproblemer annoncéieren sech duerch d'Gréisst, ni duerch d'Adressen. Äre Peer äntwert eng Stonn op en 56-Byte ping an ass dann bei 1400 Bytes stëll, wärend den Tunnel uewen bleift an keng Route sech geännert huet. Den Handshake passt, dat éischt vollt TCP-Fënster net, an den Transfer stockt Sekonnen nodeems en gesond ausgesinn huet.

Moosst d'Plafong, ier Dir eppes ännert, well eng ongemoossene Plafong ass eng, déi Dir zweemol géift nolauschteren. Schéckt eng Sonde ënner der verdächteger Gréisst mat dem do-not-fragment-Bit gesat, ping -M do -s 1000 10.9.0.2, a widderhëlt se dann op enger Gréisst, déi Dir scho wësst ze grouss ass. Wann de Kippen der Gréisst vun der Notzlaascht follegt, wärend d'Destinatioun onverännert bleift, mécht d'Routing seng Aarbecht an et feelt en Header am Budget.

Zielt all Header ee Mol, op der richteger Schicht

Fänkt bei der klengster MTU um Wee un an net bei der Tunnelschnëttstell, well d'Mauer iwwer béiden Endpunkte läit. WireGuard gëtt 60 Bytes fir en IPv4-Aussentransport aus: 20 fir IP, 8 fir UDP an 32 fir säin eegenen Header, an 80 Bytes wann deen Transport IPv6 ass. Eng 1420-Byte wg0 hält 20 Bytes Spillraum ënner den 1440, déi e 1500-Byte-Wee wierklech liwwere kann, an dofir passt d'Zuel, déi aus enger Wiki kopéiert gouf nach ëmmer hei. Zeechent de ganze Stack op den Diagramm, well wien den MTU als nächstes ännert, soss eng nei ronn Zuel wielt an Äre Feeler ierft.

Déi fënneft Zeil ass de Punkt, wou d'Budgeten aus dem Ruder lafen, well déi 1400 Bytes, déi eng ageschachtelt Schnëttstell dréit, schonn déi eegen 40 Bytes Header vum Originalpaket enthalen. Nëmmen 1360 vun deene Bytes erreechen de Prozess, deen d'Datei liest. Behandelt 1400 als Applikatiounsnotzlaascht, wéi et all Diagramm ouni déi Kolonn Iech invitéiert, an dat bannenzegt Gerät ass 40 Bytes ze generéis géint eng Mauer, déi sech net geréckelt huet.

Setzt déi zwou MTUen getrennt

Den Träger an dat ageschachtelt Gerät sinn getrennt Objeten, also brauch jiddereen säin eegene Wäert. Wënnt se an dëser Reihenfolg un, well dat ageschachtelt Gerät näischt vum Träger ierft:

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

D'Regel, déi et wäert ass ze memoriséieren: bannenzeg MTU = baussenzeg MTU - 20 wann de Paket, deen den IPIP-Tunnel dréit, IPv4 ass, an - 40 soubal eng Säit vum bannenzegen Paket IPv6 ass, well den ageschachtelten Header vun 20 Bytes op 40 wiisst. Näischt anescht gehéiert an déi Subtraktioun. D'WireGuard-Overhead war schonn ausginn, wéi Dir 1420 gewielt hutt, an se zweemol ze berechnen produzéiert en Tunnel, deen perfekt funktionéiert an dee lues bleift soulaang kee se misst. Eng Ausrollung, an där béid Geräter eng ronn 1400 droen, ass de Fangerofdrock vum genee deem Feeler.

IPv6 op all Säit vum ageschachtelte Paket annuléiert all Zuel uewendriwwer, also rechent nei, amplaz eng Zuel vun enger ähnlecher Säit ze kopéieren. Déi ofgezunn Headeren sinn 40 Bytes jiddereen, soubal IPv6 am baussenzege Wee oder am ursprénglechen Datagramm erschéngt, an d'Notzlaaschtzuel fällt genee esou vill.

D'Firewallregel, déi Dir wahrscheinlech net braucht

Tëscht zwee WireGuard-Peeren ass dat eenzegt um Kabel UDP, dofir schaaft eng Inbound-Regel fir Protokoll 4, d'Nummer, déi RFC 2003 der IPv4-an-IPv4-Kapselung gëtt, weder de ageschachtelte Wee nach hält se en um Liewen. Den IPIP-Header lieft an der verschlësselter Notzlaascht, wou keng Edge-Firewall en gesäit. De Protokoll 4 trotzdem opzemaachen kaaft näischt ausser engem weidere erlaabte Wee an den Host.

Politik, déi d'Quellen an d'Destinatioune vum Originalpaket ernimmt, gehéiert no der Dekapsulatioun, op den Tunnelschnëttstellen an an der Routingtabell. Setzt se do, an d'Edge-Regel kann zou bleiwen.

Wat WireGuard tatsächlech validéiert

AllowedIPs beurteelt d'Quell vum Paket, deen WireGuard dréit, an dat, wat en dréit, ass deen IPIP-kapseléierte Paket. Eng erlaabte IPIP-Quell gëtt akzeptéiert och wann den Header dobannen en Host nennt, deen Dir léiwer net géift routen. D'Originalquell ass also net dat, wat de Peer fir Iech gepréift huet, an dee bannenzegen Adresspaar brauch no der Dekapsulatioun seng eegen Duerchsetzung.

Den Abrëller liwwert Routingstruktur, net eng zweet Kryptographieschicht. IPIP als extra Schutz an der WireGuard ze bezeechnen beschreift en aneren Design.

Verifizéiert mat enger Leeder, net engem eenzegen Ping

Testt Gréissten, déi d'Grenz, déi Dir berechent hutt, op béide Säite begrenzen, a bestätegt dann, wat de Kernel iwwer béid Geräter mengt. Wann 1360 Bytes Notzlaascht plus 40 Bytes Headeren 1400 erginn, passt den éischte Echo hei ënnen, an den zweeten sëtzt ee Byte iwwer d'Plafong:

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

En proppere Passage ënner der Plafong an e Feeler bei der éischter Gréisst driwwer bedeiten, datt d'Arithmetik vun Enn zu Enn hält. Start dann den Transfer, deen ursprénglech gestockt huet, nach eng Kéier, well eng syntheetesch Sonde beweise sech de Budget an seet näischt iwwer d'Schreifgréissten vum Sender selwer. Wann den ageschachtelte Wee nach ëmmer bei enger Gréisst brécht, déi Dir bewisen hutt datt se passt, iwwerpréift dem wäitem Enn seng Dekapsulatioun an d'Routen, ier Dir nach zéng Bytes vum MTU ofschneit.