Slik gir du ett test-LAN sin egen WireGuard-utgang

Tre design løser det samme laboratorieproblemet: et lite LAN må ut gjennom en WireGuard-peer mens gatewayen selv beholder den vanlige oppstrømsforbindelsen. Den fristende snarveien er å flytte ruterens standardrute inn i tunnelen, men det bryter boksens egen administrasjonsvei og alt annet den videresender. Det interessante alternativet er policy-ruting avgrenset til ett grensesnitt og ett prefiks. Velg mellom dem ved å svare på tre spørsmål om maskinen du faktisk har.

Avgjør hvor utgangen bor

Første spørsmål: videresender denne verten for noe annet? En dedikert laboratoriegateway kan leve med en videresendingspolicy som dropper som standard. En ruter med produksjonsoppgaver kan ikke, og å legge et konkurrerende regelsett oppå en administrert brannmur er nettopp måten avbrudd blir planlagt på. Andre: kan du eie to policyobjekter og rekkefølgen deres på tvers av omstarter? Tredje: autoriserer peeren du har tunnelkildeadressen din og tilbyr den internett-utgang? En peer som bare eksponerer et privat nettverk er et annet produkt, og ingen lokal rutingendring retter det. Hvis noe svar er nei, sett utgangen i et navnerom eller i en engangs virtuell maskin i stedet.

Et navnerom eller en VM koster minne og gir deg en ren eksplosjonsradius. Policy-ruting koster to regler og lar deg sitte igjen med én boks å feilsøke.

Velg utgangen som autoriserer kilden din

De fleste feilene i dette laboratoriet skjer før en eneste brannmurregel finnes. Utgangens operatør må godta kildeadressen pakkene dine bærer etter oversettelsen, og i dette designet er det tunneladressen og ikke LAN-prefikset. Derfor hører maskering hjemme i designet fra starten og ikke som et sent tillegg.

Bekreft tre ting med operatøren: peeren autoriserer tunneladressen din, den videresender IPv4 i stedet for å terminere hos seg selv, og den anvender utgående NAT. Uten det første kommer pakkene dine frem og forsvinner. Uten det tredje går de ut med en privat kilde og dør på neste hopp. Sjekk deretter at wg-quick ikke installerer sin egen standardrute, noe Table = off forhindrer; den innstillingen undertrykker oppretting av ruter, ikke peerens AllowedIPs-kontroller eller dens DNS-håndtering.

To policyobjekter gjør styringen

Styring krever en tabell og en regel. Tabellen holder to ruter: LAN-prefikset ut av LAN-grensesnittet og en standardrute ut av tunnelen. Regelen sender trafikk som ankommer LAN-grensesnittet og bærer dette prefikset, inn i tabellen. Bruk iif-velgeren sammen med kildevektingen, fordi gatewayens egne WireGuard-pakker oppstår lokalt og aldri matcher et innkommende grensesnitt.

Vakten kommer før oppslaget, ikke etter. Den rekkefølgen er hele sikkerhetsegenskapen ved designet.

Vakten er en andre regel på samme velger hvis dom er unreachable. Gi den høyere numerisk prioritet slik at oppslaget fortsatt vinner mens tunnelen er oppe. Når tunnelruten forsvinner, returnerer oppslaget ingenting, og vakten stopper søket i stedet for å la det falle gjennom til WAN-standarden i hovedtabellen.

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Lukk fallgruven før du åpner den

Installer vakten først og oppslaget etterpå. Gjør du det motsatt, blir det igjen et vindu på sekunder der trafikken fra en testklient kan nå oppstrømsforbindelsen.

Filteret fullfører bildet. I forward-kroken godtar du retningen fra LAN til tunnel for testprefikset og den etablerte returretningen, og slipper deretter alt annet; NAT for det prefikset ut på tunnelgrensesnittet hører i postrouting. Nettopp å la policy drop bli stående på forward-kjeden er det som gjør en manglende rute til stillhet i stedet for lekkasje. Reverse-path-filtrering krever løs modus på tunnelgrensesnittet, fordi en offentlig kilde som ankommer dekapsulert har sin beste omvendte rute på WAN-siden. Linux tar den høyeste av verdien all og per grensesnitt, så å sette tunnelgrensesnittet er ikke det samme som å svekke valideringen overalt.

Bevis det med feiltilfellet

Still kjernen et presist spørsmål ved å navngi klientens kildeadresse og grensesnittet den ankommer på. Et oppslag uten begge besvarer et annet spørsmål og vil se riktig ut i begge tilfeller. Se deretter på brannmurtellerne, peerens overføringsstatus og klientens egen tjeneste.

Test fjerningen ordentlig. Stopp tunnelen mens regelen og filteret blir stående: klienten bør stoppe og gatewayens egen trafikk bør fortsette å virke. Stopp deretter peeren uten å røre det lokale grensesnittet, og det er tilfellet som fanger design som bare stoler på at ruten finnes. Til slutt starter du på nytt og kontrollerer reglerekkefølgen igjen, fordi en nedtakingskrok som fjerner vakten gir hele designet tilbake til hovedtabellen. Noter tabellnummer, prioriteter og grensesnittnavn på endringssaken, fordi neste person som legger til en regel er den som ødelegger dette.