Ana makine IPsec eşe ulaşıyor, Docker konteyneri ulaşmıyor

Linux makinesinden uzak ana makineye ping atıyorsunuz ve yanıt geliyor, yani tünel çalışıyor. Yanınızdaki konteyner hâlâ zaman aşımına uğruyor ve doğal sonraki adım Docker’ı yeniden başlatmak. Köprü ağındaki bir konteyner genellikle farklı bir kaynak adresle başlar ve ana makineye, uygulamanın kendi çıkış yolundan değil, yönlendirme üzerinden girer, bu yüzden başarılı test farklı bir paket ölçtü. İlke tabanlı bir strongSwan tüneli için, yönlendirilen paket kurulu IPsec ilkesiyle eşleşmediğinde uzak alt ağa giden sıradan bir yol yeterli değildir.

Aşağıdaki anlatım bir hedefi iki kaynak üzerinden izler ve herhangi bir şeyi değiştirmeden önce durumu okur.

Tek hedef ve iki kaynakla başlayın

Önce IP ile bilinen bir hizmet seçin, böylece aynı anda DNS ayıklamayın. Üç olguyu yazın: konteynerin köprü öneki, çalışan ana makine isteğinin kaynak adresi ve tünel için görüşülen yerel ve uzak trafik seçicileri. Bu üç sayı bu belirtinin neredeyse her vakasını açıklar.

Sonra başarısız isteği konteynerin içinden yineleyin ve gerçekte kullandığı kaynağı yakalayın. Bu adres yerel seçici tarafından kapsanmıyorsa sonucu zaten biliyorsunuz ve konteyneri yeniden oluşturmak bunu değiştirmez.

Docker’a dokunmadan önce ilkeleri okuyun

Salt okunur ana makine denetimleri yönlendirme kararlarını, ilke veritabanını ve aralarında seçim yapan kuralları kapsar:

ip rule show
ip route show table all
ip xfrm policy

İlke listesi seçicileri ve yönü, anahtar malzemesiyle dolu bir IPsec durum dökümüne gerek kalmadan gösterir, bu yüzden bir bilete yapıştırmak güvenlidir. Ana makine adresini kapsayan ama köprü önekini kapsamayan yerel bir seçici arayın. Çakışmayı da denetleyin: uzak hedefi yerel sayan bir konteyner yolu, beklediğiniz yönlendirilmiş paketi asla üretmez ve suç tünele atılır. Bu listeyi konteynerin kaynak adresinin yanında saklayın, çünkü ikisi birlikte karşılaştırmanın tamamıdır.

Konteyner öneki yoksa durun ve başka bir şeyi düzenlemeden önce mimariye karar verin. Anlatımın geri kalanı, hangi kaynak adresin ağda görünmesi gerektiği konusunda anlaştığınızı varsayar.

Filtrelemeyi ve çeviriyi sırayla denetleyin

Docker’ın Linux köprü güvenlik duvarı yönlendirmeyi IPsec’den bağımsız olarak engelleyebilir. iptables arka ucuyla FORWARD yolunu ve DOCKER-USER kararlarını inceleyin; önceki bir hükmün ardından eklenen bir kuralın hiç çalışmayabileceğini unutmayın. nftables arka ucu farklı bütünleşir, bu yüzden yalnızca bir iptables örneği öyle adlandırdı diye DOCKER-USER zinciri oluşturmayın; daemonunuzun gerçekte hangi arka ucu kullandığını denetleyin.

Sonra kaynak çevirisini denetleyin. Geniş bir MASQUERADE kuralı, önceden bir IPsec seçicisiyle eşleşen paketi artık eşleşmeyen bir pakete dönüştürebilir ve arıza tam olarak bir yönlendirme sorunu gibi görünür. strongSwan yönlendirme kılavuzu zaten bir ilkeyle eşleşen trafik için böyle bir çeviriden önce gereken NAT muafiyetini belgeler.

Bu muafiyet, kapsanmayan bir konteyner kaynağını tünele eklemenin yolu değildir. Yalnızca tasarıma zaten uyan trafiği korur, bu yüzden önce seçici ve dönüş yolu sorularını çözün, sonra NAT ve filtrelemeyi yanıtla uyumlu hale getirin. Muafiyeti genişletmeye başlarsanız değiştirilmesi gereken şey seçicidir, NAT kuralı değil.

Sonra yönlendirilmiş mi çevrilmiş mi karar verin

Yönlendirilmiş bir konteyner alt ağı, iki eşin de bu alt ağı kabul etmesini ve ona uzak bir dönüş yolu olmasını gerektirir; bu genellikle iki uçta seçici değişikliği ve uzak tarafın sahibiyle bir görüşme anlamına gelir. Bilerek çevrilmiş bir tasarım ise ilgili arama aşamasında ilkenin kapsadığı bir adres sunmalıdır; bu genellikle varsayılan MASQUERADE yerine dar ve belgelenmiş bir kural anlamına gelir.

İki düzenlemeden hiçbiri ana makinenin çalışan tünelinden otomatik olarak çıkmaz ve aralarında seçim yapmak sahibi olan bir tasarım kararıdır. Hangisini seçtiğinizi yazın, yoksa sonraki mühendis bunu güvenlik duvarı sayaçlarından yeniden türetir.

Melez arızaya da dikkat edin: kural kümesinin yarısı çevrilmiş yarısı çevrilmemiş; bu, hedef bağlantı noktasına bağlı olan ve ağdaki hiçbir şeye bağlı olmayan aralıklı başarı üretir.

Yeniden başlatmayla değil, yeni bir bağlantıyla doğrulayın

Dar güvenlik duvarı sayaçlarını ve uzak alıcıyı izlerken yeni bir uygulama bağlantısı kullanın, böylece her gözlemin bir kaynağı olsun. Docker’ı yeniden başlatmak kural durumunu değiştirebilir ve iş yüklerini de bozar; bu da elde etmeye çalıştığınız temiz sinyali size kaybettirir.

Kalıcı sonuç, gösterebileceğiniz dört ifadedir: konteyner kaynağı, eşleşen korumalı yol, izin verilen yönlendirme ve geri dönen bir yanıt. Dördü de geçerli olduğunda konteyner, ana makinenin ulaştığı nedenle eşe ulaşır.