VPN'inizin DNS'i gerçekten kullanılıyor mu? 53 numaralı bağlantı noktasını yakalayın ve görün

Çoğu insana VPN istemcisinin DNS ile ne yaptığını sorun, çözümleyiciyi ayarladığını söylerler, böylece sorgular tünelin içinde yol alır. İtme gerçektir; bunun bir sorguya dönüştüğü varsayımı değildir. İtilen bir seçenek ile teldeki bir paket arasında üç aşama vardır ve her biri bağımsız olarak öyle başarısız olur ki hepsi bozuk bir DNS sunucusu gibi görünür. Bu yüzden bir sızıntı testi sayfası ile çalışan bir tarayıcı aynı makine hakkında aynı anda çelişebilir.

İtilen seçenek bir sorgu değildir

Birinci aşama sunucunun ayar önermesidir, örneğin tünel içinde bir çözümleyici adlandıran itilen DNS seçeneği. İkinci aşama istemcinin bu ayarları bir arayüze uygulamasıdır. Üçüncü aşama bir uygulamanın gerçekten o adrese sorgu göndermesidir. İkinci aşamadaki başarısızlık seçeneği bağlantı günlüğünde görünür bırakırken çözümleyici listesi değişmez, üçüncü aşamadaki başarısızlık ise tamamen doğru bir çözümleyici listesini kullanılmadan bırakır.

Hata ayıklamanın çoğu bu üçünü birleştirip VPN sunucusunu suçlar, oysa genellikle kendi payını yaptığını kanıtlayabilen tek taraf odur. Bunun yerine istemcinin gerçek çözümleyici durumunu okuyun, sonra bir sorgunun çıkışını izleyin. Bu iki gözlem yapılandırmayı yönlendirmeden ve politikadan ayırır ve yaklaşık beş dakika sürer. Kayıtları saklayın, çünkü sonraki mühendis bunların tanımını değil öncesini ve sonrasını ister.

Arayüzün gerçekte ne tuttuğunu denetleyin

Linux'ta sistem çözümleyicisi düz dosya, NetworkManager ya da systemd-resolved olabilir ve bunlardan hangisinin ona sahip olduğu itilen sunucunun nereye ineceğini belirler. Komut satırındaki bir OpenVPN süreci sistem çözümleyicisini kendiliğinden güncellemez, bu yüzden belgelenmiş entegrasyon bir up/down betiği ya da ayarları nasıl uygulayacağını zaten bilen bir bağlantı yöneticisidir. İkisini birlikte çalıştırmak yarış oluşturmanın verimli bir yoludur.

resolvectl status
cat /etc/resolv.conf

Windows'ta liste bağdaştırıcı başınadır, bu yüzden tünel bağdaştırıcısı iç sunucuları tutarken fiziksel bağdaştırıcı yerelleri korur ve bazı adlarda kazanır. Etkin olduğunu varsaydığınız yerine iki bağdaştırıcıyı karşılaştırın.

Bir sorguyu makinenin dışına kadar izleyin

İki arayüzü aynı anda yakalayın, sonra iç çözümleyiciyi kullanması gereken bir adı çözün. Bu yakalama çifti hiçbir yapılandırma çıktısının yanıtlayamadığını yanıtlar.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Fiziksel arayüzde görünüp tünelde asla görünmeyen bir sorgu, istemcinin yanlış çözümleyici seçtiği anlamına gelir. İkisinde de görünmeyen bir sorgu ise uygulamanın önbellekten yanıt verdiği, loopback'te dinleyen bir stub'a sorduğu ya da trafiği hiçbir zaman 53 numaralı bağlantı noktası olarak görünmeyen şifreli bir çözümleyici kullandığı anlamına gelir. Yalnızca sorguları değil yanıtları da yakalayın, çünkü tünelden çıkan bir sorguya genel bir adresten yanıt gelmesi yanıtın hiç gelmemesinden farklı bir arızadır.

Yalnızca kendi DNS'ini kabul eden güvenlik duvarı

Ticari istemciler bazen kendi filtre zincirlerini kurar. Belgelenmiş bir desen, istemcinin kendi çözümleyicisine DNS izni verir ve loopback olmayan bir arayüzden çıkmaya çalışan kalan tüm UDP 53 numaralı bağlantı noktası trafiğini atar, kullanıcının bilerek başka yere yönlendirdiği trafik dahil. Daemon sorguları iz bırakmadan kaybolur, bu da filtre değil çözümleyici arızası olarak okunur.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Bir atma kuralı sizin istisnanızdan önce değerlendiriliyorsa, sonradan eklenen kurala asla ulaşılmaz, bu yüzden onu ilk konuma ekleyin ve hedefi gerçekten kastettiğiniz çözümleyiciyle sınırlayın.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Bu istisna politika değil tanıdır. Sağlayıcının kuralı bilerek konmuşsa, desteklenen onarım istemciyi o çözümleyiciye izin verecek şekilde yapılandırmak ve kararı kayda geçirmektir, çünkü eklenen bir kural sonraki istemci güncellemesini atlatamaz.

Sızıntı sayfası neden göründüğünden az kanıtlar

Bir sızıntı testi sayfasının gösterdiği, test operatörüyle konuşan çözümleyicidir, makinenizin danıştığı değil. Dışa doğru özyineleme yapan yerel bir iletici kendi çıkış adresini o sayfaya koyar ve şifreli sorgular sayfayı tamamen boş bırakabilir. İki sonuç da yanlış okunur, biri sızıntı diğeri garanti olarak, ve iki okumanın hiçbiri gözlemden çıkmaz.

Savunulabilir kanıt yakalamadır: arayüz, hedef adres, yanıt ve zaman damgası. Tünel kalkmadan önce bir tane ve sonra bir tane alın, bir sonraki ad başarısız olduğunda karşılaştırın. Bu çift, sonraki kişiye arızanın çözümlemede, yönlendirmede mi yoksa çözümleyicinin kendi erişim politikasında mı olduğunu da söyler.