Blokirati enega odjemalca OpenVPN iz LAN brez zaustavitve tunela
Pripnite naslov tunela odjemalca na njegovo potrdilo, zavrzite njegov promet LAN na čelu FORWARD in nato preverite IPv6, sledene seje in preživetje po ponovnem zagonu.
En odjemalec na vašem strežniku OpenVPN mora izgubiti dostop do LAN, medtem ko vsi drugi tuneli ostanejo aktivni. Če to poiščete, najboljši odgovor običajno pravi, da demon tega ne zmore, kar je le pol resnice: OpenVPN nima požarnega zidu za vsakega odjemalca, a gostitelj, ki tunel zaključi, že filtrira pakete. Dve odločitvi, ki štejeta, sta identiteta, ki jo blokirate, in položaj pravila. Naredite ju pravilno in sprememba postane ena vrstica, ki jo lahko preizkusite in odstranite.
Pripnite odjemalca, preden napišete pravilo
OpenVPN daje naslove tunela v najem iz nabora, zato je 10.8.0.6 sedež, ne oseba. Ko se seja konča, se najem vrne in se lahko dodeli naslednji povezavi, kar pomeni, da pravilo, napisano proti temu naslovu, sledi sedežu, ne uporabniku. Zato najprej odločite, kaj v resnici blokirate: naslov za kratek poskus ali potrdilo za nekoga, ki ga želite držati zunaj.
Če želite naslov povezati s potrdilom, ustvarite datoteko v imeniku, ki ga navaja client-config-dir, in ji dajte točno common name potrdila. Vanjo vstavite eno direktivo, ifconfig-push 10.8.0.6 255.255.255.0, in ta odjemalec ob ponovni povezavi obdrži isti naslov tunela. Za to morata obstajati dve nastavitvi: client-config-dir mora biti deklariran v konfiguraciji strežnika, poslani naslov pa mora ležati v podomrežju, ki ga strežnik lahko usmerja. Če ena manjka, se datoteka prezre brez napake, kar naredi naslednji preizkus požarnega zidu zavajajoč.
Začasna blokada lahko uporabi naslov iz nabora, če zahtevek zabeleži, katera seja ga je takrat imela.
Vrstni red odloči, ali se zavrženje izvede
Na prehodu Linux, ki posreduje med tunelom in LAN, paketi prečijo verigo FORWARD. Preberite ukaz spodaj kot stavek: vstavi na čelo FORWARD, ujemi promet, ki vstopa iz tun0, s tega enega gostitelja, naslovljen v podomrežje LAN, in ga zavrzi.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROPPrav -I poskrbi, da pravilo teče. Dodano z -A, pristane pod vsako široko odobritvijo za podomrežje tunela in nikoli ne vidi paketa. Preverite položaj z iptables -vnL FORWARD --line-numbers in preberite tudi števce: zavrženje na vrhu, ki nič ne šteje, pomeni, da promet prihaja po drugi poti.
Lasten naslov LAN prehoda je druga pot. Paketi, poslani sami škatli, gredo v INPUT, ne v FORWARD, zato lahko odjemalec izgubi gostitelja v LAN in vseeno odpre skrbniško stran usmerjevalnika. Ko je to pomembno, dodajte ustrezno pravilo INPUT.
Česa filter ne more videti
Filtriranje se zgodi ob oceni paketa, zato se lahko vzpostavljena seja TCP nadaljuje, dokler se ne zapre ali ponastavi. Če mora blokada prijeti takoj, počistite sledene tokove za ta vir z conntrack -D -s 10.8.0.6, potem ko je pravilo vstavljeno. Če je nekaj sekund prekrivanja sprejemljivih, zapišite to izbiro, namesto da bi ostala implicitna. Kakorkoli, naslednja oseba mora vedeti, ali pravilo ustavi živi promet ali le nove povezave.
Promet med vrstniki se nikoli ne dotakne požarnega zidu gostitelja. Ko je client-to-client omogočen, OpenVPN te pakete posreduje znotraj demona, zato jih ne vidita niti FORWARD niti INPUT. Edini rešitvi sta izklop client-to-client ali sprejetje, da lahko vrstniki dosežejo drug drugega; pravilo iptables tega prometa ne bo videlo.
IPv6, vdelana programska oprema in preživetje po ponovnem zagonu
Pravilo IPv4 ne pove nič o IPv6. Če tunel in LAN prenašata obe družini, mora enakovredno pravilo obstajati v ip6tables ali v naboru pravil nftables, ki ima na tem gostitelju politiko. Vdelana programska oprema usmerjevalnika pogosto skrije netfilter za lastno abstrakcijo, zato se sintaksa in imena tabel, kopirani s foruma, morda ne uporabljajo.
Na OpenWrt je dokumentirana pot vnos konfiguracije požarnega zidu in ne ročno napisana vrstica iptables, ročno napisana vrstica pa lahko izgine ob ponovnem nalaganju požarnega zidu. Druge distribucije obnovijo pravila prek netfilter-persistent, zagonske enote ali shrambe proizvajalca in ti mehanizmi niso zamenljivi. Dokažite izbranega s ponovnim zagonom, ker ponovno nalaganje vadi drugo pot.
Preverite po poteh, nato čisto povrnite
Preizkusite vsako pot posebej, ker en uspešen pregled skrije druge. Blokiran odjemalec mora še vedno doseči internet po tunelu, a spodleteti proti gostitelju v LAN, drugi odjemalec mora doseči istega gostitelja, naslov prehoda in pot do vrstnika pa potrebujeta vsak svoje opazovanje. Zapišite rezultate ob pravilo, da ima naslednja sprememba osnovo. Spodnja tabela je nabor, ki ga je vredno obdržati v zahtevku.
| Pot | Pričakovano s pravilom | Ko spodleti |
|---|---|---|
| Blokiran odjemalec do gostitelja v LAN | Ni odgovora | Pravilo je pod odobritvijo ali vir se ne ujema |
| Blokiran odjemalec do interneta | Deluje prek tun0 | Pravilo je preširoko, brez ujemanja cilja |
| Drugi odjemalec do istega gostitelja v LAN | Deluje | Pravilo se je ujemalo z več kot predvidenim gostiteljem |
| Blokiran odjemalec do naslova LAN prehoda | Blokirano le z ustreznim pravilom INPUT | Pravilo INPUT manjka |
| Blokiran odjemalec do naslova tunela vrstnika | Še vedno deluje | client-to-client je omogočen in zunaj dosega požarnega zidu |
Povrnitev je brisanje po specifikaciji, ne flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP odstrani točno ta vnos in pusti preostanek verige nedotaknjen. Odstranite isto vrstico iz datoteke, ki ob zagonu obnovi pravila, jo znova naložite in potrdite, da odjemalec spet doseže gostitelja v LAN. Flush FORWARD bi razveljavil tudi pravila, ki jih niste napisali, kar povrnitev spremeni v drugi incident.
Preden zaprete zahtevek, potrdite tri stvari: pripeti naslov se ujema s potrdilom, pravilo je nad odobritvami s števcem, ki ni nič, in datoteka obstojnosti vsebuje isto pravilo, ki ste ga preizkusili. Če kaj od tega manjka, je blokada iluzija v seji lupine.