IPIP în interiorul WireGuard: cei 20 de octeți în plus pe care nimeni nu i-a bugetat

Ping-urile mici traversează tunelul toată ziua, bannerul SSH ajunge și apoi sesiunea îngheață în momentul în care începe un transfer de fișier. Acest model indică un buget de octeți numărat la stratul greșit, unde tunelul exterior a fost dimensionat pentru propriul cost și nimeni nu l-a scăzut pe cel interior. Un pachet IPIP imbricat este doar un alt pachet IP pentru WireGuard, și exact de aceea consumă octeți pe care nu i-ați rezervat niciodată. Corecția este aritmetică și încape în trei comenzi și un tabel.

Simptomul care o trădează

Problemele de fragmentare se anunță prin dimensiune, niciodată prin adrese. Partenerul tău răspunde la un ping de 56 de octeți timp de o oră și apoi tace la 1400 de octeți în timp ce tunelul rămâne ridicat și nicio rută nu s-a schimbat. Handshake-ul încape, prima fereastră TCP completă nu, iar transferul se blochează la câteva secunde după ce a părut sănătos.

Măsurați plafonul înainte de a edita ceva, pentru că un plafon nemăsurat este cel pe care îl veți urmări de două ori. Trimiteți o sondă sub dimensiunea suspectă cu bitul do-not-fragment setat, ping -M do -s 1000 10.9.0.2, apoi repetați-o la o dimensiune despre care știți deja că este prea mare. Când răsturnarea urmează dimensiunea încărcăturii în timp ce destinația rămâne neschimbată, rutarea își face treaba și lipsește un antet din buget.

Numărați fiecare antet o dată, la stratul corect

Porniți de la cel mai mic MTU de pe traseu, nu de la interfața tunelului, pentru că zidul se află în amonte de ambele capete. WireGuard cheltuie 60 de octeți pe un transport exterior IPv4: 20 pentru IP, 8 pentru UDP și 32 pentru propriul antet, și 80 de octeți când acel transport este IPv6. Un wg0 de 1420 de octeți păstrează 20 de octeți de rezervă sub 1440 pe care o rută de 1500 de octeți poate livra cu adevărat, și de aceea cifra copiată dintr-un wiki încă se potrivește aici. Desenați întregul stivă pe diagramă, pentru că următorul care va schimba MTU va alege altfel un număr rotund nou și vă va moșteni eroarea.

Al cincilea rând este locul unde bugetele se strică, pentru că 1400 de octeți pe care îi poartă o interfață imbricată includ deja propriii 40 de octeți de anteturi ai pachetului original. Doar 1360 dintre acei octeți ajung la procesul care citește fișierul. Tratați 1400 ca încărcătură a aplicației, cum vă invită orice diagramă fără acea coloană, iar dispozitivul interior ajunge cu 40 de octeți prea generos față de un zid care nu s-a mișcat.

Setați cele două MTU separat

Purtătorul și dispozitivul imbricat sunt obiecte separate, așa că fiecare are nevoie de propria valoare. Aplicați-le în această ordine, pentru că dispozitivul imbricat nu moștenește nimic de la purtător:

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

Regula care merită memorată: MTU interior = MTU exterior - 20 când pachetul purtat de tunelul IPIP este IPv4, și - 40 de îndată ce orice parte a pachetului interior este IPv6, pentru că antetul imbricat crește de la 20 de octeți la 40. Nimic altceva nu aparține acelei scăderi. Costul WireGuard a fost deja cheltuit când ați ales 1420, iar taxarea lui de două ori produce un tunel care funcționează perfect și rămâne lent atât timp cât nimeni nu îl măsoară. O instalare în care ambele dispozitive poartă un 1400 rotund este amprenta exactă a acelei greșeli.

IPv6 pe oricare parte a pachetului imbricat invalidează fiecare cifră de mai sus, așa că recalculați în loc să copiați un număr de pe un site similar. Anteturile scăzute sunt de 40 de octeți fiecare de îndată ce IPv6 apare pe traseul exterior sau în datagrama originală, iar cifra încărcăturii scade exact cu atât.

Regula de firewall de care probabil nu aveți nevoie

Între doi parteneri WireGuard singurul lucru de pe fir este UDP, așa că o regulă de intrare pentru protocolul 4, numărul pe care RFC 2003 îl atribuie încapsulării IPv4-în-IPv4, nici nu creează traseul imbricat, nici nu îl ține în viață. Antetul IPIP trăiește în interiorul încărcăturii criptate, unde niciun firewall de margine nu îl vede. Deschiderea protocolului 4 oricum nu cumpără nimic în afară de încă o cale permisă către gazdă.

Politica ce menționează sursele și destinațiile pachetului original aparține după decapsulare, pe interfețele tunelului și în tabela de rutare. Puneți-o acolo și regula de margine poate rămâne închisă.

Ce validează de fapt WireGuard

AllowedIPs judecă sursa pachetului pe care îl poartă WireGuard, iar ceea ce poartă este pachetul încapsulat în IPIP. O sursă IPIP permisă este acceptată chiar și când antetul din interior numește o gazdă pe care ați prefera să nu o rutați. Așadar sursa originală nu este ceea ce partenerul a verificat pentru dumneavoastră, iar acea pereche interioară de adrese are nevoie de propria aplicare după decapsulare.

Învelișul oferă structură de rutare, nu un al doilea strat de criptografie. A numi IPIP protecție suplimentară în interiorul WireGuard descrie un alt proiect.

Verificați cu o scară, nu cu un singur ping

Testați dimensiuni care înconjoară granița calculată, apoi confirmați ce crede nucleul despre ambele dispozitive. Cu 1360 de octeți de încărcătură plus 40 de octeți de anteturi făcând 1400, primul ecou de mai jos încape, iar al doilea stă cu un octet dincolo de 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

O trecere curată sub plafon și un eșec la prima dimensiune de deasupra înseamnă că aritmetica rezistă de la un capăt la altul. Apoi rulați din nou transferul care s-a blocat inițial, pentru că o sondă sintetică dovedește bugetul și nu spune nimic despre dimensiunile de scriere ale expeditorului însuși. Dacă traseul imbricat încă se rupe la o dimensiune despre care ați dovedit că încape, inspectați decapsularea și rutele capătului îndepărtat înainte de a mai tăia zece octeți din MTU.