Docker bağlantı noktası yayını ve VPN kaynakları: kaçırdığınız iki eşleşme
Bir VPN sunucusunun IP'si her zaman Docker'ın gördüğü kaynak değildir ve DNAT sonrası bağlantı noktası yayınlanan nokta değildir. İki olguyu da gerçek yolla karşılaştırın.
Kural, VPN sunucusunun adresine yayınlanan hizmete izin verin diyor, ama bağlantı yine de düşüyor. Bu sonuç yaygındır ve Docker hatası değildir. Ayrı iki eşleşme yanlıştır: yazdığınız kaynak, ana bilgisayarın aldığı kaynak olmayabilir ve yazdığınız bağlantı noktası, filtrenin gördüğü nokta olmayabilir. İkisini de düzeltmek, hizmet şeması yerine paket yoluna bakmayı gerektirir.
Efsane: VPN sunucusuna izin ver ve iş bitti
Yönlendirilmiş bir VPN, istemci tünel adresini Docker ana bilgisayarına kadar koruyabilir. Kaynak çevirisi yapan bir ağ geçidi bu adresi kendi adresiyle değiştirebilir. İki tasarım da meşrudur ve aynı kullanıcı eylemi için farklı kaynaklar üretir.
Yani VPN sunucusu IP ifadesi bir varsayımı anlatır, gözlemi değil. Önünüzdeki iki tasarımdan hangisinin olduğunu bilene kadar kural bir tahmindir.
Kaynak: istemci havuzu mu çevrilmiş ağ geçidi mi
Dört şeyi sırayla denetleyin. Birincisi, istemci adres havuzu, örneğin 10.90.0.0/24. İkincisi, ağ geçidi bu havuzu ana bilgisayara ulaşmadan önce çeviriyor mu. Üçüncüsü, ana bilgisayarın tek bir yeni bağlantı için gerçekte gözlediği kaynak. Dördüncüsü, uygulama kimlik doğrulaması bireysel kullanıcıları ayırt ediyor mu, çünkü paylaşılan çevrilmiş bir adres bunu yapamaz.
Havuz korunursa, yalnızca ağ geçidinin genel adresiyle eşleşen kural her istemciyi kaçırır. Ağ geçidi bilerek çeviriyorsa, çevrilmiş adrese izin vermek arkasındaki her kullanıcıyı içeri alır; bu, kendi oturum açması olan bir hizmet için kabul edilebilir, başka her şey için kabul edilemez.
Bağlantı noktası: DNAT eşleştirdiğiniz sayıyı değiştirir
Docker iptables ile olağan Linux köprü yayınında, ana bilgisayarın 8443'ten konteyner bağlantı noktası 443'e eşlemesi, iletme filtresi çalışmadan önce çevrilir. Paket filtreye hedef bağlantı noktası 443 ile ulaşır. O noktada 8443 ile eşleşen bir kural hiçbir zaman tetiklenmez, istemcinin yazdığı 8443 olsa bile.
Yayınlanan bağlantı noktası bağlantı izlemede hâlâ vardır, bu yüzden gerçekten ihtiyaç duyduğunuzda özgün hedef orada eşleştirilebilir.
Hangi sayının niyeti anlattığına karar verin. Kural konteyner içindeki hizmeti koruyorsa DNAT sonrası konteyner bağlantı noktasını eşleştirin. Kural istemcinin ne istediğini anlatmak zorundaysa, conntrack seçeneğiyle özgün hedefi eşleştirin ve bununla gelen ek eşleştirme maliyetini ve kural sırası özenini kabul edin.
Zincir: INPUT değil, DOCKER-USER
Docker'ın iptables kılavuzu kullanıcı iletme ilkesini DOCKER-USER zincirine koyar; bu zincir Docker'ın kendi iletme kurallarından önce değerlendirilir. Bir ana bilgisayar hizmetinden INPUT zincirine kopyalanan kural, ana bilgisayara yönelen trafiği süzer, konteynere iletilen trafiği değil. Bu hata, doğru görünen ve konteyner yoluna hiçbir etkisi olmayan bir kural üretir.
Kaynak aralığını, etkin hedef bağlantı noktasını, protokolü ve giriş arayüzünü aynı kuralda birlikte tutun. İletilen her hedef için yalnızca kaynağa dayalı izin, tek bir yayınlanan hizmete izin vermekten daha geniştir.
Yeni bağlantılarla doğrulayın
İki yönü de yeni bağlantılarla deneyin: izin verilen bir VPN istemcisi ve reddedilmiş kalması gereken bir kaynak. Var olan bağlantı durumu, ilke değiştikten sonra oturumu canlı tutabilir, bu yüzden eski bir bağlantı yeni kural hakkında hiçbir şey kanıtlamaz. Ardından yanıt yolunu denetleyin, çünkü konteyner hâlâ gördüğü kaynağa geri yönlendirme yapmak zorundadır.
Zincir sırasını ve bağlantı noktası çevirisi davranışını bu denetimlerin arkasında Docker'ın iptables kılavuzu belgeler. Bir tarifi kopyalamadan önce onu okuyun ve kurulu Docker'ın hangi arka ucu kullandığını doğrulayın, çünkü nftables arka ucu ilkeyi farklı biçimde bütünleştirir.