Docker: Während einer VPN-Sitzung sind keine vordefinierten Adresspools mehr übrig

Der Fehler ist spezifisch: Docker findet kein akzeptables automatisches Subnetz für ein neues Bridge-Netzwerk. Das heißt nicht, dass der Maschine die Adressen ausgegangen sind, und es heißt nicht, dass das VPN defekt ist. Zwei Fragen entscheiden die Diagnose: welche Kandidatenblöcke der Daemon sehen kann und welche davon sein Allokator in dieser Umgebung ausschließt. Arbeiten Sie sie in dieser Reihenfolge ab, denn die zweite Frage ist sinnlos, solange die erste nicht beantwortet ist.

Bestätigen Sie, was fehlgeschlagen ist, bevor Sie etwas ändern

Führen Sie die folgenden Schritte auf dem Host aus, der den Daemon ausführt. Eine Shell, die mit einem entfernten Kontext spricht, beschreibt eine andere Maschine, und allein dieser Fehler kann eine Stunde kosten.

Notieren Sie gleichzeitig die Engine-Version im Ticket. Jede Heuristik im Rest dieses Runbooks ist versionsgebunden, und eine Aussage ohne Version ist ein Gerücht.

Zählen Sie die Zuweisungen, die Sie bereits haben

Listen Sie die Netzwerke auf und sehen Sie sich dann die wichtigen an: docker network ls, gefolgt von docker network inspect NETWORK_NAME. Lesen Sie deren IPAM-Subnetze und die jeweils angeschlossenen Container. Mehrere Compose-Projekte verbrauchen mehr Blöcke, als ihre Containerzahlen vermuten lassen, weil jedes Projekt dazu neigt, sein eigenes Standardnetzwerk anzulegen. Ein gestoppter Container gibt die Zuweisung seines Netzwerks nicht frei.

Prüfen Sie auch die Poolkonfiguration, denn ein Standardpool hat einen Basisbereich und eine Präfixgröße pro Netzwerk. Große Zuweisungen pro Netzwerk erschöpfen die verfügbaren Blöcke schneller, und das ist eine Kapazitätstatsache, kein Routingproblem.

Schreiben Sie die Zahl auf. Sie ist die Ausgangsbasis, die Ihnen sagt, ob die nächste Änderung geholfen hat.

Vergleichen Sie die Sicht des Daemons auf Routen

Ein VPN kann die Kandidatenauswahl beeinflussen, aber die konkrete Implementierung entscheidet wie. In Moby 28.2.2 auf Linux sammelt InferReservedNetworks Nameserver-Adressen und bestimmte On-Link-IPv4-Routen und reserviert nicht einfach jede Route aus jeder Tabelle. Gesammelte Link-Routen schließen außerdem eine unspezifizierte Zieladresse aus, sodass eine einzelne 0.0.0.0/1-Route nicht alle Adressen reserviert. Ein anderes breites On-Link-Präfix wie 128.0.0.0/1 kann die vertrauten Kandidatenbereiche 172 und 192 schneiden.

Vergleichen Sie ip -4 route show table all vor und nach dem Verbindungsaufbau des VPN auf dem Host des Daemons. Das Delta ist der Beweis, und die Version ist der Geltungsbereich der Aussage.

Verallgemeinern Sie die Heuristik einer Version nicht auf alle Versionen. So wird aus einer Forumsantwort eine Richtlinienänderung.

Wählen Sie die kleinste Korrektur, die funktioniert

Wenn ein bestätigt ungenutztes Netzwerk einen Block enthält, den Sie brauchen, planen Sie dessen gezielte Stilllegung mit dem Eigentümer, statt breit zu beschneiden. Für ein neues Netzwerk vermeidet ein ausdrücklich geprüftes ungenutztes Subnetz die Abhängigkeit von der automatischen Auswahl vollständig. Dieses Subnetz muss dennoch echte Docker-, LAN- und erforderliche VPN-Ziele meiden, denn privat bedeutet nicht sicher. Das Routen eines echten entfernten Präfixes würde den Zuweisungsfehler gegen kaputten Zugriff eintauschen.

Das Ändern von default-address-pools ist eine breitere Richtlinie zu künftigen Zuweisungen. Wählen Sie eine konfliktfreie Basis und eine passende zugewiesene Größe, führen Sie sie mit den vorhandenen Daemon-Einstellungen zusammen und planen Sie die dokumentierte Neustartwirkung. Bestehende Netzwerke werden nicht stillschweigend umnummeriert.

Deaktivieren Sie keine Unternehmens-Routenübertragungen, damit die Zuweisung gelingt. Ein ausdrücklicher Adressplan löst das lokale Problem meist, ohne eine verbindliche Richtlinie abzuschwächen.

Akzeptieren Sie Zuweisung und Routing getrennt

Untersuchen Sie nach der Änderung das Subnetz, das Docker tatsächlich angelegt hat, und testen Sie die VPN- und lokalen Abhängigkeiten der Anwendung. Erfolgreiche Zuweisung und korrektes Routing zur Laufzeit sind zwei verschiedene Abnahmeprüfungen, und das Bestehen der ersten ist kein Beweis für die zweite. Wenn die Anwendung eine Ressource hinter dem Tunnel nicht erreicht, haben Sie ein Routingproblem, das der Poolfehler verdeckt hat. Halten Sie beide Ergebnisse im Ticket fest.

Bewahren Sie das Routendelta und die Poolanzahl zusammen mit dem Änderungsdatensatz auf, denn das nächste VPN-Client-Update kann das erste ändern, ohne Docker zu berühren.

Das Runbook ist vollständig, wenn jemand anderes diese beiden Prüfungen wiederholen und dasselbe Ergebnis erhalten kann.