Ühe OpenVPN-kliendi blokeerimine LAN-ist ilma tunnelit peatamata
Kinnitage kliendi tunneli aadress tema sertifikaadi külge, visake tema LAN-liiklus FORWARD-i algusesse ja seejärel kontrollige IPv6-t, jälgitud sessioone ja taaskäivituse üleelamist.
Üks klient teie OpenVPN serveris peab kaotama LAN-juurdepääsu, samal ajal kui kõik teised tunnelid jäävad tööle. Kui seda otsida, ütleb parim vastus tavaliselt, et deemon ei saa seda teha, mis on ainult pool tõde: OpenVPN-il pole kliendipõhist tulemüüri, kuid host, mis tunneli lõpetab, juba filtreerib pakette. Kaks otsust, mis loevad, on identiteet, mille blokeerite, ja reegli asukoht. Tee need õigesti ja muudatusest saab üks rida, mida saab testida ja eemaldada.
Kinnitage klient enne reegli kirjutamist
OpenVPN rendib tunneli aadresse basseinist, seega 10.8.0.6 on koht, mitte inimene. Kui sessioon lõpeb, naaseb rent ja selle võib anda järgmisele ühendusele, mis tähendab, et selle aadressi vastu kirjutatud reegel järgib kohta, mitte kasutajat. Otsustage kõigepealt, mida te tegelikult blokeerite: aadress lühikese katse jaoks või sertifikaat kellegi jaoks, keda tahate väljas hoida.
Aadressi sertifikaadi külge sidumiseks looge fail kataloogi, mille nimi on client-config-dir, ja andke failile täpselt sertifikaadi common name. Pange sinna üks direktiiv, ifconfig-push 10.8.0.6 255.255.255.0, ja see klient hoiab sama tunneli aadressi ka taasühendustel. Selle mõju saavutamiseks peavad olemas olema kaks seadet: client-config-dir peab olema serveri konfiguratsioonis deklareeritud ja saadetav aadress peab asuma alamvõrgus, mida server suudab marsruutida. Kui üks puudub, jäetakse fail veata tähelepanuta, mis teeb järgmise tulemüüri testi eksitavaks.
Ajutine blokeering võib kasutada basseini aadressi, kui pilet fikseerib, milline sessioon seda tol hetkel hoidis.
Järjekord otsustab, kas viskamine käivitub
Linuxi lüüsil, mis edastab tunneli ja LAN-i vahel, läbivad paketid ahela FORWARD. Lugege allolevat käsku lausena: sisestage FORWARD algusesse, sobitage liiklus, mis siseneb tun0-st, ainult sellelt hostilt, suunatud LAN-i alamvõrku, ja visake see ära.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP-I on see, mis paneb reegli tööle. -A-ga lisatuna maandub see tunneli alamvõrgu mis tahes laia lubamise alla ega näe kunagi paketti. Kontrollige asukohta käsuga iptables -vnL FORWARD --line-numbers ja lugege ka loendureid: üleval olev viskamine, mis ei loe midagi, tähendab, et liiklus saabub teist teed.
Lüüsi enda LAN-aadress on teine tee. Kasti enda poole saadetud paketid lähevad INPUT-i, mitte FORWARD-i, seega võib klient kaotada LAN-hosti ja siiski avada ruuteri halduslehe. Lisage vastav INPUT reegel, kui see loeb.
Mida filter ei näe
Filtreerimine toimub paketi hindamisel, seega võib loodud TCP-sessioon jätkuda, kuni see suletakse või lähtestatakse. Kui blokeering peab kohe hammustama, tühjendage selle allika jälgitud vood käsuga conntrack -D -s 10.8.0.6 pärast reegli lisamist. Kui mõne sekundi kattuvus on vastuvõetav, kirjutage see valik üles, selle asemel et jätta see kaudseks. Igal juhul peab järgmine inimene teadma, kas reegel peatab elava liikluse või ainult uued ühendused.
Võrdsete vaheline liiklus ei puuduta kunagi hosti tulemüüri. Kui client-to-client on lubatud, edastab OpenVPN need paketid deemoni sees, seega ei näe neid ei FORWARD ega INPUT. Ainsad lahendused on client-to-client välja lülitada või nõustuda, et võrdsed võivad üksteiseni jõuda; iptables-reegel ei näe seda liiklust.
IPv6, püsivara ja taaskäivituse üleelamine
IPv4 reegel ei ütle IPv6 kohta midagi. Kui tunnel ja LAN kannavad mõlemat perekonda, peab samaväärne reegel olemas olema ip6tables-is või nftables-i reeglistikus, mis sellel hostil poliitikat omab. Ruuteri püsivara peidab netfilteri sageli oma abstraktsiooni taha, seega foorumist kopeeritud süntaks ja tabelinimed ei pruugi kehtida.
OpenWrt-is on dokumenteeritud tee tulemüüri konfiguratsioonikirje, mitte käsitsi kirjutatud iptables-rida, ja käsitsi kirjutatud rida võib tulemüüri uuesti laadimisel kaduda. Teised distributsioonid taastavad reeglid netfilter-persistent-i, alglaadimisüksuse või tootja hoidla kaudu ning need mehhanismid ei ole vahetatavad. Tõestage valitut taaskäivitusega, sest uuesti laadimine harjutab teist teed.
Kontrollige tee kaupa, seejärel kerige puhtalt tagasi
Testige iga teed eraldi, sest üks edukas kontroll varjab teised. Blokeeritud klient peaks tunnelist endiselt internetti jõudma, kuid LAN-hosti vastu ebaõnnestuma, teine klient peaks samasse hosti jõudma ning lüüsi aadress ja võrdse tee vajavad kumbki oma vaatlust. Kirjutage tulemused reegli kõrvale, et järgmisel muudatusel oleks baasjoon. Allolev tabel on kogum, mida tasub piletisse jätta.
| Tee | Oodatav reegliga | Kui see ebaõnnestub |
|---|---|---|
| Blokeeritud klient LAN-hosti poole | Vastust pole | Reegel on lubamise all või allikas ei sobitu |
| Blokeeritud klient internetti | Töötab läbi tun0 | Reegel on liiga lai, sihtkoha sobivuseta |
| Teine klient samasse LAN-hosti | Töötab | Reegel sobis rohkem kui kavatsetud host |
| Blokeeritud klient lüüsi LAN-aadressi poole | Blokeeritud ainult vastava INPUT-reegliga | INPUT-reegel puudub |
| Blokeeritud klient võrdse tunneli aadressi poole | Töötab endiselt | client-to-client on lubatud ja väljaspool tulemüüri ulatust |
Tagasikerimine on spetsifikatsiooni järgi kustutamine, mitte flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP eemaldab täpselt selle kirje ja jätab ülejäänud ahela puutumata. Eemaldage sama rida failist, mis taastab reeglid alglaadimisel, laadige see uuesti ja kinnitage, et klient jõuab jälle LAN-hostini. FORWARD flushimine tühistaks ka reeglid, mida te ei kirjutanud, mis muudab tagasikerimise teiseks intsidendiks.
Enne pileti sulgemist kinnitage kolm asja: kinnitatud aadress vastab sertifikaadile, reegel asub lubamiste kohal ja loendur ei ole null ning püsivusfail sisaldab sama reeglit, mida testisite. Kui midagi neist puudub, on blokeering shell-sessiooni illusioon.