Der Pool-Überlappungsfehler von Docker ist kein VPN-Routenproblem

Docker weigert sich, ein Netzwerk zu erstellen, mit der Meldung, der Pool überlappe einen anderen in diesem Adressraum, und jemand beschließt, die VPN-Route müsse die Ursache sein. Das kann sie nicht. Dieser Fehler entsteht, während ein Pool zugewiesen wird, bevor auch nur ein einziges Paket existiert, und eine manuelle Kernel-Route hat keinen Einfluss darauf. Die VPN zählt einen Schritt später, wenn ein Container, der bereits eine Adresse hat, nach dem Auftauchen einer Route nicht mehr erreichbar ist. Zwei Probleme, zwei Beweisgruppen, und ihre Vermischung erzeugt eine Änderung, die keines von beiden behebt.

Zwei Fehler, die gleich aussehen

Der Zuweisungsfehler ist arithmetisch. Docker vergleicht das angeforderte Subnetz mit den Subnetzen, die es bereits verwaltet, findet eine Überschneidung und lehnt ab. Es läuft noch nichts, also gibt es keine Route, keinen Container und keinen Verkehr zum Untersuchen.

Das Laufzeitsymptom ist eine Erreichbarkeitsfrage. Ein Container, der gestern antwortete, antwortet jetzt nicht mehr, und in der Routing-Tabelle des Hosts hat sich etwas geändert. Der Container hält seine Adresse weiterhin; die Frage ist, welchen Pfad diese Adresse nimmt.

Beides sind Adressplanprobleme. Nur eines davon ist ein Docker-Problem.

Lies zuerst die zugewiesenen Pools

Liste die Netzwerke auf und untersuche die, die sich überschneiden könnten. Das Subnetz steht in der IPAM-Konfiguration, und die angeschlossenen Container werden separat aufgeführt:

docker network ls
docker network inspect EXISTING_NETWORK

Vergleiche dieses Subnetz mit dem Pool, den das neue Netzwerk anfordert, und denk daran, dass Compose pro Projekt ein eigenes Standardnetzwerk anlegt. Ein Konflikt mit einem vergessenen Projekt sieht genauso aus wie ein Konflikt mit dem Daemon.

Eine statische ipv4_address an einem Dienst ist die Adresse eines Containers, nicht die Pool-Definition. Sie zu ändern beseitigt keine Überlappung, denn die Überlappung besteht zwischen Netzwerk-Subnetzen und nicht zwischen Containern. Dockers network-create-Referenz verlangt nicht überlappende Subnetze für die gewöhnliche Bridge-Zuweisung und dokumentiert, wie man eines explizit auswählt.

Wähle ein Präfix, das die VPN übersteht

Der unmittelbare Konflikt und die künftige Route werden von derselben Entscheidung bestimmt, also triff sie einmal. Vergleiche den Kandidatenbereich mit dem LAN, mit jedem VPN-Ziel, das der Host erreichen kann, und mit jedem anderen verwendeten Overlay.

Ein Präfix, das Docker zufriedenstellt und mit dem entfernten Netz kollidiert, liefert einen Container, der sauber startet und in dem Moment unerreichbar wird, in dem der Tunnel steht. Das ist der zweite Fehler in diesem Artikel, und er ist später viel schwerer zu diagnostizieren als jetzt zu vermeiden.

Schreib die gewählten Bereiche irgendwo auf, wo das nächste Projekt sie lesen kann. Ein einzeiliges Register zugewiesener Präfixe ist billiger als eine Woche unerklärlicher Timeouts.

Ein Netzwerk bewusst außer Betrieb nehmen oder ändern

Für ein neues Compose-Netzwerk setze das ungenutzte Präfix in der IPAM-Konfiguration des Netzwerks. Für ein bestehendes Projekt plane die Umnummerierung: feste Adressen, abhängige Dienste und der Schritt des Neuerstellens des Netzwerks müssen alle berücksichtigt werden, denn das Bearbeiten von YAML nummeriert ein laufendes Netzwerk nicht um.

Besitzt ein veraltetes Netzwerk die konfliktbehaftete Zuweisung, prüfe vor dem Entfernen, wer angebunden ist. docker network rm verweigert, solange aktive Endpunkte existieren, und docker stop nimmt Containernamen oder IDs statt eines Netzwerknamens. Einen Container zu stoppen entfernt auch nicht die Netzwerkdefinition, die den Pool hält.

Ein breites prune ist kein Diagnosewerkzeug. Es erreicht unbeteiligte Projekte und zerstört die Beweise, die du gerade sammeln wolltest.

Standard-Pools helfen nur der nächsten Zuweisung

Die Einstellung für den Standard-Adresspool des Daemons verbessert künftige automatische Zuweisungen, indem sie diese aus den von dir reservierten Bereichen heraushält. Sie vergibt vorhandenen Netzwerken nicht rückwirkend neue Adressen, und sie löst kein explizites Subnetz, das ein anderes explizites Subnetz überlappt.

Behandle diese Einstellung als separate, geplante Änderung mit eigenem Neustart, nicht als Teil der Reparatur eines Projekts. Beides zu vermischen heißt, dass ein Daemon-Neustart mitten in eine unabhängige Untersuchung fällt. Plane ihn in einem eigenen Zeitfenster. Bestätige dann, dass eine neue automatische Zuweisung tatsächlich außerhalb der von dir reservierten Bereiche landet.

Wenn die Erstellung gelingt, prüfe das tatsächlich laufende Subnetz und stelle dann eine echte Anwendungsanfrage, während die VPN im vorgesehenen Zustand ist. Ist der Pool gültig und der Zugriff schlägt weiterhin fehl, besteht die verbleibende Arbeit aus Routenauswahl, Filterung und Rückweg. Das ist eine Laufzeituntersuchung, und sie macht den Zuweisungsfehler nicht rückwirkend bedeutungslos.

Reihenfolge der Arbeit: Lies die zugewiesenen Pools, wähle ein Präfix, das Docker und die VPN-Ziele gleichermaßen meidet, erstelle das Netzwerk bewusst neu und teste dann eine Anfrage bei aufgebautem Tunnel.