NAT arkasındaki bir WireGuard peer'ına port yönlendirme: DNAT artı SNAT

Bir tarayıcı https://203.0.113.10:8443 adresini ister, proxy bağlantıyı kabul eder ve WireGuard peer'ındaki hizmet hiçbir zaman yanıt vermez. DNAT kuralı işini yapıyor; başarısız olan kısım yanıttır. Paketi iki çeviriden geçirerek izleyin, eksik kural belirginleşir. Düzeltme, doğru hook içinde bir NAT ifadesi daha eklemektir, yeni bir tünel değil.

Bir isteği baştan sona izleyin

İstek, kaynak olarak istemcinin genel adresiyle ve hedef olarak proxy adresiyle proxy'nin genel arayüzüne ulaşır. nat PREROUTING içinde DNAT kuralı hedefi peer'ın tünel adresine, 10.90.0.2'ye yeniden yazar. Ardından yönlendirme kararı paketi wg0 üzerinden dışarı gönderir ve iletme yolu tamamlanır.

Peer üzerinde paket artık özgün genel kaynak adresini taşıyor, çünkü hiçbir şey onu yeniden yazmadı. Hizmet bağlantıyı kabul eder ve yanıtı kendi varsayılan ağ geçidine gönderir, o da peer'ın önündeki ev yönlendiricisidir. O yönlendiricinin hiç görmediği bir akış için durumu yoktur ve ya paketi düşürür ya da kendi genel adresine çevirir, istemci bunu kabul etmez.

Asimetri tüm sorundur: istek proxy üzerinden geçer, yanıt doğrudan gitmeye çalışır. Proxy'nin bağlantı izleme özelliği yalnızca yanıt proxy üzerinden geri dönerse yardımcı olur ve kaynak adres hâlâ özgün istemciyi gösterdiği sürece yanıt oraya geri dönemez.

Dönüş çevirisini ekleyin

İletilen akışın kaynağını peer'a gitmeden önce proxy'nin tünel adresine yeniden yazın. Ardından hizmet 10.90.0.1 adresine yanıt verir, proxy bunu alır ve paket istemciye dönmeden önce bağlantı izleme iki çeviriyi de tersine çevirir.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

POSTROUTING kuralı bilerek dardır: çevrilmiş hedefle ve tünel arayüzüyle eşleşir, bu yüzden wg0 üzerinden tesadüfen çıkan ilgisiz trafiği yeniden yazmaz. Geniş bir masquerade kuralı istemci adresini de gizlerdi, ancak bunu her akış için yapar ve NAT tablosunun denetlenmesini zorlaştırırdı.

Kuralları tünelin bulunduğu yere koyun

Tünel adresine veya arayüzüne başvuran kurallar, wg-quick onu yapılandırdıktan sonra çalışmalıdır. Arayüz PreUp'tan önce oluşturulur, ancak adresler, MTU, DNS ve rotalar sonra uygulanır ve PostUp bunların hepsi yerindeyken çalışır. Eklemeleri PostUp'a, silmeleri PreDown'a koyun.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Silmeler eklemelerle jeton jeton eşleşmelidir, multiport ve arayüz eşleşmeleri dahil. Tek bir eşleşmede farklılaşan silme hiçbir şeyi kaldırmaz ve sonraki yeniden bağlanma kuralın ikinci kopyasını ekler. Birkaç yeniden bağlanmadan sonra tabloda bir yapılandırma satırına atfedilmesi zor yinelenenler kalır.

Sonucu iptables -t nat -S ile yeniden bağlanmadan sonra kontrol edin. Aynı kural iki kez görünüyorsa PreDown satırı eşleşmiyor ve temizlik sessizce başarısız oluyor.

İletme, filtreleme ve diğer NAT

IPv4 iletmeyi kalıcı olarak açın, ardından filtrelenen tabloda iletilen akışa izin verin. DNAT, FORWARD zincirinden önce gerçekleşir, bu yüzden filtre kuralı genel adresle değil çevrilmiş hedefle eşleşir. UFW güvenlik duvarını yönetiyorsa izni bir rota kuralı olarak ifade edin; basit bir ana bilgisayar kuralı iletilen trafiği kapsamaz.

Proxy kuralları doğru olsa bile başka iki NAT katmanı yolu bozabilir. Ev bağlantısında genel adres yönlendiriciye aittir ve onun güvenlik duvarında portu açmak, o portu proxy'ye gönderen bir port yönlendirme kaydı oluşturmakla aynı şey değildir. Dışarıdan açık görünen ama hiçbir şeyin yanıt vermediği bir port genellikle tam olarak o eşlemeyi eksik bırakır.

NAT VPS üzerinde sağlayıcı genel bir portu özel bir adrese eşler. Eşleme, duyurduğunuz portla uyuşmalıdır ve uyuşmazlık bozuk bir tünel gibi görünür. WireGuard yapılandırmasını değiştirmeden önce sağlayıcının eşlemesini doğrulayın.

Dönüş yolunu doğrulayın ve bedeli kabul edin

Proxy'nin LAN'ı olmayan bir ağdan bağlanın, ardından bağlantı açıkken çeviri çiftini inceleyin:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

conntrack kaydı özgün tuple'ı, çevrilmiş tuple'ı ve yanıtın yönünü göstermelidir. Yanıt yoksa peer tünel üzerinden göndermiyor demektir; bu genellikle SNAT kuralının uygulanmadığı veya peer'ın kendi güvenlik duvarının akışı düşürdüğü anlamına gelir.

PostUp'ın kuralları yeniden uyguladığını kanıtlamak için bir kez yeniden başlatın, ardından tüneli durdurun ve PreDown'ın onları kaldırdığını doğrulayın. Bağlantı kesildikten sonra kalan ölü kurallar, sonraki bir değişikliğin öngörülemez davranmasının nedenidir.

Son olarak SNAT'ın neye mal olduğunu kabul edin. Hizmet her isteği proxy'den geliyormuş gibi görür, bu yüzden erişim günlükleri, istemci başına hız sınırları ve izin verilen adres listeleri artık kullanıcıları ayırt etmez. Hairpin durumu, proxy'nin LAN'ındaki istemciler için kendi kaynak çevirisini gerektirir. Peer gerçek istemci adreslerine ihtiyaç duyuyorsa alternatif, istemci ağına dönüş rotasıdır; bu daha fazla iş ama bilgiyi korur.