Bir VPN alt ağına port yönlendirmede SNAT kullanmalı mısınız?

Bir portu yönlendiricinin kendi VPN istemcisinin arkasındaki bir ana bilgisayara yönlendirmek, istek açıkça ulaştığı hâlde güvenlik duvarı sorunu gibi görünen bir şekilde başarısız olur. Hizmet bir bağlantı kaydeder, istemci bekler ve hiçbir şey geri dönmez. Hedef çevirisi işini yaptı; kaybolan kısım dönüş paketidir. Yönlendiricideki tek bir seçici kaynak NAT kuralı bunu düzeltir ve ilginç kısım bu kuralın ne kadar dar olabileceğine karar vermektir.

Yanıt neden başka bir yol izler

Port yönlendirme bir paketin nereye gittiğini yeniden yazar, nereden geldiğini asla. İnternet istemcisinin adresi tünel boyunca kaynak alanında kalır, bu yüzden uzak hizmet bir yabancı görür ve bildiği tek yolla yanıt verir: kendi varsayılan ağ geçidi üzerinden. O ağ geçidi karşı taraftaki VPN toplayıcısıdır ve rastgele bir genel adrese geri dönüş yolu yoktur.

Tünel arayüzünde bir kaydı izleyin ve asimetri açıktır: istek paketleri dışarı, içeri hiçbir şey. Yönlendirme zinciri akışa izin verdi ve tünel onu taşıdı, yani düşme uzak ana bilgisayar zaten bir dönüş yolu seçtikten sonra gerçekleşir.

Güvenilecek kadar dar bir kaynak kuralı

Yönlendiriciyi uzak ana bilgisayarın yanıt verdiği kaynak yapın. Bu düzenlemede WAN adresi 203.0.113.24, LAN 192.168.88.0/24, yönlendiricinin tünel adresi 172.20.5.1 ve hizmet 172.20.5.40:8443 adresinde yanıt verir. Aşağıdaki kural paketi hedef çevirisinden sonra eşleştirir, bu yüzden genel adres yerine çevrilmiş adresi adlandırır. İçinde hiçbir şey istemcinin adresine bağlı değildir ve asıl mesele tam olarak budur.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

O satırdaki her eşleşme, yeniden yazmanın tek bir tünelde tek bir hizmetle sınırlı kalması için vardır. Arayüzü veya portu çıkarın, sorunun gerektirdiğinden daha fazla trafiği yeniden yazarsınız ve hedefli bir düzeltme böylece sonraki kişi için bilmeceye dönüşür.

Kapsamlı maskeleme ne zaman dürüst seçimdir

Yönlendirici birçok hizmeti aynı VPN alt ağına yönlendiriyorsa, hizmet başına kural kimsenin bakmadığı bir listeye dönüşür. Tünel arayüzünden çıkan her şeyi maskelemek daha basit ve öngörülebilirdir, bunun bedeli özgün istemciyi karşı taraftaki her ana bilgisayardan gizlemektir. Oradaki günlükler atıf için kullanılmıyorsa bunu seçin; kullanılıyorsa dar kuralı koruyun.

İki seçenek de farklı şekilde başarısız olur. Eksik dar kural bir hizmeti bozar; çok fazlasıyla eşleşen geniş bir maskeleme, zaten çalışan trafiği, yönlendiricinin kendi giden bağlantıları dâhil, sessizce yeniden yazabilir.

Yayımlamadan önce sayaçları kontrol edin

Hiç eşleşmeyen kurallar, paketleri sayana kadar çalışan kurallarla aynı görünür. Herhangi bir istemci bağlanmadan önce tabloyu bayt sayaçlarıyla yeniden okuyun, sonra LAN olmayan bir ağdan bağlanıp tekrar okuyun. Bir tahmini gerçeğe dönüştüren şey iki okumadır. Yönlendirmeyi ancak ikincisi hareket ettikten sonra yayımlayın.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Gerçek bir bağlantıdan sonra kaynak kuralında sıfır sayaç, eşleşmenin yanlış olduğu anlamına gelir; genellikle hedef veya port çeviri sonrası paketle eşleşmez. Sayaç artıyor ama istemci hâlâ zaman aşımına uğruyorsa dönüş yolu düzeltilmiştir ve başka bir şey yanıtı düşürüyordur, bu yüzden sonra karşı tarafın yönlendirme ilkesine bakın. LAN içinden toka erişimi ayrı bir sorundur ve bunun daha geniş bir sürümü değil, kendi kuralını gerektirir.