WireGuard DNS DNAT: yanıt yolunu çalışır tutmak

DNAT hedefi yeniden yazar, kaynağı değil. Kuralı eklemeden önce üst akış çözümleyicisinin nasıl yanıt verebileceğine karar verin ve her eşleşmeyi dar tutun.

Bir WireGuard istemcisinin DNS sorgusunu başka bir çözümleyiciye yönlendirmek tek bir kural gibi görünür ama üç karar gibi davranır. Hedefin yeniden yazılması, paketin iletilmesi ve yanıtın ağ geçidinin oluşturduğu çeviri durumundan geçerek geri yolunu bulması gerekir. Üçüncüyü atlarsanız sorgu temiz çıkar, istemci ise sonsuza kadar bekler.

10.77.0.0/24 içindeki yetkili istemcilerin wg0 üzerinden gelip bildirilen 10.77.0.1 adresini sorguladığı ve 203.0.113.53 adresinde bir çözümleyiciye ihtiyaç duyduğu örneği ele alın. Üst akış adresi bir belgeleme yer tutucusudur, çalışan bir hizmet değildir.

Sorguyu yönlendirmek yalnızca hedefini değiştirir

PREROUTING içindeki hedef-NAT kuralı adresi yönlendirme kararı verilmeden önce yeniden yazar, böylece paket daha sonra eski hedef yerine yeni hedefe yönlendirilir. İstemcinin kaynak adresi bu işlemden etkilenmez. Bu yüzden eksiksiz görünen bir kural yine de sessizlik üretebilir: istek artık istemcinin özel aralığını hiç duymamış bir çözümleyiciye gider. Ağ geçidi bir alanı çevirdi ve ikinci bir sorunu devraldı.

Her iki DNS taşıması da eşleşen kurallara ihtiyaç duyar, çünkü yanıt kesildiğinde istemci TCP'ye geri döner.

Aşağıdaki kurallar bir gelen arayüz, bir istemci aralığı ve bir özgün hedef adresi seçer. Ağ geçidindeki başka hiçbir şey etkilenmez ve ağ geçidinin kendi sorgusu hiç eşleşmez.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

Yanıt yolu ayrı bir karardır

İki düzenleme yanıtın geri dönmesini sağlar ve birini erken seçmek bir hata ayıklama oturumu kazandırır. Ya üst akış çözümleyicisinin bu ağ geçidi üzerinden 10.77.0.0/24 ağına geri dönüş rotası vardır, ya da ağ geçidi çıkışta kaynağı çevirir, böylece yanıt üst tarafın zaten bildiği bir adrese ulaşır. İkisi de çalışır; yalnızca biri üst taraf üzerindeki denetiminize uyar.

Yönlendirme ilk denemeyi hak eder, çünkü istemcinin adresini çözümleyici için görünür tutar ve ikinci bir çeviri katmanından kaçınır. Üst taraf denetiminizin dışındaysa, belirli çıkış arayüzünde kaynak çevirisi pratik seçimdir.

Bu çeviriyi yönlendirme kadar sıkı sınırlayın, yoksa kural ona rastlantıyla uyan her şey için genel amaçlı bir NAT olur:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

Bağlantı izleme eşlemeyi çift halinde tutar, böylece yanıt dönüşte istemcinin özgün tuple'ına geri yazılır. Çıkış kuralı olmadan çözümleyici yanıtını ulaşamayacağı özel bir adrese gönderir ve istemci hata yerine zaman aşımı görür.

Kuralları işin göründüğünden daha dar yazın

İletme izni aynı kapsama aittir. Makinedeki her DNAT bağlantısını kabul etmek yerine istemciden çözümleyiciye akışa ve conntrack'in zaten tanıdığı dönüş trafiğine izin verin. Toplu kabul, DNS ile hiç ilgisi olmayan port iletmelerini de yetkilendirir.

Ağ geçidinin kendi çözümleyicisi farklı bir kod yoludur. Yerelde yayınlanan bir sorgu OUTPUT üzerinden geçer, bu yüzden ağ geçidi kabuğundan test etmek ne PREROUTING kuralını ne de iletme ilkesini çalıştırır. Bu yüzden yerel bir test geçerken her istemci başarısız olabilir ve tersi de aynı sıklıkta görülür.

Burada hiçbir şey 443 portunda HTTPS üzerinden DNS'i veya 853 portunda TLS üzerinden DNS'i kapsamaz ve hiçbir şey IPv6'yı kapsamaz. IPv6 çözümleyicisi yapılandırılmış bir istemci tüm düzeni memnuniyetle yok sayacaktır.

Yeni bir sorgu neyi kanıtlar

Bağlantı izleme önceki eşlemeleri hatırlar, bu yüzden bir kural değişikliğinden önce gönderilen sorgu eski durumdan yanıtlanabilir ve yeni kuralı bozuk gösterebilir. Yeni bir kaynak portuyla ve istemcinin yanıtları önbelleğe aldığı yerlerde yeni bir adla başlayın.

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

İlk komut istemci yolunun hiç çözülüp çözülmediğini, ikincisi ise ağ geçidinin gerçekten kurduğu çeviriyi tuple'ın her iki yönüyle birlikte gösterir. Doğru çözümleyiciyi işaret eden ama yanıt sayacı sıfırda takılı kalan bir eşleme, filtreleme değil dönüş yolu sorunudur.

Herhangi bir şeyi yönlendirmeden önce çözümleyicinin beklediğiniz adları bildiğini doğrulayın. Genel adlara yanıt veren ama özel bölgenize vermeyen bir yedek çalışan bir aramayı bozuk bir tünele benzeyen NXDOMAIN'e dönüştürür. İstemci yolu devreye girmeden önce çözümleyiciyi doğrudan ağ geçidinden test edin. Ve iptables uzantıları başvurusu bu kuralların dayandığı DNAT ve masquerade anlambilimini belgeler.

İlgili makaleler