IPIP sa Loob ng WireGuard: ang 20 Byte na Dagdag na Walang Naglaan sa Badyet

Maliliit na ping ang tumatawid sa tunnel buong araw, dumarating ang SSH banner, at pagkatapos ay nagyeyelo ang session sa sandaling magsimula ang paglilipat ng file. Itinuturo ng pattern na iyon ang isang badyet ng byte na binilang sa maling layer, kung saan ang panlabas na tunnel ay sinukat para sa sarili nitong overhead at walang nagbawas ng panloob. Ang isang nested na IPIP packet ay isa pang IP packet lamang para sa WireGuard, at iyon mismo ang dahilan kung bakit kumakain ito ng mga byte na hindi mo kailanman inilaan. Ang pagwawasto ay aritmetika, at kasya ito sa tatlong command at isang table.

Ang sintomas na nagbubunyag nito

Inihahayag ng problema sa fragmentation ang sarili sa pamamagitan ng laki, hindi kailanman sa pamamagitan ng address. Sinasagot ng iyong peer ang isang 56-byte na ping sa loob ng isang oras at pagkatapos ay tumatahimik sa 1400 byte habang nananatiling nakataas ang tunnel at walang ruta ang nagbago. Kasya ang handshake, hindi kasya ang unang buong TCP window, at humihinto ang paglilipat pagkalipas ng ilang segundo matapos itong magmukhang malusog.

Sukatin ang kisame bago mo i-edit ang anuman, dahil ang kisame na hindi sinukat ay ang hahabulin mo nang dalawang beses. Magpadala ng isang probe sa ilalim ng pinaghihinalaang laki na nakatakda ang do-not-fragment bit, ping -M do -s 1000 10.9.0.2, pagkatapos ay ulitin ito sa laking alam mo nang masyadong malaki. Kapag sinusundan ng pagbaligtad ang laki ng payload habang hindi nagbabago ang destinasyon, ginagawa ng routing ang trabaho nito at may isang header na kulang sa badyet.

Bilangin ang bawat header nang isang beses, sa tamang layer

Magsimula sa pinakamaliit na MTU sa landas at hindi sa interface ng tunnel, dahil ang pader ay nasa itaas ng dalawang dulo. Gumagastos ang WireGuard ng 60 byte sa isang panlabas na IPv4 transport: 20 para sa IP, 8 para sa UDP at 32 para sa sarili nitong header, at 80 byte kapag ang transport na iyon ay IPv6. Ang isang wg0 na 1420 byte ay nagtatabi ng 20 byte na agwat sa ilalim ng 1440 na tunay na maihahatid ng isang 1500-byte na landas, at iyon ang dahilan kung bakit ang pigurang kinopya mula sa isang wiki ay umaangkop pa rin dito. Iguhit ang buong stack sa diagram, dahil ang susunod na magbabago ng MTU ay pipili ng bagong bilog na numero at mamamana ang iyong bug.

Ang ikalimang hilera ang lugar kung saan nasisira ang mga badyet, dahil ang 1400 byte na dala ng isang nested interface ay kasama na ang sariling 40 byte na header ng orihinal na packet. Tanging 1360 sa mga byte na iyon ang nakakarating sa prosesong nagbabasa ng file. Ituring ang 1400 na payload ng application, gaya ng inaanyayahan ng anumang diagram na walang column na iyon, at ang panloob na device ay nagtatapos na 40 byte na masyadong mapagbigay sa harap ng pader na hindi gumalaw.

Itakda ang dalawang MTU nang hiwalay

Ang carrier at ang nested device ay magkahiwalay na bagay, kaya kailangan ng bawat isa ang sariling halaga. Ilapat ang mga ito sa ayos na ito, dahil walang namamana ang nested device mula sa carrier:

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

