TCP sıfırlaması VPN'inizin engellendiğini kanıtlamaz

İstemci günlüğünde «bağlantı sıfırlandı, yeniden başlatılıyor» görünür ve sonuç kanıttan önce gelir. Birisi ağın VPN'i engellediğine, sertifikanın yanlış olduğuna ya da belirli bir ülkenin müdahale ettiğine karar verir. Sıfırlama, bağlantıyı sonlandıran bir TCP paketidir ve günlük satırı istemcinizin bir tane aldığını kaydeder. Gönderen cihazı ya da nedeni adlandırmaz.

Sıfırlama bir pakettir, hüküm değil

TCP sıfırlama işlemesini tanımlar: RST bayraklı bir segment bağlantıyı hemen sonlandırır. Alıcı pazarlık etmez, yeniden denemez ve neden diye sormaz. Sıfırlamayı bildirir ve yoluna devam eder.

İstemcinin bildiği tek şey budur. RST sunucudan, bir proxy'den, bir güvenlik duvarından veya durumunu kaybetmiş bir yük dengeleyiciden gelmiş olabilir.

Kaynağı belirlemek ayrı bir alıştırmadır. Yakalamada görünen kaynak adresi fiziksel kaynağın kanıtı değildir ve arkasındaki politika kararı hakkında hiçbir şey söylemez. Aracı cihazlar adresleri taklit edebilir ve durum tutan cihazlar niyetten değil zaman aşımından sıfırlayabilir. Sıfırlamayı hüküm olarak ele almak, gerçeği öğrendiğiniz kısmı atlar.

Hangi bağlantının sıfırlandığını doğrulayın

Önce etkin profilin gerçekten TCP kullanıp kullanmadığını kontrol edin. UDP tünelinde sıfırlama anlamsızdır ve bir HTTP proxy günlüğü VPN'in kendisinden farklı bir TCP bacağıyla ilgili olabilir.

Hedefi, bağlantı noktasını, deneme zamanını ve istemcinin ulaştığı aşamayı kaydedin.

Aşama en yararlı alandır. TLS el sıkışması sırasındaki sıfırlama bir şüpheli grubuna işaret eder; kimlik doğrulamadan sonraki sıfırlama başka bir gruba. Aşama olmadan her teori uyum sağlar.

Yolun iki ucunu karşılaştırın

Sunucuyu yönetiyorsanız, aynı deneme için olaylarını karşılaştırın. Bağlantıyı kabul etti mi? Kasıtlı olarak mı kapattı? Bir yanıt bir sınırı terk edip bir sonrakine hiç ulaşmadı mı?

Mümkünse istemcide ve sunucuda yakalama yapın. İstemcide görünen ama sunucuda görünmeyen bir sıfırlama sunucuda oluşmamıştır.

Her iki yöndeki RST segmentlerine dikkat edin:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Kontrollü bir karşılaştırmayla daraltın

İkinci onaylı bir ağ, hatanın istemciyi mi yoksa yolu mu izlediğini söyleyebilir. Aynı profil başka yerde çalışıyorsa istemci yapılandırması büyük olasılıkla sorunsuzdur ve değişken yoldur.

Bu hâlâ tek bir aracı cihazı tanımlamaz. Kapsamı bir rotaya daraltır, ki bu yararlı ve dürüst bir sonuçtur.

«Bu yol başarısız oluyor» ile «bu adlandırılmış aktör buna neden oldu» arasındaki ayrımı koruyun. Birincisi test edilebilir; ikincisi genellikle tek bir istemciden edilemez.

Güven ayarlarını değiştirmeden düzeltmeyi doğrulayın

TLS doğrulamasını kapatmayın, kimlik bilgilerini yeniden oluşturmayın ve tek bir sıfırlama satırından yola çıkarak bir engelleme politikası duyurmayın. Bu değişikliklerin her biri test edilen sistemi değiştirir ve bir sonraki karşılaştırmayı anlamsız kılar.

Tanımlanan bileşeni sahibi aracılığıyla düzeltin, ardından aynı profili ve aynı gözlemi yineleyin:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Yararlı sonuç daha iyi konumlandırılmış bir hatadır, daha kendinden emin bir hikâye değil. Proxy düzeltmesinden sonra sıfırlama kaybolursa bir nedeniniz var. Başka bir aşamaya geçerse yol hakkında bir şey öğrendiniz. Her iki durumda da kanıt ikinci bir kişinin okumasına dayanabilmelidir. Gözlemlediğinizi yazın, vardığınız sonucu değil.