Afgræns en OpenVPN-gateway til ét LAN med UFW-regler

Beslut tilladelsen, før du åbner en firewall-fil: godkendte klienter må åbne forbindelser til ét bestemt undernet, og gatewayen skal afvise enhver anden transitvej, selv når en klient installerer ekstra ruter. Den sætning er designet, og hver regel nedenfor findes for at håndhæve den. Alt bredere, som hele det private adresserum, internetadgang gennem tunnelen eller peer-to-peer-trafik, er et andet design, der kræver sin egen beslutning. Reglerne er også med vilje kedelige, for en smart firewall er en, som ingen kan revidere senere.

Skriv topologien og tilladelsen ned først

Eksemplet bruger en Community OpenVPN server med en TUN-enhed i brugerrummet kaldet tun0, en klientpulje 10.77.0.0/24, og ét tilsluttet undernet 192.168.60.0/24 på lan0. IPv4-videresendelse virker allerede, og LAN'et har allerede en returrute til puljen, så intet her afhænger af oversættelse mellem dem.

UFW ejer firewallen på denne vært, og hverken et container-regelsæt eller en separat nftables-tabel må installere en tidligere acceptvej. En flow-offload-genvej, der springer filteret over, ville gøre vagtkæderne dekorative, så bekræft, at ingen er aktiv. Lad OpenVPNs egen client-to-client videresendelse være deaktiveret, fordi peer-to-peer-trafik, der aldrig krydser operativsystemets filter kan ikke afgrænses af den. Den eksterne lytter og administrationsreglerne forbliver som de er, da denne ændring styrer dekrypteret tunneltrafik i stedet for at erstatte firewallen.

Placer vagterne før UFWs tidlige accepter

En rute-tilladelse efterfulgt af en afvisning er ikke nok til en streng grænse. Standard before-regler accepterer etableret trafik og udvalgte ICMP, før nogen brugerregel konsulteres, så en strøm, der blev tilladt i sidste uge, kan blive uden for den nye destinationsbegrænsning alene fordi den stadig har tilstand. Tag backup af UFW-filerne, og hold en out-of-band-konsol åben før redigering.

I afsnittet *filter i filen /etc/ufw/before.rules, erklær to kæder ved siden af de eksisterende erklæringer og før enhver regellinje.

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

Umiddelbart efter erklæringerne, og før tilladelserne for input og videresendelse, spring ind i dem og definér, hvad de tillader.

-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 af afsnittet og dets COMMIT -linje. At indsætte en anden filtertabel eller slette urelaterede regler er måden, hvorpå en firewall-ændring bliver et nedbrud, og filen er én genstart fra at være den eneste kopi, der betyder noget.

Læs, hvad hver vagt tillader og afviser

Den første kæde fortsætter behandlingen kun, når kilden er i puljen, destinationen er det ene undernet, udgangsinterfacet er LAN'et, og pakken bevæger sig i den oprindelige retning af sin strøm. Alt andet, der ankommer fra tunnelen, droppes, inklusive en kilde uden for puljen og enhver destination ud over det tilladte undernet.

En peer-to-peer-pakke går ind i og ud af tun0, så den fejler LAN-interfacetesten, før en destinationskontrol overhovedet nås. Nye forbindelser fra LAN'et mod klienter fejler også svarets retningstest, hvilket som standard lukker den omvendte tilbagekaldsvej.

Målet RETURN holder almindelig UFW-politik i spil. Disse kæder filtrerer, og den rute-tilladelse, du tilføjer derefter, afgør stadig, om en overlevende pakke accepteres. Netop den adskillelse gør det muligt senere at ændre det tilladte undernet ét sted. Hvis vagterne accepterede pakker direkte, skulle hver fremtidig regel tilføjes to gange.

Tillad undernettet og luk sidedørene

Forhåndsvis rute-tilladelsen først, og fjern derefter forhåndsvisningsflaget for at anvende 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. Gennemgå bagefter rækkefølgen af brugerreglerne, for en tidligere afvisning vinder stadig over en senere tilladelse. En tilladelse for hele undernettet er også den forkerte form, når kun én værts HTTPS-port skal være tilgængelig.

Bemærk, hvad input-droppet gør: tunnelklienter kan ikke nå nogen tjeneste på gatewayen selv, inklusive en DNS-lytter bundet til dens LAN-adresse. At hoste DNS der kræver en bevidst undtagelse før droppet og en revideret tilladelseskontrakt. Hvis UFW styrer IPv6, skal du også tilføje tilsvarende drops for tun0 i before6.rules, fordi en IPv4-destinationsliste intet siger om IPv6-pakker.

Verificér den indlæste politik, ikke forhåndsvisningen

Forhåndsvis genindlæsningen, anvend den i et vedligeholdelsesvindue, og læs det levende regelsæt.

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

Bekræft, at tunnelvagterne vises før standardtilladelserne for tilstand og ICMP. Almindelig ufw status viser ikke håndredigerede before-regler, og derfor konkluderer operatører, at en regel mangler, når den faktisk er indlæst. Læs den rå liste fra top til bund i stedet for at søge efter et fragment. Hvis vagterne vises efter en tilstandstilladelse, gør grænsen ikke, hvad filen antyder.

Test derefter adfærd frem for tekst. Åbn en ny forbindelse til en tilladt vært og se svaret, send en uskyldig anmodning til en destination uden for undernettet og bekræft, at den dør, prøv en peer-to-peer-forbindelse, prøv en tjeneste, der er lokal på gatewayen, og prøv en uopfordret LAN-til-klient-forbindelse. Medtag én strøm uden for rammerne, som eksisterede før ændringen, og ryd kun den strøm i stedet for at tømme maskinens hele sporingstabel.

Skriv grænserne ned ved siden af reglerne: dette begrænser transit og intet andet. Det forhindrer ikke en klient i at bruge sin egen internetforbindelse, forhindrer ikke en tilladt LAN-vært i at videresende trafik, og erstatter ikke godkendelse inde i de tilladte tjenester.