WireGuard-peer lämnar via fel WAN: fem kontroller i ordning

På en gateway med flera uplänkar kan handskakningen och det vidarebefordrade flödet ta olika vägar. Gå igenom regel, markering, översättning och svar i den ordningen.

Två uplänkar, en gateway och en WireGuard-peer vars trafik ständigt dyker upp på reservlinjen. Handskakningen förblir frisk hela tiden. Därför är symtomet lätt att felläsa som ett WireGuard-fel i stället för ett routingfel.

Utför kontrollerna nedan i ordning. Var och en har ett stoppvillkor, och att hoppa framåt ger oftast ett självsäkert fel svar.

Skilj handskakningen från det vidarebefordrade flödet

Det krypterade peer-utbytet har en slutpunktsrutt till serverns offentliga adress. Vidarebefordrad klienttrafik har en annan destination och kan väljas av markeringar eller policyregler. Det är två routingbeslut som delar ett gränssnitt. Att behandla det ena som bevis om det andra är det första felet.

Stanna så snart du kommer på dig själv med att resonera utifrån handskakningen. Den är bara bevis om slutpunktens väg.

Läs policyregeln, inte standardtabellen

En standardtabell visar vad som händer när ingen policyregel matchar. På en gateway som routar efter källa, markering eller destination bor den avgörande regeln någon annanstans. Den vanliga tabellen kan se helt rimlig ut medan det verkliga valet görs ovanför den.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Läs policyreglerna och tabellerna de pekar på. Bekräfta sedan vilken regel som matchar ditt testflöde. En regel som hänvisar till ett gränssnitt som inte längre bär den avsedda uplänken är ett fynd, inte en detalj. Routuppslagningen i slutet visar svaret mycket snabbare än att läsa en tabell och gissa.

Kontrollera markeringen och översättningen tillsammans

Policyrouting bygger på en paketmarkering som satts tidigare i kedjan. Om markeringsregeln missar din trafik faller flödet igenom till huvudtabellen och lämnar via vad som än är standard där. Vidarebefordrade paket hoppar ofta över kedjor som skrivits för lokalt genererad trafik.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

Översättningen måste stämma med den uplänk som bär flödet. En regel som översätter till primäradressen medan paketet lämnar via reservlinjen producerar svar adresserade till ett gränssnitt som flödet aldrig använde. Kontrollera översättningsregelns eget gränssnittsvillkor. En ovillkorlig regel fungerar tills den andra uplänken används, och misslyckas sedan på ett sätt som verkar intermittent.

Se vilket gränssnitt som bär svaret

Fånga på båda uplänkarna medan en förfrågan körs. Notera vilket gränssnitt som bär förfrågan och vilket som bär svaret. Asymmetriska vägar är mycket lättare att se än att förutse.

Om svaret kommer in via fel uplänk har problemet flyttat från WireGuard till anslutningsspårning eller översättning. Ingen ändring av peer-konfigurationen åtgärdar det.

Ändra en sak med en väg tillbaka

Behåll konsol- eller out-of-band-åtkomst innan du redigerar policyregler på en gateway. Gör en ändring, testa samma auktoriserade destination, anslut sedan igen och bekräfta att handskakningen fortfarande använder den avsedda slutpunktsvägen. Lägg till ett numeriskt test på den andra adressfamiljen, eftersom en policy som bara gäller v4 lämnar samma fel tillgängligt.

Notera vilken uplänk varje flöde använde. Den anteckningen gör nästa rapport till en tvåminuterskontroll i stället för en hel eftermiddag. WireGuards anteckningar om namnutrymmen och routing beskriver hur man medvetet skiljer slutpunktsvägen från tunnlad trafik, vilket oftast är renare än att kopiera en omväg med standardrutt.

Relaterade artiklar