Docker: tidak ada kumpulan alamat yang telah ditentukan selama sesi VPN

Kegagalannya spesifik: Docker tidak dapat menemukan subnet otomatis yang dapat diterima untuk jaringan jembatan baru. Ini bukan berarti mesin kehabisan alamat, dan bukan berarti VPN rusak. Dua pertanyaan menentukan diagnosis: blok kandidat mana yang dapat dilihat daemon, dan mana di antaranya yang dikecualikan pengalokasinya di lingkungan ini. Kerjakan keduanya dalam urutan itu, karena pertanyaan kedua tidak bermakna sampai yang pertama dijawab.

Pastikan apa yang gagal sebelum mengubah apa pun

Jalankan langkah-langkah di bawah ini dari host yang menjalankan daemon. Shell yang berbicara dengan konteks jarak jauh sedang menjelaskan mesin lain, dan kesalahan itu saja bisa membuang satu jam.

Catat versi Engine di tiket pada saat yang sama. Setiap heuristik di sisa panduan ini dibatasi versi, dan klaim tanpa versi adalah rumor.

Hitung alokasi yang sudah Anda miliki

Daftar jaringan, lalu periksa yang penting: docker network ls diikuti docker network inspect NETWORK_NAME. Baca subnet IPAM dan kontainer yang terpasang pada masing-masing. Beberapa proyek Compose mengonsumsi lebih banyak blok daripada yang disarankan jumlah kontainernya, karena setiap proyek cenderung membuat jaringan bawaannya sendiri. Kontainer yang berhenti tidak melepaskan alokasi jaringannya.

Periksa juga konfigurasi kumpulan, karena kumpulan bawaan memiliki rentang dasar dan ukuran prefiks per jaringan. Alokasi besar per jaringan menghabiskan blok yang tersedia lebih cepat, dan itu fakta kapasitas, bukan masalah perutean.

Tuliskan jumlahnya. Itulah garis dasar yang memberi tahu Anda apakah perubahan berikutnya membantu.

Bandingkan pandangan daemon tentang rute

VPN dapat memengaruhi pemilihan kandidat, tetapi implementasi persisnya menentukan caranya. Di Moby 28.2.2 pada Linux, InferReservedNetworks mengumpulkan alamat server nama dan rute IPv4 on-link tertentu, dan tidak sekadar mencadangkan setiap rute dari setiap tabel. Rute tautan yang dikumpulkan juga mengecualikan alamat tujuan yang tidak ditentukan, sehingga satu rute 0.0.0.0/1 saja tidak mencadangkan semua alamat. Prefiks on-link luas yang lain, seperti 128.0.0.0/1, dapat memotong rentang kandidat yang sudah dikenal 172 dan 192.

Bandingkan ip -4 route show table all sebelum dan sesudah VPN terhubung, pada host daemon. Selisihnya adalah bukti, dan versinya adalah cakupan klaim.

Jangan menggeneralisasi heuristik satu rilis ke semua rilis. Begitulah jawaban forum menjadi perubahan kebijakan.

Pilih perbaikan terkecil yang berhasil

Jika jaringan tak terpakai yang terkonfirmasi menyimpan blok yang Anda butuhkan, rencanakan penghentian tertargetnya bersama pemiliknya alih-alih memangkas secara luas. Untuk jaringan baru, subnet tak terpakai yang ditinjau secara eksplisit menghindari ketergantungan pada pemilihan otomatis sama sekali. Subnet itu tetap harus menghindari tujuan Docker, LAN, dan VPN yang nyata dan diwajibkan, karena privat tidak berarti aman. Merutekan prefiks jarak jauh yang nyata akan menukar kesalahan alokasi dengan akses yang rusak.

Mengubah default-address-pools adalah kebijakan yang lebih luas tentang alokasi di masa depan. Pilih basis yang tidak bertentangan dan ukuran teralokasi yang sesuai, gabungkan dengan pengaturan daemon yang ada, dan rencanakan dampak mulai ulang yang didokumentasikan. Jaringan yang ada tidak dinomori ulang secara diam-diam.

Jangan menonaktifkan pengiriman rute perusahaan agar alokasi berhasil. Rencana alamat yang eksplisit biasanya menyelesaikan masalah lokal tanpa melemahkan kebijakan wajib.

Terima alokasi dan perutean secara terpisah

Setelah perubahan, periksa subnet yang benar-benar dibuat Docker dan uji dependensi VPN serta lokal aplikasi. Alokasi yang berhasil dan perutean yang benar saat berjalan adalah dua pemeriksaan penerimaan yang berbeda, dan lulus yang pertama bukan bukti untuk yang kedua. Jika aplikasi tidak dapat menjangkau sumber daya di balik terowongan, Anda memiliki masalah perutean yang disembunyikan oleh kesalahan kumpulan. Catat kedua hasil di tiket.

Simpan selisih rute dan jumlah kumpulan bersama catatan perubahan, karena pembaruan klien VPN berikutnya dapat mengubah yang pertama tanpa menyentuh Docker.

Panduan ini lengkap ketika orang lain dapat mengulangi kedua pemeriksaan itu dan mendapatkan jawaban yang sama.