Blokirati jednog OpenVPN klijenta iz LAN-a bez zaustavljanja tunela
Pričvrstite tunelsku adresu klijenta na njegov certifikat, odbacite njegov LAN promet na čelu FORWARD, zatim provjerite IPv6, praćene sesije i preživljavanje ponovnog pokretanja.
Jedan klijent na vašem OpenVPN poslužitelju mora izgubiti pristup LAN-u dok svi ostali tuneli ostaju aktivni. Ako to tražite, najbolji odgovor obično kaže da to demon ne može, što je samo napola točno: OpenVPN nema vatrozid po klijentu, ali host koji završava tunel već filtrira pakete. Dvije odluke koje su važne su identitet koji blokirate i položaj pravila. Učinite ih ispravno i promjena postaje jedan redak koji možete testirati i ukloniti.
Pričvrstite klijenta prije nego napišete pravilo
OpenVPN iznajmljuje tunelske adrese iz skupa, pa je 10.8.0.6 sjedalo, a ne osoba. Kad sesija završi, najam se vraća i može se dati sljedećoj vezi, što znači da pravilo napisano protiv te adrese slijedi sjedalo, a ne korisnika. Zato prvo odlučite što zapravo blokirate: adresu za kratki pokus ili certifikat za nekoga koga želite držati vani.
Da biste adresu vezali uz certifikat, stvorite datoteku u mapi koju imenuje client-config-dir i dajte datoteci točno common name certifikata. Stavite u nju jednu direktivu, ifconfig-push 10.8.0.6 255.255.255.0, i taj klijent zadržava istu tunelsku adresu između ponovnih spajanja. Dvije postavke moraju postojati da bi to djelovalo: client-config-dir mora biti deklariran u konfiguraciji poslužitelja, a gurnuta adresa mora biti u podmreži koju poslužitelj može usmjeravati. Ako jedno nedostaje, datoteka se ignorira bez pogreške, što sljedeći test vatrozida čini zavaravajućim.
Privremena blokada može koristiti adresu iz skupa, dokle god zahtjev bilježi koja je sesija tada držala tu adresu.
Redoslijed odlučuje hoće li se odbacivanje izvršiti
Na Linux prolazu koji prosljeđuje između tunela i LAN-a paketi prolaze kroz lanac FORWARD. Pročitajte naredbu ispod kao rečenicu: umetni na čelo FORWARD, uskladi promet koji ulazi iz tun0, s tog jednog hosta, upućen u podmrežu LAN-a, i odbaci ga.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP-I je ono što pokreće pravilo. Dodano s -A, pada ispod bilo kakvog širokog dopuštenja za tunelsku podmrežu i nikad ne vidi paket. Provjerite položaj s iptables -vnL FORWARD --line-numbers i pročitajte i brojače: odbacivanje na vrhu koje ništa ne broji znači da promet dolazi drugim putem.
Vlastita LAN adresa prolaza je drugi put. Paketi poslani samom uređaju idu u INPUT, a ne u FORWARD, pa klijent može izgubiti LAN host i ipak otvoriti administratorsku stranicu usmjerivača. Dodajte odgovarajuće pravilo INPUT kad je to važno.
Što filtar ne može vidjeti
Filtriranje se događa kad se paket vrednuje, pa uspostavljena TCP sesija može trajati dok se ne zatvori ili poništi. Ako blokada mora djelovati odmah, očistite praćene tokove tog izvora s conntrack -D -s 10.8.0.6 nakon što pravilo uđe. Ako je nekoliko sekundi preklapanja prihvatljivo, zabilježite taj odabir umjesto da ga ostavite implicitnim. U svakom slučaju, sljedeća osoba mora znati zaustavlja li pravilo živi promet ili samo nove veze.
Promet između partnera nikad ne dotiče vatrozid hosta. Kad je client-to-client omogućen, OpenVPN prosljeđuje te pakete unutar demona, pa ih ni FORWARD ni INPUT ne vide. Jedina rješenja su isključiti client-to-client ili prihvatiti da partneri mogu dosegnuti jedan drugoga; pravilo iptablesa neće vidjeti taj promet.
IPv6, firmware i preživljavanje ponovnog pokretanja
Pravilo IPv4 ne govori ništa o IPv6. Ako tunel i LAN nose obje obitelji, ekvivalentno pravilo mora postojati u ip6tables ili u skupu pravila nftablesa koji posjeduje politiku na tom hostu. Firmware usmjerivača često skriva netfilter iza vlastite apstrakcije, pa se sintaksa i nazivi tablica kopirani s foruma možda neće primijeniti.
Na OpenWrt-u je dokumentirani put unos konfiguracije vatrozida, a ne rukom napisan redak iptablesa, i rukom napisan redak može nestati kad se vatrozid ponovno učita. Druge distribucije vraćaju pravila kroz netfilter-persistent, boot jedinicu ili pohranu proizvođača, i ti mehanizmi nisu zamjenjivi. Dokažite odabrani ponovnim pokretanjem, jer ponovno učitavanje uvježbava drugi put.
Provjerite po putu, zatim se čisto vratite
Testirajte svaki put zasebno, jer jedna uspješna provjera skriva ostale. Blokirani klijent trebao bi i dalje dosezati internet kroz tunel, ali padati prema LAN hostu, drugi klijent trebao bi dosezati taj isti host, a adresa prolaza i put prema partneru trebaju svaki svoje promatranje. Zapišite rezultate uz pravilo da bi sljedeća promjena imala osnovicu. Tablica ispod je skup koji je vrijedno zadržati u zahtjevu.
| Put | Očekivano s pravilom | Kad zakaže |
|---|---|---|
| Blokirani klijent prema LAN hostu | Nema odgovora | Pravilo je ispod dopuštenja ili se izvor ne podudara |
| Blokirani klijent prema internetu | Radi kroz tun0 | Pravilo je preširoko, bez podudaranja odredišta |
| Drugi klijent prema istom LAN hostu | Radi | Pravilo se podudarilo s više od predviđenog hosta |
| Blokirani klijent prema LAN adresi prolaza | Blokirano samo s odgovarajućim pravilom INPUT | Nedostaje pravilo INPUT |
| Blokirani klijent prema tunelskoj adresi partnera | Još uvijek radi | client-to-client je omogućen i izvan dosega vatrozida |
Vraćanje je brisanje po specifikaciji, a ne flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP uklanja točno taj unos i ostavlja ostatak lanca netaknutim. Uklonite isti redak iz datoteke koja vraća pravila pri podizanju, ponovno je učitajte i potvrdite da klijent opet doseže LAN host. Flush FORWARD poništio bi i pravila koja niste napisali, što vraćanje pretvara u drugi incident.
Prije zatvaranja zahtjeva potvrdite tri stvari: pričvršćena adresa odgovara certifikatu, pravilo je iznad dopuštenja s brojačem različitim od nule i datoteka postojanosti sadrži isto pravilo koje ste testirali. Ako nešto od toga nedostaje, blokada je iluzija u shell sesiji.