SNAT, DNAT ve Masquerade: her VPN NAT kuralı ne yapar

Bir VPN geçidinin iki tarafına yakalama koyun; tek bir akış dört farklı adres gösterebilir. Kaynak NAT, paketin nereden geldiğini iddia ettiğini yeniden yazar; hedef NAT, nereye gittiğini yeniden yazar. Masquerade üçüncü bir yön değil, adresi sabit bir değer yerine giden arayüzden alan bir kaynak NAT kuralıdır. Üçünden hangisine gerçekten ihtiyacınız olduğunu adlandırın; „VPN bozuk“ biletlerinin çoğu dönüş yoluyla ilgili bir soruya indirgenir.

Her kural neyi yeniden yazar

Kaynak NAT, genellikle SNAT olarak yazılır, akış bir yönlendiriciyi veya geçidi terk ederken kaynak adresini değiştirir. Karşılayan hizmet çevrilmiş adrese yanıt verir ve çeviren kutu, o bağlantı için tuttuğu durumla değişikliği geri alır. Linux'ta bu durum conntrack içinde yaşar, bu yüzden conntrack -L özgün ve yanıt demetlerini yan yana yazdırır.

Hedef NAT, DNAT, bunun yerine hedefi değiştirir. UDP 51820 üzerinde genel bir adrese gönderilen paket 10.8.0.2:51820 adresindeki iç WireGuard sunucusuna yeniden yazılabilir. Ev yönlendiricisi veya bulut yük dengeleyicisi bir VPN dinleyicisini böyle yayınlar ve bu, tünelin sonrasında ne taşıyabileceği hakkında hiçbir şey söylemez.

Masquerade SNAT ailesine aittir. Kural hiçbir adres adlandırmaz; paket çıkarken giden arayüzün sahip olduğu adresi kullanır. Linux ona kendi hedefini verir ve bu, adresini DHCP veya PPPoE üzerinden alan bir WAN arayüzünde olağan seçimdir.

Eşlemenin nerede yaşadığı arızayı belirler

Demeti her sınırda kaydedin: tünelden önce, içinde ve genel arayüzde. Tünel içindeki yakalama, dışındakinden meşru olarak farklıdır ve çevirinin nerede olduğunu bilmeden ikisini karşılaştıran kişi yanlış ana bilgisayarın peşine düşer.

Dönüş trafiği eşlemeyi tutan aygıttan geçmelidir. Yanıt başka bir yol, ikinci bir üst bağlantı, ilke rotası veya özel aralığınızı hiç duymamış bir sağlayıcı üzerinden giderse durumlu ters çeviri hiç gerçekleşmez ve istemci tek yönlü trafik görür. Daha fazla kaynak NAT eklemek eksik dönüş yolunu nadiren düzeltir; bir akışta belirtiyi gizlerken her yerde adres tabanlı ilkeyi bozabilir.

Diğer yaygın hata, tünelin yönlendirilebilirlik yaratmasını beklemektir. Paketleri internete çıkan özel bir istemcinin geçerli bir çıkış düzenine ihtiyacı vardır: varsayılan rota, ileten bir geçit ve genellikle genel bir adrese kaynak çevirisi. Şifreleme tek başına özel bir adresi erişilebilir kılmaz.

Masquerade mi açık SNAT mı

İkisini vaat ettiklerine göre karşılaştırın. Masquerade çıkış adresini seçer, açık SNAT onu sabitler. Genel adresi kararlı bir geçitte sabitleme, günlüklere ve iş ortağı izin listelerine öngörülebilir tek bir değer verir. Dinamik bir WAN bağlantısında sabitlenmiş SNAT adresi kiralama değiştiği anda yanlış olur ve Masquerade tam bu durum için yapılmıştır.

Kapsam en az seçim kadar önemlidir. Geçitten çıkan her paketle eşleşen, kaynak veya hedef sınırı olmayan bir Masquerade kuralı el değmeden bırakmak istediğiniz trafiği de çevirir, diğer özel ağlara giden trafik dahil. Kuralı istemci aralığı, amaçlanan hedef ve arayüzle sınırlayın.

İlke tabanlı IPsec'te bu en sert ısırır. strongSwan'ın iletme kılavuzu IP iletmeyi etkinleştirmeyi ve istemciler için kaynak NAT kuralı eklemeyi adım adım anlatır; aynı belge özgün adresini koruması gereken trafiğin hariç tutulmasını da kapsar. Kaynağı güvenlik ilkesi eşleşmeden önce çevirin; tünel ayağa kalkabilir ama trafik yine düşer, çünkü paket artık görüşülen seçiciye benzemez.

