VPN uygulaması çöktü: güvenlik anahtarı hâlâ açık mı?

Kullanıcının başladığı yerden başlayın: istemci penceresi yok, tepsi simgesi kayboldu ve tarayıcı ya yüklüyor ya da yüklemiyor. Bu gözlem tek başına blokajın hayatta kalıp kalmadığını söyleyemez. Cevap, hangi bileşenin kuralları tuttuğuna, o bileşenin pencereyle birlikte ölüp ölmediğine ve platformun uygulamayı uygulamanın dışında tutup tutmadığına bağlıdır. Pencereden sürece, sonra güvenlik duvarına, sonra gerçek yola doğru ilerleyin.

Önce yeniden başlatmayın; yeniden başlatma genellikle kanıtları yok eder.

Hâlâ çalışan şeyden başlayın

Herhangi bir şeye dokunmadan önce süreç listesini açın. Masaüstü istemci genellikle bir kullanıcı arayüzü süreci ile bir hizmet veya daemon olarak ikiye ayrılır ve ilkindeki çökme ikincisini her zaman durdurmaz. Windows'ta hizmet hâlâ listede olabilir, Linux'ta birim hâlâ etkin olabilir ve Android'de izin verildikten sonra tünel sistemindir. Bu üç gerçeği bu sırayla okuyun.

Daemon yaşıyorsa tünel de büyük olasılıkla yaşıyordur ve eksik pencere yalnızca kozmetiktir.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Blokajı uygulamadan değil, uygulayandan okuyun

İstemci güvenlik anahtarını güvenlik duvarı kuralları ekleyerek uyguluyorsa, bu kurallar işletim sistemine aittir ve onları oluşturan süreçten sonra da kalır. O zaman çökme sizi onu kapatacak hiçbir arayüz olmadan bloke bırakır ve bu, korumadan çok bozuk bir ağ gibi görünür. Blokaj bunun yerine istemcinin kendi paket yolunda yaşıyorsa, süreci öldürmek blokajı aynı anda kaldırır.

Android bunu yine başka türlü ele alır: lockdown ile always-on VPN bir platform ayarıdır, bu yüzden blokaj uygulama sürecinden bağımsız olarak sürer ve sistem hizmeti yeniden başlatabilir. Masaüstü istemcisine uyduğunu varsaymak yerine tam davranış için platform belgelerine bakın.

Temiz çıkışı çökmeden ayırın

Normal bir Quit genellikle istemcinin kapanma yolunu çalıştırır; bu yol kuralları bilerek kaldırır ve tüneli kapatır. Çökme o yolu atlar ve uygulayıcının zaten kurduğu her şeyi bırakır. Fark, kuralların zaman damgalarında sürecin çıkışına göre ve sahipsiz eski bir tünel arayüzünün hâlâ var olup olmadığında görülür.

Bu fark kurtarmanızı belirler: temiz çıkış yeni bir bağlantı gerektirebilir, çökme ise kalan kuralların istemcinin desteklenen onarım eylemiyle kaldırılmasını gerektirebilir.

Diğer kontrolleri bozmadan kurtarın

İstemciyi belgelenmiş iş akışıyla yeniden başlatın, ardından gereksinimin iki yarısını da kontrol edin: tünel trafiği taşıyor ve blokaj gerektiğinde hâlâ uygulanıyor. Bağlantıyı geri kazanmak için tüm güvenlik duvarını boşaltmak ilgisiz kontrolleri de kaldırır ve bu takas nadiren buna değer.

Tekrarlanan bir çökmede istemci sürümünü, platform derlemesini ve satıcının istediği sınırlı günlükleri toplayın. Başka bir hesabın istemci profili, özel anahtarı veya tam bağlantı günlüğü bir çökme raporu için gerekli değildir ve bunları eklemek bir destek vakasını veri işleme sorununa dönüştürür.

Tek bir çökme sızıntı kanıtı değildir. Kanıt, politikanın önlemesi gereken bir yoldan çıktığı gözlemlenen ve istemcinin kapalı olduğu anda yakalanan bir pakettir. Bunu bilerek, zararsız bir hedefle test edin ve hangi uygulama katmanının dayandığını yazın.