IPIP znotraj WireGuarda: tistih dodatnih 20 bajtov, ki jih nihče ni vključil v proračun
IPIP znotraj WireGuarda stane 20 bajtov več. Naredite proračun na pravi plasti, preden krivite razdrobljenost za zataknjen prenos na živem tunelu.
Majhni pingi ves dan prečkajo tunel, prispe pasica SSH in nato se seja zamrzne v trenutku, ko se začne prenos datoteke. Ta vzorec kaže na proračun bajtov, izračunan na napačni plasti, kjer je bil zunanji tunel dimenzioniran za lastne stroške in nihče ni odštel notranjega. Gnezden paket IPIP je za WireGuard le še en paket IP, in prav zato porabi bajte, ki jih nikoli niste rezervirali. Popravek je aritmetika in se prilega v tri ukaze ter eno tabelo.
Simptom, ki to razkrije
Težave z razdrobljenostjo se oznanjajo z velikostjo, nikoli z naslovi. Vaš partner se eno uro odziva na 56-bajtni ping in nato pri 1400 bajtih utihne, medtem ko tunel ostane dvignjen in nobena pot se ni spremenila. Ročna sponka se prilega, prvo polno okno TCP ne, in prenos se ustavi nekaj sekund potem, ko je bil videti zdrav.
Izmerite zgornjo mejo, preden karkoli uredite, ker neizmerjena meja je tista, ki jo boste lovili dvakrat. Pošljite eno sondo pod sumljivo velikostjo z nastavljenim bitom do-not-fragment, ping -M do -s 1000 10.9.0.2, nato jo ponovite pri velikosti, za katero že veste, da je prevelika. Ko preobrat sledi velikosti koristnega tovora, medtem ko cilj ostaja nespremenjen, usmerjanje opravlja svoje delo in v proračunu manjka ena glava.
Preštejte vsako glavo enkrat, na pravi plasti
Začnite z najmanjšim MTU na poti in ne z vmesnikom tunela, ker stena stoji nad obema koncema. WireGuard porabi 60 bajtov za zunanji transport IPv4: 20 za IP, 8 za UDP in 32 za lastno glavo, in 80 bajtov, ko je ta transport IPv6. wg0 s 1420 bajti ohrani 20 bajtov rezerve pod 1440, ki jih pot s 1500 bajti res lahko dostavi, in zato številka, kopirana z wikija še vedno ustreza tukaj. Narišite celoten sklad na diagram, ker bo naslednji, ki bo spremenil MTU, sicer izbral novo okroglo število in podedoval vašo napako.
| 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 |
Peta vrstica je kraj, kjer se proračuni zlomijo, ker 1400 bajtov, ki jih nosi gnezden vmesnik, že vključuje lastnih 40 bajtov glav izvirnega paketa. Do procesa, ki bere datoteko, pride le 1360 od teh bajtov. Obravnavajte 1400 kot aplikacijski tovor, h čemur vas vabi vsak diagram brez tega stolpca, in notranja naprava se konča 40 bajtov preveč radodarna pred steno, ki se ni premaknila.
Nastavite oba MTU ločeno
Nosilec in gnezdena naprava sta ločena objekta, zato vsak potrebuje svojo vrednost. Uporabite ju v tem vrstnem redu, ker gnezdena naprava ne podeduje ničesar od nosilca:
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, ki si ga velja zapomniti: notranji MTU = zunanji MTU - 20, ko je paket, ki ga nosi tunel IPIP, IPv4, in - 40, takoj ko je katera koli stran notranjega paketa IPv6, ker gnezdna glava zraste z 20 bajtov na 40. Nič drugega ne spada v to odštevanje. Stroški WireGuarda so bili že porabljeni, ko ste izbrali 1420, in njihovo dvakratno zaračunavanje ustvari tunel, ki deluje brezhibno in ostane počasen, dokler ga nihče ne meri. Uvedba, kjer obe napravi nosita okroglih 1400, je odtis natanko te napake.
IPv6 na kateri koli strani gnezdenega paketa razveljavi vsako številko zgoraj, zato preračunajte, namesto da bi kopirali številko s podobnega mesta. Odštete glave so po 40 bajtov, takoj ko se IPv6 pojavi na zunanji poti ali v izvirnem datagramu, in številka tovora pade natanko za toliko.
Pravilo požarnega zidu, ki ga verjetno ne potrebujete
Med dvema partnerjema WireGuarda je edina stvar na žici UDP, zato vhodno pravilo za protokol 4, številko, ki jo RFC 2003 dodeli kapsuliranju IPv4-v-IPv4, niti ne ustvari gnezdene poti niti je ne ohranja žive. Glava IPIP živi znotraj šifriranega tovora, kjer je noben robni požarni zid ne vidi. Odpiranje protokola 4 vseeno ne kupi ničesar razen še ene dovoljene poti na gostitelja.
Politika, ki omenja vire in cilje izvirnega paketa, spada za dekapsulacijo, na vmesnike tunela in v usmerjevalno tabelo. Postavite jo tja in robno pravilo lahko ostane zaprto.
Kaj WireGuard dejansko preverja
AllowedIPs presoja vir paketa, ki ga WireGuard nosi, in nosi paket, kapsuliran v IPIP. Dovoljen vir IPIP je sprejet tudi, ko notranja glava imenuje gostitelja, ki mu raje ne bi usmerjali. Izvirni vir torej ni tisto, kar je partner preveril za vas, in ta notranji par naslovov potrebuje lastno uveljavljanje po dekapsulaciji.
Ovoj zagotavlja usmerjevalno strukturo, ne druge plasti kriptografije. Imenovati IPIP dodatno zaščito znotraj WireGuarda opisuje drugačno zasnovo.
Preverite z lestvijo, ne z enim pingom
Preizkusite velikosti, ki objemajo izračunano mejo, nato potrdite, kaj jedro misli o obeh napravah. Ko 1360 bajtov tovora plus 40 bajtov glav daje 1400, prvi odmev spodaj se prilega, drugi pa sedi en bajt čez mejo:
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 prehod pod mejo in neuspeh pri prvi velikosti nad njo pomenita, da aritmetika drži od začetka do konca. Nato znova zaženite prenos, ki se je prvotno zataknil, ker sintetična sonda dokazuje proračun in ne pove ničesar o pisalnih velikostih pošiljatelja samega. Če se gnezdna pot še vedno lomi pri velikosti, za katero ste dokazali, da se prilega, preglejte dekapsulacijo in poti oddaljenega konca, preden odrežete še deset bajtov z MTU.