Bloķēt vienu OpenVPN klientu no LAN, neapturot tuneli
Piesieniet klienta tuneļa adresi pie viņa sertifikāta, nometiet viņa LAN satiksmi FORWARD sākumā, pēc tam pārbaudiet IPv6, izsekotās sesijas un izdzīvošanu pēc pārstartēšanas.
Vienam klientam jūsu OpenVPN serverī jāzaudē piekļuve LAN, kamēr visi pārējie tuneļi turpina darboties. Ja to meklēsiet, labākā atbilde parasti saka, ka dēmons to nevar, un tas ir tikai pa pusei taisnība: OpenVPN nav ugunsmūra katram klientam, bet resursdators, kas pabeidz tuneli, jau filtrē paketes. Divi svarīgākie lēmumi ir identitāte, ko bloķējat, un noteikuma pozīcija. Izdaļiet tos pareizi, un izmaiņas kļūs par vienu rindu, ko varat pārbaudīt un noņemt.
Piesieniet klientu pirms noteikuma rakstīšanas
OpenVPN iznomā tuneļa adreses no baseina, tāpēc 10.8.0.6 ir vieta, nevis persona. Kad sesija beidzas, noma atgriežas un var tikt nodota nākamajam savienojumam, tas nozīmē, ka noteikums, kas rakstīts pret šo adresi, seko vietai, nevis lietotājam. Tāpēc vispirms izlemiet, ko īsti bloķējat: adresi īsam eksperimentam vai sertifikātu kādam, ko vēlaties turēt ārpusē.
Lai piesaistītu adresi sertifikātam, izveidojiet failu direktorijā, ko norāda client-config-dir, un piešķiriet failam tieši sertifikāta common name. Ierakstiet tajā vienu direktīvu, ifconfig-push 10.8.0.6 255.255.255.0, un šis klients saglabā to pašu tuneļa adresi atkārtotos savienojumos. Lai tas darbotos, jābūt diviem iestatījumiem: client-config-dir jābūt deklarētam servera konfigurācijā, un nosūtītajai adresei jāatrodas apakštīklā, ko serveris var maršrutēt. Ja trūkst viena, fails tiek ignorēts bez kļūdas, kas padara nākamo ugunsmūra testu maldinošu.
Īslaicīgs bloķējums var izmantot baseina adresi, ja biļetē ir ierakstīts, kura sesija to toreiz turēja.
Secība nosaka, vai nomešana tiek izpildīta
Linux vārtejā, kas pārsūta starp tuneli un LAN, paketes šķērso ķēdi FORWARD. Lasiet zemāk esošo komandu kā teikumu: ievietojiet FORWARD sākumā, saskaņojiet satiksmi, kas nāk no tun0, no šī viena resursdatora, adresētu LAN apakštīklam, un nometiet to.
iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP-I ir tas, kas liek noteikumam darboties. Pievienots ar -A, tas nonāk zem jebkuras plašas atļaujas tuneļa apakštīklam un nekad neredz paketi. Pārbaudiet pozīciju ar iptables -vnL FORWARD --line-numbers un izlasiet arī skaitītājus: nomešana augšā, kas neko neskaita, nozīmē, ka satiksme nāk pa citu ceļu.
Pašas vārtejas LAN adrese ir cits ceļš. Paketes, kas sūtītas uz pašu kārbu, iet uz INPUT, nevis FORWARD, tāpēc klients var zaudēt LAN resursdatoru un tomēr atvērt maršrutētāja administrēšanas lapu. Pievienojiet atbilstošo INPUT noteikumu, kad tas ir svarīgi.
Ko filtrs nevar redzēt
Filtrēšana notiek, kad pakete tiek novērtēta, tāpēc izveidota TCP sesija var turpināties, līdz tā tiek aizvērta vai atiestatīta. Ja bloķējumam jāiedarbojas uzreiz, notīriet izsekotās plūsmas šim avotam ar conntrack -D -s 10.8.0.6 pēc noteikuma ievietošanas. Ja dažu sekunžu pārklāšanās ir pieņemama, pierakstiet šo izvēli, nevis atstājiet to netiešu. Jebkurā gadījumā nākamajam cilvēkam jāzina, vai noteikums aptur dzīvu satiksmi vai tikai jaunus savienojumus.
Satiksme starp vienaudžiem nekad nepieskaras resursdatora ugunsmūrim. Kad client-to-client ir ieslēgts, OpenVPN pārsūta šīs paketes dēmona iekšienē, tāpēc tās neredz ne FORWARD, ne INPUT. Vienīgie risinājumi ir izslēgt client-to-client vai pieņemt, ka vienaudži var viens otru sasniegt; iptables noteikums šo satiksmi neredzēs.
IPv6, programmaparatūra un izdzīvošana pēc pārstartēšanas
IPv4 noteikums neko nepasaka par IPv6. Ja tunelis un LAN pārvadā abas saimes, līdzvērtīgam noteikumam jābūt ip6tables vai nftables noteikumu kopā, kas šajā resursdatorā pārvalda politiku. Maršrutētāja programmaparatūra bieži slēpj netfilter aiz savas abstrakcijas, tāpēc no foruma kopētā sintakse un tabulu nosaukumi var nebūt piemērojami.
OpenWrt dokumentētais ceļš ir ugunsmūra konfigurācijas ieraksts, nevis ar roku rakstīta iptables rinda, un ar roku rakstīta rinda var pazust, kad ugunsmūris tiek pārlādēts. Citas distribūcijas atjauno noteikumus ar netfilter-persistent, sāknēšanas vienību vai ražotāja krātuvi, un šie mehānismi nav savstarpēji aizstājami. Pierādiet izvēlēto ar pārstartēšanu, jo pārlāde trenē citu ceļu.
Pārbaudiet pa ceļiem, tad atritiniet tīri
Pārbaudiet katru ceļu atsevišķi, jo viena veiksmīga pārbaude paslēpj pārējās. Bloķētam klientam joprojām jāsasniedz internets pa tuneli, bet jācieš neveiksme pret LAN resursdatoru, otram klientam jāsasniedz tas pats resursdators, un vārtejas adresei un vienaudža ceļam katram vajadzīgs savs novērojums. Ierakstiet rezultātus blakus noteikumam, lai nākamajām izmaiņām būtu bāze. Zemāk esošā tabula ir kopa, ko ir vērts paturēt biļetē.
| Ceļš | Gaidāms ar noteikumu | Kad tas neizdodas |
|---|---|---|
| Bloķēts klients uz LAN resursdatoru | Nav atbildes | Noteikums ir zem atļaujas, vai avots nesakrīt |
| Bloķēts klients uz internetu | Darbojas pa tun0 | Noteikums ir pārāk plašs, bez galamērķa sakritības |
| Otrs klients uz to pašu LAN resursdatoru | Darbojas | Noteikums sakrita ar vairāk nekā paredzēto resursdatoru |
| Bloķēts klients uz vārtejas LAN adresi | Bloķēts tikai ar atbilstošo INPUT noteikumu | Trūkst INPUT noteikuma |
| Bloķēts klients uz vienaudža tuneļa adresi | Joprojām darbojas | client-to-client ir ieslēgts un ārpus ugunsmūra tvēruma |
Atritināšana ir dzēšana pēc specifikācijas, nevis flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP noņem tieši to ierakstu un atstāj pārējo ķēdi neskartu. Noņemiet to pašu rindu no jebkura faila, kas atjauno noteikumus sāknēšanas laikā, pārlādējiet to un apstipriniet, ka klients atkal sasniedz LAN resursdatoru. FORWARD flush atceltu arī noteikumus, ko neesat rakstījis, un tas atritināšanu pārvērš otrajā incidentā.
Pirms biļetes aizvēršanas apstipriniet trīs lietas: piesietā adrese atbilst sertifikātam, noteikums ir virs atļaujām un skaitītājs nav nulle, un noturības failā ir tas pats noteikums, ko testējāt. Ja kaut kas no tā trūkst, bloķējums ir shell sesijas ilūzija.