IPIP binne WireGuard: die ekstra 20 grepe wat niemand begroot het nie

Klein pings kruis die hele dag deur die tonnel, die SSH-banier kom deur, en dan vries die sessie op die oomblik wanneer 'n lêeroordrag begin. Dié patroon dui op 'n grepebegroting wat op die verkeerde laag getel is, waar die buitenste tonnel vir sy eie oorhoofs geskaal is en niemand die binneste afgetrek het nie. 'n Geneste IPIP-pakket is net nog 'n IP-pakket sover WireGuard aangaan, en dit is juis hoekom dit grepe opgebruik wat jy nooit gereserveer het nie. Die regstelling is rekenkunde, en dit pas in drie opdragte en een tabel.

Die simptoom wat dit verraai

Fragmentasieprobleme kondig hulself deur grootte aan, nooit deur adresse nie. Jou eweknie antwoord 'n uur lank op 'n 56-grepe ping en word dan stil by 1400 grepe terwyl die tonnel op bly en geen roete verander het nie. Die handdruk pas, die eerste volle TCP-venster nie, en die oordrag stagneer sekondes nadat dit gesond gelyk het.

Meet die plafon voordat jy enigiets redigeer, want 'n ongemete plafon is een waarvoor jy twee keer sal jaag. Stuur een probe onder die vermoede grootte met die do-not-fragment-bis ingestel, ping -M do -s 1000 10.9.0.2, en herhaal dit dan teen 'n grootte wat jy reeds weet te groot is. Wanneer die omslaan die loonvrag se grootte volg terwyl die bestemming onveranderd bly, doen routing sy werk en ontbreek daar 'n opskrif in die begroting.

Tel elke opskrif een keer, op die regte laag

Begin by die kleinste MTU op die pad eerder as by die tonnelkoppelvlak, want die muur sit stroomop van beide eindpunte. WireGuard bestee 60 grepe aan 'n IPv4-buitevervoer, verdeel as 20 vir IP, 8 vir UDP en 32 vir sy eie opskrif, en 80 grepe wanneer daardie vervoer IPv6 is. 'n 1420-grepe wg0 hou 20 grepe speling onder die 1440 wat 'n 1500-grepe pad werklik kan lewer, en daarom pas die syfer wat uit 'n wiki gekopieer is hier steeds. Skryf die hele stapel op die diagram, want wie volgende die MTU verander, sal anders 'n nuwe ronde getal kies en jou fout erf.

Die vyfde ry is waar begrotings verkeerd loop, want die 1400 grepe wat 'n geneste koppelvlak dra, sluit reeds die oorspronklike pakket se eie 40 grepe opskrifte in. Slegs 1360 van daardie grepe bereik die proses wat die lêer lees. Behandel 1400 as toepassingsloonvrag, soos enige diagram sonder daardie kolom jou nooi om te doen, en die binneste toestel eindig 40 grepe te vrygewig teen 'n muur wat nie beweeg het nie.

Stel die twee MTU's afsonderlik

Die draer en die geneste toestel is aparte objekte, so elkeen het sy eie waarde nodig. Pas hulle in hierdie volgorde toe, want die geneste toestel erf niks van die draer nie:

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

Die reël wat die moeite werd is om te memoriseer: binneste MTU = buitenste MTU - 20 wanneer die pakket wat die IPIP-tonnel dra IPv4 is, en - 40 sodra enige kant van die binneste pakket IPv6 is, want die geneste opskrif groei van 20 grepe na 40. Niks anders hoort in daardie aftrekking nie. WireGuard se oorhoofs is reeds bestee toe jy 1420 gekies het, en om dit twee keer te hef lewer 'n tonnel wat perfek werk en stadig bly solank niemand dit meet nie. 'n Ontplooiing waar beide toestelle 'n ronde 1400 dra, is die vingerafdruk van presies daardie fout.

IPv6 aan weerskante van die geneste pakket maak elke syfer hierbo ongeldig, so herbereken in plaas daarvan om 'n nommer van 'n soortgelyke webwerf te kopieer. Die afgetrekte opskrifte is 40 grepe elk sodra IPv6 in die buitenste pad of in die oorspronklike datagram verskyn, en die loonvragsyfer val presies soveel.

Die firewall-reël wat jy waarskynlik nie nodig het nie

Tussen twee WireGuard-eweknieë is die enigste ding op die draad UDP, so 'n inkomende reël vir protokol 4, die nommer wat RFC 2003 aan IPv4-in-IPv4-inkapseling toeken, skep nie die geneste pad nie en hou dit ook nie lewendig nie. Die IPIP-opskrif woon binne die geënkripteerde loonvrag, waar geen randfirewall dit sien nie. Om protokol 4 nietemin oop te maak, koop niks meer as een ekstra toegelate weg na die gasheer nie.

Beleid wat die oorspronklike pakket se bronne en bestemmings noem, hoort ná dekapsulering, op die tonnelkoppelvlakke en in die roetebeheer. Sit dit daar en die randreël kan toe bly.

Wat WireGuard werklik valideer

AllowedIPs beoordeel die bron van die pakket wat WireGuard dra, en wat dit dra is die IPIP-ingekapselde pakket. 'n Toegelate IPIP-bron word aanvaar selfs wanneer die opskrif binne 'n gasheer noem wat jy liewer nie sou roeteer nie. Die oorspronklike bron is dus nie wat die eweknie vir jou nagegaan het nie, en daardie binneste paar adresse het sy eie afdwinging nodig ná dekapsulering.

Die omhulsel verskaf roetestruktuur, nie 'n tweede kriptografielaag nie. Om IPIP ekstra beskerming binne WireGuard te noem, beskryf 'n ander ontwerp.

Verifieer met 'n leer, nie 'n enkele ping nie

Peil groottes wat die grens wat jy bereken het weerskante oorskry, en bevestig dan wat die kernel oor albei toestelle glo. Met 1360 grepe loonvrag plus 40 grepe opskrifte wat 1400 maak, pas die eerste eggo hieronder en sit die tweede een grepe verby die plafon:

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

'n Skoon slaag onder die plafon en 'n mislukking by die eerste grootte daarbo beteken die rekenkunde hou van begin tot einde. Herhaal dan die oordrag wat oorspronklik vasgehaak het, want 'n sintetiese probe bewys die begroting en sê niks oor die sender se eie skryfgroottes nie. As die geneste pad steeds breek by 'n grootte wat jy bewys het pas, ondersoek die verre eindpunt se dekapsulering en roetes voordat jy nog tien grepe van die MTU afsny.