WireGuard-peer forlader via den forkerte WAN: fem kontroller i rækkefølge

To uplinks, én gateway og en WireGuard-peer, hvis trafik hele tiden dukker op på backuplinjen. Håndtrykket forbliver sundt hele vejen. Derfor er symptomet let at fejllæse som en WireGuard-fejl i stedet for en routingfejl.

Udfør kontrollerne nedenfor i rækkefølge. Hver har en stopbetingelse, og at springe frem producerer normalt et selvsikkert forkert svar.

Adskil håndtrykket fra den videresendte strøm

Den krypterede peer-udveksling har en endepunktsrute til serverens offentlige adresse. Videresendt klienttrafik har en anden destination og kan blive valgt af markeringer eller politikregler. Det er to routingbeslutninger, der deler én grænseflade. At behandle den ene som bevis om den anden er den første fejl.

Stop, så snart du opdager, at du ræsonnerer ud fra håndtrykket. Det er kun bevis om endepunktsstien.

Læs politikreglen, ikke standardtabellen

En standardtabel viser, hvad der sker, når ingen politikregel matcher. På en gateway, der router efter kilde, markering eller destination, bor den afgørende regel et andet sted. Den almindelige tabel kan se helt rimelig ud, mens det reelle valg træffes oven over den.

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

Læs politikreglerne og de tabeller, de peger på. Bekræft derefter, hvilken regel der matcher din teststrøm. En regel, der henviser til en grænseflade, som ikke længere bærer det tilsigtede uplink, er et fund, ikke en detalje. Ruteopslaget til sidst viser svaret meget hurtigere end at læse en tabel og gætte.

Kontroller markeringen og oversættelsen sammen

Politikrouting afhænger af en pakkemarkering, der er sat tidligere i kæden. Hvis markeringsreglen misser din trafik, falder strømmen igennem til hovedtabellen og forlader via hvad der end er standard der. Videresendte pakker springer ofte kæder over, der blev skrevet til lokalt genereret trafik.

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

Oversættelsen skal stemme overens med det uplink, der bærer strømmen. En regel, der oversætter til den primære adresse, mens pakken forlader via backuplinjen, producerer svar rettet mod en grænseflade, som strømmen aldrig brugte. Kontroller oversættelsesreglens egen grænsefladebetingelse. En ubetinget regel virker, indtil det andet uplink bruges, og fejler derefter på en måde, der ser periodisk ud.

Se, hvilken grænseflade der bærer svaret

Optag på begge uplinks, mens én anmodning kører. Noter, hvilken grænseflade der bærer anmodningen, og hvilken der bærer svaret. Asymmetriske stier er meget lettere at se end at forudsige.

Hvis svaret ankommer på det forkerte uplink, er problemet flyttet fra WireGuard til forbindelsessporing eller oversættelse. Ingen ændring af peer-konfigurationen vil rette det.

Ændr én ting med en vej tilbage

Behold konsol- eller out-of-band-adgang, før du redigerer politikregler på en gateway. Foretag én ændring, test den samme autoriserede destination, og genopret derefter forbindelsen og bekræft, at håndtrykket stadig bruger den tilsigtede endepunktssti. Tilføj en numerisk test på den anden adressefamilie, fordi en politik, der kun gælder v4, efterlader den samme fejl tilgængelig.

Noter, hvilket uplink hver strøm brugte. Den registrering gør den næste rapport til et tominutters tjek i stedet for en hel eftermiddag. WireGuards noter om navnerum og routing beskriver, hvordan man bevidst adskiller endepunktsstien fra tuneleret trafik, hvilket normalt er renere end at kopiere en omvej med standardrute.