Neden bir hotspot VPN bağlanmadan önce DNS'i yönlendirir?
Bir hotspot kendi ağında aramaları yeniden yazar ve ana makine adı olarak yazılmış bir uç nokta herhangi bir tünel oluşmadan önce çözülür. Hangi çözümleyicinin her sorguyu yanıtladığını izleyin.
Bir otel ağına katılmak, farklı anlarda karşınıza iki DNS kararı çıkarır: cihazın oturum açarken yaptığı aramalar ve tünel ayakta olduktan sonra yapılan aramalar. Bir hotspot, kontrol ettiği ağ üzerinden ilkini etkileyebilir. İkincisi istemcinin kendi politikasına bağlıdır ve bu, ayrıca incelenmesi gereken bir konudur.
Bağlantıyı sırasıyla izleyin, ilk DHCP kiralamasından özel bir adı çözen sorguya kadar. O zaman bir destek talebinde aynı görünen iki arıza net biçimde ayrılır: biri tünel oluşmadan önce, diğeri onun içinde gerçekleşti.
Hotspot'un dokunabildiği ve dokunamadığı şeyler
Erişim ağı DHCP'de bir çözümleyici adresi dağıtır ve o adrese giden 53 numaralı bağlantı noktasını yakalayabilir. Bu, korumasız her aramaya portal adresi veya engelleme sayfasıyla yanıt vermek için yeterlidir. Uç noktası ana makine adı olarak yazılmış bir VPN istemcisini kırmak için de yeterlidir.
Hotspot'un yapamadığı şey, bir sorgu kurulmuş bir tünelin içinde yol aldıktan sonra onu okumak veya yeniden yazmaktır; elbette tünel onu gerçekten taşıyorsa. Yakalama, soruyu düz metinde görmeye bağlıdır.
Sorgular yine de hotspot'la ilgisi olmayan nedenlerle tünelden çıkar: tarayıcının güvenli DNS ayarı, kurumsal bir son eki yerel çözümleyicide tutan bir split-DNS kuralı veya DNS'i tünelden hariç tutacak şekilde yapılandırılmış bir istemci. Her biri istemci tarafında bir seçimdir ve her biri dışarıdan bakıldığında hotspot müdahalesi gibi görünür.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
İlk arama tünel oluşmadan önce gerçekleşir
Ana makine adı verilen bir istemci önce onu çözmelidir ve o anda hiçbir tünel sorguyu korumaz. Hotspot portal adresiyle yanıt verirse görüşme başarısız olur veya askıda kalır. Hiçbir şeyle yanıt vermezse istemci bir ad hatası bildirir ve tünel hiç başlamaz. İki sonuçtan herhangi biri, aksi halde masum görünen boş bir tünel günlüğünü açıklar.
İşletim sistemleri ayrıca kendi bağlantı kontrollerini ve portal keşfini çalıştırır; bunlar RFC 8910 ve RFC 8952'de açıklanmıştır ve bu istekler herhangi bir VPN ayakta olmadan önce dışarı çıkar. Onları bir proxy günlüğünde görmek beklenen davranıştır, sızıntı kanıtı değildir.
Pratik çözüm, istemciye arama gerektirmeyen bir uç nokta vermektir. Bu mümkün olmadığında önce oturum açmayı tamamlayın, sonra bağlanın.
Hangi çözümleyicinin yanıtladığını bulun
Tarayıcıya değil sisteme sorun ve sorguyu iki kez çalıştırın: bir kez cihazın şu anda kullandığı çözümleyici üzerinden, bir kez sabit bir adrese karşı.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
İlk komutun yanıtı üçüncüden farklıysa, yerel çözümleyicinin başka bir şey döndürdüğünü söyler; yönlendiren bir hotspot'un yaptığı da tam olarak budur. Üçüncünün başarısızlığı ile birincinin başarısı birlikte portala işaret eder: yerel çözümleyici bir oturum açma adresi sundu, giden 53 numaralı bağlantı noktası ise düşürüldü. İkisinde de zaman aşımı, kimlik doğrulama tamamlanana kadar ağın DNS'i attığı anlamına gelir.
Bağlandıktan sonra tekrarlayın ve karşılaştırın. Önbelleğe alınmış yanıt geçişi atlatır, bu yüzden önbelleği temizleyin veya ikinci gözlem için yeni bir ad sorgulayın.
Sonraki aramaları amaçladığınız yolda tutun
DNS'i de yakalayan tam tünel profili en basit düzenlemedir: her uygulamanın her sorgusu tünelin zorladığı çözümleyiciye gider ve yerel ağ yalnızca şifreli trafik görür. Bunu, bağlandıktan sonra dahili ve genel bir adı çözerek ve ardından iki yanıtı tünel çözümleyicisinin tek başına döndürdüğüyle karşılaştırarak kanıtlayın.
Split-DNS, niyetle yazılmış bir alan adı listesi gerektirir: kurumsal son ekler tünelden, geri kalan her şey yerelden ve ikisi arasında örtüşme olmadan.
Tarayıcının güvenli DNS'i bu politikanın dışındadır, bu yüzden profil öngörülebilir davransın diye kapalı olması gerekiyorsa, makine için değil o profil için kapatın. Sistem çözümleyicisini düzenleyerek değil, tarayıcı ayarlarında yapın ki değişiklik bir dahaki sefere görünsün. Her test için yanıtı, çözümleyiciyi ve bağlantı aşamasını tek satırda kaydedin. Otel Wi-Fi'sinde DNS'in başarısız olduğunu söyleyen bir rapor, en az üç farklı nedeni olan bir belirtiyi tanımlar.