WireGuard-peer går ut via feil WAN: fem kontrollar i rekkjefølgje

To uplinkar, ein gateway og ein WireGuard-peer der trafikken stadig dukkar opp på reservelinja. Handtrykket held seg sunt heile tida. Difor er symptomet lett å feillesa som ein WireGuard-feil i staden for ein rutingsfeil.

Utfør kontrollane nedanfor i rekkjefølgje. Kvar har ein stoppbetingelse, og å hoppe framover gir vanlegvis eit sjølvsikkert feil svar.

Skil handtrykket frå den videresende straumen

Den krypterte peer-utvekslinga har ein endepunktsrute til den offentlege adressa til tenaren. Videresend klienttrafikk har ein annan destinasjon og kan veljast av markeringar eller policyreglar. Det er to rutingsavgjerder som deler eitt grensesnitt. Å handsame den eine som prov om den andre er den første feilen.

Stopp så snart du tek deg i å resonnere frå handtrykket. Det er berre prov om endepunktsvegen.

Les policyregelen, ikkje standardtabellen

Ein standardtabell viser kva som skjer når ingen policyregel passar. På ein gateway som rutar etter kjelde, markering eller destinasjon, bur den avgjerande regelen ein annan stad. Den vanlege tabellen kan sjå heilt rimeleg ut medan det eigentlege valet blir teke over han.

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

Les policyreglane og tabellane dei peikar på. Stadfest deretter kva regel som passar med teststraumen din. Ein regel som viser til eit grensesnitt som ikkje lenger ber den tiltenkte uplinken, er eit funn, ikkje ein detalj. Ruteoppslaget til slutt viser svaret mykje raskare enn å lese ein tabell og gjette.

Kontroller markeringa og omsetjinga saman

Policyruting er avhengig av ei pakkemarkering sett tidlegare i kjeda. Viss markeringsregelen bommar på trafikken din, fell straumen gjennom til hovudtabellen og går ut via det som er standard der. Videresende pakkar hoppar ofte over kjeder skrivne 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

Omsetjinga må stemme med uplinken som ber straumen. Ein regel som omset til primæradressa medan pakken går ut via reservelinja, gir svar adresserte til eit grensesnitt straumen aldri brukte. Kontroller grensesnittvilkåret til omsetjingsregelen sjølv. Ein vilkårslaus regel verkar til den andre uplinken blir teken i bruk, og sviktar deretter på ein måte som verkar periodisk.

Sjå kva grensesnitt som ber svaret

Ta opp på begge uplinkane medan éin førespurnad køyrer. Noter kva grensesnitt som ber førespurnaden og kva som ber svaret. Asymmetriske vegar er mykje lettare å sjå enn å føreseie.

Viss svaret kjem inn på feil uplink, har problemet flytta seg frå WireGuard til tilkoplingssporing eller omsetjing. Ingen endring i peer-konfigurasjonen vil rette det.

Endra éin ting med ein veg tilbake

Ha konsoll- eller bandutekontroll tilgjengeleg før du redigerer policyreglar på ein gateway. Gjer éi endring, test den same autoriserte destinasjonen, kople deretter til på nytt og stadfest at handtrykket framleis brukar den tiltenkte endepunktsvegen. Legg til ein numerisk test på den andre adressefamilien, fordi ein policy som berre gjeld v4, lèt den same feilen vere tilgjengeleg.

Noter kva uplink kvar straum brukte. Den registreringa gjer neste rapport til ein tomminutts kontroll i staden for ein heil ettermiddag. WireGuards notat om namnerom og ruting skildrar korleis ein med vilje skil endepunktsvegen frå tunnelert trafikk, noko som vanlegvis er reinare enn å kopiere ein omveg med standardrute.