VPN bağlantısı kesildikten sonra da güvenlik anahtarı trafiği engelliyor

Tünel gitti, ağ simgesi normal görünüyor ve hiçbir şey yüklenmiyor. VPN'i kestiniz, kaldırdınız veya yeniden başlattınız, bağlantı düştüğünde sizi koruması gereken engel hâlâ ayakta. İstemci penceresi bunu açıklayamaz, çünkü sizi engelleyen istemci değil: karar sizin adınıza çekirdeğe yazıldı ve onu kaldıracak hiçbir şey bırakılmadı. Windows'ta bu durum Windows Filtering Platform içinde; Linux'ta iptables veya nftables içindeki bir kural kümesi, çoğu zaman açılışta yeniden uygulanan bir anlık görüntüyle. Aşağıdakiler benim kullandığım sıra: durumu oku, hatayı açıklayan en dar nesneyi sil, sonra onu sürekli geri koyan şeyi bul.

Güvenlik anahtarı bir ayar değil, çekirdek durumudur

Masaüstü istemciler engellemeyi tünel dışındaki trafiği reddeden filtreler ekleyerek uygular. Windows'ta bunlar connect-redirect ve transport katmanlarındaki WFP filtreleridir ve bazıları kalıcıdır: Base Filtering Engine ilke deposuna kaydedilir ve makine açılışında, herhangi bir VPN yazılımı çalışmadan önce geri yüklenir. İstemciler temizleme zamanında farklıdır. Bazıları filtreleri bağlantı kesilirken kaldırır, bazıları yalnızca temiz çıkışta, bazıları ise ancak anahtar önce kapatılırsa. Engel etkinken kaldırın veya süreci öldürün, filtreler kalır.

Linux'taki eşdeğeri çıkış yolundaki drop veya reject kuralıdır, bazen bir forwarding kuralı, bazen değiştirilmiş bir zincir ilkesi. Bu kurallar onları ekleyen süreçten daha uzun yaşar çünkü bunlar çekirdek durumudur: istemciyi öldürün, çökertin veya gücü kesin, çekirdek paketleri düşürmeye devam eder ve geri alacak hiçbir şey kalmaz. Bir kalıcılık paketi, geçerli kural kümesinin anlık görüntüsünü alıp açılışta geri yükleyerek ikinci bir kalıcılık katmanı ekler, böylece bir sonraki başlangıç engel zaten kuruluyken başlar.

Bir şeyi silmeden önce WFP durumunu okuyun

Windows ihtiyacınız olan araçlarla gelir. Yönetici istemi açın ve platform durumunu dökün; döküm çalışma dizinine wfpstate.xml olarak iner.

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

XML'de ayrılan sağlayıcının adını, Block eylemini ve katmanı arayın. Sıradan trafiği bozanlar connect-redirect ve transport filtreleridir; receive-accept katmanındaki bir filtre genellikle sizin nedeniniz değildir. Base Filtering Engine hiç çalışmıyorsa başka yere bakın, çünkü bu filtreleri başka hiçbir şey uygulayamaz.

Olağan güvenlik duvarı görünümünü de çapraz kontrol edin, çünkü çoğu kişi ikisinden yalnızca birini inceler:

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

Yerleşik profiller açıkken ve başarısız trafikle hiçbir kural eşleşmezken engel Windows Firewall'dan değil, üçüncü taraf bir sağlayıcıdan gelir. Bu ayrım onarım için hangi aracı kullanacağınızı belirler.

Linux kurallarını sileceğiniz sözdiziminde okuyun

iptables -S kuralları eklendikleri biçimde yazdırır, bu da çıktıyı silme için doğrudan yeniden kullanılabilir kılar. iptables -L -v -n paket sayaçları ekler ve bu sayaçlar bir kuralın başarısız isteklerinizle gerçekten eşleşip eşleşmediğini yoksa sadece zincirde oturup oturmadığını söyler.

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

Yalnızca kuralları değil zincir ilkelerini de okuyun: -P OUTPUT DROP hiçbir kural eşleşmese bile trafiği engeller. IPv6'yı ayrı inceleyin, çünkü iki aileyi de kuran bir istemci IPv4 kuralları gittikten sonra IPv6 engelini yerinde bırakabilir ve belirti o zaman uygulamanın hangi aileyi tercih ettiğine bağlı olur. nftables kullanılan yerlerde nft list ruleset komutunu da çalıştırın; iki araç uyumluluk katmanı üzerinden bir arada yaşar ve tek bir liste bir paketi düşürebilecek her kuralı göstermek zorunda değildir.

