IPIP brenda WireGuard: ato 20 bajt shtesë që askush nuk i planifikoi

Ping-et e vogla kalojnë tunelin gjithë ditën, banner-i SSH arrin dhe më pas sesioni ngrin në momentin kur fillon një transferim skedari. Ky model tregon një buxhet bajtësh të numëruar në shtresën e gabuar, ku tuneli i jashtëm u përmasua për kostot e tij dhe askush nuk zbriti atë të brendshëm. Një paketë IPIP e ndërthurur është thjesht një paketë tjetër IP për WireGuard, dhe pikërisht për këtë harxhon bajt që nuk i rezervuat kurrë. Korrigjimi është aritmetikë dhe futet në tre komanda dhe një tabelë.

Simptoma që e zbulon

Problemet e fragmentimit shpallen me madhësi, kurrë me adresa. Partneri juaj përgjigjet për një orë ndaj ping prej 56 bajtësh dhe më pas hesht në 1400 bajt, ndërsa tuneli mbetet lart dhe asnjë rrugë nuk ka ndryshuar. Shtrëngimi i dorës futet, dritarja e parë e plotë TCP jo, dhe transferimi ngec disa sekonda pasi dukej i shëndoshë.

Matni tavanin përpara se të ndryshoni çdo gjë, sepse një tavan i pamatur është ai që do të ndiqni dy herë. Dërgoni një sondë nën madhësinë e dyshuar me bitin do-not-fragment të vendosur, ping -M do -s 1000 10.9.0.2, pastaj përsëriteni në një madhësi që tashmë e dini se është shumë e madhe. Kur rrokullisja ndjek madhësinë e ngarkesës ndërsa destinacioni mbetet i pandryshuar, rrugëtimi po bën punën e vet dhe në buxhet mungon një krye.

Numëroni çdo krye një herë, në shtresën e duhur

Filloni nga MTU-ja më e vogël në rrugë dhe jo nga ndërfaqja e tunelit, sepse muri qëndron sipër të dy skajeve. WireGuard shpenzon 60 bajt për një transport të jashtëm IPv4: 20 për IP, 8 për UDP dhe 32 për kryen e vet, dhe 80 bajt kur ai transport është IPv6. Një wg0 prej 1420 bajtësh mban 20 bajt hapësirë nën 1440 që një rrugë 1500 bajtësh mund t'i dorëzojë vërtet, dhe për këtë arsye numri i kopjuar nga një wiki përshtatet ende këtu. Vizatoni të gjithë stivën në diagram, sepse kushdo që ndryshon MTU-në më pas do të zgjedhë ndryshe një numër të ri të rrumbullakët dhe do të trashëgojë gabimin tuaj.

Rreshti i pestë është vendi ku buxhetet prishen, sepse 1400 bajt që mbart një ndërfaqe e ndërthurur tashmë përfshijnë 40 bajt kryet e vetë paketës origjinale. Vetëm 1360 prej atyre bajteve arrijnë në procesin që lexon skedarin. Trajtoni 1400 si ngarkesë aplikacioni, siç ju fton çdo diagram pa atë kolonë, dhe pajisja e brendshme përfundon 40 bajt tepër bujare përballë një muri që nuk është lëvizur.

Vendosni dy MTU-të veçmas

Transportuesi dhe pajisja e ndërthurur janë objekte të veçanta, kështu që secili ka nevojë për vlerën e vet. Zbatoni ato në këtë rend, sepse pajisja e ndërthurur nuk trashëgon asgjë nga transportuesi:

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

Rregulli që ia vlen të mbahet mend: MTU e brendshme = MTU e jashtme - 20 kur paketa që mbart tuneli IPIP është IPv4, dhe - 40 sapo njëra anë e paketës së brendshme është IPv6, sepse kryet e ndërthurur rritet nga 20 bajt në 40. Asgjë tjetër nuk i përket asaj zbritjeje. Kostoja e WireGuard është harxhuar tashmë kur zgjodhët 1420, dhe fatura e dyfishtë prodhon një tunel që funksionon në mënyrë të përsosur dhe mbetet i ngadaltë për sa kohë askush nuk e mat. Një vendosje ku të dyja pajisjet mbartin 1400 të rrumbullakët është gjurma e pikërisht atij gabimi.

IPv6 në çdo anë të paketës së ndërthurur anulon çdo numër më lart, prandaj rillogaritni në vend që të kopjoni një numër nga një sajt i ngjashëm. Kryet e zbritura janë 40 bajt secila sapo IPv6 shfaqet në rrugën e jashtme ose në datagramin origjinal, dhe numri i ngarkesës bie saktësisht po aq.

Rregulli i firewall-it që ndoshta nuk ju nevojitet

Midis dy partnerëve WireGuard e vetmja gjë në tel është UDP, kështu që një rregull hyrës për protokollin 4, numrin që RFC 2003 i cakton inkapsulimit IPv4-brenda-IPv4, as e krijon rrugën e ndërthurur as e mban gjallë. Kryet IPIP jeton brenda ngarkesës së kriptuar, ku asnjë firewall skaji nuk e sheh. Hapja e protokollit 4 gjithsesi nuk blen asgjë përtej një rruge tjetër të lejuar drejt hostit.

Politika që përmend burimet dhe destinacionet e paketës origjinale i përket pas dekapsulimit, në ndërfaqet e tunelit dhe në tabelën e rrugëtimit. Vendoseni atje dhe rregulli i skajit mund të mbetet i mbyllur.

Çfarë vërteton në të vërtetë WireGuard

AllowedIPs gjykon burimin e paketës që mbart WireGuard, dhe ajo që mbart është paketa e inkapsuluar në IPIP. Një burim IPIP i lejuar pranohet edhe kur kryet brenda emërton një host që do të preferonit të mos e rrugëtonit. Burimi origjinal nuk është pra ai që partneri kontrolloi për ju, dhe ai çift i brendshëm adresash ka nevojë për zbatimin e vet pas dekapsulimit.

Mbështjellja ofron strukturë rrugëtimi, jo një shtresë të dytë kriptografie. Ta quash IPIP mbrojtje shtesë brenda WireGuard përshkruan një dizajn tjetër.

Verifikoni me një shkallë, jo me një ping

Provoni madhësi që rrethojnë kufirin që llogaritët, pastaj konfirmoni çfarë mendon kerneli për të dyja pajisjet. Me 1360 bajt ngarkesë plus 40 bajt krye që bëjnë 1400, ekoja e parë më poshtë futet dhe e dyta ulet një bajt përtej tavanit:

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

Një kalim i pastër nën tavan dhe një dështim në madhësinë e parë mbi të do të thotë që aritmetika qëndron nga fillimi në fund. Pastaj rikandoni transferimin që ngeci fillimisht, sepse një sondë sintetike vërteton buxhetin dhe nuk thotë asgjë për madhësitë e shkrimit të dërguesit. Nëse rruga e ndërthurur ende thyhet në një madhësi që provuat se futet, inspektoni dekapsulimin dhe rrugët e skajit të largët përpara se të prisni edhe dhjetë bajt nga MTU-ja.