Kāpēc OpenVPN klienta bloķēšanas noteikums nekad nesasniedz FORWARD

Divi klienti uz tā paša OpenVPN servera var sasniegt viens otru pat pēc tam, kad to pūlam pievienojāt DROP noteikumu. Noteikums atrodas FORWARD ķēdē, traffics acīmredzami plūst, un šī noteikuma skaitītājs paliek uz nulles. Dabiskais secinājums ir, ka ugunsmūris ir salūzis. Biežāk pakete ķēdē nemaz nav iekļuvusi.

Ir divi ceļi, pa kuriem vienādranga pakete var iet cauri OpenVPN serverim, un tos nosaka konfigurācija, nevis ugunsmūris. Zināšana, kurš ceļš tiek izmantots, pasaka, vai resursdatora noteikums vispār ir īstajā vietā.

Divi ceļi, pa kuriem var iet vienādranga pakete

Kad iekšējās pārsūtīšanas opcija ir izslēgta, pakete no klienta A ierodas tuneļa saskarnē ar galamērķi klientam B piešķirtās adreses iekšienē. Servera maršrutēšanas tabula to nosūta atpakaļ pa to pašu tuneļa saskarni, jo maršruts uz B adresi pieder serverim. Tas ir iekšā-un-ārā plūsma caur resursdatoru, un to vērtē IPv4 pārsūtīšanas ceļš.

Kad iekšējās pārsūtīšanas opcija ir ieslēgta, servera process saskaņo paketi ar pievienotu klientu un ieraksta to atpakaļ tieši tam klientam. Pakete tiek apstrādāta dēmona iekšienē un nekad vairs neieiet tuneļa ierīcē, tāpēc resursdatora pārsūtīšanas ceļš tiek pilnībā izlaists. OpenVPN 2.6 rokasgrāmata apraksta šo opciju kā iekšēju pārsūtīšanu no klienta uz klientu, un tieši tāpēc resursdatora ugunsmūra noteikums to nevar redzēt.

Pastāv trešais variants izvietojumos, kas datu kanālu pārceļ uz kodola moduli. Pārsūtīšanas lēmums un šifrēšana iziet no lietotāja telpas, un tas, vai netfilter redz plūsmu, ir atkarīgs no tā, kā uzbūvēts pārcelšanas ceļš. Nekad nepieņemiet, ka vecs noteikumu kopums uz pārcelta servera uzvedas tāpat kā uz servera lietotāja telpā. Apstipriniet režīmu no darbojošās konfigurācijas, nevis no pakotnes versijas.

Kad skaitītājs nekad nekustas

Nulles skaitītājs nozīmē, ka pakete tajā punktā neatbilda šim noteikumam, un iemesli ir vairāki. Pirmais ir iepriekš aprakstītā apiešana: traffics ķēdi nemaz nesasniedza. Otrais ir nesakritība saskarnē, virzienā, avotā vai galamērķī, kas ir parasta parādība, kad pūls tiek pārnumurēts un noteikums joprojām nosauc veco prefiksu.

Trešais ir pozīcija. Agrāks noteikums ķēdē var pieņemt plūsmu pirms jūsu DROP tiek novērtēts, un vēlāks noteikums var būt tas, kas faktiski izšķir rezultātu. Lasiet ķēdi secīgi ar redzamiem skaitītājiem, pēc tam pārbaudiet, kuram noteikumam skaits pieaug, kad atkārtojat testu.

Veiciet vienu kontrolētu apmaiņu starp diviem klientiem, kuru īstās adreses esat apstiprinājis no paša servera stāvokļa, nevis no atmiņā palikušas nomās. Ja attiecīgais skaitītājs joprojām nekustas, aizdomīgi par ceļu, pirms pārrakstīt atbilstību. Ja tas kustas, bet savienojums joprojām izdodas, drop tiek vēlāk pārspēts un problēma ir secībā. Šī atbilde nosaka, vai labojums ir noteikuma maiņa vai topoloģijas maiņa, tāpēc iegūstiet to pirms kaut ko rediģējat.

Izvēlēties robežu, kas spēj filtrēt

Ja politikai jādzīvo resursdatora ugunsmūrī, lieciet traffiku tur, kur ugunsmūris to var redzēt. Iekšējās pārsūtīšanas izslēgšana ir atbalstītais veids, kā likt vienādranga trafikam iet caur tuneļa saskarni un pārsūtīšanas ceļu, par cenu, ka katra vienādranga pakete iet caur resursdatora steku.

Pēc tam precīzi saskaņojiet plūsmu. Traffics ienāk tuneļa saskarnē un iziet pa tuneļa saskarni, abos virzienos, tāpēc noteikumi, kas ņem vērā tikai fizisko saskarni, nesaskanēs. Adresēs balstītiem noteikumiem vajadzīgs pašreizējais pūls, un tiem jāņem vērā arī atgriešanās virziens, ne tikai uz priekšu.

Daudzos izvietojumos labāk kalpo filtrēšana klienta vai grupas līmenī, kur identitāte ir zināma un politika seko lietotājam, nevis adresei, kas mainās atkārtotas savienošanas laikā. Tas ir cits mehānisms nekā resursdatora ķēde, un abus nevajadzētu jaukt bez skaidra iemesla.

Nepārnesiet vecas topoloģijas noteikumu kopumu pāri migrācijai bez izmaiņām. Adrešu pūli, saskarņu nosaukumi un pārsūtīšanas režīmi visi ietekmē to, vai noteikums sakrīt, un nokopēts noteikums, kas agrāk strādāja, ir visvairāk maldinošais pierādījumu veids. Sāciet ar plūsmu, kuru vēlaties atļaut, un ierakstiet tai atbilstošu noteikumu.

Testēt izolāciju, nevis paļauties uz noteikumu

Pārbaudiet aizliegto gadījumu un atļauto gadījumu vienā palaidē. Sāciet jaunu savienojumu no viena klienta uz otru un apstipriniet, ka tas neizdodas, pēc tam apstipriniet, ka savienojums, kuram jābūt atļautam, joprojām darbojas. Ja pārbauda tikai pirmo, ugunsmūris, kas bloķē visu, izskatās kā panākums.

Atkārtojiet pēc servera konfigurācijas pārlādes un pēc tam, kad klients atkārtoti pieslēdzas, jo iekšējā pārsūtīšana un pūlu piešķiršana ir izpildes laika stāvoklis. Pārbaudiet skaitītājus abos virzienos, jo noteikums, kas sakrīt ar vienu virzienu un nesakrīt ar atbildi, rada daļēju izolāciju, ko ātrā testā ir grūti pamanīt.

Izolācija ir novērotais rezultāts pie robežas, kas faktiski nes plūsmu. DROP noteikums kaut kur resursdatorā nav pierādījums; neizdevies savienojums un tā izraisītā noteikuma pakustinātais skaitītājs ir pierādījums.