Sådan får ét test-LAN sin egen WireGuard-udgang

Tre designs løser det samme laboratorieproblem: et lille LAN skal ud gennem en WireGuard-peer, mens gatewayen selv beholder sin sædvanlige uplink. Den fristende genvej er at flytte routerens standardrute ned i tunnelen, men det bryder boksens egen administrationsvej og alt andet, den videresender. Den interessante mulighed er policy-routing afgrænset til én grænseflade og ét præfiks. Vælg mellem dem ved at besvare tre spørgsmål om den maskine, du faktisk har.

Afgør, hvor udgangen bor

Første spørgsmål: videresender denne vært for noget andet? En dedikeret laboratoriegateway kan leve med en videresendelsespolitik, der som standard dropper. En router med produktionsopgaver kan ikke, og at lægge et konkurrerende regelsæt oven på en administreret firewall er netop måden, nedbrud bliver planlagt på. Andet: kan du eje to politikobjekter og deres rækkefølge hen over genstarter? Tredje: godkender den peer, du har, din tunnelkildes adresse og tilbyder den internetudgang? En peer, der kun eksponerer et privat netværk, er et andet produkt, og ingen lokal routingændring retter det. Hvis et svar er nej, så læg udgangen i et navnerum eller i en maskine, der bare smides væk, i stedet.

Et navnerum eller en VM koster hukommelse og giver dig en ren eksplosionsradius. Policy-routing koster to regler og efterlader dig med én boks at fejlfinde på.

Vælg den udgang, der godkender din kilde

De fleste fejl i dette laboratorium sker, før der findes en enkelt firewallregel. Udgangens operatør skal acceptere den kildeadresse, dine pakker bærer efter oversættelse, og i dette design er det tunneladressen frem for LAN-præfikset. Derfor hører maskering hjemme i designet fra starten og ikke som en sen tilføjelse.

Bekræft tre ting med operatøren: peeren godkender din tunneladresse, den videresender IPv4 i stedet for at terminere hos sig selv, og den anvender udgående NAT. Uden det første ankommer dine pakker og forsvinder. Uden det tredje forlader de med en privat kilde og dør på næste hop. Kontroller derefter, at wg-quick ikke installerer sin egen standardrute, hvilket Table = off forhindrer; den indstilling undertrykker oprettelse af ruter, ikke peerens AllowedIPs-kontroller eller dens DNS-håndtering.

To politikobjekter styrer trafikken

Styring kræver en tabel og en regel. Tabellen holder to ruter: LAN-præfikset ud af LAN-grænsefladen og en standardrute ud af tunnelen. Reglen sender trafik, der ankommer på LAN-grænsefladen og bærer dette præfiks, ind i tabellen. Brug iif-vælgeren sammen med kildebetingelsen, fordi gatewayens egne WireGuard-pakker opstår lokalt og aldrig matcher en indgående grænseflade.

Vagten kommer før opslaget, ikke efter det. Den rækkefølge er hele sikkerhedsegenskaben ved designet.

Vagten er en anden regel på samme vælger, hvis dom er unreachable. Giv den en højere numerisk prioritet, så opslaget stadig vinder, mens tunnelen er oppe. Når tunnelforløbet forsvinder, returnerer opslaget intet, og vagten stopper søgningen i stedet for at lade den falde igennem 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

Luk faldgruben, før du åbner den

Installer vagten først og opslaget bagefter. Gør du det omvendt, efterlader det et vindue på sekunder, hvor en testklients trafik kan nå uplinken.

Filteret fuldender billedet. I forward-krogen accepterer du retningen fra LAN til tunnel for testpræfikset og den etablerede returretning og dropper derefter alt andet; NAT for det præfiks ud på tunnelgrænsefladen hører i postrouting. Netop at lade policy drop blive på forward-kæden er det, der gør en manglende rute til tavshed i stedet for en lækage. Reverse-path-filtrering kræver løs tilstand på tunnelgrænsefladen, fordi en offentlig kilde, der ankommer dekapsuleret, har sin bedste omvendte rute på WAN-siden. Linux tager den højeste af værdien for all og for grænsefladen, så at sætte tunnelgrænsefladen er ikke det samme som at svække valideringen overalt.

Bevis det med fejlscenariet

Stil kernen et præcist spørgsmål ved at navngive klientens kildeadresse og den grænseflade, den ankommer på. Et opslag uden begge besvarer et andet spørgsmål og vil se korrekt ud under alle omstændigheder. Se derefter på firewalltællerne, peerens overførselsstatus og klientens egen tjeneste.

Test fjernelsen ordentligt. Stop tunnelen, mens reglen og filteret bliver på plads: klienten bør gå i stå, og gatewayens egen trafik bør fortsætte med at virke. Stop derefter peeren uden at røre den lokale grænseflade, og det er netop det tilfælde, der fanger designs, som kun stoler på rutens tilstedeværelse. Genstart til sidst og kontroller reglerækkefølgen igen, fordi en nedtagningskrog, der fjerner vagten, giver hele designet tilbage til hovedtabellen. Skriv tabelnummer, prioriteter og grænsefladenavne på ændringsbilletten, fordi den næste person, der tilføjer en regel, er den, der brækker det.