Hatayı açıklayan en dar nesneyi silin

Windows'ta ilk adım hâlâ sağlayıcının kendi kaldırma yoludur: yükleyiciyi yeniden çalıştırın ve repair veya uninstall kullanın, ya da sağlayıcı yayımlıyorsa temizleme aracını çalıştırın. Kalan hizmetler ve zamanlanmış görevler yaygındır ve oturum açılışında istemciyi başlatan bir görev filtrelerini bir sonraki açılışta yeniden kurar. İstemcinin kayıt anahtarını okurken başarısız olan bir kaldırma genellikle bir hizmetin veya görevin onu hâlâ tuttuğu anlamına gelir, kayıt defterinin bozuk olduğu değil.

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

Kalıcı filtreler son çaredir. HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter altında bulunurlar, her filtre için GUID ile anahtarlanmış bir değer. Önce anahtarı dışa aktarın, kaldırdığınız GUID'leri not edin, yalnızca ayrılan istemciye ait değerleri silin, ardından motorun durumu yeniden kurması için yeniden başlatın. Anahtarın tamamını silmeyin ve Base Filtering Engine'i devre dışı bırakmayın: Windows Firewall ve Defender ona bağlıdır ve bir kesintiyi daha kötüsüyle değiştirirsiniz.

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

Linux'ta iptables -S tarafından yazdırılan satırı alın ve -A yerine -D koyun. Belirlediğiniz tek kuralı silmek bir zinciri boşaltmaktan iyidir, çünkü kendi ilkeniz bozulmadan kalır.

sudo iptables -D OUTPUT -p udp -j REJECT

drop kullanıcı tanımlı bir zincirdeyse önce o zincire atlamayı silin, sonra zinciri -X ile kaldırın. drop kuralları dururken zincir ilkesini ACCEPT yapmak yalnızca ilke kararına ulaşan paketlere yardım eder. Tüm tabloları boşaltmak son çaredir: başka nedenlerle eklediğiniz kuralları da kaldırır ve ufw etkinken hizmeti artık var olmayan zincirlere sahip olduğuna inandırır.

Onu geri koyan sahibi bulun

Anlık onarımdan sonra durumu geri getirecek şeyi arayın. Linux'ta bir kalıcılık biriminin etkin olup olmadığını, istemcinin oturum açılışında güvenlik duvarını geri yükleme ayarı olup olmadığını ve /etc altında kayıtlı bir kural dosyası bulunup bulunmadığını kontrol edin. Windows'ta başlangıç girdilerini, hizmetleri ve zamanlanmış görevleri yeniden kontrol edin, ardından yeniden başlatın ve durumu öncekiyle aynı komutlarla okuyun.

Engel geri gelirse silme çözüm değildi; sahibiydi. Hangi istemcinin veya hizmetin onu kurduğunu not edin ve özelliği orada devre dışı bırakın, her bağlantı kesilişinden sonra güvenlik duvarı katmanında onunla savaşmak yerine.

Tek bir ping ile değil, gerçek trafikle doğrulayın

Bir ad çözümlemesi, bir TCP bağlantısı ve yeni bir tarayıcı oturumu test edin, ardından yeniden başlatın ve aynı üç kontrolü tekrarlayın. HTTPS başarısızken ping çalışıyorsa bu ağa değil transport katmanındaki bir filtreye işaret eder ve yalnızca yeniden başlatmadan sonra geri gelen bir engel henüz bulamadığınız bir sahibe işaret eder.

Kanıtları saklayın: dışa aktarılan BFE anahtarı veya değişiklikten önce yakalanan iptables -S çıktısı. Düzeltildi demeden önce nesneyi hangi katmandan kaldırdığınızı, onu yeniden kurabilecek sahibi, bir temiz yeniden başlatmadan sonraki durumu ve VPN süreci çalışmadan normal gezinmenin çalıştığını doğrulayın. iptables(8) kılavuz sayfasında temizliği betikleştirirseniz tam silme ve ilke sözdizimi vardır.