Begrens en OpenVPN-gateway til ett LAN med UFW-regler

Bestem tillatelsen før du åpner en brannmurfil: autentiserte klienter kan åpne forbindelser til ett bestemt subnett, og gatewayen må avvise enhver annen transittvei selv når en klient installerer ekstra ruter. Den setningen er designet, og hver regel nedenfor finnes for å håndheve den. Noe bredere, som hele det private adresserommet, internettutgang gjennom tunnelen eller peer-to-peer-trafikk, er et annet design som trenger sin egen beslutning. Reglene er også med vilje kjedelige, for en smart brannmur er en som ingen kan revidere senere.

Skriv ned topologien og tillatelsen først

Eksempelet bruker en Community OpenVPN server med en TUN-enhet i brukerrommet kalt tun0, en klientpool 10.77.0.0/24, og ett tilkoblet subnett 192.168.60.0/24 på lan0. IPv4-videreformidling virker allerede, og LAN-et har allerede en returrute til poolen, så ingenting her avhenger av oversettelse mellom dem.

UFW eier brannmuren på denne verten, og verken et containerregelsett eller en separat nftables-tabell kan installere en tidligere akseptvei. En snarvei for flytofflasting som hopper over filteret ville gjøre vaktkjedene til dekorasjon, så bekreft at ingen er aktiv. La OpenVPNs egen client-to-client videreformidling være avslått, fordi peer-to-peer-trafikk som aldri krysser operativsystemets filter ikke kan begrenses av den. Den eksterne lytteren og administrasjonsreglene blir som de er, siden denne endringen styrer dekryptert tunneltrafikk i stedet for å erstatte brannmuren.

Plasser vaktene før UFWs tidlige aksepter

En rute-tillatelse etterfulgt av en avvisning er ikke nok for en streng grense. Standard before-regler aksepterer etablert trafikk og utvalgte ICMP før noen brukerregel blir konsultert, så en strøm som ble tillatt i forrige uke kan bli stående utenfor den nye destinasjonsbegrensningen bare fordi den fortsatt har tilstand. Ta sikkerhetskopi av UFW-filene og hold en out-of-band-konsoll åpen før du redigerer.

I seksjonen *filter i filen /etc/ufw/before.rules, deklarer to kjeder ved siden av de eksisterende deklarasjonene og før enhver regellinje.

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

Rett etter deklarasjonene, og før tillatelsene for inngang og videreformidling, hopp inn i dem og definer hva de slipper gjennom.

-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

Behold resten av seksjonen og dens COMMIT -linje. Å lime inn en andre filtertabell eller slette urelaterte regler er måten en brannmur-endring blir et avbrudd, og filen er én omstart unna å være den eneste kopien som betyr noe.

Les hva hver vakt slipper gjennom og avviser

Den første kjeden fortsetter behandlingen bare når kilden er i poolen, destinasjonen er det ene subnettet, utgangsgrensesnittet er LAN-et og pakken reiser i den opprinnelige retningen til strømmen sin. Alt annet som kommer fra tunnelen, forkastes, inkludert en kilde utenfor poolen og enhver destinasjon utenfor det tillatte subnettet.

En peer-to-peer-pakke går inn i og ut av tun0, så den feiler LAN-grensesnitttesten før en destinasjonskontroll i det hele tatt nås. Nye forbindelser fra LAN-et mot klientene feiler også retningsretesten, noe som som standard lukker den omvendte tilbakeringingsveien.

Målet RETURN holder vanlig UFW-policy i spill. Disse kjedene filtrerer, og rute-tillatelsen du legger til etterpå avgjør fortsatt om en overlevende pakke godtas. Nettopp den separasjonen gjør det mulig å endre det tillatte subnettet på ett sted senere. Hvis vaktene godtok pakker direkte, måtte hver fremtidig regel legges til to ganger.

Tillat subnettet og lukk sidedørene

Forhåndsvis rute-tillatelsen først, og fjern deretter forhåndsvisningsflagget for å bruke den: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Gå deretter gjennom rekkefølgen på brukerreglene, for en tidligere avvisning vinner fortsatt over en senere tillatelse. En tillatelse for hele subnettet er også feil form når bare HTTPS-porten til én vert skal være tilgjengelig.

Legg merke til hva inngangsdroppet gjør: tunnelklienter kan ikke nå noen tjeneste på gatewayen selv, inkludert en DNS-lytter bundet til LAN-adressen. Å være vert for DNS der krever et bevisst unntak før droppet og en revidert tillatelseskontrakt. Hvis UFW administrerer IPv6, legg til tilsvarende dropp for tun0 i before6.rules også, fordi en IPv4-destinasjonsliste ikke sier noe om IPv6-pakker.

Verifiser den innleste policyen, ikke forhåndsvisningen

Forhåndsvis omlastingen, bruk den i et vedlikeholdsvindu, og les det levende regelsettet.

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

Bekreft at tunnelvaktene vises før standardtillatelsene for tilstand og ICMP. Vanlig ufw status viser ikke håndredigerte before-regler, og derfor konkluderer operatører med at en regel mangler når den faktisk er lastet. Les den rå listen fra topp til bunn i stedet for å søke etter et fragment. Hvis vaktene vises etter en tilstandstillatelse, gjør grensen ikke det filen antyder.

Test deretter atferd og ikke tekst. Åpne en ny forbindelse til en tillatt vert og se svaret, send en uskyldig forespørsel til en destinasjon utenfor subnettet og bekreft at den dør, prøv en peer-to-peer-forbindelse, prøv en tjeneste som er lokal på gatewayen, og prøv en uoppfordret LAN-til-klient-forbindelse. Ta med én strøm utenfor rammen som fantes før endringen, og fjern bare den strømmen i stedet for å tømme maskinens hele sporings tabell.

Noter grensene ved siden av reglene: dette begrenser transitt og ingenting annet. Det hindrer ikke en klient i å bruke sin egen internettforbindelse, hindrer ikke en tillatt LAN-vert i å videresende trafikk videre, og erstatter ikke autentisering inne i de tillatte tjenestene.