Omejiti prehod OpenVPN na eno lokalno omrežje s pravili UFW
Dovolite klientom tunela, da dosežejo eno podomrežje in nič drugega. Varovalne verige pred zgodnjimi sprejetji UFW, dovoljenje poti in testi, ki dokažejo mejo.
Odločite o dovoljenju, preden odprete datoteko požarnega zidu: overjeni odjemalci lahko odpirajo povezave do enega določenega podomrežja, prehod pa mora zavrniti vsako drugo tranzitno pot, tudi ko odjemalec namesti dodatne poti. Ta stavek je zasnova in vsako pravilo spodaj obstaja zato, da jo uveljavi. Karkoli širšega, na primer ves zasebni naslovni prostor, izhod v internet skozi tunel ali promet med enakimi vozlišči, je druga zasnova, ki potrebuje svojo odločitev. Pravila so tudi namenoma dolgočasna, ker je pameten požarni zid tisti, ki ga pozneje nihče ne more pregledati.
Najprej zapišite topologijo in dovoljenje
Primer uporablja strežnik Community OpenVPN z napravo TUN v uporabniškem prostoru z imenom tun0, nabor odjemalcev 10.77.0.0/24, in eno priključeno podomrežje 192.168.60.0/24 na lan0. Posredovanje IPv4 že deluje in lokalno omrežje že ima povratno pot v nabor, zato tukaj nič ni odvisno od prevajanja med njima.
Požarni zid na tem gostitelju upravlja UFW in noben nabor pravil v vsebniku niti ločena tabela nftables ne sme namestiti zgodnejše poti sprejema. Bližnjica za razbremenitev toka, ki preskoči filter, bi varovalne verige naredila zgolj okrasne, zato potrdite, da nobena ni dejavna. Pustite lastno posredovanje client-to-client OpenVPN izklopljeno, ker prometa med enakimi vozlišči, ki nikoli ne prečka filtra operacijskega sistema, ni mogoče omejiti z njim. Zunanji poslušalec in administrativna pravila ostanejo takšna, kot so, saj ta sprememba ureja dešifriran promet tunela, namesto da bi zamenjala požarni zid.
Postavite varovala pred zgodnja sprejetja UFW
Dovoljenje poti, ki mu sledi zavrnitev, ne zadošča za strogo mejo. Standardna pravila before sprejmejo vzpostavljen promet in nekatere ICMP, preden se upošteva katero koli uporabniško pravilo, zato lahko tok, dovoljen prejšnji teden, ostane zunaj nove omejitve cilja samo zato, ker ima še vedno stanje. Naredite varnostno kopijo datotek UFW in pred urejanjem imejte odprto konzolo zunaj pasu.
V razdelku *filter datoteke /etc/ufw/before.rules razglasite dve verigi poleg obstoječih deklaracij in pred katero koli vrstico pravila.
:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]Takoj za deklaracijami in pred dovoljenji za vhod in posredovanje skočite vanje in določite, kaj spustijo skozi.
-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 DROPObdržite preostanek razdelka in njegovo vrstico COMMIT. Prilepitev druge tabele filtra ali brisanje nepovezanih pravil je način, kako sprememba požarnega zidu postane izpad, datoteka pa je eno ponovno zaganjanje oddaljena od tega, da bi bila edina kopija, ki šteje.
Preberite, kaj vsako varovalo spusti skozi in zavrne
Prva veriga nadaljuje obdelavo le, kadar je vir v naboru, cilj je tisto eno podomrežje, izhodni vmesnik je lokalno omrežje in paket potuje v prvotni smeri svojega toka. Vse drugo, kar pride iz tunela, se zavrže, vključno z virom zunaj nabora in katerim koli ciljem onkraj dovoljenega podomrežja.
Paket med enakimi vozlišči vstopi in izstopi skozi tun0, zato ne prestane preskusa vmesnika lokalnega omrežja še preden se doseže preverjanje cilja. Tudi nove povezave iz lokalnega omrežja proti odjemalcem ne prestanejo preskusa smeri odgovora, kar privzeto zapre obratno pot povratnega klica.
Cilj RETURN ohranja običajno politiko UFW v veljavi. Te verige filtrirajo, dovoljenje poti, ki ga dodate zatem, pa še vedno odloča, ali bo preživeli paket sprejet. Prav ta ločitev vam pozneje omogoči, da dovoljeno podomrežje spremenite na enem mestu. Če bi varovala pakete sprejela neposredno, bi bilo treba vsako prihodnje pravilo dodati dvakrat.
Dovolite podomrežje in zaprite stranska vrata
Najprej predoglejte dovoljenje poti, nato odstranite zastavico predogleda, da ga uporabite: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Zatem pregledajte vrstni red uporabniških pravil, ker zgodnejša zavrnitev še vedno premaga poznejše dovoljenje. Dovoljenje za celotno podomrežje je tudi napačna oblika, ko mora biti dosegljiva le vrata HTTPS enega gostitelja.
Opazite, kaj naredi zavrženje vhoda: odjemalci tunela ne dosežejo nobene storitve na samem prehodu, vključno s poslušalcem DNS, vezanim na njegov naslov v lokalnem omrežju. Gostovanje DNS tam zahteva namerno izjemo pred zavrženjem in pregledano dovoljenjsko pogodbo. Če UFW upravlja IPv6, dodajte ustrezna zavrženja tudi za tun0 v datoteki before6.rules, ker seznam ciljev IPv4 ne pove ničesar o paketih IPv6.
Preverite naloženo politiko, ne predogleda
Predoglejte ponovno nalaganje, uporabite ga v vzdrževalnem oknu in preberite živi nabor pravil.
sudo ufw --dry-run reload
sudo ufw show rawPotrdite, da se varovala tunela pojavijo pred privzetimi dovoljenji za stanje in ICMP. Navaden ufw status ne prikazuje ročno urejenih pravil before, zato operaterji sklepajo, da pravilo manjka, ko je v resnici naloženo. Preberite surov seznam od zgoraj navzdol, namesto da bi iskali odlomek. Če se varovala pojavijo po dovoljenju za stanje, meja ne dela tega, kar nakazuje datoteka.
Nato preizkusite vedenje, ne besedila. Odprite novo povezavo do dovoljenega gostitelja in opazujte odgovor, usmerite neškodljivo zahtevo na cilj zunaj podomrežja in potrdite, da umre, poskusite povezavo med enakimi vozlišči, poskusite storitev, lokalno na prehodu, in poskusite nezaželeno povezavo iz lokalnega omrežja proti odjemalcu. Vključite en tok zunaj obsega, ki je obstajal pred spremembo, in počistite samo ta tok, namesto da bi izpraznili celotno sledilno tabelo stroja.
Zapišite omejitve ob pravilih: to omejuje tranzit in nič drugega. Ne preprečuje odjemalcu uporabe lastne internetne povezave, ne preprečuje dovoljenemu gostitelju v lokalnem omrežju posredovanja prometa naprej in ne nadomešča overjanja znotraj dovoljenih storitev.