IPIP unutar WireGuard-a: dodatnih 20 bajtova koje niko nije uračunao
IPIP košta još 20 bajtova unutar WireGuard-a. Napravite budžet na pravom sloju prije nego što okrivite fragmentaciju za zaglavljeni prenos na živom tunelu.
Mali pingovi cijeli dan prolaze kroz tunel, SSH banner stigne, a onda se sesija zamrzne u trenutku kad počne prenos datoteke. Taj obrazac ukazuje na budžet bajtova izračunat na pogrešnom sloju, gdje je vanjski tunel dimenzioniran za vlastiti overhead, a niko nije oduzeo unutrašnji. Ugniježđeni IPIP paket je za WireGuard samo još jedan IP paket, i upravo zato troši bajtove koje nikad niste rezervisali. Ispravka je aritmetika i staje u tri komande i jednu tabelu.
Simptom koji to odaje
Problem fragmentacije se najavljuje veličinom, nikad adresama. Vaš peer odgovara na 56-bajtni ping sat vremena, a zatim utihne na 1400 bajtova dok tunel ostaje podignut i nijedna ruta se nije promijenila. Handshake staje, prvi puni TCP prozor ne, i prenos se zaustavi nekoliko sekundi nakon što je izgledao zdravo.
Izmjerite plafon prije nego što bilo šta uredite, jer neizmjereni plafon je onaj koji ćete ganjati dvaput. Pošaljite jednu sondu ispod sumnjive veličine sa postavljenim do-not-fragment bitom, ping -M do -s 1000 10.9.0.2, pa je ponovite na veličini za koju već znate da je prevelika. Kad preokret prati veličinu payloada dok odredište ostaje nepromijenjeno, rutiranje radi svoj posao i u budžetu nedostaje jedno zaglavlje.
Prebrojite svako zaglavlje jednom, na pravom sloju
Pođite od najmanjeg MTU-a na putu, a ne od interfejsa tunela, jer zid stoji uzvodno od oba kraja. WireGuard troši 60 bajtova na vanjski IPv4 transport: 20 za IP, 8 za UDP i 32 za vlastito zaglavlje, a 80 bajtova kad je taj transport IPv6. wg0 od 1420 bajtova drži 20 bajtova rezerve ispod 1440 koje put od 1500 bajtova zaista može dostaviti, i zato brojka kopirana s wikija i dalje ovdje odgovara. Nacrtajte cijeli stek na dijagramu, jer će sljedeći koji promijeni MTU inače odabrati novi okrugli broj i naslijediti vašu grešku.
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
Peti red je mjesto gdje budžeti pokleknu, jer 1400 bajtova koje nosi ugniježđeni interfejs već uključuju vlastitih 40 bajtova zaglavlja originalnog paketa. Samo 1360 od tih bajtova stigne do procesa koji čita datoteku. Tretirajte 1400 kao aplikacijski payload, kako vas poziva svaki dijagram bez te kolone, i unutrašnji uređaj završi 40 bajtova previše darežljiv prema zidu koji se nije pomjerio.
Postavite dva MTU-a odvojeno
Nosač i ugniježđeni uređaj su odvojeni objekti, pa svakom treba vlastita vrijednost. Primijenite ih ovim redom, jer ugniježđeni uređaj ne nasljeđuje ništa od nosača:
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
Pravilo koje vrijedi zapamtiti: unutrašnji MTU = vanjski MTU - 20 kad je paket koji IPIP tunel nosi IPv4, i - 40 kad god jedna strana unutrašnjeg paketa postane IPv6, jer ugniježđeno zaglavlje raste s 20 na 40 bajtova. Ništa drugo ne pripada tom oduzimanju. WireGuardov overhead je već potrošen kad ste odabrali 1420, a naplaćivanje dvaput proizvodi tunel koji savršeno radi i ostaje spor dok god ga niko ne mjeri. Postavka u kojoj oba uređaja nose okruglih 1400 otisak je upravo te greške.
IPv6 na bilo kojoj strani ugniježđenog paketa poništava svaku brojku iznad, pa preračunajte umjesto da kopirate broj sa sličnog sajta. Oduzeta zaglavlja su po 40 bajtova kad se IPv6 pojavi u vanjskom putu ili u originalnoj datagrami, a brojka payloada pada točno za toliko.
Firewall pravilo koje vam vjerojatno ne treba
Između dva WireGuard peera jedino što ide žicom je UDP, pa ulazno pravilo za protokol 4, broj koji RFC 2003 dodjeljuje IPv4-u-u-IPv4 enkapsulaciji, niti stvara ugniježđeni put niti ga održava živim. IPIP zaglavlje živi unutar šifriranog payloada, gdje ga nijedan rubni firewall ne vidi. Otvaranje protokola 4 ipak ne kupuje ništa osim još jednog dozvoljenog puta u host.
Politika koja spominje izvore i odredišta originalnog paketa pripada nakon dekapsulacije, na interfejsima tunela i u routing tabeli. Stavite je tamo i rubno pravilo može ostati zatvoreno.
Šta WireGuard zapravo validira
AllowedIPs prosuduje izvor paketa koji WireGuard nosi, a nosi IPIP-enkapsulirani paket. Dozvoljeni IPIP izvor se prihvata čak i kad zaglavlje unutra imenuje host na koji radije ne biste rutali. Originalni izvor dakle nije ono što je peer provjerio za vas, i taj unutrašnji par adresa treba vlastito provođenje nakon dekapsulacije.
Omotač pruža routing strukturu, ne drugi sloj kriptografije. Nazivati IPIP dodatnom zaštitom unutar WireGuard-a opisuje drugačiji dizajn.
Provjerite ljestvama, ne jednim pingom
Provjerite veličine koje prelaze izračunatu granicu, pa potvrdite šta kernel misli o oba uređaja. Sa 1360 bajtova payloada plus 40 bajtova zaglavlja što čini 1400, prvi eho ispod prolazi, a drugi stoji jedan bajt iza plafona:
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
Čist prolaz ispod plafona i neuspjeh na prvoj veličini iznad njega znače da aritmetika drži od kraja do kraja. Zatim ponovo pokrenite prenos koji se prvobitno zaglavio, jer sintetička sonda dokazuje budžet i ne govori ništa o pošiljaočevim vlastitim veličinama upisa. Ako se ugniježđeni put i dalje lomi na veličini koju ste dokazali da staje, pregledajte dekapsulaciju i rute udaljenog kraja prije nego što odrežete još deset bajtova s MTU-a.