Galat tumpang-tindih pool Docker bukan masalah rute VPN

Docker menolak membuat jaringan dengan pesan bahwa pool tumpang-tindih dengan yang lain di ruang alamat ini, dan seseorang memutuskan bahwa rute VPN pasti penyebabnya. Itu tidak mungkin. Galat itu dihasilkan saat pool dialokasikan, sebelum satu paket pun ada, dan rute kernel manual tidak berpengaruh padanya. VPN baru penting satu langkah kemudian, ketika kontainer yang sudah punya alamat berhenti dapat dijangkau setelah sebuah rute muncul. Dua masalah, dua set bukti, dan mencampurnya menghasilkan perubahan yang tidak memperbaiki keduanya.

Dua galat yang tampak sama

Galat alokasi bersifat aritmetika. Docker membandingkan subnet yang Anda minta dengan subnet yang sudah dikelolanya, menemukan irisan, lalu menolak. Belum ada yang berjalan, jadi tidak ada rute, tidak ada kontainer, dan tidak ada lalu lintas untuk diperiksa.

Gejala saat berjalan adalah pertanyaan keterjangkauan. Kontainer yang kemarin menjawab kini tidak menjawab, dan sesuatu berubah di tabel perutean host. Kontainer masih memegang alamatnya; pertanyaannya adalah jalur mana yang diambil alamat itu.

Keduanya masalah rencana alamat. Hanya satu yang merupakan masalah Docker.

Baca dulu pool yang dialokasikan

Daftar jaringannya dan periksa yang mungkin beririsan. Subnet berada di konfigurasi IPAM, dan kontainer yang terpasang didaftar secara terpisah:

docker network ls
docker network inspect EXISTING_NETWORK

Bandingkan subnet itu dengan pool yang diminta jaringan baru, dan ingat bahwa Compose membuat jaringan bawaannya sendiri per proyek. Konflik dengan proyek yang Anda lupakan terlihat persis seperti konflik dengan daemon.

ipv4_address statis pada sebuah layanan adalah alamat satu kontainer, bukan definisi pool. Mengubahnya tidak menghapus tumpang-tindih, karena tumpang-tindih itu antar-subnet jaringan, bukan antar-kontainer. Referensi network-create Docker mewajibkan subnet yang tidak tumpang-tindih untuk alokasi jembatan biasa dan mendokumentasikan cara memilihnya secara eksplisit.

Pilih prefiks yang bertahan melewati VPN

Konflik langsung dan rute masa depan diputuskan oleh pilihan yang sama, jadi buatlah sekali. Bandingkan rentang kandidat dengan LAN, dengan setiap tujuan VPN yang dapat dijangkau host, dan dengan overlay lain yang sedang dipakai.

Prefiks yang memuaskan Docker dan bertabrakan dengan jaringan jauh memberi Anda kontainer yang mulai bersih dan menjadi tidak terjangkau begitu terowongan naik. Itulah galat kedua dalam artikel ini, dan jauh lebih sulit didiagnosis nanti daripada dihindari sekarang.

Catat rentang yang dipilih di tempat yang bisa dibaca proyek berikutnya. Register satu baris berisi prefiks yang dialokasikan lebih murah daripada sepekan timeout tanpa penjelasan.

Pensiunkan atau ubah jaringan dengan sengaja

Untuk jaringan Compose baru, atur prefiks yang tidak terpakai di konfigurasi IPAM jaringan. Untuk proyek yang sudah ada, rencanakan penomoran ulang: alamat tetap, layanan yang bergantung, dan langkah pembuatan ulang jaringan semuanya harus diperhitungkan, karena menyunting YAML tidak menomori ulang jaringan yang berjalan.

Jika jaringan usang memiliki alokasi yang berkonflik, periksa siapa yang terpasang sebelum menghapusnya. docker network rm menolak selama ada endpoint aktif, dan docker stop menerima nama atau ID kontainer, bukan nama jaringan. Menghentikan kontainer juga tidak menghapus definisi jaringan yang menyimpan pool.

Prune yang luas bukan alat diagnosis. Ia menjangkau proyek yang tidak terkait dan menghancurkan bukti yang hendak Anda kumpulkan.

Pool bawaan hanya membantu alokasi berikutnya

Setelan pool alamat bawaan daemon memperbaiki alokasi otomatis mendatang dengan menjaganya di luar rentang yang Anda cadangkan. Setelan itu tidak mengalamatkan ulang jaringan yang sudah ada secara surut, dan tidak menyelesaikan subnet eksplisit yang tumpang-tindih dengan subnet eksplisit lain.

Perlakukan setelan itu sebagai perubahan terpisah yang terencana dengan restart-nya sendiri, bukan sebagai bagian dari perbaikan satu proyek. Mencampur keduanya berarti restart daemon jatuh di tengah penyelidikan yang tidak terkait. Jadwalkan di jendelanya sendiri. Lalu pastikan satu alokasi otomatis baru benar-benar jatuh di luar rentang yang Anda cadangkan.

Setelah pembuatan berhasil, verifikasi subnet yang benar-benar berjalan lalu lakukan satu permintaan aplikasi nyata dengan VPN dalam keadaan yang dimaksud. Jika pool valid dan akses masih gagal, pekerjaan tersisa adalah pemilihan rute, penyaringan, dan jalur balik. Itu penyelidikan saat berjalan, dan itu tidak membuat galat alokasi menjadi tak bermakna secara surut.

Urutan kerja: baca pool yang dialokasikan, pilih prefiks yang menghindari Docker dan tujuan VPN sekaligus, buat ulang jaringan dengan sengaja, lalu uji satu permintaan dengan terowongan menyala.