Så ger du ett test-LAN sin egen WireGuard-utgång

Tre konstruktioner löser samma laboratorieproblem: ett litet LAN måste gå ut genom en WireGuard-peer medan gatewayen själv behåller sin vanliga upplänk. Den frestande genvägen är att flytta routerns standardrutt in i tunneln, men det bryter boxens egen administrationsväg och allt annat den vidarebefordrar. Det intressanta alternativet är policy-routing begränsad till ett gränssnitt och ett prefix. Välj mellan dem genom att svara på tre frågor om maskinen du faktiskt har.

Bestäm var utgången bor

Första frågan: vidarebefordrar den här värden för något annat? En dedikerad laboratorie-gateway kan leva med en vidarebefordringspolicy som släpper allt som standard. En router med produktionsuppgifter kan inte det, och att lägga ett konkurrerande regelverk ovanpå en hanterad brandvägg är precis hur avbrott blir inplanerade. Andra: kan du äga två policyobjekt och deras ordning över omstarter? Tredje: auktoriserar peeren du har din tunnelkälladress och erbjuder den internetutgång? En peer som bara exponerar ett privat nätverk är en annan produkt, och ingen lokal routingändring rättar det. Om något svar är nej, placera utgången i ett namnutrymme eller i en engångsvirtuell maskin i stället.

Ett namnutrymme eller en VM kostar minne och ger dig en ren explosionsradie. Policy-routing kostar två regler och lämnar dig en enda box att felsöka.

Välj den utgång som auktoriserar din källa

De flesta fel i det här laboratoriet inträffar innan en enda brandväggsregel finns. Utgångens operatör måste acceptera källadressen som dina paket bär efter översättningen, och i den här konstruktionen är det tunneladressen och inte LAN-prefixet. Därför hör maskning hemma i konstruktionen från början och inte som ett sent tillägg.

Bekräfta tre saker med operatören: peeren auktoriserar din tunneladress, den vidarebefordrar IPv4 i stället för att termineras hos sig själv, och den tillämpar utgående NAT. Utan det första kommer dina paket fram och försvinner. Utan det tredje går de ut med en privat källa och dör på nästa hopp. Kontrollera sedan att wg-quick inte installerar sin egen standardrutt, vilket Table = off förhindrar; den inställningen undertrycker skapande av rutter, inte peerens AllowedIPs-kontroller eller dess DNS-hantering.

Två policyobjekt gör styrningen

Styrning kräver en tabell och en regel. Tabellen håller två rutter: LAN-prefixet ut ur LAN-gränssnittet och en standardrutt ut ur tunneln. Regeln skickar trafik som anländer på LAN-gränssnittet och bär det prefixet in i tabellen. Använd iif-väljaren tillsammans med källmatchningen, eftersom gatewayens egna WireGuard-paket uppstår lokalt och aldrig matchar ett inkommande gränssnitt.

Vakten kommer före uppslaget, inte efter. Den ordningen är hela säkerhetsegenskapen i konstruktionen.

Vakten är en andra regel på samma väljare vars dom är unreachable. Ge den högre numerisk prioritet så att uppslaget fortfarande vinner medan tunneln är uppe. När tunnelrutten försvinner returnerar uppslaget ingenting och vakten stoppar sökningen i stället för att låta den falla igenom till WAN-standarden i huvudtabellen.

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

Stäng återfallsgluggen innan du öppnar den

Installera vakten först och uppslaget sedan. Gör du det omvänt lämnas ett fönster på sekunder där en testklients trafik kan nå upplänken.

Filtret fullbordar bilden. I forward-kroken accepterar du riktningen från LAN till tunnel för testprefixet och den etablerade returriktningen och släpper sedan allt annat; NAT för det prefixet ut på tunnelgränssnittet hör i postrouting. Just att låta policy drop stå kvar på forward-kedjan är det som gör en saknad rutt till tystnad i stället för läckage. Reverse-path-filtrering kräver löst läge på tunnelgränssnittet, eftersom en offentlig källa som anländer dekapsulerad har sin bästa omvända rutt på WAN-sidan. Linux tar det högre av värdet all och per gränssnitt, så att ställa in tunnelgränssnittet är inte samma sak som att försvaga valideringen överallt.

Bevisa det med felet

Ställ kerneln en exakt fråga genom att namnge klientens källadress och gränssnittet den anländer på. Ett uppslag utan båda besvarar en annan fråga och ser korrekt ut i båda fallen. Titta sedan på brandväggsräknarna, peerens överföringsstatus och klientens egen tjänst.

Testa borttagningen ordentligt. Stoppa tunneln medan regeln och filtret ligger kvar: klienten bör stanna och gatewayens egen trafik bör fortsätta fungera. Stoppa sedan peeren utan att röra det lokala gränssnittet, och det är fallet som fångar konstruktioner som bara litar på att rutten finns. Starta till sist om och kontrollera regelordningen igen, eftersom en nedtagningskrok som tar bort vakten ger hela konstruktionen tillbaka till huvudtabellen. Anteckna tabellnummer, prioriteter och gränssnittsnamn på ändringsärendet, eftersom nästa person som lägger till en regel är den som bryter det här.