Qoruyucu açar VPN ayrıldıqdan sonra da trafiki bloklayır

Tunel yox oldu, şəbəkə ikonası normal görünür və heç nə yüklənmir. Siz VPN-i ayırdınız, ya sildiniz, ya da kompüteri yenidən başlatdınız, amma kəsmə zamanı sizi qorumalı olan blok hələ də qalır. Klient pəncərəsi bunu izah edə bilmir, çünki sizi bloklayan klient deyil: qərar sizin adınıza nüvəyə yazılıb və onu silmək üçün heç nə qalmayıb. Windows-da bu vəziyyət Windows Filtrasiya Platformasında oturur; Linux-da isə iptables və ya nftables-də qaydalar toplusudur, çox vaxt yükləmə zamanı təkrar oynadılan snapshot ilə. Ardınca mənim istifadə etdiyim sıra gəlir: vəziyyəti oxu, nasazlığı izah edən ən dar obyekti sil, sonra onu təkrar-təkrar qaytaran hər şeyi tap.

Qoruyucu açar parametr deyil, nüvə vəziyyətidir

Masaüstü klientlər tuneldən kənar trafiki rədd edən filtrlər əlavə etməklə bloklamanı həyata keçirir. Windows-da bunlar bağlantı-yönləndirmə və nəql qatlarında WFP filtrləridir və bəziləri davamlıdır: onlar Baza Filtrasiya Mühərrikinin siyasət anbarında qeydə alınır və maşın yüklənərkən, hər hansı VPN proqramı işə düşməzdən əvvəl bərpa olunur. Klientlər təmizləmə vaxtına görə fərqlənir. Bəziləri filtrləri ayrılma zamanı silir, bəziləri yalnız təmiz çıxışda, bəziləri isə yalnız qoruyucu açar əvvəlcə söndürüldükdə. Blok aktivkən proqramı silin və ya prosesi öldürün, filtrlər qalır.

Linux-da ekvivalent çıxış yolunda atma və ya rədd qaydasıdır, bəzən yönləndirmə qaydası, bəzən dəyişdirilmiş zəncir siyasətidir. Bu qaydalar onları əlavə edən prosesdən daha uzun yaşayır, çünki onlar nüvə vəziyyətidir: klienti öldürün, çökdürün və ya enerjini kəsin — nüvə paketləri atmağa davam edir və onu geri qaytaracaq heç nə qalmır. Davamlılıq paketi cari qaydalar toplusunun snapshotunu götürüb yükləmə zamanı bərpa etməklə ikinci bir daimilik qatı əlavə edir, beləliklə növbəti başlanğıc blok artıq quraşdırılmış vəziyyətdə başlayır.

Hər hansı bir şeyi silməzdən əvvəl WFP vəziyyətini oxuyun

Windows sizə lazım olan alətləri gətirir. Yüksəldilmiş əmr sətri açın və platformanın vəziyyətini çıxarın; nəticə iş qovluğunda wfpstate.xml kimi yazılır.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

XML-də gedən təchizatçının adını, Block əməliyyatını və qatı axtarın. Bağlantı-yönləndirmə və nəql qatlarındakı filtrlər adi trafiki pozanlardır; qəbul-qatındakı filtr adətən sizin səbəbiniz deyil. Əgər Baza Filtrasiya Mühərriki ümumiyyətlə işləmirsə, başqa yerdə axtarın, çünki o filtrləri başqa heç nə tətbiq edə bilməz.

Adi firewall görünüşünü də yoxlayın, çünki insanların çoxu ikisindən yalnız birinə baxır:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Daxili profillər aktivdirsə və uğursuz trafikə heç bir qayda uyğun gəlmirsə, blok Windows Firewall-dan deyil, üçüncü tərəf təchizatçısından gəlir. Bu fərq təmir üçün hansı alətdən istifadə edəcəyinizi müəyyən edir.

Linux qaydalarını siləcəyiniz sintaksisdə oxuyun

iptables -S qaydaları onları əlavə etmək üçün istifadə olunan formada çap edir, bu da çıxışı silmə üçün birbaşa yenidən istifadə oluna bilən edir. iptables -L -v -n paket sayğacları əlavə edir və bu sayğaclar bir qaydanın həqiqətən uğursuz sorğularınıza uyğun gəldiyini, yoxsa sadəcə zəncirdə durduğunu bildirir.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Yalnız qaydaları deyil, zəncir siyasətlərini də oxuyun: -P OUTPUT DROP heç bir qayda uyğun gəlməsə belə trafiki bloklayır. IPv6-nı ayrıca yoxlayın, çünki hər iki ailəni quraşdıran klient IPv4 qaydaları getdikdən sonra IPv6 blokunu yerində qoya bilər və simptom sonra tətbiqin hansı ailəyə üstünlük verməsindən asılı olur. nftables istifadə olunan yerlərdə nft list ruleset əmrini də işə salın; iki alət uyğunluq qatı vasitəsilə birgə mövcuddur və bir siyahı paketi ata bilən hər qaydanı mütləq göstərmir.

