VPN konteynerinde DNAT: INPUT değil, yönlendirme
DNAT sonrasında tünel adresine giden istek yönlendirilen trafiğe dönüşür. Yönlendirme kuralını daraltın, Docker zincirini okuyun ve dönüş yolunu bilinçli seçin.
İstek tünel IP adresine adreslenmiş olarak gelir ve aynı konteynerden komşu bir hizmetin adresine adreslenmiş olarak çıkar. Bu iki an arasında DNAT hedefi yeniden yazdı ve paket artık VPN konteyneri için giriş değildi. Şimdi başka bir kural tarafından değerlendirilen yönlendirilmiş trafik. Bu değişim, tünel adresi için doğru görünen bir güvenlik duvarı kuralının çevrilmiş bağlantıya neden etki etmediğini açıklıyor.
Çeviriden sonra paketi izleyin
10.90.0.0/24 istemci havuzu ve 10.90.0.1 tünel adresini alın. İki konteyner tek bir köprüde: 192.0.2.2 VPN'i, 192.0.2.3 ise uygulamayı çalıştırıyor. Bir istemci 10.90.0.1:8080'e bağlanır ve VPN konteynerinin ad alanındaki DNAT kuralı bunu uygulamanın gerçek adresine ve portuna yeniden yazar. Ardından bir yol paketi köprü üzerinden gönderir. Bu adresler örnektir, kurulum tarifi değildir.
Uygulamanın gerçekten dinlediği port, ana makinede yayımlanan herhangi bir porttan farklı olabilir. İki sayının eşleştiğini varsaymak yerine konteyner içindeki dinleyiciyi okuyun.
İzin yönlendirme yoluna aittir
VPN konteyneri IP yönlendirme ve istemci havuzu, uygulama adresi ve amaçlanan portla sınırlanmış bir yönlendirme kararı gerektirir. Kurulmuş yanıtlar kendi izinlerini gerektirir. Özgün tünel adresiyle eşleşen bir kural DNAT sonrasında eşleşmez, çünkü hedef zaten değişmiştir. INPUT izni artık bu ana makineye adreslenmeyen trafik için yanlış kancadır.
Kapsamı dar tutun: tek kaynak aralığı, tek hedef, tek hizmet. İzin verici bir yönlendirme kuralını yazmak daha kolay, sonradan savunmak çok daha zordur.
docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD
Docker'ın zincirleri konteynerinizin zincirleri değildir
Konteyner ad alanındaki kurallar Docker ana makinesinin kuralları değildir. Trafik tünel arayüzünden köprüye geçtiğinde, ana makinenin köprü güvenlik duvarı başka bir karar verebilir. Docker'ın iptables arka ucunda, belgelenmiş yönlendirme zincirleri ve DNAT sonrası eşleşme noktaları bu kararın göründüğü yerdir.
Docker güvenlik duvarı başvurusu bu zincirleri ve DNAT sonrası eşleşmeyi açıklar. Eksik bir kabulü Docker'ın güvenlik duvarı yönetimini kapatarak veya her zinciri izin verici hale getirerek düzeltmeyin, çünkü bu kullanmaya çalıştığınız sınırı ortadan kaldırır.
Dönüş yolunu bilinçli bir seçim yapın
Kaynak adres korunursa uygulama 10.90.0.x görür ve yanıtları VPN konteyneri üzerinden geri yönlendirmek zorundadır. Aksi halde olağan Docker ağ geçidi bunları tünele sahip olmayan ana makineye gönderir. Alternatif, VPN konteynerinde dar kapsamlı kaynak çevirisidir; yanıtı basitleştirir ama istemciyi uygulamadan gizler. Bilinçli seçin ve hangisini seçtiğinizi yazın.
Sıradan bir istemciden yeni izin verilen bir bağlantı deneyin, ardından ilgisiz portların kapalı kaldığını doğrulayın. Bir paket kaybolduğunda VPN ad alanını, uygulama ad alanını ve uygulamanın kendi günlüğünü inceleyin. Köprü ağ geçidine ping, hizmet için bir kabul testi değildir.
Kuralları konteynerin desteklenen başlangıç yapılandırmasında tutun, çünkü etkileşimli düzenlemeler yeniden oluşturulduğunda kaybolur. Ana makine portu yayımlamak farklı bir maruz kalma yoludur ve yalnızca hizmet tünelden erişilebilir diye gerekli değildir.