WireGuard-peer går ut via feil WAN: fem kontroller i rekkefølge

To uplinks, én gateway og en WireGuard-peer der trafikken stadig dukker opp på reservelinjen. Håndtrykket holder seg sunt hele tiden. Derfor er symptomet lett å feilleses som en WireGuard-feil i stedet for en rutingsfeil.

Utfør kontrollene nedenfor i rekkefølge. Hver har en stoppbetingelse, og å hoppe fremover gir vanligvis et selvsikkert feil svar.

Skill håndtrykket fra den videresendte strømmen

Den krypterte peer-utvekslingen har en endepunktsrute til serverens offentlige adresse. Videresendt klienttrafikk har en annen destinasjon og kan velges av markeringer eller policyregler. Det er to rutingsbeslutninger som deler ett grensesnitt. Å behandle den ene som bevis om den andre er den første feilen.

Stopp så snart du tar deg i å resonnere fra håndtrykket. Det er bare bevis om endepunktsstien.

Les policyregelen, ikke standardtabellen

En standardtabell viser hva som skjer når ingen policyregel passer. På en gateway som ruter etter kilde, markering eller destinasjon, bor den avgjørende regelen et annet sted. Den vanlige tabellen kan se helt rimelig ut mens det egentlige valget tas over den.

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

Les policyreglene og tabellene de peker på. Bekreft deretter hvilken regel som passer med teststrømmen din. En regel som viser til et grensesnitt som ikke lenger bærer den tiltenkte uplinken, er et funn, ikke en detalj. Ruteoppslaget til slutt viser svaret mye raskere enn å lese en tabell og gjette.

Kontroller markeringen og oversettelsen sammen

Policyruting er avhengig av en pakkemarkering satt tidligere i kjeden. Hvis markeringsregelen bommer på trafikken din, faller strømmen gjennom til hovedtabellen og går ut via det som er standard der. Videresendte pakker hopper ofte over kjeder som er skrevet for lokalt generert trafikk.

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

Oversettelsen må stemme med uplinken som bærer strømmen. En regel som oversetter til primæradressen mens pakken går ut via reservelinjen, gir svar adressert til et grensesnitt strømmen aldri brukte. Kontroller oversettelsesregelens egen grensesnittbetingelse. En ubetinget regel virker til den andre uplinken tas i bruk, og feiler deretter på en måte som virker periodisk.

Se hvilket grensesnitt som bærer svaret

Ta opp på begge uplinkene mens én forespørsel kjører. Noter hvilket grensesnitt som bærer forespørselen og hvilket som bærer svaret. Asymmetriske stier er mye lettere å se enn å forutsi.

Hvis svaret kommer inn på feil uplink, har problemet flyttet seg fra WireGuard til tilkoblingssporing eller oversettelse. Ingen endring i peer-konfigurasjonen vil rette det.

Endre én ting med en vei tilbake

Ha konsoll- eller båndutekontroll tilgjengelig før du redigerer policyregler på en gateway. Gjør én endring, test den samme autoriserte destinasjonen, koble deretter til på nytt og bekreft at håndtrykket fortsatt bruker den tiltenkte endepunktsstien. Legg til en numerisk test på den andre adressefamilien, fordi en policy som bare gjelder v4, lar den samme feilen være tilgjengelig.

Noter hvilken uplink hver strøm brukte. Den registreringen gjør neste rapport til en tomminutters kontroll i stedet for en hel ettermiddag. WireGuards notater om navnerom og ruting beskriver hvordan man bevisst skiller endepunktsstien fra tunnelert trafikk, noe som vanligvis er renere enn å kopiere en omvei med standardrute.