Belgi asosidagi VPN xavfsizlik devori to'sgan libvirt mehmon DNS ni tuzatish
Belgi asosidagi VPN xavfsizlik devori mehmon DNS ni filtr zanjiri ko'rishidan oldin tashlab yuboradi. mangle ustuvorligidagi bitta qoida so'rovni va uning javobini belgilaydi, LAN tarmog'ingizni ochmasdan.
Standart libvirt tarmog'idagi mehmonlar WireGuard interfeysi chiqqunga qadar nomlarni bexato hal qiladi, keyin har bir qidiruv o'sha joyda tiqilib qoladi. dnsmasq hali ham 192.168.122.1:53 da tinglamoqda, mehmonda o'sha manzil hal qiluvchi sifatida qolmoqda va so'rov hali ham kelmoqda. O'zgargan narsa shuki, xostning o'z yuqori so'rovi yoki unga beriladigan javob endi siz tahrirlashni o'ylagan har qanday filtr zanjiridan oldin baholanadigan qoida bilan tashlab yuboriladi. Chiqish yo'li yetarlicha erta qo'yilgan belgi, javob meros oladigan ulanishda.
Tunnel ko'tarilgan zahoti mehmonlar DNS ni yo'qotadi
Biror narsani o'zgartirishdan oldin shaklni tasdiqlang. Tunnelni tushiring, mehmondan dig @192.168.122.1 example.com ni ishga tushiring va uning javob berishini kuzating. Tunnelni ko'taring, takrorlang va uning vaqti tugashini kuzating. Bu ikki natija bir qadamda buzilgan libvirt tarmog'ini, noto'g'ri hal qiluvchi manzilini va o'lik dnsmasq ni chiqarib tashlaydi.
Keyin xost tomoniga qarang. Agar dnsmasq so'rovni va uning yuqori yo'naltirilishini qayd etsa, paket yetib kelgan va xatolik chiqishda. Agar dnsmasq hech narsa qayd etmasa, mehmon so'rovi kirishda tashlab yuborilmoqda va istisno ushbu maqola belgilaydigan ilgakdan boshqa ilgakka tegishli.
Keyingi zanjirdagi accept qoidasi nega hech qachon ishlamaydi
Belgi asosidagi VPN xavfsizlik devori qaror qabul qilishda manba manzilingizga emas, paket belgisiga yoki ulanish belgisiga qaraydi. Jismoniy interfeysga kutilgan belgisiz kelgan har qanday narsa rad etiladi va bu rad etish belgi sinoviga ega bo'lgan qoidalar to'plamida sodir bo'ladi. ip saddr 192.168.122.0/24 accept satr keyingi istalgan zanjirga qo'shilsa ham o'sha paket uchun hech qachon ko'rib chiqilmaydi, shuning uchun ko'rinib turgan qoida to'g'ri ko'rinadi va hech narsani o'zgartirmaydi.
Biror narsa ishlaguncha uni kengaytirish ikkinchi tuzoqdir. Xostning input yo'lida butun libvirt subnetini qabul qilish mehmonlarga xostning har bir xizmatini ochadi, holbuki haqiqiy ehtiyoj bitta port.
Tor istisnoni mumkin qiladigan mexanizm ulanishlarni kuzatishdir. Paketga ct mark ni o'rnatganingizda, qiymat faqat paketga emas, conntrack yozuviga ham saqlanadi, shuning uchun o'sha ulanishdagi har bir paket keyin uni olib yuradi, xostdan mehmonga qaytadigan javob ham. Bu butun hiyla: so'rovni bir marta belgilang, qaytish yo'li allaqachon belgilangan.
VPN jadvali ko'rishidan oldin so'rovni belgilang
Istisnoni o'z jadvaliga qo'ying, keyingi o'quvchi VPN qoidalarini tahlil qilmasdan uni topa olsin:
table inet allowedLocal {
chain guest_dns {
type filter hook input priority mangle; policy accept;
ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
th dport 53 ct mark set 0x00000f41
}
}
priority mangle manfiy, bu zanjirni VPN paketi nol ustuvorlikda o'rnatadigan oddiy filtr zanjirlaridan oldinga qo'yadi. Ilgaklar tartibi qoidani samarali qiladi; VPN zanjiridan keyin keladigan zanjirdagi xuddi shu qoida faqat bezak.
Belgi raqamining o'zi ko'chirilmaydi. O'rnatilgan VPN qoidalari o'z trafigi uchun qabul qiladigan qiymatni oling, uni ishlab turgan qoidalar to'plamidan o'qing va shuni ishlating. Noto'g'ri belgi toza yuklanadigan, har bir so'rovga mos keladigan va hech narsani ichkariga o'tkazmaydigan qoida hosil qiladi.
Teshikni port 53 kengligida saqlang
Yozilganidek, bu libvirt subnetidan xostga TCP yoki UDP port 53 orqali DNS ga ruxsat beradi, boshqa hech narsaga emas. Bu mehmonlarga tunneldan tashqarida internetga chiqishga ruxsat bermaydi va xostga mehmonlar tomon ulanish ochishga ruxsat bermaydi. Agar keyinchalik mehmonga boshqa xost xizmati kerak bo'lsa, bu qoidani yumshatish o'rniga o'sha manzil portini nomlaydigan alohida qoida qo'shing.
Nimani almashtirayotganingizda halol bo'ling. Hal qiluvchiga yeta oladigan mehmon DNS so'rovlari orqali ixtiyoriy ma'lumotni ham tunnel qilishi mumkin, va bu istisno VPN chegarasidagi ataylab qoldirilgan teshik, mahalliy tarmoq ishonchli degan bayonot emas. Manbani 192.168.122.0/24 bilan cheklash o'sha teshikni boshqa har bir mahalliy subnete uzoq tutadi, va tahdid siz uchun muhim bo'lsa, o'sha manbaga qaratilgan so'rovlarni sanash arzon.
Uni qayta yuklashdan keyin ham saqlanadigan qiling va ikkala yarmini isbotlang
Shell satrida terilgan qoida keyingi yuklanishda yo'qoladi, VPN interfeysi allaqachon trafik o'tkazayotganda yuklangan qoida esa birinchi ulanishda poygada yutqazadi. Jadvalni xostning doimiy nftables konfiguratsiyasiga yoki VPN xizmatidan oldin tartiblangan unitga qo'ying va tartibni taxmin qilish o'rniga tekshiring.
Tekshirish uch xil javob talab qiladi. Zanjir yuklanganini va birinchi bo'lib tartiblanganini tasdiqlang, conntrack yozuvi belgini ikkala yo'nalishda ko'rsatishini tasdiqlang va mehmon qidiruvi manzil qaytarishini tasdiqlang. Keyin ikkinchi yarmini tasdiqlang: tunnel tushgan yoki bloklayotganda mehmonning ommaviy xostga oddiy veb-trafigi hali ham muvaffaqiyatsiz bo'ladi. Agar DNS ishlasa va qolgan hamma narsa oqib chiqsa, qoidangiz yuqoridagidan kengroq.
Belgi qo'yilgandan keyin ham qidiruvlar muvaffaqiyatsiz bo'lsa, manbani kengaytirish istagiga qarshi turing. dnsmasq qayerga yo'naltirishini, mehmonning hal qiluvchisi 192.168.122.1 ga yoki kimdir tergan ommaviy manzilga ishora qilishini va so'rov xostga yetib borishini tekshiring. Belgilash paketni ichkariga o'tkazadi va boshqa hech narsani emas, shuning uchun yomon yuqori oqim yoki buzilgan virtual tarmoq qancha qoida qo'shsangiz ham buzilganligicha qoladi.