Ошибка перекрытия пулов Docker — не проблема маршрута VPN

Docker отказывается создавать сеть с сообщением, что пул перекрывается с другим в этом адресном пространстве, и кто-то решает, что причиной должен быть маршрут VPN. Этого не может быть. Эта ошибка возникает, пока выделяется пул, до появления хотя бы одного пакета, и ручной маршрут ядра на неё не влияет. VPN важен шагом позже, когда контейнер, у которого уже есть адрес, перестаёт быть доступным после появления маршрута. Две проблемы, два набора доказательств, и их смешение даёт изменение, которое не исправляет ни одну.

Две похожие ошибки

Ошибка выделения арифметическая. Docker сравнивает запрошенную подсеть с теми, которыми уже управляет, находит пересечение и отказывает. Ничего ещё не работает, поэтому нет ни маршрута, ни контейнера, ни трафика для проверки.

Симптом во время работы — вопрос доступности. Контейнер, который отвечал вчера, не отвечает сейчас, и что-то изменилось в таблице маршрутизации хоста. Контейнер по-прежнему держит свой адрес; вопрос в том, какой путь выбирает этот адрес.

Обе — проблемы плана адресов. Только одна из них проблема Docker.

Сначала прочитайте выделенные пулы

Перечислите сети и проверьте те, что могут пересекаться. Подсеть живёт в конфигурации IPAM, а подключённые контейнеры перечислены отдельно:

docker network ls
docker network inspect EXISTING_NETWORK

Сравните эту подсеть с пулом, который запрашивает новая сеть, и помните, что Compose создаёт собственную сеть по умолчанию для каждого проекта. Конфликт с забытым проектом выглядит точно так же, как конфликт с демоном.

Статический ipv4_address у сервиса — это адрес одного контейнера, а не определение пула. Его изменение не устраняет перекрытие, потому что перекрытие между подсетями сетей, а не между контейнерами. Справочник network-create Docker требует неперекрывающихся подсетей для обычного выделения через мост и описывает, как выбрать одну явно.

Выберите префикс, который переживёт VPN

Непосредственный конфликт и будущий маршрут решаются одним и тем же выбором, поэтому сделайте его один раз. Сравните диапазон-кандидат с LAN, с каждым пунктом назначения VPN, до которого может добраться хост, и с любым другим используемым overlay.

Префикс, который удовлетворяет Docker и конфликтует с удалённой сетью, даёт контейнер, который чисто запускается и становится недоступным в тот момент, когда поднимается туннель. Это вторая ошибка в этой статье, и её гораздо труднее диагностировать позже, чем избежать сейчас.

Запишите выбранные диапазоны туда, откуда следующий проект сможет их прочитать. Реестр выделенных префиксов в одну строку дешевле недели необъяснимых тайм-аутов.

Выведите или измените сеть намеренно

Для новой сети Compose задайте неиспользуемый префикс в конфигурации IPAM сети. Для существующего проекта спланируйте перенумерацию: фиксированные адреса, зависимые сервисы и шаг пересоздания сети — всё нужно учесть, потому что редактирование YAML не перенумеровывает работающую сеть.

Если устаревшая сеть владеет конфликтующим выделением, проверьте, кто к ней подключён, прежде чем её удалять. docker network rm отказывает, пока существуют активные endpoint'ы, а docker stop принимает имена или ID контейнеров, а не имя сети. Остановка контейнера также не удаляет определение сети, которое держит пул.

Широкий prune — не инструмент диагностики. Он добирается до несвязанных проектов и уничтожает доказательства, которые вы собирались собрать.

Пулы по умолчанию помогают только следующему выделению

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

Относитесь к этой настройке как к отдельному, запланированному изменению с собственной перезагрузкой, а не как к части ремонта одного проекта. Смешение двух означает, что перезагрузка демона попадает в середину несвязанного расследования. Запланируйте её в отдельное окно. Затем подтвердите, что одно новое автоматическое выделение действительно попадает вне зарезервированных диапазонов.

Когда создание удастся, проверьте фактически работающую подсеть и затем выполните один настоящий запрос приложения, когда VPN находится в предполагаемом состоянии. Если пул корректен, а доступ всё ещё не работает, оставшаяся работа — выбор маршрута, фильтрация и обратный путь. Это расследование во время работы, и оно не делает ошибку выделения задним числом бессмысленной.

Порядок работы: прочитайте выделенные пулы, выберите префикс, который обходит и Docker, и пункты назначения VPN, намеренно пересоздайте сеть, затем проверьте один запрос с поднятым туннелем.