WireGuard går i stå: en MTU-grænse eller en manglende videresendelsesregel?

Vanen er at sænke MTU’en, så snart WireGuard opfører sig forkert, og den vane skjuler en anden fejl. En gateway, der ikke videresender, og en sti, der ikke bærer store pakker, giver forskellige mønstre: den ene fejler i begge retninger og ved hver størrelse, den anden overlever små forespørgsler og dør på store. Afgør, hvilken form du har, før du ændrer noget tal. Testen er billig, og den fjerner halvdelen af de mulige årsager.

To fejl, to forskellige former

Et videresendelsesproblem viser sig straks efter serveren. Håndtrykket lykkes, tunneladressen svarer, og intet bag gatewayen kan nås, selv ikke med en bittelille forespørgsel. Pakken nåede serveren og blev ikke sendt videre, eller svaret havde ingen rute tilbage.

Et størrelsesproblem viser sig kun over en tærskel. DNS, et TCP-håndtryk og et lille API-kald virker, mens en filhentning eller et stort svar hænger. Pakkerne, der passede, rejste hele vejen, og dem, der ikke passede, blev tabt et sted uden en brugbar rapport.

De beskrivelser peger på forskellige mennesker og forskellige konfigurationsfiler, og derfor er det mere værd at måle formen end at gætte. En enkelt ping til gatewayen kan ikke skelne dem.

Udvisk videresendelse, før du skrumper noget

Test en destination på den anden side af gatewayen, ikke gatewayen selv. Et ping til serverens tunneladresse beviser kun, at interfacet er oppe, og at du kan nå maskinen, der afslutter tunnelen. Trafik til det bredere netværk afhænger af, at IP-videresendelse er aktiveret på den maskine, og af en firewall, der tillader den videresendte strøm. Begge skal være sande, og hvis én er falsk, får du samme stilhed.

Returrouting betyder lige så meget. Hvis destinationsnetværket ikke ved, hvordan det når klientens tunneladresse, ankommer forespørgslen, og svaret forsvinder, og klienten rapporterer en timeout, der ligner en tabt videresendelse.

Hvor designet bruger adresseoversættelse, er oversættelsesreglen en del af den returvej. At fjerne den, mens man jager et MTU-problem, gør et fungerende design til et ødelagt et, så læs de eksisterende regler, før du redigerer dem.

Mål, hvor bruddet begynder

Læs først videresendelsestilstanden og filterreglerne. Det er skrivebeskyttede kontroller, og de svarer på det billige spørgsmål:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Test derefter størrelser med don’t-fragment-bitten, fra klienten, mod en vært på den anden side af gatewayen:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

Hvis den første test virker, og den anden fejler med en fragmenteringsfejl, fortæller stien dig sin brugbare størrelse. Hvis ingen af dem virker, kigger du på videresendelse eller routing, og MTU er ikke den variabel, der skal ændres.

Ret det lag, du har bevist

Når videresendelse er fejlen, er rettelsen en videresendelsesregel eller en rute, udtrykt så snævert, som designet tillader. Når størrelsen er fejlen, er rettelsen en MTU, der tager højde for indkapslingen på netop denne sti, anvendt på det interface, der har brug for det, og ikke på hver adapter i flåden.

Uanset hvad, gentag derefter den samme opgave mod den samme destination. Hvis den oprindelige store overførsel nu fuldføres, har ændringen adresseret det lag, der fejlede. Hvis kun den lille test blev bedre, behandlede du et symptom, og den reelle grænse er stadig på plads.

Skriv ned, hvilken form du så før ændringen. Den ene linje, noteret ved siden af rettelsen, er det, der forhindrer den næste person i at sænke en MTU, der aldrig var problemet.