VPN uzilgandan keyin ham himoya kaliti trafikni bloklaydi
Himoya kaliti filtrlari va drop qoidalari klientdan uzoq yashaydi. Windows WFP holati va Linux iptables qoidalarini o‘qing, eng tor ob’yektni o‘chiring, so‘ng egasini toping.
Tunnel yo‘q, tarmoq belgisi odatdagidek ko‘rinadi, lekin hech narsa yuklanmaydi. VPNni uzdingiz, o‘chirdingiz yoki qayta yukladingiz, ulanish uzilganda sizni himoya qilishi kerak bo‘lgan blok hali turibdi. Klient oynasi buni tushuntira olmaydi, chunki sizni bloklayotgan klient emas: qaror sizning nomingizdan yadroga yozilgan va uni olib tashlash uchun hech narsa qolmagan. Windowsda bu holat Windows Filtering Platform ichida; Linuxda bu iptables yoki nftables ichidagi qoidalar to‘plami, ko‘pincha yuklash vaqtida qayta qo‘llanadigan surat bilan. Quyidagilar men ishlatadigan tartib: holatni o‘qing, nosozlikni tushuntiruvchi eng tor ob’yektni o‘chiring, so‘ng uni qayta-qayta qaytaradigan narsani toping.
Himoya kaliti — sozlama emas, yadro holati
Ish stoli klientlar tunnel tashqarisidagi trafikni rad etuvchi filtrlar qo‘shish orqali bloklashni amalga oshiradi. Windowsda bu connect-redirect va transport qatlamlaridagi WFP filtrlari, ba’zilari esa doimiy: ular Base Filtering Engine siyosat omboriga yoziladi va mashina yuklanganda, har qanday VPN dasturi ishlashidan oldin tiklanadi. Klientlar tozalash vaqti bilan farq qiladi. Ba’zilari filtrni uzilishda olib tashlaydi, ba’zilari faqat toza chiqishda, ba’zilari esa avval kalitni o‘chirganda. Blok faol bo‘lganda o‘chiring, yoki jarayonni o‘ldiring, filtrlar qoladi.
Linuxdagi ekvivalent chiqish yo‘lidagi drop yoki reject qoidasi, ba’zan forwarding qoidasi, ba’zan o‘zgartirilgan chain siyosati. Bu qoidalar ularni qo‘shgan jarayondan uzoq yashaydi, chunki ular yadro holati: klientni o‘ldiring, yiqiting yoki quvvatni uzib qo‘ying — yadro paketlarni tashlashda davom etadi va buni bekor qilish uchun hech narsa qolmaydi. Doimiylik paketi joriy qoidalar to‘plamining suratini olib, yuklash vaqtida tiklash orqali ikkinchi doimiylik qatlamini qo‘shadi, shuning uchun keyingi ishga tushish blok allaqachon o‘rnatilgan holatda boshlanadi.
Biror narsani o‘chirishdan oldin WFP holatini o‘qing
Windows kerakli vositalar bilan birga keladi. Administrator terminalini ishga tushiring va platforma holatini dump qiling; dump ish katalogida wfpstate.xml sifatida paydo bo‘ladi.
netsh wfp show state
netsh wfp show filters
Get-Service bfe
XML ichidan ketgan provayder nomini, Block amalini va qatlamni qidiring. Oddiy trafikni buzadiganlar connect-redirect va transport filtrlari; receive-accept qatlamidagi filtr odatda sizning sababingiz emas. Agar Base Filtering Engine umuman ishlamasa, boshqa joydan qidiring, chunki bu filtrlarni boshqa hech narsa bajarolmaydi.
Oddiy xavfsizlik devori ko‘rinishini ham tekshiring, chunki ko‘pchilik ikkitadan faqat bittasini ko‘radi:
netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction
Ichki profillar yoqilgan bo‘lib, muvaffaqiyatsiz trafikka hech qanday qoida mos kelmasa, blok uchinchi tomon provayderidan keladi, Windows Firewalldan emas. Bu farq ta’mirlashda qaysi vositadan foydalanishingizni hal qiladi.
Linux qoidalarini o‘chiradigan sintaksisda o‘qing
iptables -S qoidalarni qo‘shilgandagi shaklda chiqaradi, shuning uchun natijani o‘chirish uchun to‘g‘ridan-to‘g‘ri qayta ishlatish mumkin. iptables -L -v -n paket hisoblagichlarini qo‘shadi, va bu hisoblagichlar qoida muvaffaqiyatsiz so‘rovlaringizga haqiqatan mos keladimi yoki shunchaki chainda o‘tiradimi — shuni aytadi.
sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S
Faqat qoidalarni emas, chain siyosatlarini ham o‘qing: -P OUTPUT DROP hech qanday qoida mos kelmasa ham trafikni bloklaydi. IPv6ni alohida tekshiring, chunki ikkala oilani ham o‘rnatgan klient IPv4 qoidalari yo‘qolgandan keyin IPv6 blokini qoldirishi mumkin, va alomat o‘shanda dastur qaysi oilani afzal ko‘rishiga bog‘liq bo‘ladi. nftables ishlatiladigan joyda nft list ruleset ni ham ishga tushiring; ikki vosita moslik qatlami orqali birga yashaydi, va bitta ro‘yxat paketni tashlab yubora oladigan har bir qoidani ko‘rsatishi shart emas.
Nosozlikni tushuntiruvchi eng tor ob’yektni o‘chiring
Windowsda birinchi qadam hali ham provayderning o‘z olib tashlash yo‘li: o‘rnatuvchini qayta ishga tushiring va repair yoki uninstall ishlating, yoki provayder e’lon qilsa, tozalash vositasini ishga tushiring. Qolgan xizmatlar va rejalashtirilgan vazifalar keng tarqalgan, va kirish paytida klientni ishga tushiruvchi vazifa keyingi yuklashda filtrlarini qayta o‘rnatadi. Klientning registr kalitini o‘qishda muvaffaqiyatsiz bo‘lgan o‘chirish odatda xizmat yoki vazifa uni hali ushlab turganini bildiradi, registr buzilganini emas.
Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'
Doimiy filtrlar — oxirgi chora. Ular HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter ostida, har bir filtr uchun GUID bilan kalitlangan bitta qiymat. Avval kalitni eksport qiling, o‘chiradigan GUIDlarni yozib oling, faqat ketgan klientga tegishli qiymatlarni o‘chiring, so‘ng dvigatel holatini qayta qurishi uchun qayta yuklang. Butun kalitni o‘chirmang va Base Filtering Engine ni o‘chirmang: Windows Firewall va Defender unga bog‘liq, va bitta uzilishni yomonroq bilan almashtirgan bo‘lardingiz.
reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg
Linuxda iptables -S chiqargan qatorni oling va -A ni -D bilan almashtiring. Aniqlagan bitta qoidani o‘chirish chainni tozalashdan yaxshiroq, chunki o‘z siyosatingiz daxlsiz qoladi.
sudo iptables -D OUTPUT -p udp -j REJECT
Agar drop foydalanuvchi belgilagan chainda bo‘lsa, avval o‘sha chainga sakrashni o‘chiring, so‘ng chainni -X bilan olib tashlang. drop qoidalari hali mavjud bo‘lganda chain siyosatini ACCEPT qilish faqat siyosat qaroriga yetib boradigan paketlarga yordam beradi. Barcha jadvallarni tozalash — oxirgi chora: u boshqa sabablarga ko‘ra qo‘shgan qoidalaringizni ham olib tashlaydi, va ufw yoqilgan bo‘lsa, xizmatni endi mavjud bo‘lmagan chainlarga egalik qiladi deb o‘ylashga majbur qiladi.
Uni qayta o‘rnatadigan egasini toping
Tezkor ta’mirdan keyin holatni tiklaydigan narsani qidiring. Linuxda doimiylik birligi yoqilganmi, klientda kirish paytida xavfsizlik devorini tiklash sozlamasi bormi va /etc ostida saqlangan qoidalar fayli bormi — tekshiring. Windowsda ishga tushish yozuvlarini, xizmatlarni va rejalashtirilgan vazifalarni qayta tekshirib, keyin qayta yuklang va avvalgidek o‘sha buyruqlar bilan holatni qayta o‘qing.
Agar blok qaytsa, o‘chirish yechim emas edi; yechim — egasi. Qaysi klient yoki xizmat uni o‘rnatishini yozib oling va xususiyatni o‘sha yerda o‘chiring, har bir uzilishdan keyin xavfsizlik devori qatlamida kurashish o‘rniga.
Bitta ping emas, haqiqiy trafik bilan tekshiring
Nom hal qilishni, TCP ulanishni va yangi brauzer seansini sinab ko‘ring, so‘ng qayta yuklang va o‘sha uchta tekshiruvni takrorlang. HTTPS ishlamayotganda ping ishlasa, bu tarmoqqa emas, transport qatlamidagi filtrga ishora qiladi; faqat qayta yuklashdan keyin qaytadigan blok esa hali topilmagan egaga ishora qiladi.
Dalillarni saqlang: eksport qilingan BFE kaliti yoki o‘zgarishdan oldin olingan iptables -S chiqishi. Tuzatildi deb aytishdan oldin ob’yektni qaysi qatlamdan olib tashlaganingizni, uni qayta o‘rnatishi mumkin bo‘lgan egasini, bitta toza qayta yuklashdan keyingi holatni va VPN jarayoni ishlamay turib oddiy ko‘rish ishlashini tasdiqlang. iptables(8) qo‘llanma sahifasida tozalashni skript qilsangiz, aniq o‘chirish va siyosat sintaksisi bor.