Yönlendiricinin kendi DNS'i neden VPN tünelini atlıyor?

İstemci sorguları tüneli izlerken yönlendiricinin kendi sorguları WAN üzerinden çıkar ve birini yöneten güvenlik duvarı kuralının diğeri üzerinde hiçbir etkisi yoktur. Neden bir hata değildir: iletilen bir istek ile yönlendiricinin kendisinin oluşturduğu istek iki ayrı akıştır ve her biri yapılandırmanın farklı bir bölümüyle eşleştirilir. Yalnızca istemci yarısını yakalamak, ikinci yarının hiç kullanmadığı bir yol hakkında kendinden emin bir yanıt verir. Çözüm, yönlendiricinin çözümleyicisini bilinçli olarak yönlendirmek ve ardından iki yolu ayrı ayrı test etmektir.

Paket yakalama gerçekte hangi akışa ait

Bir sorgu iki alışveriş içerir. Bir LAN istemcisi yönlendiricinin çözümleyicisine sorgu gönderir ve bu sorgu LAN arayüzüne iletilen trafik olarak ulaşır, dolayısıyla iletilen paketler için yazılmış bir ilke rotası veya NAT kuralı onunla eşleşebilir. Ardından yönlendirici önbellekten yanıt verir veya kayıt yoksa kendi sorgusunu yukarı akıştaki bir sunucuya açar.

Bu ikinci sorgunun kaynağı yönlendiricinin kendisi, hedefi de kendisidir ve platform yolunu başka bir yapılandırma bloğundan seçer. İki alışveriş de aynı adı taşır ve hiçbiri diğerinin kopyası değildir. Bu nedenle LAN tarafında alınan bir yakalama, istemcinin paketinin nereye gittiğini kanıtlar ve giden paket hakkında hiçbir şey söylemez.

Pratik denetim iki tarafı aynı anda gözlemlemektir. Yönlendiricide çözümleyicinin soketini listeleyin, yerel olarak sorgulayın ve WAN arayüzünü yakalayın:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Soket listesi loopback veya LAN adresine bağlı bir dinleyici gösteriyorsa yönlendirici başka bir ana makineye iletmek yerine yerel olarak yanıt veriyor demektir. Yakalama o zaman ortaya çıkan yukarı akış sorgusunun tünel arayüzünden mi yoksa WAN üzerinden mi çıktığını gösterir ve bu, ilke rotası kuralının asla vermeyeceği yanıttır.

İlke rotası ikinci sorguyu neden hiç görmez

Güvenlik duvarı kuralları bir arayüz, kaynak, hedef ve bağlantı noktası için yazılır ve cihazdan geçen paketler için değerlendirilir. Yönlendiricinin oluşturduğu sorgu hiçbir şeyden geçmez, çünkü yerel bir süreç onu doğrudan yönlendirme tablosuna verir. İlke yönlendirmesi ve NAT bu nedenle yalnızca iletilen yol için geçerlidir ve tam da bu yüzden bir kural kümesi eksiksiz görünüp yönlendiricinin DNS'ini tünelin dışında bırakabilir.

Bu ayrım her ürün yazılımı yeniden yazımından sonra da sürer, çünkü bir özellikten değil paketin yolundan doğar. Cihazın kendisi için oluşturduğu her şey, ister çözümleyici sorguları, ister saat eşitlemesi, güncelleme denetimleri veya paket aynalarına erişim olsun, yerel kökenlidir ve aynı kör noktaya düşer. Bu yüzden bir dizüstü bilgisayardan yapılan test yönlendirici hakkında hiçbir şey kanıtlamaz.

pfSense çözümleyicisi kendi yukarı akış yoluna nerede karar verir

pfSense bu ayrımı görünür kılar. İstemci trafiği bir VPN ağ geçidi üzerinden ilke rotasıyla geçebilirken güvenlik duvarının kendi trafiği LAN kuralları yerine çözümleyicinin çıkış ayarını izler. Web arayüzünde bu ayar Services > DNS Resolver > Outgoing Network Interfaces altındadır ve değeri çözümleyicinin yukarı akış sorguları için kullanabileceği arayüzlerin listesidir.

