Docker: VPN oturumu sırasında önceden tanımlı adres havuzu kalmıyor

Arıza belirgin: Docker yeni bir köprü ağı için kabul edilebilir otomatik bir alt ağ bulamıyor. Bu, makinenin adreslerinin tükendiği anlamına gelmediği gibi VPN’in bozuk olduğu anlamına da gelmez. Teşhisi iki soru belirler: daemon hangi aday blokları görebiliyor ve bunlardan hangilerini atayıcısı bu ortamda dışlıyor. Bunları tam bu sırayla ele alın, çünkü birinci soru yanıtlanmadan ikincisi anlamsızdır.

Herhangi bir şeyi değiştirmeden önce neyin başarısız olduğunu doğrulayın

Aşağıdaki adımları daemonu çalıştıran ana makineden yürütün. Uzak bir bağlamla konuşan bir kabuk başka bir makineyi anlatıyordur ve yalnızca bu hata bir saat harcatabilir.

Aynı anda bilete Engine sürümünü de not edin. Bu kılavuzun geri kalanındaki her sezgisel yöntem sürüme bağlıdır ve sürümsüz bir iddia söylentidir.

Zaten sahip olduğunuz atamaları sayın

Ağları listeleyin, ardından önemli olanları inceleyin: docker network ls, ardından docker network inspect NETWORK_NAME. Bunların IPAM alt ağlarını ve her birine bağlı konteynerleri okuyun. Birkaç Compose projesi konteyner sayılarının ima ettiğinden daha fazla blok tüketir, çünkü her proje kendi varsayılan ağını oluşturma eğilimindedir. Durdurulmuş bir konteyner ağının atamasını serbest bırakmaz.

Havuz yapılandırmasını da denetleyin, çünkü varsayılan havuzun bir temel aralığı ve ağ başına önek boyutu vardır. Ağ başına büyük atamalar mevcut blokları daha hızlı tüketir ve bu bir kapasite gerçeğidir, yönlendirme sorunu değildir.

Sayıyı yazın. Sonraki değişikliğin yardımcı olup olmadığını söyleyen temel çizgi budur.

Daemonun yollara bakışını karşılaştırın

VPN aday seçimini etkileyebilir, ancak nasıl olacağına tam uygulama karar verir. Linux üzerinde Moby 28.2.2 sürümünde InferReservedNetworks ad sunucusu adreslerini ve belirli on-link IPv4 yollarını toplar ve her tablodaki her yolu basitçe ayırmaz. Toplanan bağlantı yolları ayrıca belirtilmemiş bir hedef adresi dışlar, bu nedenle tek bir 0.0.0.0/1 yolu tüm adresleri ayırmaz. Başka bir geniş on-link öneki, örneğin 128.0.0.0/1, tanıdık 172 ve 192 aday aralıklarını kesebilir.

VPN bağlanmadan önce ve sonra ip -4 route show table all çıktısını daemonun ana makinesinde karşılaştırın. Fark kanıttır, sürüm ise iddianın kapsamıdır.

Bir sürümün sezgisel yöntemini tüm sürümlere genellemeyin. Bir forum yanıtı böylece ilke değişikliğine dönüşür.

İşleyen en küçük düzeltmeyi seçin

Onaylanmış kullanılmayan bir ağ ihtiyacınız olan bloğu tutuyorsa, geniş biçimde budamak yerine sahibiyle birlikte hedefli olarak devreden çıkarılmasını planlayın. Yeni bir ağ için açıkça gözden geçirilmiş kullanılmayan bir alt ağ, otomatik seçime bağımlılığı tamamen önler. O alt ağ yine de gerçek Docker, LAN ve gerekli VPN hedeflerinden kaçınmalıdır, çünkü özel olmak güvenli olmak anlamına gelmez. Gerçek bir uzak öneki yönlendirmek, atama hatasını kopuk erişimle değiştirirdi.

default-address-pools değiştirmek gelecekteki atamalarla ilgili daha geniş bir ilkedir. Çakışmayan bir taban ve uygun atanmış boyut seçin, bunu mevcut daemon ayarlarıyla birleştirin ve belgelenmiş yeniden başlatma etkisini planlayın. Mevcut ağlar sessizce yeniden numaralandırılmaz.

Atamanın başarılı olması için şirket yol iletimini devre dışı bırakmayın. Açık bir adres planı genellikle zorunlu bir ilkeyi zayıflatmadan yerel sorunu çözer.

Atamayı ve yönlendirmeyi ayrı ayrı kabul edin

Değişiklikten sonra Docker’ın gerçekte oluşturduğu alt ağı inceleyin ve uygulamanın VPN ile yerel bağımlılıklarını test edin. Başarılı atama ve çalışma zamanında doğru yönlendirme iki farklı kabul denetimidir ve birincisini geçmek ikincisi için kanıt değildir. Uygulama tünelin arkasındaki bir kaynağa ulaşamıyorsa, havuz hatasının gizlediği bir yönlendirme sorununuz var. İki sonucu da bilete kaydedin.

Yol farkını ve havuz sayısını değişiklik kaydıyla birlikte saklayın, çünkü sonraki VPN istemci güncellemesi Docker’a dokunmadan birincisini değiştirebilir.

Kılavuz, başka biri bu iki denetimi yineleyip aynı yanıtı aldığında tamamdır.