Bir VPN konteynerinin ağını paylaşmak: DNS'e ne olur

Bir VPN konteynerinin ağ ad alanını paylaşmak, uygulamanıza tünelin arabirimlerini ve yollarını verir. O, ona tünelin çözümleyicisini vermez, ne de ana bilgisayardaki başka bir şeyin birleştirilmiş kopyasını. Bu boşluk çok belirli bir arıza üretir: genel adlar çözülür, iç adlar çözülmez ve başarısız olan uygulama yanlış DNS sunucusu kullanıyormuş gibi görünür, çünkü gerçekten öyle yapar. Onarım genellikle tanının ima ettiğinden daha küçüktür.

Adım 1: Ana bilgisayardan değil, uygulamadan test edin

Aramayı sorunlu konteynerin içinde çalıştırın, ana bilgisayarda ve tarayıcıda değil. docker exec app-container getent hosts db.internal önemli olan tek soruyu yanıtlar: bu sürecin çözümleyicisi ne döndürür.

Ana bilgisayar adı çözüp konteyner çözmezse arızayı buldunuz. Bundan sonrası, onu düzeltmenin desteklenen bir yolunu seçmektir.

Adım 2: Çalışma zamanının desteklediği modeli okuyun

Docker'ın ağ belgeleri başka bir konteynerin ağ modunu paylaşan konteynerler için DNS bayraklarındaki kısıtlamaları kaydeder. Compose'da network_mode: service:vpn uygulamayı VPN konteynerinin ad alanına bağlar ve her hizmet için dns ayarlar sıradan bir hizmetteki gibi davranmaz. Aldığınız çözüm, paylaşılan ad alanının sahip olduğudur.

Kullanıcı tanımlı köprü ağları da Docker'ın yerleşik DNS'ini varsayılan köprüden farklı kullanır. Bu yüzden çalışan bir köprü örneğinden kopyalanan bir dns madde paylaşılan yığında hiçbir şey yapmayabilir. Maddeyi kopyalamadan önce düzeni denetleyin.

Geri döngü adresi her zaman ilgili ağ bağlamına işaret eder. Paylaşılan bir ad alanının içinde, 127.0.0.1 ana bilgisayarın çözümleyicisi değildir.

Adım 3: Sorguyu alıcısına kadar izleyin

Uygulamanın çözümleyici yapılandırmasını, ardından uygulamanın getirdiği uygulamaya özgü şifreli DNS'i okuyun, çünkü kendi çözümleyicisini çalıştıran uygulama düzenlediğiniz dosyayı yok sayar. Ardından seçilen çözümleyicinin VPN'in yolları ve güvenlik duvarı ilkesi altında erişilebilir olup olmadığını denetleyin. Tünelin diğer tarafındaki çözümleyici adresi, ad alanının oraya yolu yoksa işe yaramaz. Herhangi bir dosyayı düzenlemeden önce alıcıyı doğrulayın.

Tarayıcıdaki IP denetim sayfası ad sorgularının nereye gittiğini söyleyemez. Bir HTTP bağlantısının nereye gittiğini söyler.

Adım 4: İki arıza sınıfını farklı düzeltin

Genel adlar çalışırken hizmet adları başarısız olursa sorun konteyner ağının içindeki hizmet keşfidir, genel çözümleyici listesi değil. Her genel DNS adresini değiştirmek, ağın keşif mekanizmasından hiç istenmemiş kayıtları oluşturmaz.

İki sınıf da başarısız olursa çözümleyiciye erişilebilirlikle başlayın. Yalnızca biri başarısız olursa keşif mekanizmasıyla başlayın. İkisinin sahipleri farklıdır, bu yüzden bir onarım ikisini birden asla kapsamaz.

Adım 5: Yeniden oluşturduktan sonra yeniden test edin

Yapılandırmayı çalışma zamanının desteklediği mekanizmayla değiştirin, ardından çalışan bir konteynerin içindeki dosyaları düzenlemek yerine konteynerleri yeniden oluşturun. Yeni bir özel ad, yeni bir genel ad ve aramayı izleyen uygulama isteğini test edin. Bir değişiklik /etc/resolv.conf konteynerin içinde yeniden oluşturmada kaybolur ve onarım işe yaramadığında yaradığına sizi ikna eder.

Çözümleyicinin sahibini ve beklenen ad alanını paylaşılan ağ tanımının yanına not edin. Sıradaki kişi ikisine de ihtiyaç duyacak.