Nasazlığı izah edən ən dar obyekti silin

Windows-da birinci addım hələ də təchizatçının öz silmə yoludur: quraşdırıcını yenidən işə salın və təmir və ya silmə seçin, ya da təchizatçı yayımlayırsa təmizləmə alətini işə salın. Qalan xidmətlər və planlaşdırılmış tapşırıqlar adi haldır və klienti giriş zamanı başladan tapşırıq növbəti yükləmədə onun filtrlərini yenidən quraşdırır. Klientin registr açarını oxuyarkən uğursuz olan silmə adətən registrin korlandığını deyil, həmin açarı hələ bir xidmətin və ya tapşırığın saxladığını bildirir.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Davamlı filtrlər son çarədir. Onlar HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter altında yaşayır, hər filtr üçün bir dəyər GUID ilə açarlanır. Əvvəlcə açarı ixrac edin, sildiyiniz GUID-ləri qeyd edin, yalnız gedən klientə aid dəyərləri silin, sonra mühərrikin öz vəziyyətini yenidən qurması üçün yenidən başladın. Bütün açarı silməyin və Baza Filtrasiya Mühərrikini söndürməyin: Windows Firewall və Defender ondan asılıdır və bir nasazlığı daha pis biri ilə dəyişərdiniz.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

Linux-da iptables -S tərəfindən çap edilən sətri götürün və -A yerinə -D yazın. Müəyyən etdiyiniz bir qaydanı silmək zənciri təmizləməkdən yaxşıdır, çünki öz siyasətinizi salamat saxlayır.

sudo iptables -D OUTPUT -p udp -j REJECT

Atma istifadəçi tərəfindən təyin edilmiş zəncirdədirsə, əvvəlcə həmin zəncirə atlanmanı silin, sonra zənciri -X ilə çıxarın. Atma qaydaları hələ yerində ikən zəncir siyasətini ACCEPT-ə qoymaq yalnız siyasət qərarına ümumiyyətlə çatan paketlərə kömək edir. Bütün cədvəlləri təmizləmək son çarədir: o, başqa səbəblərlə əlavə etdiyiniz qaydaları da silir və ufw aktivkən xidməti artıq mövcud olmayan zəncirlərə sahib olduğuna inandırır.

Onu geri qoyan sahibi tapın

Dərhal təmirdən sonra vəziyyəti bərpa edə biləcək hər şeyi axtarın. Linux-da davamlılıq vahidinin aktiv olub-olmadığını, klientin giriş zamanı firewall-u bərpa etmə parametrinin olub-olmadığını və /etc altında saxlanmış qayda faylının olub-olmadığını yoxlayın. Windows-da başlanğıc qeydlərini, xidmətləri və planlaşdırılmış tapşırıqları yenidən yoxlayın, sonra yenidən başladın və vəziyyəti əvvəlki əmrlərlə yenidən oxuyun.

Blok qayıdırsa, silmə həll deyildi; sahib həll idi. Onu hansı klientin və ya xidmətin quraşdırdığını qeyd edin və funksiyanı orada söndürün, hər ayrılmadan sonra firewall qatında onunla vuruşmaq əvəzinə.

Tək ping ilə deyil, real trafiklə yoxlayın

Ad axtarışını, TCP bağlantısını və təzə brauzer sessiyasını yoxlayın, sonra yenidən başladın və eyni üç yoxlamanı təkrarlayın. HTTPS uğursuz olarkən işləyən ping şəbəkəyə deyil, nəql qatındakı filtrə işarə edir və yalnız yenidən başlatmadan sonra qayıdan blok hələ tapmadığınız sahibə işarə edir.

Sübutları saxlayın: ixrac edilmiş BFE açarını və ya dəyişiklikdən əvvəl götürülmüş iptables -S çıxışını. Düzəldildi deməzdən əvvəl obyekti hansı qatdan sildiyinizi, onu yenidən quraşdıra biləcək sahibi, bir təmiz yenidən başlatmadan sonrakı vəziyyəti və VPN prosesi işləmədən adi gəzintinin işlədiyini təsdiqləyin. Təmizliyi skriptlə yazırsınızsa, iptables(8) təlimat səhifəsində dəqiq silmə və siyasət sintaksisi var.