Ang tuntuning sulit tandaan: panloob na MTU = panlabas na MTU - 20 kapag ang packet na dala ng IPIP tunnel ay IPv4, at - 40 sa sandaling ang alinmang panig ng panloob na packet ay IPv6, dahil lumalaki ang nested header mula 20 byte hanggang 40. Wala nang iba pang nabibilang sa pagbabawas na iyon. Nagastos na ang overhead ng WireGuard nang piliin mo ang 1420, at ang pagsingil nito nang dalawang beses ay gumagawa ng tunnel na gumagana nang perpekto at nananatiling mabagal hangga't walang sumusukat dito. Ang deployment kung saan ang dalawang device ay may dalang bilog na 1400 ay ang fingerprint ng eksaktong pagkakamaling iyon.

Binabalewala ng IPv6 sa alinmang panig ng nested packet ang bawat pigura sa itaas, kaya muling kalkulahin sa halip na kopyahin ang isang numero mula sa katulad na site. Ang mga ibinawas na header ay 40 byte bawat isa sa sandaling lumitaw ang IPv6 sa panlabas na landas o sa orihinal na datagram, at bumababa ang pigura ng payload nang eksaktong ganoon.

Ang firewall rule na malamang ay hindi mo kailangan

Sa pagitan ng dalawang WireGuard peer, ang tanging nasa wire ay UDP, kaya ang isang inbound rule para sa protocol 4, ang numerong itinakda ng RFC 2003 sa IPv4-sa-loob-ng-IPv4 encapsulation, ay hindi gumagawa ng nested path at hindi rin ito pinananatiling buhay. Ang IPIP header ay nabubuhay sa loob ng naka-encrypt na payload, kung saan wala pang edge firewall ang nakakakita nito. Ang pagbubukas ng protocol 4 gayunpaman ay walang binibili maliban sa isa pang pinapayagang daan patungo sa host.

Ang patakarang nagbabanggit ng mga source at destination ng orihinal na packet ay kabilang pagkatapos ng decapsulation, sa mga interface ng tunnel at sa routing table. Ilagay ito roon at maaaring manatiling sarado ang edge rule.

Ano ang aktwal na vine-verify ng WireGuard

AllowedIPs ang humahatol sa source ng packet na dala ng WireGuard, at ang dala nito ay ang packet na naka-encapsulate sa IPIP. Tinatanggap ang isang pinapayagang IPIP source kahit na ang panloob na header ay nagpangalan ng host na mas gusto mong hindi i-route. Kaya ang orihinal na source ay hindi ang sinuri ng peer para sa iyo, at ang panloob na pares ng address na iyon ay nangangailangan ng sarili nitong pagpapatupad pagkatapos ng decapsulation.

Nagbibigay ang wrapper ng routing structure, hindi ng pangalawang layer ng cryptography. Ang tawagin ang IPIP na dagdag na proteksyon sa loob ng WireGuard ay naglalarawan ng ibang disenyo.

I-verify gamit ang isang hagdan, hindi isang ping

Subukan ang mga laki na pumapalibot sa hangganang kinakalkula mo, pagkatapos ay kumpirmahin kung ano ang pinaniniwalaan ng kernel tungkol sa dalawang device. Kapag ang 1360 byte na payload at 40 byte na header ay gumawa ng 1400, kasya ang unang echo sa ibaba at ang pangalawa ay nakaupo nang isang byte lampas sa kisame:

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

Ang malinis na pagdaan sa ilalim ng kisame at pagkabigo sa unang laki sa itaas nito ay nangangahulugang matibay ang aritmetika mula simula hanggang dulo. Pagkatapos ay patakbuhin muli ang paglilipat na orihinal na natigil, dahil pinatutunayan ng synthetic probe ang badyet at walang sinasabi tungkol sa sariling laki ng pagsulat ng nagpadala. Kung ang nested path ay nababasag pa rin sa laking pinatunayan mong kasya, siyasatin ang decapsulation at mga ruta ng malayong dulo bago putulin ang sampung byte pa mula sa MTU.