Har bir VPN mijoz hovuzi uchun bitta manzil oralig‘ini bloklash
Bitta nftables qoidasi ruxsat etilgan VPN hovuzi uchun manzil prefiksini shlyuzning o‘z trafigiga tegmasdan rad eta oladi. Hook va joylashuvni moslashtiring.
Bitta qoida ruxsat etilgan VPN hovuzini manzil oralig‘idan uzoqda ushlab tura oladi, shlyuz qiladigan boshqa hech narsaga xalal bermasdan. Qoidaning o‘zi qisqa; uning ishlashini hook — u yashaydigan joy — va zanjirdagi joylashuvi hal qiladi. Bu ikkisida xato qilsangiz, to‘g‘ri ko‘rinadigan, lekin nomuvofiq ishlaydigan xavfsizlik devori olasiz. Qoida paketni ko‘rganda paket nima qilayotganidan boshlang.
Qoida aslida nimani moslashtiradi
Qoida bir vaqtda uch narsani moslashtiradi: kiruvchi interfeys, manba prefiksi va manzil prefiksi. Drop qo‘llanishidan oldin uchtasi ham to‘g‘ri bo‘lishi kerak, va shu uni tor saqlaydi. Uni uchta alohida siyosat sifatida o‘qishdan ko‘ra bitta ifoda sifatida o‘qish osonroq.
Interfeys mosligi yo‘naltirilgan mijoz trafigini shlyuzning o‘z ulanishlaridan ajratadi. Usiz faqat manba hovuzini ko‘rsatuvchi qoida shlyuzning o‘zi o‘sha manzildan yaratadigan paketlariga ham ta’sir qilardi, agar bu qachondir sodir bo‘lsa. Manba prefiksi siyosatni ruxsat etilgan mijozlar bilan, manzil prefiksi esa uni bitta oraliq bilan cheklaydi. Qoidani ro‘yxat emas, kesishma sifatida o‘qing.
Biror narsani o‘zgartirishdan oldin uchta qiymatni yozib qo‘ying: tunnel interfeysining nomi, server tarqatadigan hovuz va rad qilmoqchi bo‘lgan prefiks. Ulardan birida xato bo‘lsa, toza tahlil qilinadigan, lekin hech narsani himoya qilmaydigan qoida hosil bo‘ladi. Bu uch qiymatni qoida yonidagi o‘zgarish yozuvida saqlang.
Hook qoida kimga taalluqli ekanini hal qiladi
netfilter zanjiri hookka bog‘lanadi, va qaysi paketlarni zanjir ko‘rishini hook hal qiladi. forward hook shlyuz orqali yo‘naltiriladigan trafikni ko‘radi, bu esa mijozdan manzilga ketayotgan trafikdir. Zanjirdagi qolgan hamma narsa boshqa auditoriyaga qaratilgan.
input hook shlyuzning o‘ziga murojaat qilingan trafikni ko‘radi, shuning uchun u yerda qo‘yilgan qoida tranzitni emas, uning o‘z xizmatlariga kirishni boshqaradi. output hook shlyuzning o‘zi yaratadigan trafikni ko‘radi, bu esa mijoz hovuzi siyosatiga kerak bo‘lgan narsaning aksi. Zanjir nomlari qoidalar to‘plamini yozgan kishi tanlagan ixtiyoriy belgilar, shuning uchun hookni nomdan chiqarmang. Zanjir qayerga bog‘langanini tekshiring, keyin u nimalarni moslashtira olishini taxmin qiling.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
Bog‘lanishni o‘qish — bir qatorli tekshiruv, u qoidaning paketni hech qachon ko‘rmaydigan zanjirga tushishini oldini oladi.
Qoidani keng acceptdan oldin joylashtiring
Qoidalar tartib bilan baholanadi va birinchi hukm g‘alaba qozonadi. Zanjirda oldinroq turgan keng accept o‘zi moslashtirgan paketlar uchun baholashni tugatadi, shuning uchun keyin qo‘shilgan drop ular uchun hech qachon ishlamaydi. Aynan shu tartib qoidasi to‘g‘ri ko‘rinadigan qoidaning hech qanday ta’siri bo‘lmasligining to‘liq sababidir.
Qoidani oxiriga qo‘shish o‘rniga acceptdan oldin kiriting. Agar zanjirda tunnel interfeysi uchun umumiy accept allaqachon bo‘lsa, yangi qoida undan oldin turishi kerak, aks holda u faqat bezak. Tahrirlagan faylingizni emas, hosil bo‘lgan tartibni tekshiring, chunki bir nechta fayldan yig‘ilgan qoidalar to‘plami ularning birortasiga ham mos kelmasligi mumkin. So‘ngra hovuzdan olingan sinov paketi bilan tasdiqlang.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf
Uchinchi buyruq faylni qo‘llamasdan tahlil qiladi, bu sintaksis xatolarini uzilishga aylanishidan oldin ushlaydi. Orqaga qaytarish rejasi bilan qo‘llang, chunki forward zanjiridagi noto‘g‘ri qoida siz ishlayotgan tunnelni kesib qo‘yishi mumkin.
Mavjud oqimlar yangi qoidangizga parvo qilmaydi
Qoida paydo bo‘lishidan oldin yaratilgan conntrack yozuvi avvalgi acceptga mos kelaveradi. Shuning uchun yangi drop ba’zan yangi ulanishlar uchun ishlayotgandek ko‘rinadi, sinovdan o‘tayotgan ulanish uchun esa hech narsa qilmaydi.
Zanjir boshidagi holat mosligini o‘qing. Agar u sizning qoidangizdan oldin established va related trafikni qabul qilsa, allaqachon davom etayotgan har bir oqim yopilguncha oqishda davom etadi. Favqulodda qoida uchun odatda shu xatti-harakat kerak bo‘ladi, va darhol uzilishni kutganingizda bu chalkashtiradi. Joylashtirishdan oldin qanday ta’sir xohlayotganingizni hal qiling. Ochiq ulanishni qayta ishlatadigan sinov sizga noto‘g‘ri voqeani aytadi.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'
Birinchi buyruq oqim bor-yo‘qligini, ikkinchisi esa erta holat qoidasi uni qabul qilishda davom etayotganini ko‘rsatadi. Ikkisi ham faqat o‘qish uchun va hodisa davomida ishga tushirish xavfsiz.
Bu qoida nima emas
Qoida domenlarning qora ro‘yxati, IPv6 siyosati yoki alohida dastur hisobiga qo‘yilgan cheklov emas.
Ularning har biriga o‘z mexanizmi kerak. Domen bloklanishi nomlarni hal qilishi kerak, paket filtri buni qilmaydi. IPv6 trafigiga o‘z mosligi kerak, chunki ip ifodasi ip6 paketlari haqida hech narsa demaydi. Dastur darajasidagi cheklov prefiks mosligiga emas, xizmat yoki autentifikatsiya qilingan proksiga tegishli. Aynan bu talablarni alohida saqlash bitta tor qoidadan to‘rtta ish talab qilinishining oldini oladi.
Bu qoida beradigan shartnoma aniq: ruxsat etilgan hovuzdan bitta manzil prefiksiga trafik rad etiladi, shlyuzning aloqasiz trafigi esa o‘z amaldagi siyosatini saqlaydi. Bu gapni qoida yoniga yozing, keyingi odam nima uchun ekanini biladi.