Avgrens ein OpenVPN-gateway til eitt LAN med UFW-reglar

Avgjer tillatinga før du opnar ei brannmurfil: autentiserte klientar kan opne samband til eitt bestemt subnett, og gatewayen må avvise kvar annan transittveg sjølv når ein klient installerer ekstra ruter. Den setninga er designet, og kvar regel nedanfor finst for å handheve det. Noko breiare, som heile det private adresserommet, internettutgang gjennom tunnelen eller peer-to-peer-trafikk, er eit anna design som treng si eiga avgjerd. Reglane er også med vilje keisame, for ein smart brannmur er ein som ingen kan revidere seinare.

Skriv ned topologien og tillatinga først

Dømet brukar ein Community OpenVPN server med ein TUN-eining i brukarrommet kalla tun0, ein klientpool 10.77.0.0/24, og eitt tilkopla subnett 192.168.60.0/24 på lan0. IPv4-vidareformidling verkar alt, og LAN-et har alt ein returveg til poolen, så ingenting her heng av omsetjing mellom dei.

UFW eig brannmuren på denne verten, og korkje eit containerregelsett eller ein separat nftables-tabell kan installere ein tidlegare akseptveg. Ein snarveg for flytofflasting som hoppar over filteret ville gjere vaktkjedene til pynt, så stadfest at ingen er aktiv. Lat OpenVPN sin eigen client-to-client vidareformidling vere avslått, fordi peer-to-peer-trafikk som aldri kryssar filteret i operativsystemet ikkje kan avgrensast av han. Den eksterne lyttaren og administrasjonsreglane blir som dei er, sidan denne endringa styrer dekryptert tunneltrafikk i staden for å bytte ut brannmuren.

Set vaktene før dei tidlege akseptane til UFW

Ei rute-tillating etterfølgd av ei avvising er ikkje nok for ei streng grense. Standard before-reglar aksepterer etablert trafikk og utvalde ICMP før nokon brukarregel blir rådført, så ein straum som vart tillaten førre veke kan bli ståande utanfor den nye avgrensinga av mål berre fordi han framleis har tilstand. Ta sikkerheitskopi av UFW-filene og hald ein out-of-band-konsoll open før du redigerer.

I seksjonen *filter i fila /etc/ufw/before.rules, erklær to kjedar ved sida av dei eksisterande erklæringane og før kvar einaste regellinje.

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

Straks etter erklæringane, og før tillatingane for inngang og vidareformidling, hopp inn i dei og definer kva dei slepp 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

Behald resten av seksjonen og COMMIT -linja hans. Å lime inn ein andre filtertabell eller slette urelaterte reglar er måten ei brannmur-endring blir eit avbrot, og fila er ein omstart unna å vere den einaste kopien som tel.

Les kva kvar vakt slepp gjennom og avviser

Den første kjedan held fram med handsaminga berre når kjelda er i poolen, målet er det eine subnettet, utgangsgrensesnittet er LAN-et og pakken fer i den opphavlege retninga av straumen sin. Alt anna som kjem frå tunnelen blir kasta, inkludert ei kjelde utanfor poolen og eitkvart mål utanfor det tillatne subnettet.

Ein peer-to-peer-pakke går inn i og ut av tun0, så han feilar på LAN-grensesnifttesten før ein målkontroll i det heile blir nådd. Nye samband frå LAN-et mot klientane feilar også på retningsretesten, noko som som standard stengjer den omvende tilbakeringingsvegen.

Målet RETURN held vanleg UFW-policy i spel. Desse kjedane filtrerer, og rute-tillatinga du legg til etterpå avgjer framleis om ein overlevande pakke blir godteken. Nettopp den skilnaden gjer det mogleg å endre det tillatne subnettet på ein stad seinare. Viss vaktene godtok pakkar direkte, måtte kvar framtidig regel leggjast til to gonger.

Tillat subnettet og steng sidedørene

Sjå førehandsvising av rute-tillatinga først, og fjern så førehandsvisinga for å bruke ho: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Deretter går du gjennom rekkjefølgja av brukarreglane, for ei tidlegare avvising vinn framleis over ei seinare tillating. Ei tillating for heile subnettet er også feil form når berre HTTPS-porten til éin vert skal vere tilgjengeleg.

Legg merke til kva inngangsdroppet gjer: tunnelklientar når ingen teneste på gatewayen sjølv, inkludert ein DNS-lyttar bunden til LAN-adressa hans. Å vere vert for DNS der krev eit medvite unntak før droppet og ein revidert tillatingskontrakt. Viss UFW administrerer IPv6, legg til tilsvarande dropp for tun0 i before6.rules også, fordi ei liste med IPv4-mål ikkje seier noko om IPv6-pakkar.

Stadfest den lasta policyen, ikkje førehandsvisinga

Sjå førehandsvising av omlastinga, bruk ho i eit vedlikehdsvindauge, og les det levande regelsettet.

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

Stadfest at tunnelvaktene kjem fram før standardtillatingane for tilstand og ICMP. Vanleg ufw status viser ikkje handredigerte before-reglar, og difor konkluderer operatørar med at ein regel manglar når han faktisk er lasta. Les den rå lista frå topp til botn i staden for å leite etter eit fragment. Viss vaktene kjem fram etter ei tilstandstillating, gjer grensa ikkje det fila antydar.

Test så åtferd og ikkje tekst. Opne eit nytt samband til ein tillaten vert og sjå på svaret, send ei uskuldig førespurnad til eit mål utanfor subnettet og stadfest at ho døyr, prøv eit peer-to-peer-samband, prøv ei teneste som er lokal på gatewayen, og prøv eit uoppfordra LAN-til-klient-samband. Ta med ein straum utanfor ramma som fanst før endringa, og fjern berre den straumen i staden for å tømme heile sporings tabellen til maskina.

Noter grensene ved sida av reglane: dette avgrensar transitt og ingenting anna. Det hindrar ikkje ein klient i å bruke sitt eige internett Samband, hindrar ikkje ein tillaten LAN-vert i å senda trafikk vidare, og erstattar ikkje autentisering inne i dei tillatne tenestene.