DNS yönlendirmesinden sonra dnsmasq sorguları neden VPN’in dışına çıkar

LAN istemcisi VPN’ine doğru şekilde ulaşır ve yine de DNS sorguları yanlış üst bağlantıda görünür. Bu, olağan anlamda bir sızıntı değildir; yönlendirici bir sorguyu iletmeyi bırakıp ona kendisi yanıt verdiğinde olan budur. Araya girme hedefi yerel bir sokete yeniden yazar ve ardından çözümleyici kendi kaynak adresi ve kendi yönlendirme kararıyla ikinci, ilgisiz bir konuşma açar. İstemci akışına uygulanan işaretler ilk konuşmayı tanımlar ve ikincisi hakkında hiçbir şey söylemez.

İşaret sorguyla birlikte yolculuk etmez

Paket işaretleri bir conntrack girdisinde ve uçuştaki pakette yaşar. Bir REDIRECT kuralı o uçuşu bitirir: yük yerel bir sokete teslim edilir ve özgün girdi işini yapmış olur. Ardından yönlendiriciden çıkan şey, çözümleyici sürecinin oluşturduğu ve kaynağı yönlendiricinin kendi adresi olan yeni bir sokettir.

Bu yüzden LAN istemcisinin adresine bağlanmış ilke rotası üst akış sorgusuyla asla eşleşmez. Yeni soket istemciye değil dnsmasq’a aittir ve çekirdek rotayı yönlendiricinin kendi trafiği için değerlendirir. Kaynak kuralları, arayüz kuralları ve işaret kuralları hepsi farklı bir demet görür. İşaretin yayıldığını varsaymak bu kurulumdaki en yaygın hatadır ve istemci tarafındaki bir yakalamada görünmez.

İki konuşma gerçekten bir adı ve bir zamanı paylaşır; bir yakalamayı hızlıca gözden geçirdiğinizde tek bir akış gibi görünmelerinin nedeni de budur.

İletmenin yerel çözümlemeye dönüştüğü yer

53 numaralı bağlantı noktasının yönlendirilip yönlendirilmediğini, başka bir ana bilgisayara çevrilip çevrilmediğini yoksa olduğu gibi bırakılıp bırakılmadığını bularak başlayın, çünkü üç durum farklı davranır. Yerel bir bağlantı noktasına yönlendirme iletmeyi bitirir; başka bir makineye çeviri ise paketi hareket hâlinde tutar ve istemcinin demetini anlamlı kılar.

Her iki protokole bakın. UDP ve TCP üzerinden erişilebilen bir çözümleyici ikisi üzerinden de sınanacaktır ve yalnızca UDP’yi kapsayan bir kural kümesi büyük yanıtlar için sessiz bir delik bırakır. Yönlendiricinin kendi yapılandırma yöneticisinin ürettiği kurallar da sayılır ve üretilmiş bir dosyayı düzenlemek genellikle bir sonraki yeniden yüklemeye yenilir.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Bu çıktılar sırayla üç soruyu yanıtlar: sorguyu ne yeniden yazar, onu ne alır ve dinleyen soketin sahibi hangi süreçtir. Sahibi bilindiğinde üst akış ilkesinin yaşayacak bir yeri olur.

Çözümleyiciye kendi çıkış ilkesini verin

Etki alanına özgü bir üst akış, tünele yalnızca bazı adların ihtiyaç duyduğu durumda en temiz araçtır. dnsmasq, bir etki alanıyla sınırlanmış server satırını kabul eder; isteğe bağlı bir arayüz veya kaynak adresiyle sorguyu seçilen aygıttan dışarı yönlendirir. İkinci konuşmayı VPN’i izlemeye iten şey tam olarak bu yönlendirmedir.

server=/corp.example/10.30.0.53@tun_work
log-queries

Yukarıdaki etki alanı, adres ve arayüz kendi değerleriniz için yer tutuculardır. Etki alanı seçimi ve çıkış denetimi ayrı kararlar olarak kalır: rota var olmalı, kaynak adrese üst akış çözümleyicisi izin vermeli ve güvenlik duvarı yanıta izin vermelidir. Yalnızca arayüz yönlendirmesi fail-closed değildir, çünkü kaybolan bir tünel çözümleyiciyi başka bir yola düşürebilir. Herhangi bir genel yedek yolu özel kalması gereken bir ad alanından uzak tutun.

Satırı üretilmiş bir dosyaya değil, yönlendiricinin desteklediği yapılandırma sahibine koyun; yoksa bir sonraki yeniden yükleme düzeltmeyi siler.

Paylaşılan bir önbelleğin koruyamadığı şey

Tek önbellekli tek bir iletici her LAN istemcisine hizmet eder ve bu, bazı ağların ihtiyaç duyduğu ayrımı çökertir. İki istemci aynı adı farklı şekilde çözmek zorundaysa, paylaşılan soketin hangi istemcinin sorduğunu geri kazanmasının hiçbir yolu yoktur. İstemci başına ilke ayrı çözümleyici örneklerinde ya da kimliği koruyan bir iletme özelliğinde yaşamalıdır.

Önbelleğe alınmış bir yanıt da yeni yol hakkında kanıt değildir. Üst akış rotası bozuk kalırken yanıt bellekten gelebilir.

53 numaralı bağlantı noktası kuralları, DNS’i HTTPS veya TLS üzerinden konuşan uygulamalar hakkında hiçbir şey söylemez. O sorgular yönlendirmeye asla ulaşmaz, bu yüzden yalnızca 53 numaralı bağlantı noktası üzerine kurulmuş bir ilke trafiğin bir alt kümesini tanımlar ve alt küme olarak belgelenmelidir.

İkinci konuşmayı doğrulayın, ilkini değil

Denetlediğiniz bir adla sınayın ve iki tarafı da izleyin. İstemci tarafındaki yakalama sorgunun LAN’dan çıktığını kanıtlar; sonra nereye gittiğini yalnızca yönlendirici tarafı kanıtlar.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Her denemeden önce önbelleği boşaltın, çünkü sıcak bir yanıt bozuk bir üst akışı gizler. TCP üzerinden yineleyin, sonra tünel kapalıyken yineleyin; çözümleyicinin tercih ettiği yol gittiğinde ne yaptığını görün. Tasarımın fail-closed mı yoksa yalnızca şanslı mı olduğuna o son davranış karar verir.