nginx'i bozmadan önce OpenVPN SNAT kuralını sınırlayın

Aynı tür ana bilgisayardan iki arıza sürekli geliyor. Birincisinde istemciler kimlik doğrular ve sonra tünelin ötesinde hiçbir yere ulaşamaz. İkincisinde VPN açılır ve sunucunun kendi web sitesi yanıt vermeyi bırakır, bu daha endişe vericidir çünkü yan hasar gibi görünür. Konteyner tabanlı bir VPS'te ikisi de genellikle aynı kısa kontrol listesine döner ve sıra önemlidir: önce aygıt, sonra çeviri, en son kapsam.

Konteynerin bir tun aygıtı oluşturabildiğini doğrulayın

Tünel arayüzü var olamıyorsa başka hiçbir şey önemli değil. /dev/net/tun dosyasının bulunduğunu ve test aygıtı oluşturmanın başarılı olduğunu kontrol edin, çünkü birçok sağlayıcı konteynerlerde tunnı varsayılan olarak devre dışı bırakır. Hiçbir firewall çalışması hiç oluşturulmamış bir aygıtın yerini tutmaz.

Aygıt yoksa yalnızca ana bilgisayar veya sağlayıcı etkinleştirebilir. Başka bir paket genellikle bir hafta süren açık bir destek başlığından daha ucuzdur. OpenVPN günlüğünün tek bir satırını okumadan önce bunu doğrulayın. Aksi hâlde akşamı asla paket görmeyecek kuralları ayarlayarak geçirirsiniz.

MASQUERADE'in bu arayüzde ne yaptığına karar verin

Sıradan bir sanal makinede olağan çıkış kuralı ana arayüzden POSTROUTING MASQUERADE olur. Bir OpenVZ konteynerinde görünen aygıt çoğu zaman venet0 olur; yönlendirilmiş bir ağ kartı değil, ana bilgisayarın yönettiği sanal bir arayüzdür ve MASQUERADE orada her zaman eğitimlerin varsaydığı gibi davranmaz.

İşe yarayan biçim, istemcilerin zaten ulaştığı adrese açık çeviridir ve iki yönde de iletmeye izin verilir. Havuzun sunucu yapılandırmasından değiştirilmesi, adresin değiştirilmesi kadar önemlidir. Yapıştırmadan önce her satırı okuyun.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

İletme kuralları olmadan çeviri yine gerçekleşir ve çekirdek yine iletmeyi reddeder. Bu birleşim, NAT kuralındaki sayaçlar artarken istemcinin hiçbir şey almadığı kafa karıştırıcı durumu yaratır. İki FORWARD satırı da aynı zincirdeki herhangi bir geniş drop kuralından önce gelmelidir. Sıra yapılandırmanın parçasıdır, uygulama ayrıntısı değildir.

Kuralı tek bir havuza ve tek bir arayüze sınırlayın

İkinci belirtinin başka bir nedeni var: kaynak ve çıkış sınırlaması olmayan bir POSTROUTING kuralı. Böyle bir kural ana bilgisayardan çıkan her paketi yeniden yazar.

Özgün kaynağa bağlı hizmetler sonra yanlış davranır. Yerel bir proxy arkasındaki web sunucusu yanıt vermeyi bırakabilir ve yeniden başlatmak hiçbir şeyi değiştirmez çünkü kural hâlâ yoldadır. Ana bilgisayarın kendi genel adresine gönderdiği trafik de etkilenir, bu yüzden arıza firewall değil DNS veya sertifika sorunu gibi görünebilir. Kural neredeyse kesinlikle ilk belirtiyi düzeltmek için eklenmiştir.

Çözüm, eşleşmeyi tünel havuzuna ve çıkış arayüzüne daraltmak, sonra birden fazlasını kapsamak için tek bir kuralı genişletmek yerine her havuz için bir kural eklemektir.

Kuralları kalıcı hâle getirin ve onlara başka kimin sahip olduğunu öğrenin

Elle eklenen kurallar yeniden başlatmada kaybolur, bu yüzden onları iptables-save ile kaydedin veya kurulu olduğu yerde netfilter-persistent üzerinden yönetin. Geri yüklemenin OpenVPN başlamadan önce çalıştığını doğrulayın. Sonra bir olay sırasında boşluğu keşfetmek yerine bir kez bilerek yeniden başlatın.

Konteyner ana bilgisayarında, kalıcılık dosyasının yazılabilir konteyner depolamasında olduğunu ve sağlayıcının açılışta filtrelemeyi değiştirmediğini de doğrulayın. Bazı platformlar politikayı konteyner dışında yönetir; orada yerel kurallar ya yok sayılır ya da ana bilgisayarın kendi kurallarıyla çakışır.

Sayaçlarla ve yakalanan tek bir akışla doğrulayın

Bağlı bir istemciden, bir dış hizmetin bildirdiği genel adresi kontrol edin. Sunucunun adresiyle eşleşiyorsa çeviri çalışıyor demektir; eşleşmiyorsa paket başka bir yoldan çıkıyor ya da hiç çıkmıyor. Sonra hem sunucuda barındırılan bir hizmeti hem de genel internetteki bir hizmeti deneyin, çünkü ikisi aynı kural kümesinden farklı yollardan geçer.

Sunucuda iptables -t nat -L -v -n ile NAT ve FORWARD kurallarındaki paket sayaçlarını okuyun ve bir yakalamada tek bir akışı izleyin. İstemcinin adresi yakalamada görünür ve yanıt gelmezse boşluk dönüş yolunda veya sağlayıcının filtrelemesindedir, istemci profilinde değil. Yakalanan kaynağı kuralın çevirdiği adresle karşılaştırın, çünkü uyuşmazlık başka bir kuralın önce eşleştiği anlamına gelir. Gözlemlenen tek bir akış, bir sayfa yapılandırma okumaktan daha fazlasını çözer.

Havuzu, çevrilen adresi ve arayüz adını değişiklik kaydında birlikte tutun. Bir havuz için doğru olan kural bir sonrakini yanlış çevirir.