Docker: під час сеансу VPN не залишається передвизначених пулів адрес

Збій конкретний: Docker не знаходить прийнятної автоматичної підмережі для нової мостової мережі. Це не означає, що в машини закінчилися адреси, і не означає, що VPN зламано. Діагноз визначають два питання: які блоки-кандидати бачить демон і які з них його розподільник виключає в цьому середовищі. Пройдіть їх саме в такому порядку, бо друге питання безглузде, доки не отримано відповіді на перше.

Підтвердьте, що саме зламалося, перш ніж щось змінювати

Виконайте наведені нижче кроки на хості, який запускає демон. Оболонка, що спілкується з віддаленим контекстом, описує іншу машину, і сама ця помилка може коштувати години.

Одночасно запишіть версію Engine у заявку. Кожна евристика в решті цього посібника прив’язана до версії, а твердження без версії — це чутка.

Порахуйте виділення, які у вас уже є

Перелічіть мережі, потім огляньте ті, що важливі: docker network ls, а за ним docker network inspect NETWORK_NAME. Прочитайте їхні підмережі IPAM і контейнери, під’єднані до кожної. Кілька проєктів Compose споживають більше блоків, ніж можна припустити з кількості їхніх контейнерів, бо кожен проєкт схильний створювати власну мережу за замовчуванням. Зупинений контейнер не звільняє виділення своєї мережі.

Перевірте й конфігурацію пулу, оскільки пул за замовчуванням має базовий діапазон і розмір префікса для кожної мережі. Великі виділення на мережу швидше вичерпують доступні блоки, і це факт ємності, а не проблема маршрутизації.

Запишіть число. Саме воно є базовою лінією, що показує, чи допомогла наступна зміна.

Порівняйте, як демон бачить маршрути

VPN може впливати на вибір кандидатів, але конкретна реалізація вирішує як. У Moby 28.2.2 на Linux InferReservedNetworks збирає адреси серверів імен і певні on-link маршрути IPv4 і не просто резервує кожен маршрут з кожної таблиці. Зібрані маршрути зв’язку також виключають неуточнену адресу призначення, тож один маршрут 0.0.0.0/1 сам по собі не резервує всі адреси. Інший широкий on-link префікс, наприклад 128.0.0.0/1, може перетнути знайомі діапазони кандидатів 172 і 192.

Порівняйте ip -4 route show table all до і після підключення VPN на хості демона. Різниця — це доказ, а версія — межі твердження.

Не переносьте евристику одного випуску на всі випуски. Саме так відповідь із форуму перетворюється на зміну політики.

Виберіть найменше виправлення, яке працює

Якщо підтверджена невикористовувана мережа тримає потрібний вам блок, плануйте її цілеспрямоване виведення разом із власником, а не широке обрізання. Для нової мережі явно перевірена невикористовувана підмережа повністю позбавляє залежності від автоматичного вибору. Ця підмережа все одно має уникати реальних призначень Docker, LAN і обов’язкових VPN, бо приватний не означає безпечний. Маршрутизація реального віддаленого префікса обміняла б помилку виділення на зламаний доступ.

Зміна default-address-pools — це ширша політика щодо майбутніх виділень. Виберіть неконфліктну базу й відповідний виділений розмір, об’єднайте його з наявними налаштуваннями демона та сплануйте задокументований вплив перезапуску. Наявні мережі не перенумеровуються мовчки.

Не вимикайте розсилання корпоративних маршрутів, щоб виділення вдалося. Явний план адрес зазвичай вирішує локальну проблему, не послаблюючи обов’язкову політику.

Приймайте виділення й маршрутизацію окремо

Після зміни огляньте підмережу, яку Docker справді створив, і перевірте залежності застосунку від VPN і локальних ресурсів. Успішне виділення й правильна маршрутизація під час роботи — дві різні перевірки приймання, і проходження першої не є доказом другої. Якщо застосунок не може дістатися ресурсу за тунелем, у вас проблема маршрутизації, яку приховувала помилка пулу. Запишіть обидва результати в заявку.

Зберігайте різницю маршрутів і число пулу разом із записом про зміну, бо наступне оновлення клієнта VPN може змінити перше, не торкаючись Docker.

Посібник завершено, коли хтось інший може повторити ці дві перевірки й отримати ту саму відповідь.