IPIP WireGuardi sees: need 20 lisabaiti, mida keegi eelarvesse ei pannud

Väikesed pingid läbivad tunnelit kogu päeva, SSH-bänner jõuab kohale ja siis tardub sessioon hetkel, mil failiülekanne algab. See muster viitab valel kihil loetud baidieelarvele, kus välimine tunnel mõõdeti omaenda üldkulule ja keegi ei lahutanud sisemist. WireGuardi jaoks on pesastatud IPIP-pakett lihtsalt veel üks IP-pakett, ja just seepärast kulutab see baite, mida te kunagi ei reserveerinud. Parandus on aritmeetika ja see mahub kolme käsusse ja ühte tabelisse.

Sümptom, mis selle ära annab

Fragmentatsiooniprobleemid annavad endast märku suurusega, mitte kunagi aadressidega. Teie partner vastab 56-baidisele ping-le tund aega ja jääb siis 1400 baidi juures vait, samal ajal kui tunnel püsib üleval ja ükski marsruut ei muutunud. Kätlus mahub, esimene täis TCP-aken mitte, ja ülekanne takerdub sekundeid pärast seda, kui see tervena paistis.

Mõõtke lagi enne, kui midagi muudate, sest mõõtmata lagi on see, mida hakkate taga ajama kaks korda. Saatke üks sond kahtlustatavast suurusest allapoole, do-not-fragment-bitt seatud, ping -M do -s 1000 10.9.0.2, ja korrake seda siis suurusel, mille kohta te juba teate, et see on liiga suur. Kui pööre järgib kasuliku koormuse suurust, samal ajal kui sihtkoht jääb muutumatuks, teeb marsruutimine oma tööd ja eelarvest on puudu üks päis.

Loendage iga päis üks kord, õigel kihil

Alustage tee väikseimast MTU-st, mitte tunneli liidesest, sest sein asub mõlemast otsast ülesvoolu. WireGuard kulutab 60 baiti IPv4 välisele transpordile: 20 IP-le, 8 UDP-le ja 32 omaenda päisele, ning 80 baiti, kui see transport on IPv6. 1420-baidine wg0 hoiab 20 baiti varu 1440 all, mida 1500-baidine tee suudab tõesti kohale toimetada, ja seepärast vikist kopeeritud number sobib siia ikka. Joonistage kogu virn diagrammile, sest järgmine, kes MTU-d muudab, valib muidu uue ümara numbri ja pärib teie vea.

Viies rida on koht, kus eelarved viltu lähevad, sest 1400 baiti, mida pesastatud liides kannab, sisaldavad juba algse paketi enda 40 baiti päiseid. Ainult 1360 neist baitidest jõuab faili lugeva protsessini. Käsitlege 1400 rakenduse kasuliku koormusena, millele iga ilma selle veeruta diagramm teid kutsub, ja sisemine seade osutub 40 baiti liiga heldeks seina ees, mis ei ole liikunud.

Määrake kaks MTU-d eraldi

Kandja ja pesastatud seade on eraldi objektid, seega vajab kumbki oma väärtust. Rakendage neid selles järjekorras, sest pesastatud seade ei päri kandjalt midagi:

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

Reegel, mida tasub meelde jätta: sisemine MTU = välimine MTU - 20, kui IPIP-tunneli kantav pakett on IPv4, ja - 40, kui sisemise paketi kumbki pool on IPv6, sest pesastatud päis kasvab 20 baidilt 40-ni. Midagi muud sellesse lahutamisse ei kuulu. WireGuardi üldkulu oli juba kulutatud, kui valisite 1420, ja selle kahekordne arvestamine loob tunneli, mis töötab täiuslikult ja jääb aeglaseks seni, kuni keegi seda ei mõõda. Juurutus, kus mõlemad seadmed kannavad ümaraid 1400, on täpselt selle vea sõrmejälg.

IPv6 pesastatud paketi kummalgi küljel muudab kõik ülaltoodud numbrid kehtetuks, seega arvutage uuesti, selle asemel et sarnaselt saidilt numbrit kopeerida. Lahutatavad päised on 40 baiti tükis, kui IPv6 ilmub välisele teele või algsele datagrammile, ja kasuliku koormuse number langeb täpselt nii palju.

Tulemüürireegel, mida te tõenäoliselt ei vaja

Kahe WireGuardi partneri vahel on juhtmel ainult UDP, seega sissetulev reegel protokollile 4, numbrile, mille RFC 2003 omistab IPv4-IPv4-siseselt kapseldamisele, ei loo pesastatud teed ega hoia seda elus. IPIP päis elab krüpteeritud kasuliku koormuse sees, kus ükski serva tulemüür seda ei näe. Protokolli 4 avamine ei osta niikuinii midagi peale ühe lubatud tee hosti.

Poliitika, mis nimetab algse paketi allikaid ja sihtkohti, kuulub dekapsulatsiooni järele, tunneli liidestele ja marsruutimistabelisse. Pange see sinna ja serva reegel võib suletuks jääda.

Mida WireGuard tegelikult valideerib

AllowedIPs hindab WireGuardi kantava paketi allikat, ja see, mida see kannab, on IPIP-kapseldatud pakett. Lubatud IPIP-allikas võetakse vastu ka siis, kui seesmine päis nimetab hosti, kuhu te pigem ei marsruudiks. Algne allikas ei ole seega see, mida partner teie eest kontrollis, ja see sisemine aadressipaar vajab pärast dekapsulatsiooni oma jõustamist.

Ümbris annab marsruutimisstruktuuri, mitte teist krüptograafiakihti. IPIP-i nimetamine WireGuardi sees lisakaitseks kirjeldab teistsugust disaini.

Kontrollige redeliga, mitte ühe pingiga

Sondige suurusi, mis piiravad teie arvutatud piiri, ja kinnitage siis, mida tuum mõlemast seadmest arvab. Kui 1360 baiti kasulikku koormust pluss 40 baiti päiseid annab 1400, mahub esimene kaja allpool ja teine istub ühe baidi võrra üle lae:

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

Puhas läbiminek allpool lage ja ebaõnnestumine esimesel suurusel sellest ülalpool tähendavad, et aritmeetika peab otsast otsani. Seejärel käivitage uuesti algselt takerdunud ülekanne, sest sünteetiline sond tõestab eelarvet ega ütle midagi saatja enda kirjutussuuruste kohta. Kui pesastatud tee ikka katkeb suurusel, mille te tõestasite mahtuvat, uurige kauge otsa dekapsulatsiooni ja marsruute, enne kui MTU-st veel kümme baiti maha lõikate.