Sunucunun IP'si değiştikten sonra SNAT kuralı hâlâ eskisini adlandırıyor

Sunucu yeni bir adrese taşındı, istemciler hâlâ bağlanıyor ve gönderdiklerinin hiçbiri internete ulaşmıyor. Bu ayrım ipucudur: dinleyen soket ve bağlantı noktası yönlendirmesi taşınmayı atlattı, bu yüzden tünel açılıyor, oysa iletilen paketlere uygulanan kaynak çevirisi hâlâ ana makinenin artık sahip olmadığı bir adresi adlandırıyor. Bu yeniden yazılmış paketlerin yanıtları artık var olmayan bir makineye gidiyor.

Bağlanma ve iletme farklı yerlerde başarısız oluyor

Kurulum, istemcilerin zaten bildiği uç noktaya bağlıdır: genel adres, önündeki bağlantı noktası yönlendirmesi ve içerideki dinleyici. İletilen trafik ise paket tünele girdikten sonra verilen ikinci karara bağlıdır; ana makine, yanıtların dönüş yolunu bulması için kaynağını yeniden yazar.

Adres değişikliği yalnızca ikinci kararı bozar, bu yüzden belirti "bağlı ama internet yok" diye okunur. Bu aynı zamanda istemci tarafındaki olağan kontrollerin neden sağlıklı göründüğünü açıklar: el sıkışma tamamlanır, istemci bir adres alır ve sunucunun tünel adresine ping bile yanıt verebilir. Sorun diğer tarafta yaşarken istemcide saatler harcanır, bu yüzden kural tablosu ilk bakılacak yerdir.

Düzenlemeden önce kuralı ve sayaçlarını okuyun

Çeviri kurallarını sayaçlarıyla listeleyin ve yapılandırılmış kaynağı ana makinenin gerçekten sahip olduğu adreslerle karşılaştırın. Ölü bir adrese yeniden yazılmış kural genellikle giriş yolunda trafik gösterir, çünkü paketler ona ulaşır ve çevrilir, dönüş yolunda ise hiçbir şey görünmez.

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

Oradayken üç alanı kontrol edin: kaynak eşleşmesindeki havuzu, kural bir tane adlandırıyorsa çıkış arayüzünü ve tüneller arası trafiğin yeniden yazılmasını önleyen istisnayı. Bu istisnayı düzenleme sırasında kaybetmek kolaydır ve kaybedildiğinde eşler arası trafik çalışıyor gibi görünürken yanıtları tuhaf bir yol izler.

Sayaçlar sıfırda takılıysa paketler bu kurala hiç ulaşmaz ve adres mevcut sorun değildir. Zincirde daha önceki rakip bir kural arayın; bu, biri orijinali düzenlemek yerine bir yedek eklediğinde olur. Kural numaralarını bir dakika önce not ettiğiniz çıktıyla karşılaştırın. Sıra yapılandırmanın parçasıdır, kozmetik bir ayrıntı değildir.

Kaynağı değiştirin ya da adlandırmayı bırakın

Ana makinenin kararlı bir adresi varsa, bir tane daha eklemek yerine kuralı yerinde değiştirin. Kural numarasına göre değiştirme, zincirin geri kalanının bağlı olduğu sırayı korur.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

Adres dinamik olarak atanıyorsa hiç kaynak adlandırmayın ve çekirdeğin çıkış arayüzünden mevcut olanı seçmesine izin verin. Bu varyant bir sonraki taşınmayı düzenleme olmadan atlatır, hangi adresin kullanıldığını gizleme pahasına.

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

IPv4 iletiminin yönetilen yapılandırma üzerinden hâlâ açık olduğunu doğrulayın, ardından kuralı dağıtımın kendi mekanizmasıyla kalıcı hâle getirin. Yalnızca çalışan çekirdekte yapılan değişiklik bir sonraki yeniden başlatmada geri döner; genellikle kimsenin değişiklikle ilişkilendirmediği bir bakım penceresinde olur.

Değiştirmeyi yanlış yapmanın iki yolu

Havuzu sunucunun LAN adresi yerine tünel adresine çevirmek, yanıtları doğrudan tünele geri gönderir; orada hiç istemeyen bir istemciye doğru yönlendirilirler. Bağlantı, yönlendirme döngüsüne benzeyen bir biçimde takılır, çünkü gerçekten döngüdür.

Eski kuralın üstüne ikinci bir çeviri yığmak diğer hatadır. İlk eşleşen kural kazanır, bu yüzden eski giriş silinene kadar paketleri işlemeye devam eder ve yeni kuralın sayaçları sıfırda kalırken herkes değiştirmeyi suçlar. Yeni bir şey eklemeden önce kopyayı silin. Ardından listeyi bir kez daha okuyun ve havuzla tam olarak bir çevirinin eşleştiğini doğrulayın.

Tünel IPv6 da taşıyorsa tüm incelemeyi diğer yığında tekrarlayın. Çeviri ve yönlendirilmiş önek olmadan IPv6 varsayılan rotası da aynı sessizlikle başarısız olur ve unutmak kolaydır çünkü üstündeki her şey aynı görünür.

Gelen hizmetler ters çeviriyi gerektirir

Bir VPN istemcisinde dışarıdan erişilebilir olması gereken hizmet, kaynak çevirisi değil hedef çevirisi gerektirir: genel bağlantı noktası içeri girmeden önce istemcinin tünel adresine yeniden yazılır. İletme yolu da bu trafiğe izin veren açık bir kural gerektirir.

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

Tünelin kendisini taşıyan bağlantı noktasını asla çevirmeyin, çünkü o yeniden yazma hizmeti erişilebilir tutan bağlantıyı keser. Tünel bağlantı noktasını hedef kurallarının tamamen dışında tutun. Sonunda iki uçtan doğrulayın: yeni kuralda sayaçlar, tünel aygıtında kısa bir yakalama ve genel olanı denemeden önce tünelin içindeki bir adrese bir istek.