Bir macvlan konteyneri VPN istemcisine neden yanıt veremez

VPN'i sonlandıran ve aynı zamanda macvlan ağında bir konteyner çalıştıran bir Linux ana bilgisayarı düşünün. LAN 192.168.60.0/24, konteyner 192.168.60.210 adresine sahip ve VPN istemcileri 10.95.0.0/24 ağından geliyor. İstemci hizmete ulaşır, yanıt asla geri dönmez ve ana bilgisayardaki her güvenlik duvarı kuralı doğru görünür. Bu belirtiyi iki ayrı kısıt oluşturur ve birini düzeltmek diğerini yerinde bırakır.

İki kısıt, bir belirti

İlk kısıt yalıtımdır: Docker'ın macvlan sürücüsü bir konteynerin üst arabirim üzerinden kendi ana bilgisayarıyla konuşmasına izin vermez. Ana bilgisayar yığını ile konteyner arasındaki trafiğin yolu yoktur, ana bilgisayardaki rotalar nasıl yazılmış olursa olsun.

İkinci kısıt dönüş yoludur. Konteynerin varsayılan ağ geçidi genellikle LAN yönlendiricisidir, bu yüzden bir VPN istemcisine adreslenmiş yanıt o yönlendiriciden çıkar. Yönlendiricinin VPN havuzuna geri dönüş rotası yoksa yanıt ortada bir yerde düşürülür.

İki arıza istemci tarafından aynı görünür: gelen bir istek ve asla gelmeyen bir yanıt. Farklı onarımlar gerektirirler ve geniş bir masquerade kuralı hangisinin hâlâ bozuk olduğunu gizleyebilir. Bu yüzden ilk test, güvenlik duvarında bir değişiklik daha değil, konteyner tarafında bir yakalamadır. İstek orada hiç görünmüyorsa yalıtım kısıtı iş başındadır.

Ana bilgisayar tarafındaki shim'i dar biçimde kurun

Ana bilgisayardaki, aynı üst öğeye köprü modunda bağlı ikinci bir macvlan arabirimi, ana bilgisayar yığınına o LAN segmentinde kendi kimliğini verir. Bunun için DHCP havuzunun dışında ve konteyner aralığının dışında bir adres ayırın ve yalnızca konteyneri onun üzerinden geçirin.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

İlk komut arabirimi köprü modunda oluşturur; bu, bu sürücü için belgelenmiş varsayılandır ve ana bilgisayar ile konteyner arasındaki trafik için istediğiniz moddur. İkincisi, adresin LAN önekiyle çakışmaması için bir /32 atar ve dördüncüsü shim üzerinden yalnızca konteynerin adresini gönderir.

Tüm LAN'ı yeni arabirim üzerinden yönlendirmeyin. Olağan bağlı rota olduğu gibi kalır ve ana bilgisayar rotası bilerek dardır; böylece bir konteyner yol kazanırken segmentin geri kalanı davranışını değiştirmez. Shim'e işaret eden varsayılan bir rota, farklı sonuçları olan farklı bir tasarım olurdu. Onu belirli tutun, hasar yarıçapı küçük kalır.

Bu komutlar çalışan bir ana bilgisayarda ağ ayarlarını değiştirir. Bir cihazda veya yönetilen platformda o platformun desteklediği yapılandırma mekanizmasını kullanın, çünkü root shell içinde yapılan etkileşimli bir değişiklik bir yükseltmeden sonra kalmayabilir.

Kaynağın nasıl korunacağına karar verin

Shim yerindeyken konteyner ana bilgisayara ulaşabilir ve soru, yanıtın hangi kaynak adresini taşıdığına dönüşür. Özgün VPN kaynağını korumak daha temiz modeldir: konteyner istemcinin gerçek adresini görür ve hizmetin günlükleri ile erişim kuralları onu kullanabilir.

Bunun çalışması için konteynerin ağ yapılandırması bu yol için 10.95.0.0/24 trafiğini kendi ağ geçidi olarak 192.168.60.250'ye göndermelidir. Bu, konteynerin kendi yapılandırmasının içindeki desteklenen bir rota veya ağ geçidi ayarıdır, ana bilgisayar tarafında bir numara değildir. Ayarın yürürlüğe girdiğini varsaymak yerine konteynerin içinden doğrulayın. Hâlâ LAN yönlendiricisine işaret eden varsayılan bir ağ geçidi yanıtları aynı deliğe göndermeye devam edecektir.

Onaylanan tasarım bunun yerine VPN kaynaklarını gizliyorsa çeviriyi dar tutun: gerçek VPN havuzu, çıkış arabirimi olarak shim ve belirli konteyner ile hizmet.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Shim'i çıkış arabirimi olarak eşleştirin, tüneli değil. Tüneli çıkış arabirimi olarak adlandıran bir kural, konteynere doğru giden bir paketle eşleşmez ve bu tür kurulumlarda genellikle bulunan hata tam olarak budur. Kuralı yukarıdaki cümle kadar dar tutun ve havuz değiştiğinde gözden geçirin.

İstemciden doğrulayın, ana bilgisayardan değil

Ana bilgisayarın kendisinden shim adresine bağlanmış bir istek, shim'in konteynere ulaşabildiğini kanıtlar. Konteynerin korunmuş 10.95.0.x kaynağına trafik döndürebildiğini kanıtlamaz, çünkü o testteki kaynak adres shim'in kendisinindir.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

İlk komut ana bilgisayardan konteynere olan bölümü test eder ve ikincisi gerçek bir VPN istemcisi isteği yaparken shim'den gerçekte ne geçtiğini gösterir. Giriş yolundaki kaynak adrese ve aynı akışla bir yanıt görünüp görünmediğine bakın.

Ana bilgisayarda yönlendirme etkin olmalıdır ve yönlendirme yolunun hizmet bağlantı noktasında VPN havuzundan shim'e izin ile kurulmuş yanıtlara izin gerektirir. Ana bilgisayardaki INPUT kuralı iletilen trafiğe yetki vermez ve bu, yönlendirme doğru göründükten sonra paketin düşürülmesinin yaygın bir nedenidir.

Gerçek uygulamayı gerçek kimlik bilgileriyle çalıştırın, ardından aynı konteynerdeki ikinci ve ilgisiz bir hizmetin sizi hâlâ reddedip etmediğini kontrol edin. Çalışmasını sağlamanın tek yolu her yönlendirme kuralını açmaksa tasarım tamamlanmamıştır. Hizmetin hangi kaynak adresini kaydettiğini de not edin, çünkü bundan sonra kendi erişim kuralları onu kullanacaktır.