VPN NAT'ı UFW'nin before.rules dosyasında nereye gider ve nasıl test edilir

Bir kabuğa yazıldığında çalışan NAT kuralı, before.rules dosyasına yapıştırıldığında başarısız olur, çünkü o dosya bir betik değildir. Tablo bölümleri, zincir bildirimleri ve her tablo için bir COMMIT işareti olan bir geri yükleme biçimi belgesidir. Yanlış yerdeki bir satır ya tüm geri yüklemeyi iptal eder ya da orada olduğunu sandığınız kuralları sessizce düşürür. Aşağıdaki yordam parçayı çerçevenin beklediği yere koyar ve sonucu bir sonraki yeniden yüklemeden önce kanıtlar.

Bir kabuk komutu geri yükleme dosyası değildir

iptables -t nat ile başlayan bir satır iptables ikili dosyasına yönelik bir yönergedir; UFW'nin okuduğu dosya ise eksiksiz bir kural kümesinin tanımıdır. Fark kozmetik değildir: geri yükleme biçimi hangi tabloda olduğunu, hangi zincirlerin bulunduğunu ve tablonun nerede bittiğini bilmelidir. O belgeye yapıştırılan bir komut ya sözdizimi hatasıdır ya da daha kötüsü, yanlış tabloya bağlanmış bir kuraldır. Çerçeve bu dosyaları geri yükleme araçlarıyla yükler çünkü bunlar sıralı değil bildirimseldir.

Belge bir bütün olarak da yüklenir, bu nedenle bozuk bir bölüm dosyanın geri kalanının uygulanmasını durdurabilir. Bu yüzden NAT parçasındaki küçük bir hata filtre kurallarını da beraberinde aşağı çeker ve böylece güvenlik duvarı değişikliği bir kesintiye dönüşür.

Parçayı mevcut tablo bölümünün içine koyun

NAT parçasının bir biçimi vardır ve biçim içindeki kural metninden daha önemlidir. Tablo başlığı bölümü açar, zincir bildirimleri sayaçları kurar, kurallar izler ve bir COMMIT bölümü kapatır.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Yukarıdaki havuz ve arayüz kendi değerleriniz için yer tutuculardır; kopyalanmaya değer kısım yapıdır. Dosyada zaten bir *nat bölümü varsa, ikincisini açmak yerine kuralı o bölümün içine ekleyin, çünkü biçim tablo başına bir COMMIT bekler ve aynı tablo için iki bölüm olması gerçekleşmeyi bekleyen bir onarımdır. Dağıtımın zincir tanımlarını bozmadan koruyun, satıcının kendi entegrasyonu için ekledikleri dahil. UFW çerçeve kılavuzu before, user ve after dosyalarını ve eşleşen bir COMMIT gerekliliğini belgeler.

Dosya boş çıkarsa, onu bir öğreticiden doldurmayın. Hangi paketin ona sahip olduğunu ve gerçek etkin ilkenin ne olduğunu doğrulayın, çünkü boş bir kalıcı dosya çekirdeğin kural tutmadığını kanıtlamaz ve yüklenmiş bir kural kümesi bir sonraki yeniden yüklemenin okuyacak eksiksiz bir dosyası olacağını kanıtlamaz. Önce desteklenen taban çizgisini geri yükleyin, sonra site değişikliklerini onun üzerine yeniden uygulayın.

Adayı uygulamadan test edin

Geri yükleme aracı bir kural kümesini uygulamadan ayrıştırabilir ve oluşturabilir; bu, mevcut en ucuz testtir. Canlı dosya yerine korumalı bir kopya üzerinde çalıştırın ve yalnızca çıkış durumunu değil hata metnini okuyun. Ayrıştırma hatası bir satır ve genellikle bir tablo adlandırır; bu, başarısız bir yeniden yüklemenin size söyleyeceğinden fazladır.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Bu denetimi geçmek, belgenin ayrıştırıldığını kanıtlar ve başka bir şeyi değil. Adayın UFW'nin bağlı olduğu her zinciri hâlâ içerdiğini, yalnızca amaçladığınız kaynaklara izin verdiğini veya uzaktan yönetimin erişilebilir kaldığını kanıtlamaz. Bunlar ayrı incelemelerdir ve sonuncusu başlamadan önce açılan ikinci bir oturumu hak eder.

Kurulu arka uca ve adres ailesine uygun aracı seçin. nft arka ucunu uyumluluk katmanı üzerinden çalıştıran bir ana makine ilgili komuta ihtiyaç duyar ve IPv6 kuralları tamamen başka bir dosyada yaşar.

Yönlendirmeyi, NAT'ı ve erişim ilkesini ayrı tutun

Kaynak çevirisi bir adresleme sorununu çözer ve hiçbir şey vermez. Yönlendirme, bir sysctl ve filtre tablosu tarafından denetlenen ayrı bir izindir ve insanların bir tünel yönlendirdiğinde ama trafik geçirmediğinde unuttuğu şey odur. Erişim ilkesi, hangi kaynakların hangi hizmetlere ulaşabileceğine dair üçüncü karardır ve hiçbir NAT kuralı bunu ifade etmez. Bu üçünü ayrı tutmak, bir arızayı tek bir belirsiz belirti yerine teşhis edilebilir kılan şeydir.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Bu üç çıktıyı birer birer değil birlikte okuyun. Yönlendirmesi kapalı bir masquerade kuralı, bağlanan ama hiçbir yere ulaşamayan bir istemci üretir; bu istemci tarafından tam olarak bir yönlendirme arızası gibi görünür ve insanları yanlış dosyaya gönderir. Filtre tablosu aynı zamanda çok geniş bir accept'in saklandığı yerdir, bu yüzden oradayken varsayılan ilkesini de denetleyin.

Bir yeniden yüklemeyi, bir reddi ve bir VPN kaybını doğrulayın

Üç gözlem eksiksiz bir kabul testi oluşturur: yeniden yükleme başarılı olur, izin verilen bir istemci işlemi çalışır ve reddedilmesi gereken bir istek gerçekten reddedilir. Atlanan üçüncüsüdür ve ilkenin bir şey yaptığının tek kanıtı odur.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Ardından tasarladığınız arızayı test edin. Tüneli düşürün ve ana makinenin ne yaptığını izleyin, çünkü yalnızca VPN açıkken çalışan bir ilke, belirtilmemiş bir bağımlılığı olan ilkedir. Sonrasında bir kez daha yeniden yükleyin; çalışan sonucu artık kalan bir çalışma durumunun değil dosyanın ürettiğini kanıtlamak için.

IPv4 NAT'ı IPv6 hakkında hiçbir şey söylemez, bu yüzden amaçlanan kapsamı her iki aile için kuralın bulunduğu aynı notta belirtin. Hedef tutarlı bir yönetilen ilkedir ve tesadüfen ayrıştırılmış bir parça bunun kanıtı değildir.