Uzak ucun ne görmesi gerektiğine de karar verin. Çeviriden sonra hizmet geçidi görür, tek tek istemciyi değil. Bu, dönüş yönlendirmesini basitleştirirken günlükleri düzleştirir ve istemci başına izin listelerini etkisiz kılar. İstemci adreslerini korumak önemliyse, bir test geçsin diye onları gizlemek yerine yönlendirilmiş bir dönüş yolu planlayın.

Linux geçidinde kuralları okumak

10.8.0.0/24 üzerinde istemcileri ve eth0 adlı WAN arayüzü olan uzaktan erişim geçidi, iletmenin açık ve akışa izin veren bir filtre ilkesinin var olmasına ihtiyaç duyar; ancak o zaman herhangi bir NAT kuralı yardımcı olabilir. iptables sürümü iki yönü de nat tablosunda tutar:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

nftables biçimi aynı iki kancayı adlandırılmış arayüz ve açık zincirle kullanır:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Her iki parça da filtre zincirinin iletilen akışı zaten kabul ettiğini varsayar. NAT bir izin kuralı değildir ve doğru çevrilmiş bir paket bir tablo sonra yine de atılabilir. Canlı eşlemeyi conntrack -L ile doğrulayın, ne yüklendiğini nft list ruleset veya iptables-save -t nat ile doğrulayın, sonra adresin gerçekten değiştiğini görmek için iki arayüzde de yakalama yapın.

Kötü kural gibi görünen arıza biçimleri

Saç tokası trafiği klasiktir. Sunucunun ortak adresi üzerinden iç sunucuya ulaşan iç istemci, girişte DNAT ve dönüşte kaynak çevirisi gerektirir; yoksa sunucu doğrudan istemciye yanıt verir ve yanıt reddedilir. Çözüm, o içten-dışarı durumu için daha dar ikinci bir kuraldır, her şey için daha geniş bir Masquerade kuralı değil.

Çift çeviri sessiz olandır. Zaten operatör düzeyinde NAT'ın arkasında olan istemci, geçide geri yönlendiremediğiniz bir adresle gelir, siz de yeniden çevirirsiniz. Çalışır, ama günlükler artık iki özel adresleme sıçraması taşır ve her soruşturma iki eşlemeyi de gerektirir. İlke tabanlı IPsec üçüncü bir büküm ekler: ilke eşleşmesinden önce çevirin, trafik geçmeden ayağa kalkmış bir SA elde edersiniz; bu, NAT hatası değil güvenlik duvarı hatası gibi okunur.

Sonra geçen test ve başarısız olan dağıtım vardır. NAT komutunu elle çalıştırmak mekanizmayı kanıtlar, yapılandırmayı değil. Çalışma sırasında eklenen kural yeniden başlatmada veya sonraki arayüz olayında kaybolur ve numarası değişen bir arayüze bağlı Masquerade kuralı uzak ucun gördüğü adresi sessizce değiştirebilir. Kuralı sahibi olan güvenlik duvarının yapılandırmasına koyun ve yeniden bağlandıktan sonra tekrar test edin.

Kuralı kaydetmeden önce kontrol listesi

Önce yönü adlandırın: kaynak, hedef veya ikisi. Sonra durumu kimin tutması gerektiğini belirleyin — geçit, üstteki yönlendirici veya IPsec eşi — ve yanıt yolunun onun üzerinden döndüğünü doğrulayın. Kuralı gerçekten kastettiğiniz istemci aralığı, hedef ve arayüzle sınırlayın; uzak ucun geçidi mi yoksa istemcinin özgün adresini mi görmesi gerektiğine önceden karar verin.

Geçitten değil istemciden test edin. Geçidin kendi üzerindeki tarayıcı istemci çeviri kuralını tümüyle atlayabilir, bu yüzden orada çalışan bir sayfa tünel hakkında hiçbir şey kanıtlamaz. İstemciden kaynaklanan tek bir istek gönderin, sayaçları ve conntrack tablosunu izleyin; çalıştığınız yerde ikisinden biri mümkünse tünel yeniden bağlandıktan ve WAN adresi değiştikten sonra tekrarlayın.