IPIP inde i WireGuard: de ekstra 20 byte, som ingen havde budgetteret med

Små ping går gennem tunnelen hele dagen, SSH-banneret ankommer, og så fryser sessionen i det øjeblik, en filoverførsel starter. Det mønster peger på et bytebudget talt på det forkerte lag, hvor den ydre tunnel blev dimensioneret til sit eget overhead, og ingen trak den indre fra. En indlejret IPIP-pakke er bare endnu en IP-pakke set fra WireGuards side, og netop derfor bruger den byte, du aldrig reserverede. Rettelsen er aritmetik, og den passer i tre kommandoer og en tabel.

Det symptom, der afslører det

Fragmenteringsproblemer annoncerer sig gennem størrelse, aldrig gennem adresser. Din peer svarer på en 56-byte ping i en time og tier så ved 1400 byte, mens tunnelen bliver oppe, og ingen rute ændrede sig. Håndtrykket passer, det første fulde TCP-vindue gør ikke, og overførslen går i stå sekunder efter, at den så sund ud.

Mål loftet, før du redigerer noget, for et umålt loft er et, du vil jage to gange. Send en enkelt sonde under den formodede størrelse med do-not-fragment-bitten sat, ping -M do -s 1000 10.9.0.2, og gentag den så ved en størrelse, du allerede ved er for stor. Når vippet følger nyttelastens størrelse, mens destinationen forbliver uændret, gør routing sit arbejde, og der mangler en header i budgettet.

Tæl hver header én gang, på det rigtige lag

Start fra den mindste MTU på vejen i stedet for fra tunnelinterfacet, fordi muren sidder opstrøms for begge ender. WireGuard bruger 60 byte på en IPv4-ydertransport: 20 til IP, 8 til UDP og 32 til sin egen header, og 80 byte når den transport er IPv6. En 1420-byte wg0 holder 20 byte i slæk under de 1440, som en 1500-byte vej reelt kan levere, og derfor passer tallet kopieret fra en wiki stadig her. Tegn hele stakken på diagrammet, for den næste, der ændrer MTU, vælger ellers et nyt rundt tal og arver din fejl.

Den femte række er, hvor budgetter går galt, fordi de 1400 byte, et indlejret interface bærer, allerede inkluderer den oprindelige pakkes egne 40 byte headers. Kun 1360 af de byte når processen, der læser filen. Behandl 1400 som applikationsnyttelast, som ethvert diagram uden den kolonne opfordrer dig til, og den indre enhed ender 40 byte for gavmild over for en mur, der ikke har flyttet sig.

Sæt de to MTU'er hver for sig

Bæreren og den indlejrede enhed er separate objekter, så hver især har brug for sin egen værdi. Anvend dem i denne rækkefølge, fordi den indlejrede enhed ikke arver noget fra bæreren:

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

Reglen, der er værd at huske: indre MTU = ydre MTU - 20, når pakken, IPIP-tunnelen bærer, er IPv4, og - 40, så snart en af siderne af den indre pakke er IPv6, fordi den indlejrede header vokser fra 20 byte til 40. Intet andet hører i den subtraktion. WireGuards overhead blev allerede brugt, da du valgte 1420, og at opkræve den to gange giver en tunnel, der fungerer perfekt og forbliver langsom, så længe ingen måler den. En udrulning, hvor begge enheder bærer et rundt 1400, er fingeraftrykket af netop den fejl.

IPv6 på hver side af den indlejrede pakke ugyldiggør hvert tal ovenfor, så genberegn i stedet for at kopiere et tal fra et lignende websted. De fratrukne headere er 40 byte hver, så snart IPv6 optræder i den ydre vej eller i det oprindelige datagram, og nyttelasttallet falder præcis så meget.

Firewallreglen, du sandsynligvis ikke har brug for

Mellem to WireGuard-peers er det eneste på ledningen UDP, så en indgående regel for protokol 4, det nummer RFC 2003 tildeler IPv4-i-IPv4-indkapsling, hverken skaber den indlejrede vej eller holder den i live. IPIP-headeren lever inde i den krypterede nyttelast, hvor ingen kantfirewall ser den. At åbne protokol 4 alligevel køber intet ud over endnu en tilladt vej ind i værten.

Politik, der nævner den oprindelige pakkes kilder og destinationer, hører efter afkapslingen, på tunnelinterfaces og i rutetabellen. Læg den der, og kantreglen kan forblive lukket.

Hvad WireGuard faktisk validerer

AllowedIPs bedømmer kilden til den pakke, WireGuard bærer, og det, den bærer, er den IPIP-indkapslede pakke. En tilladt IPIP-kilde accepteres, selv når headeren indeni nævner en vært, du hellere ville undgå at route til. Den oprindelige kilde er derfor ikke det, peeren tjekkede for dig, og det indre adressepar har brug for sin egen håndhævelse efter afkapslingen.

Indpakningen leverer rutestruktur, ikke et andet kryptografilag. At kalde IPIP ekstra beskyttelse inde i WireGuard beskriver et andet design.

Verificer med en stige, ikke et enkelt ping

Sondér størrelser, der omkranser den grænse, du beregnede, og bekræft så, hvad kernen mener om begge enheder. Med 1360 byte nyttelast plus 40 byte headere, der giver 1400, passer det første ekko nedenfor, og det andet sidder en byte forbi loftet:

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

En ren passering under loftet og en fejl ved den første størrelse derover betyder, at aritmetikken holder fra ende til anden. Kør så overførslen, der oprindeligt gik i stå, igen, fordi en syntetisk sonde beviser budgettet og intet siger om afsenderens egne skrivestørrelser. Hvis den indlejrede vej stadig brækker ved en størrelse, du har bevist passer, så undersøg den fjerne ends afkapsling og ruter, før du skærer endnu ti byte af MTU'en.