IPIP en WireGuard: la kromaj 20 bajtoj, kiujn neniu buĝetis

Malgrandaj pingoj trapasas la tunelon la tutan tagon, la SSH-standardo alvenas, kaj tiam la seanco frostas en la momento, kiam komenciĝas dosiera transigo. Tiu ŝablono montras bajto-buĝeton kalkulitan ĉe la malĝusta tavolo, kie la ekstera tunelo estis dimensiita por sia propra superkosto kaj neniu subtrahis la internan. Nestita IPIP-paketo estas por WireGuard nur alia IP-paketo, kaj ĝuste tial ĝi konsumas bajtojn, kiujn vi neniam rezervis. La korekto estas aritmetiko, kaj ĝi eniras tri komandojn kaj unu tabelon.

La simptomo, kiu malkaŝas ĝin

Fragmentadaj problemoj anoncas sin per grandeco, neniam per adresoj. Via samtavolano respondas al 56-bajta ping dum horo kaj poste silentas ĉe 1400 bajtoj, dum la tunelo restas supre kaj neniu vojo ŝanĝiĝis. La manpremo eniras, la unua plena TCP-fenestro ne, kaj la transigo haltas sekundojn post kiam ĝi aspektis sana.

Mezuru la plafonon antaŭ ol redakti ion ajn, ĉar ne mezurita plafono estas tiu, kiun vi ĉasos dufoje. Sendu unu sondan paketon sub la suspektata grandeco kun la do-not-fragment-bito ŝaltita, ping -M do -s 1000 10.9.0.2, kaj poste ripetu ĝin ĉe grandeco, kiun vi jam scias esti tro granda. Kiam la renverso sekvas la grandecon de la utila ŝarĝo dum la celloko restas senŝanĝa, la enkursigado faras sian laboron kaj unu kapo mankas el la buĝeto.

Kalkulu ĉiun kapon unufoje, ĉe la ĝusta tavolo

Komencu de la plej malgranda MTU sur la vojo anstataŭ de la tunela interfaco, ĉar la muro staras supre de ambaŭ finpunktoj. WireGuard elspezas 60 bajtojn por IPv4-a ekstera transporto: 20 por IP, 8 por UDP kaj 32 por sia propra kapo, kaj 80 bajtojn kiam tiu transporto estas IPv6. wg0 de 1420 bajtoj tenas 20 bajtojn da rezervo sub la 1440, kiujn vojo de 1500 bajtoj vere povas liveri, kaj tial la cifero kopiita el vikio ankoraŭ taŭgas ĉi tie. Desegnu la tutan stakon sur la diagramo, ĉar kiu ajn venonte ŝanĝos la MTU alie elektos novan rondan nombron kaj heredos vian cimon.

La kvina vico estas kie buĝetoj misfunkcias, ĉar la 1400 bajtoj, kiujn portas nestita interfaco, jam inkluzivas la proprajn 40 bajtojn da kapoj de la originala paketo. Nur 1360 el tiuj bajtoj atingas la procezon, kiu legas la dosieron. Traktu 1400 kiel aplikaĵan utilan ŝarĝon, kiel invitas vin ĉiu diagramo sen tiu kolumno, kaj la interna aparato finiĝas 40 bajtojn tro malavara antaŭ muro, kiu ne moviĝis.

Agordu la du MTU-ojn aparte

La portanto kaj la nestita aparato estas apartaj objektoj, do ĉiu bezonas sian propran valoron. Apliku ilin en tiu ĉi ordo, ĉar la nestita aparato heredas nenion de la portanto:

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

La regulo inda je memorigo: interna MTU = ekstera MTU - 20 kiam la paketo, kiun portas la IPIP-tunelo, estas IPv4, kaj - 40 tuj kiam iu ajn flanko de la interna paketo estas IPv6, ĉar la nestita kapo kreskas de 20 bajtoj al 40. Nenio alia apartenas al tiu subtraho. La superkosto de WireGuard jam elspeziĝis kiam vi elektis 1420, kaj ŝargi ĝin dufoje produktas tunelon, kiu funkcias perfekte kaj restas malrapida dum neniu mezuras ĝin. Eligo, en kiu ambaŭ aparatoj portas rondan 1400, estas la fingropremo de ĝuste tiu eraro.

IPv6 sur iu ajn flanko de la nestita paketo nuligas ĉiun ciferon supre, do rekalkulu anstataŭ kopii nombron de simila retejo. La subtrahataj kapoj estas po 40 bajtoj tuj kiam IPv6 aperas en la ekstera vojo aŭ en la originala datagramo, kaj la cifero de utila ŝarĝo falas ĝuste tiom.

La fajroŝirma regulo, kiun vi probable ne bezonas

Inter du WireGuard-samtavolanoj la sola afero sur la drato estas UDP, do envena regulo por protokolo 4, la numero, kiun RFC 2003 atribuas al IPv4-en-IPv4-enkapsuligo, nek kreas la nestitan vojon nek tenas ĝin viva. La IPIP-kapo vivas ene de la ĉifrita utila ŝarĝo, kie neniu randa fajroŝirmilo vidas ĝin. Malfermi protokolon 4 tamen aĉetas nenion krom unu plia permesita vojo en la gastiganton.

Politiko, kiu mencias la fontojn kaj celojn de la originala paketo, apartenas post la malkapsuligo, sur la tunelaj interfacoj kaj en la enkursiga tabelo. Metu ĝin tien kaj la randa regulo povas resti fermita.

Kion WireGuard efektive validigas

AllowedIPs juĝas la fonton de la paketo, kiun WireGuard portas, kaj kion ĝi portas estas la IPIP-enkapsuligita paketo. Permesita IPIP-fonto estas akceptita eĉ kiam la kapo interne nomas gastiganton, kiun vi preferus ne enkursigi. La originala fonto do ne estas tio, kion la samtavolano kontrolis por vi, kaj tiu interna paro de adresoj bezonas sian propran plenumadon post la malkapsuligo.

La envolvaĵo liveras enkursigan strukturon, ne duan tavolon de kriptografio. Nomi IPIP plian protekton ene de WireGuard priskribas alian dezajnon.

Kontrolu per ŝtuparo, ne per unu ping

Sondi grandecojn, kiuj ĉirkaŭas la limon, kiun vi kalkulis, kaj poste konfirmu, kion la kerno kredas pri ambaŭ aparatoj. Kun 1360 bajtoj da utila ŝarĝo plus 40 bajtoj da kapoj farantaj 1400, la unua eĥo sube eniras kaj la dua sidas unu bajton preter la plafono:

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

Pura trapaso sub la plafono kaj malsukceso ĉe la unua grandeco super ĝi signifas, ke la aritmetiko tenas de fino al fino. Poste relanĉu la transigon, kiu origine haltis, ĉar sinteza sondilo pruvas la buĝeton kaj diras nenion pri la propraj skribgrandecoj de la sendinto. Se la nestita vojo ankoraŭ rompiĝas ĉe grandeco, kiun vi pruvis taŭga, ekzamenu la malkapsuligon kaj vojojn de la malproksima finpunkto antaŭ ol detranĉi pliajn dek bajtojn de la MTU.