Ralat pertindihan pool Docker bukan masalah laluan VPN

Docker enggan mencipta rangkaian dengan mesej bahawa pool bertindih dengan yang lain dalam ruang alamat ini, dan seseorang membuat kesimpulan bahawa laluan VPN mesti punca. Ia tidak mungkin. Ralat itu dihasilkan semasa pool diperuntukkan, sebelum satu paket pun wujud, dan laluan kernel manual tidak memberi kesan kepadanya. VPN penting satu langkah kemudian, apabila kontena yang sudah mempunyai alamat tidak lagi boleh dicapai selepas laluan muncul. Dua masalah, dua set bukti, dan mencampurkannya menghasilkan perubahan yang tidak membaiki kedua-duanya.

Dua ralat yang kelihatan serupa

Ralat peruntukan bersifat aritmetik. Docker membandingkan subnet yang anda minta dengan subnet yang sudah diuruskannya, menemui persilangan dan enggan. Belum ada apa-apa yang berjalan, jadi tiada laluan, tiada kontena dan tiada trafik untuk diperiksa.

Gejala semasa berjalan ialah persoalan kebolehcapaian. Kontena yang menjawab semalam kini tidak menjawab, dan sesuatu berubah dalam jadual penghalaan hos. Kontena masih memegang alamatnya; persoalannya ialah laluan mana yang diambil oleh alamat itu.

Kedua-duanya masalah pelan alamat. Hanya satu daripadanya masalah Docker.

Baca pool yang diperuntukkan dahulu

Senaraikan rangkaian dan periksa yang mungkin bersilang. Subnet berada dalam konfigurasi IPAM, dan kontena yang dilampirkan disenaraikan secara berasingan:

docker network ls
docker network inspect EXISTING_NETWORK

Bandingkan subnet itu dengan pool yang diminta oleh rangkaian baharu, dan ingat bahawa Compose mencipta rangkaian lalai sendiri bagi setiap projek. Konflik dengan projek yang anda lupa kelihatan sama seperti konflik dengan daemon.

ipv4_address statik pada perkhidmatan ialah alamat satu kontena, bukan definisi pool. Menukarnya tidak menghapuskan pertindihan, kerana pertindihan berlaku antara subnet rangkaian, bukan antara kontena. Rujukan network-create Docker memerlukan subnet yang tidak bertindih untuk peruntukan jambatan biasa dan mendokumenkan cara memilihnya secara eksplisit.

Pilih prefiks yang bertahan melepasi VPN

Konflik segera dan laluan masa depan ditentukan oleh pilihan yang sama, jadi buat sekali sahaja. Bandingkan julat calon dengan LAN, dengan setiap destinasi VPN yang boleh dicapai hos, dan dengan mana-mana overlay lain yang digunakan.

Prefiks yang memuaskan Docker tetapi berlanggar dengan rangkaian jauh memberi anda kontena yang bermula dengan bersih dan menjadi tidak boleh dicapai sebaik terowong dinaikkan. Itulah ralat kedua dalam artikel ini, dan jauh lebih sukar untuk didiagnosis kemudian daripada dielakkan sekarang.

Catat julat yang dipilih di tempat yang boleh dibaca projek seterusnya. Daftar satu baris prefiks yang diperuntukkan lebih murah daripada seminggu tamat masa yang tidak dijelaskan.

Nyahaktifkan atau ubah rangkaian secara sengaja

Untuk rangkaian Compose baharu, tetapkan prefiks yang tidak digunakan dalam konfigurasi IPAM rangkaian. Untuk projek sedia ada, rancang penomboran semula: alamat tetap, perkhidmatan bergantung dan langkah mencipta semula rangkaian semuanya mesti diambil kira, kerana menyunting YAML tidak menomborkan semula rangkaian yang sedang berjalan.

Jika rangkaian lama memiliki peruntukan yang berkonflik, periksa siapa yang dilampirkan sebelum mengalih keluarnya. docker network rm enggan selagi endpoint aktif wujud, dan docker stop mengambil nama atau ID kontena dan bukannya nama rangkaian. Menghentikan kontena juga tidak menghapuskan definisi rangkaian yang memegang pool itu.

Prune yang luas bukan alat diagnosis. Ia menjangkau projek yang tidak berkaitan dan memusnahkan bukti yang anda hendak kumpulkan.

Pool lalai hanya membantu peruntukan seterusnya

Tetapan pool alamat lalai daemon menambah baik peruntukan automatik masa depan dengan menyimpannya di luar julat yang anda tempah. Ia tidak memberi alamat semula kepada rangkaian yang sudah wujud secara retroaktif, dan ia tidak menyelesaikan subnet eksplisit yang bertindih dengan subnet eksplisit lain.

Anggap tetapan itu sebagai perubahan berasingan yang dirancang dengan permulaan semulanya sendiri, bukan sebahagian daripada pembaikan satu projek. Mencampurkan kedua-duanya bermakna permulaan semula daemon berlaku di tengah-tengah siasatan yang tidak berkaitan. Jadualkannya dalam tetingkapnya sendiri. Kemudian sahkan bahawa satu peruntukan automatik baharu benar-benar jatuh di luar julat yang anda tempah.

Setelah penciptaan berjaya, sahkan subnet yang benar-benar berjalan dan kemudian buat satu permintaan aplikasi sebenar dengan VPN dalam keadaan yang dimaksudkan. Jika pool itu sah dan akses masih gagal, kerja yang tinggal ialah pemilihan laluan, penapisan dan laluan pulang. Itu siasatan masa jalan, dan ia tidak menjadikan ralat peruntukan tidak bermakna secara retroaktif.

Urutan kerja: baca pool yang diperuntukkan, pilih prefiks yang mengelakkan Docker dan destinasi VPN sekali gus, cipta semula rangkaian secara sengaja, kemudian uji satu permintaan dengan terowong dinaikkan.