DNS'e yalnızca kendi VPN çözümleyiciniz üzerinden izin verin: adım adım inceleme
Tek bir ad sorgusunu tarayıcıdan yanıta kadar izleyin. Çözümleyicinin nerede seçildiğini, güvenlik duvarının bunu nerede uyguladığını ve 53 numaralı bağlantı noktası kuralının neleri hiç kapsamadığını görün.
Adı yazdığınız andan itibaren tek bir ad sorgusunu izleyin. Tarayıcı işletim sistemine sorar, işletim sistemi politikasının seçtiği çözümleyiciye sorar ve sorgu bir arayüzden bir taşımayla cihazdan çıkar. VPN tasarımınız yanıtın belirli bir çözümleyiciden belirli bir yoldan gelmesi gerektiğini söyler. Bu iki ifade arasındaki boşluk, sizin yapılandırdığınız ve ardından uyguladığınız şeydir.
Adım 1: çözümleyiciyi ve yolu adlandırın
Güvenlik duvarına dokunmadan önce üç şey yazın: çözümleyicinin adresi, beklediğiniz protokol ve bağlantı noktası ve sorgunun çıkması gereken arayüz. Bu liste olmadan kural, trafik hakkında bir tahmindir, bir kararın uygulanması değil. VPN, uygulama verilerini taşırken DNS ayrı bir düzeni izleyebilir ve bu kendi başına bir hata değildir. Kimse istemciye başka bir şey söylemediğinde olan budur.
Yolu açıkça adlandırmak, bir tasarım ile bir kaza arasındaki farktır. Ayrıca size sonradan test edecek bir şey verir, çünkü her gözlem yazılı bir beklentiyle karşılaştırılabilir. Bu listeyi değişiklik kaydında tutun, birinin kafasında değil.
Adım 2: politikayı gerçekten yaşadığı yere koyun
Çözümleyici seçimi istemciye aittir: işletim sisteminin ağ yapılandırması, VPN istemcisinin kendi ayarları veya yönetilen bir tarayıcı politikası. Önce oraya koyun, platformun desteklediği mekanizmayla, çünkü güvenlik duvarı bir istemciyi hiç duymadığı bir çözümleyiciyi seçmeye zorlayamaz. Bölünmüş tünelli bir istemcide hangi alan adlarının iç çözümleyiciye gittiğini açıkça söyleyin. Yönetilen bir filoda tarayıcı politikası çoğu zaman DoH için tek kaldıraçtır, çünkü tarayıcı sistem ayarından bağımsız olarak kendi şifreli çözümleyicisini seçebilir.
Bunu atlayıp doğrudan güvenlik duvarına giderseniz, doğru çözümleyiciye izin veren bir kural ve onu hiç kullanmayan bir istemci elde edersiniz. Kural doğru görünür ve çözümleyici günlükleri boş kalır; bu, hata ayıklarken kafa karıştıran bir çifttir. Önce seçimi yapılandırın, sonra uygulayın.
Adım 3: yolu dar biçimde uygulayın
Şimdi izin verilen yol için ağ iznini ekleyin: çözümleyicinin adresi, protokol ve bağlantı noktası ve çıkması gereken arayüz. Kuralı tüm giden DNS'e izin vermek yerine o çözümleyiciyle sınırlı tutun. Aşağıdaki üç yol, modern bir istemcinin izleyebileceği yollardır ve 53 numaralı bağlantı noktası kuralı yalnızca ilkini kapsar.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
DoH ve DoT'u engellemek meşrudur; 53 numaralı bağlantı noktası kuralının onları zaten engellediğini varsaymak değildir. DoH kullanan bir tarayıcı adları, kuralınızın hiç tanımlamadığı bir yoldan çözer ve kendi çözümleyicisini getiren bir uygulama da aynısını yapar. İzin vermeyi düşündüğünüz her yolu ve reddetmeyi düşündüğünüz her yolu yazın. Bir yolu adlandırmayan kural, o yol hakkında hiçbir karar vermemiştir.
Adım 4: özel ve genel adları izleyin
Bölünmüş DNS bilerek yalnızca özel ad alanlarını iç çözümleyiciye gönderir, genel adlar başka yere gider, bu yüzden tasarımda birden fazla çözümleyici olması bir sızıntı değildir. Sızıntı, sizin çözümleyicinize gitmesi gereken bir sorgunun başka yere ulaşması veya ulaşılamayan amaçlanan bir yolun istemciyi sessizce geri düşürmesidir. Aranacak iki durum bunlardır. Amaçlanan politika altında bir iç ve bir genel adı izleyin ve her birine hangi çözümleyicinin yanıt verdiğini not edin.
Çözümleyicinizi bildiren bir test sitesi bir ipucudur, kanıt değil, çünkü yalnızca ona ulaşan sorguları görür. Sorgunun gerçekte hangi yolu izlediğini bilmeniz gerektiğinde onu istemci tarafında yakalayın, sonra iki gözlemi karşılaştırın. Uyuşmadıklarında, kimsenin belgelemediği bir geri düşüş bulmuşsunuzdur.
Çözümleyici adresi doğru ama ulaşılamazsa sorun politikada değil yönlendirme veya filtrelemededir. Sorguyu o adrese kadar izleyin ve herhangi bir çözümleyici ayarını değiştirmeden önce yanıtın beklenen arayüzden geri döndüğünü doğrulayın.
Adım 5: geri dönüş yolu bırakın
Ağ geçidindeki DNS erişimini sıkılaştırmadan önce ad çözümüne bağlı olmayan bir kurtarma yöntemi doğrulayın. Bozuk bir çözümleyici her onarım aracına ulaşmayı zorlaştırır, değişikliği geri almak için kullanacağınız araçlar dahil. Yeni politika kanıtlanana kadar yerel bir konsolu veya bant dışı bir yolu açık tutun. Yalnızca politika bir yeniden bağlanmayı atlattıktan sonra kaldırın.
Bir yeniden bağlanma veya tarayıcı politikası güncellemesinden sonra etkin durumu yeniden inceleyin, çünkü ikisi de kuralınızı değiştirmeden çözümleyiciyi değiştirebilir. Gereklilik, sorgular için bilinen bir alıcı ve korunan bir yoldur, tek bir ekran görüntüsündeki rahatlatıcı çözümleyici etiketi değil. RFC 8484 DNS over HTTPS belirtimi, bağlantı noktası kuralınızın görmediği şifreli yol için referanstır.