Begränsa en OpenVPN-gateway till ett LAN med UFW-regler

Bestäm tillståndet innan du öppnar en brandväggsfil: autentiserade klienter får öppna anslutningar till ett bestämt subnät, och gatewayen måste avvisa varje annan transitväg även när en klient installerar extra rutter. Den meningen är designen, och varje regel nedan finns för att genomdriva den. Något bredare, som hela det privata adressutrymmet, internetutgång genom tunneln eller peer-to-peer-trafik, är en annan design som behöver sitt eget beslut. Reglerna är också medvetet tråkiga, för en smart brandvägg är en som ingen kan granska i efterhand.

Skriv ner topologin och tillståndet först

Exemplet använder en Community OpenVPN server med en TUN-enhet i användarutrymmet som heter tun0, en klientpool 10.77.0.0/24, och ett anslutet subnät 192.168.60.0/24 på lan0. IPv4-vidarebefordran fungerar redan och LAN:et har redan en returrutt till poolen, så ingenting här beror på översättning mellan dem.

UFW äger brandväggen på den här värden, och varken en containerregeluppsättning eller en separat nftables-tabell får installera en tidigare acceptväg. En genväg för flödesavlastning som hoppar över filtret skulle göra vaktkedjorna till dekoration, så bekräfta att ingen är aktiv. Låt OpenVPN:s egen client-to-client vidarebefordran vara avstängd, eftersom peer-to-peer-trafik som aldrig passerar operativsystemets filter inte kan begränsas av den. Den externa lyssnaren och administrationsreglerna förblir som de är, eftersom den här ändringen styr dekrypterad tunneltrafik i stället för att ersätta brandväggen.

Placera vakterna före UFW:s tidiga accepter

Ett ruttillstånd följt av en avvisning räcker inte för en strikt gräns. Standardreglerna before accepterar etablerad trafik och utvalda ICMP innan någon användarregel konsulteras, så ett flöde som tilläts förra veckan kan stanna utanför den nya destinationsbegränsningen bara för att det fortfarande har tillstånd. Säkerhetskopiera UFW-filerna och håll en out-of-band-konsol öppen innan du redigerar.

I avsnittet *filter i filen /etc/ufw/before.rules, deklarera två kedjor bredvid de befintliga deklarationerna och före varje regelrad.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Direkt efter deklarationerna, och före tillstånden för ingång och vidarebefordran, hoppa in i dem och definiera vad de släpper igenom.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Behåll resten av avsnittet och dess COMMIT -rad. Att klistra in en andra filtertabell eller radera orelaterade regler är hur en brandväggsändring blir ett avbrott, och filen är en omstart från att vara den enda kopia som betyder något.

Läs vad varje vakt släpper igenom och avvisar

Den första kedjan fortsätter behandlingen bara när källan finns i poolen, målet är det enda subnätet, utgångsgränssnittet är LAN:et och paketet färdas i den ursprungliga riktningen av sitt flöde. Allt annat som kommer från tunneln kastas, inklusive en källa utanför poolen och varje destination bortom det tillåtna subnätet.

Ett peer-to-peer-paket går in i och ut ur tun0, så det faller på LAN-gränssnittstestet innan en destinationskontroll ens nås. Nya anslutningar från LAN:et mot klienterna faller också på svarsriktningstestet, vilket som standard stänger den omvända återuppringningsvägen.

Målet RETURN håller vanlig UFW-policy i spel. Dessa kedjor filtrerar, och ruttillståndet du lägger till efteråt avgör fortfarande om ett överlevande paket accepteras. Just den separationen gör det möjligt att senare ändra det tillåtna subnätet på ett ställe. Om vakterna accepterade paket direkt skulle varje framtida regel behöva läggas till två gånger.

Tillåt subnätet och stäng sidodörrarna

Förhandsgranska ruttillståndet först och ta sedan bort förhandsgranskningsflaggan för att tillämpa det: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Granska därefter ordningen på användarreglerna, för en tidigare avvisning vinner fortfarande över ett senare tillstånd. Ett tillstånd för hela subnätet är också fel form när bara en värds HTTPS-port ska vara nåbar.

Notera vad ingångsavyttringen gör: tunnelklienter når ingen tjänst på gatewayen själv, inklusive en DNS-lyssnare bunden till dess LAN-adress. Att vara värd för DNS där kräver ett medvetet undantag före avyttringen och ett reviderat tillståndsavtal. Om UFW hanterar IPv6, lägg till motsvarande avyttringar för tun0 i before6.rules också, för en IPv4-destinationslista säger ingenting om IPv6-paket.

Verifiera den lästa policyn, inte förhandsgranskningen

Förhandsgranska omladdningen, tillämpa den i ett underhållsfönster och läs den levande regeluppsättningen.

sudo ufw --dry-run reload
sudo ufw show raw

Bekräfta att tunnelvakterna visas före standardtillstånden för tillstånd och ICMP. En vanlig ufw status visar inte handredigerade before-regler, och därför drar operatörer slutsatsen att en regel saknas när den faktiskt är laddad. Läs den råa listan uppifrån och ner i stället för att söka efter ett fragment. Om vakterna visas efter ett tillståndstillstånd gör gränsen inte det filen antyder.

Testa sedan beteende och inte text. Öppna en ny anslutning till en tillåten värd och observera svaret, skicka en oskyldig begäran till en destination utanför subnätet och bekräfta att den dör, prova en peer-to-peer-anslutning, prova en tjänst som är lokal på gatewayen och prova en oombedd LAN-till-klient-anslutning. Inkludera ett flöde utanför ramen som fanns före ändringen, och rensa bara det flödet i stället för att tömma maskinens hela spårningstabell.

Anteckna gränserna bredvid reglerna: detta begränsar transit och ingenting annat. Det hindrar inte en klient från att använda sin egen internetanslutning, hindrar inte en tillåten LAN-värd från att vidarebefordra trafik, och ersätter inte autentiseringen inom de tillåtna tjänsterna.