ufw allow 443 VPN arkasındaki hizmete hiçbir şey yapmadı

VPN istemcisinden ping başarılı oluyor, TCP hizmeti zaman aşımına uğruyor ve ufw allow 443/tcp hiçbir şeyi değiştirmiyor. Uygulama ağ geçidinin kendisinde değil de arkasındaki bir sunucuda çalıştığında, bu izin yanlış trafik yolu için yazılmıştı. Paket güvenlik duvarına adreslenmemiştir ve yerel bir sürece teslim edilmez, bu yüzden giriş kuralları onu hiç görmez. Düzeltme, yönlendirilen akışa yönelik bir yol kuralıdır ve bunun kanıtı zaten günlükte duruyor.

Hedefin yerel mi yönlendirilmiş mi olduğuna karar verin

Paketi çekirdeğin gördüğü gibi okuyun. Ağ geçidindeki bir hizmete teslim edilen trafik yerel giriştir. Ağ geçidinin başka bir sunucuya yönlendirdiği trafik yönlendirilmiştir ve UFW iki yol için ayrı kural kümeleri tutar. Ayrımı hedef adresi ve yol araması belirler, paketin geldiği arabirim değil.

IN ve OUT alanlarının ikisinde de aynı arabirimi gösteren bir günlük satırı yine de yönlendirilmiş bir paketi tanımlayabilir, çünkü istemcileri tek bir cihazın içine ve dışına taşıyan tünel tam olarak öyle görünür. Hedef adresi bu soruyu arabirim adlarından daha hızlı çözer. Aynı adı iki kez görmek yerel teslimi kanıtlamaz ve dağıtımın hiç oluşturmadığı bir tünel arabirimi uydurmak da yardımcı olmaz.

Herhangi bir kural eklemeden önce bloğu okuyun

Yetkili tek bir bağlantı denemesini yeniden üretin ve kaynağını, hedefini, protokolünü ve hedef bağlantı noktasını ağ geçidinin kaydettiği gibi yakalayın. Bu dört değeri günlük kaydıyla ve hizmetin gerçek konumuyla karşılaştırın. Daha önceki başarılı bir ping yalnızca kendi alışverişinin izinli olduğunu kanıtlar ve bir güvenlik duvarı bir uygulamaya giden TCP SYN'i tamamen farklı ele alabilir.

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

İlk komut kararı kendi alanlarıyla birlikte döndürür, ikincisi neyin zaten yüklü olduğunu ve hangi sırayla olduğunu gösterir. Herhangi bir şeyi düzenlemeden önce ikisini de okuyun, çünkü kuralınızın üstündeki daha eski bir ret, eksik bir kural olmadan da aynı belirtiyi açıklar.

Uyan en dar yol kuralını yazın

Bu örnekte istemciler 172.20.8.0/24 adresinden tun0 üzerine gelir, hizmet 8443 bağlantı noktasında 10.30.0.15 üzerinde dinler ve ağ geçidi ens5 üzerinden çıkar. Bu değerler, bulut VPC'nin varsayılanı olan 10.0.0.0/16 ya da ev ağı olan 192.168.0.0/16 gibi hiç görünmemeleri için seçildi ve 8443 örneği ağ geçidinin kendi 443 dinleyicisinden uzak tutar.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

Kuru çalıştırma, oluşacak kural kümesini yazdırır ve kuralınızın mevcut bir reddin önüne mi arkasına mı düştüğünü görmenin en ucuz yolu budur. Arabirim adlarını ve iç adresleri örnekle değil dağıtımla karşılaştırarak doğrulayın ve hedef NAT önce çalıştığında filtrenin çevrilmiş hedefi gördüğünü unutmayın.

Dönüş yolunu durumlu tutun

UFW izin verilen bağlantıları izler, bu yüzden izinli yönlendirilmiş bir akışın yanıtları açık bir ters kural olmadan kabul edilir. İşlerin yürümesi için ters yönde sınırsız bir kural eklemek politikayı tek hizmetin çok ötesine genişletir ve normal bir istek-yanıt alışverişi için gerekli değildir. Dönüş yolunu örtük, kural kümesini okunabilir tutun.

Kuralı ancak kuru çalıştırma amacınıza uyduğunda uygulayın, sonra sıralı listenin onu beklenen konumda gösterdiğini doğrulayın. VPN dinleyicisini ve yönetim kurallarını ayrı konular olarak koruyun, çünkü onları değiştirmek tek bir uygulamaya izin vermekten farklı bir karardır. Değişikliği topolojinin yazıldığı yere not edin ki bir sonraki mühendis onu paket yakalamasından yeniden keşfetmek zorunda kalmasın.

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

UFW'nin sizin adınıza uygulayamadığını denetleyin

Doğru bir kural hâlâ çekirdek yönlendirmesi ve hizmete ulaşan bir yol gerektirir. Güvenlik duvarını ikinci kez suçlamadan önce ikisini de doğrulayın.

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

Sonra sunucunun dışına bakın. Bir bulut örneğinde konuğun UFW politikası güvenlik gruplarının, alt ağ ACL'lerinin veya sağlayıcının kendi yönlendirme yapılandırmasının yerini almaz, bu yüzden yerel bir engelleme tek bir katmana dair kanıttır, diğer tüm katmanların hizmete izin verdiğinin kanıtı değildir.

Güvenlik duvarı etkinken yeni bir bağlantıyı sınayarak bitirin, izinli bir kaynaktan ve ilgisiz bir kaynaktan. UFW'yi devre dışı bırakmak belirtiyi aynı komutta ortadan kaldırır ve kanıtı yok eder, bu yüzden ilk değil son deney olmalıdır.