Tünel arayüzünü orada ve yalnızca o arayüzü adlandırmak, yönlendiricinin kendi sorgularının tüneli izlemesini sağlayan şeydir. Varsayılanda bırakılırsa çözümleyici yönlendirme tablosundan bir çıkış seçer ve iki WAN veya VPN olan bir ana makinede bu çoğu zaman WAN'dır.

Diğer ürün yazılımları aynı kararı başka bir etiket altında sunar: kaynak adresine bağlı yukarı akış sunucu listesi, yalnızca iletme kipi veya belgelenmiş rota ilkesi. Aranacak ayar her zaman yerel olarak oluşturulan sorgular için bir çıkış veya kaynak seçen ayardır. Çözümleyici yapılandırması başvurusu bu seçeneği pfSense için belgeler ve değişiklikten önce okumaya değer.

Ayar öncesinde hata davranışını seçin

Tünel düştüğünde iki davranış savunulabilir: hiçbir şey sızmasın diye yukarı akış sorgularını durdurmak veya bilinen bir yolda onaylanmış bir çözümleyiciye geri dönmek. İkisi de politika ve hiçbiri varsayılan olarak elde edilen şey değil. Arayüz listesine dokunmadan önce ağın hangisine ihtiyacı olduğuna karar verin.

Hatada kapanmak savunması daha kolay, ancak tünel kesintisini yönlendiricinin arkasındaki her cihaz için ad çözümleme kesintisine dönüştürür. Geri dönüş ofisi kullanılabilir tutar, ama tünel dışındaki bir yukarı akış alışverişi pahasına ve bu kasıtlı olarak kabul edilebilir olmalı, kazara değil. Seçimi yazın, çünkü VPN dışında bir çözümleyici adresi gören bir sonraki kişi, bir not aksini söylemedikçe bunu sızıntı olarak okuyacaktır. O not, belgelenmiş bir geri dönüşü sonraki çeyrek incelemesinde açıklanamayan bir bulgudan ayıran şeydir.

İki durum kararı zorlaştırır. Özel adlar tünelin ulaşabildiği bir iç çözümleyici gerektirebilir ve kendi şifreli DNS'ine sahip bir tarayıcı veya uygulama yönlendiriciyi tamamen atlayabilir, bu nedenle yapılandırdığınız çözümleyici her zaman belirli bir uygulamanın kullandığı çözümleyici değildir.

İki yolu da test edin ve sonuçları ayrı tutun

Tarayıcı tabanlı bir DNS testi dar bir soruyu yanıtlar: o testin koşullarında o tarayıcı hangi çözümleyicileri kullandı. Ağdaki cihazların envanterini çıkarmaz ve yönlendiricinin kendisi için oluşturduğu bir sorguyu göremez. Çıktısını bir denetim değil, tek bir veri noktası olarak değerlendirin.

Bir LAN istemcisinden yönlendiriciye önce genel bir ad, sonra yalnızca iç bölgenizin yanıtlaması gereken özel bir ad sorun. Yalnızca ikinci sorgudaki başarısızlık tünele değil ad iletimine işaret eder:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Ardından tüneli düşürün ve iki sorguyu yineleyin. Reddedilen yanıtlar çözümleyicinin hatada kapandığı anlamına gelir; başarılı bir yanıt yedek bir çözümleyiciye ve onun kullandığı yola işaret eder. Bunu yazdığınız notla ve aynı dakikada WAN arayüzünde alınan bir yakalamayla karşılaştırın.

Gözlemleri kayıtta ayrı tutun: istemci ile yönlendirici arasındaki alışveriş, yönlendirici ile yukarı akış sunucusu arasındaki alışveriş ve ikincisine karar veren yapılandırma. Daha sonraki bir yönlendirme değişikliği o ikinci alışverişi uyarı olmadan çalıştıracaktır. VPN uç noktası dışında bir yerden gelen yanıt kendi başına bir sızıntı değildir; yalnızca yapılandırma o yolu kazara seçtiğinde sızıntı olur.