Docker konteyner trafiği ana makinenin VPN'ini atlıyor: nasıl kontrol edilir
Ana makine VPN'i yalnızca ana makinenin ağ ad alanını kapsar. Köprüdeki konteyner trafiğinin tünele girip girmediğini ya da doğrudan dışarı çıkıp çıkmadığını bu kontrollerle belirleyin.
Ana makinedeki tarayıcınız VPN'in çıkış adresini gösteriyor, konteyner ev bağlantınızı bildiriyor ve biri buna sızıntı diyor. Hiçbir şey sızmadı. Ana makine tüneli, ana makinenin ağ ad alanına ait arayüzler, yollar ve kurallar toplamıdır; köprüdeki konteyner ise kendi varsayılan yoluna sahip başka bir ad alanıdır. VPN istemcisinin haftalarca bağlı olduğu ama tek bir konteyner paketinin bile içine girmediği bir Compose yığınında oturdum.
Ad alanını tepsi simgesinden önce kontrol edin
Ad alanları bütün tartışmadır. Docker bir köprü ağında konteyner başlattığında bir ağ ad alanı oluşturur, bir veth çiftinin bir ucunu içine bağlar ve o ad alanına bir adres ile varsayılan bir yol verir. Tünel arayüzü, adı ne olursa olsun, ana makinenin ad alanında yaşar. Konteyner içindeki trafik onu göremez ve hiçbir istemci ayarı bunu dışarıdan değiştirmez.
Yalıtımdan çıkmanın iki desteklenen yolu vardır. --network host konteyneri ana makinenin ad alanına yerleştirir, böylece ana makinenin yollarını ve dolayısıyla tüneli devralır. --network container:vpn başka bir konteynerin ad alanını paylaşır ve çoğu sidecar tasarımı iş yükünü bir VPN konteynerinden bu şekilde geçirir. İkisi de açık seçimlerdir; genellikle bunlardan yalnızca biri dağıtımı yapan kişinin kastettiği şeydir.
Ana makine modu ücretsiz bir yükseltme değildir. Konteyner kendi adresine sahip olmayı bırakır, port yayınlama geçerliliğini yitirir ve orada NET_ADMIN tutan bir süreç ana makinenin yönlendirmesini yeniden yazabilir. Bunu kabul etmek doğru karar olabilir. Zaten açık olduğunu varsaymak, insanların yolda hiç olmamış bir tüneli bir akşam boyunca hata ayıklamasının nedenidir.
Paketi köprüden dışarı izleyin
Köprü konteyneri paketini varsayılan ağ geçidine gönderir, bu da ana makinedeki köprü arayüzüdür. Ardından ana makine paketi iletir ve varsayılan yapılandırmada paket çıkmadan önce kaynak adresini kendi adresine çevirir. Politikayı sessizce boşa çıkaran tam olarak bu çeviri adımıdır.
Paket tünelin uç noktasına ulaştığında ana makinenin adresini taşır. Konteynerin özgün adresine dayanan her kural, ilke yolu ya da bölünmüş tünel kararı artık eşleşmez ve farklı çıkışlardan çıkması gereken iki konteyner yalnızca kaynağa bakılarak ayırt edilemez. Konteyner başına yönlendirme gerekiyorsa karar çeviriden önce ya da denetlediğiniz bir ad alanı içinde verilmelidir.
Docker bu kuralları kendisi sürdürür, daemon hangi güvenlik duvarı arka ucuyla yapılandırıldıysa onun üzerinden. Yönlendirilen trafik için desteklenen kancanın dışında elle yazılan kurallar, DOCKER-USER, daemon yeniden başladığında veya ana makine yükseltildiğinde yeniden sıralanabilir ya da düşürülebilir. Docker'ın paket filtreleme belgeleri zincirlerin sırasını gösterir; pratik nokta her kuralın bir sahibe ve gerçekten test ettiğiniz bir yeniden yükleme yoluna ihtiyaç duymasıdır.
İki sistemi ayrı ayrı test edin
Bir ad alanından gelen kanıt diğeri hakkında hiçbir şey söylemez. VPN konteyneri içinde çalıştırılan bir istek, tünelin o konteyner için çalıştığını kanıtlar. Bu ana makine hakkında kanıt değildir ve aynı komutun --network host konteynerinden çalıştırılması köprü hakkında kanıt değildir.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Ardından testi benzer bir imgede değil, gerçek uygulama konteynerinin içinde tekrarlayın. Uygulama ek bir yol, proxy ortam değişkeni veya farklı bir çözümleyici taşıyabilir ve bunların her biri yanıtı değiştirir. Her seferinde ad çözümlemesini ve ikinci adres ailesini kontrol edin: kullanıcı tanımlı köprülerdeki konteynerler Docker'ın yerleşik çözümleyicisi üzerinden 127.0.0.11 adresinde çözülür ve köprüdeki IPv6 varsayılan yolu, siz yalnızca IPv4 tüneli test etmekle meşgulken trafiği dışarı taşıyabilir.
Kimlik bilgilerine dokunmadan önce deseni okuyun
Ana makine çalışıp konteyner çalışmadığında neden neredeyse her zaman yapısaldır ve anahtarları döndürmek ya da istemciyi yeniden kurmak bir öğleden sonrayı boşa harcar. Önce belirtiyi sıralayın, düzeltme genellikle kendi adını koyar.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
Örtüşme satırı kendi cümlesini hak ediyor. 172.17.0.0/16 için ya da köprünüzün önekini tesadüfen içeren bir 10.0.0.0/8 için yol iten bir VPN profili, tünelin konteyner alt ağını talep etmesine yol açar ve çevrilen adreslere giden yanıtlar yanlış yöne gider ya da kaybolur. Docker ağını yeniden numaralandırmak genellikle istisna biriktirmekten daha temizdir.
Kapsamı açık hale getirin, sonra bilerek kırın
İki tasarım incelemeden geçer. VPN konteynerinin ad alanını paylaşın; kapsanan her iş yükü tek bir yeniden başlatma sınırı olan tek bir tünel kullanır, bu da bir hizmetin başka bir çıkışa ya da kendi DNS yoluna ihtiyaç duymasına kadar basittir. Ya da konteyner ağını ana makinedeki bir VPN ağ geçidine yönlendirin: yönlendirme açık, köprü öneki tünele çevrilmiş, dönüş trafiği açıkça ele alınmış. Bu, ağ başına denetim satın alır ve size daemon ile istemci yükseltmeleri boyunca sürdüreceğiniz bir kural kümesine mal olur.
Her ne olursa olsun, önemli olan test arıza durumudur. Konteyner isteği havadayken tüneli durdurun ve paketin nereye gittiğine bakın. Doğrudan yola geri düşerse kapsam hiçbir zaman uygulanmamıştır, çünkü bir istemcinin kill switch'i istemcinin kendi trafiğini yönetir, köprüden yönlendirilen paketleri değil. Ardından daemon'u ve ana makineyi yeniden başlatın ve sonucu ikinci kez doğrulayın; elle yazılan kuralların kaybolduğu an tam olarak orasıdır.
Bitmiş demeden önce dört şeyi doğrulayın: tünel arayüzü trafikle aynı ad alanında, konteyner testi gerçek konteyner içinde çalıştırıldı, ad çözümlemesi ve her iki adres ailesi kontrol edildi ve tünel arıza testi hâlâ kapalı biçimde başarısız oluyor. Ardından güvenlik duvarı arka ucunu, istemci sürümünü ve her kuralın sahibini yazın. O kayıt, bir sonraki yükseltmenin eski varsayımlardan oluşan belgelenmemiş bir karışım bırakmasını engelleyen şeydir.