De pool-overlapfout van Docker is geen VPN-routeprobleem

Docker weigert een netwerk aan te maken met de melding dat de pool overlapt met een andere in deze adresruimte, en iemand besluit dat de VPN-route de oorzaak moet zijn. Dat kan niet. Die fout ontstaat terwijl een pool wordt toegewezen, voordat er ook maar één pakket bestaat, en een handmatige kernelroute heeft er geen invloed op. De VPN telt een stap later, wanneer een container die al een adres heeft onbereikbaar wordt nadat een route verschijnt. Twee problemen, twee bewijssets, en ze door elkaar halen levert een wijziging op die geen van beide oplost.

Twee fouten die op elkaar lijken

De toewijzingsfout is rekenkundig. Docker vergelijkt het subnet dat je hebt aangevraagd met de subnetten die het al beheert, vindt een doorsnede en weigert. Er draait nog niets, dus er is geen route, geen container en geen verkeer om te inspecteren.

Het runtime-symptoom is een bereikbaarheidsvraag. Een container die gisteren antwoordde, antwoordt nu niet, en er is iets veranderd in de routetabel van de host. De container houdt zijn adres nog steeds; de vraag is welk pad dat adres neemt.

Beide zijn adresplanproblemen. Slechts één ervan is een Docker-probleem.

Lees eerst de toegewezen pools

Vermeld de netwerken en inspecteer de netwerken die kunnen overlappen. Het subnet staat in de IPAM-configuratie, en de aangesloten containers worden apart vermeld:

docker network ls
docker network inspect EXISTING_NETWORK

Vergelijk dat subnet met de pool die het nieuwe netwerk aanvraagt, en onthoud dat Compose per project een eigen standaardnetwerk maakt. Een conflict met een vergeten project lijkt precies op een conflict met de daemon.

Een statisch ipv4_address op een service is het adres van één container, niet de pooldefinitie. Het wijzigen ervan haalt geen overlap weg, want de overlap zit tussen netwerksubnetten en niet tussen containers. Dockers network-create-referentie vereist niet-overlappende subnetten voor gewone bridgetoewijzing en documenteert hoe je er expliciet een kiest.

Kies een prefix dat de VPN overleeft

Het onmiddellijke conflict en de toekomstige route worden door dezelfde keuze bepaald, dus maak die één keer. Vergelijk het kandidaatbereik met het LAN, met elke VPN-bestemming die de host kan bereiken, en met elke andere overlay die in gebruik is.

Een prefix dat Docker tevreden stelt en met het externe netwerk botst, geeft je een container die schoon start en onbereikbaar wordt op het moment dat de tunnel staat. Dat is de tweede fout in dit artikel, en die is later veel moeilijker te diagnosticeren dan nu te vermijden.

Schrijf de gekozen bereiken ergens op waar het volgende project ze kan lezen. Een register van één regel met toegewezen prefixen is goedkoper dan een week onverklaarde time-outs.

Haal een netwerk bewust uit gebruik of wijzig het

Voor een nieuw Compose-netwerk stel je het ongebruikte prefix in de IPAM-configuratie van het netwerk in. Voor een bestaand project plan je de hernummering: vaste adressen, afhankelijke services en de stap om het netwerk opnieuw aan te maken moeten allemaal worden meegenomen, want YAML bewerken hernummert een draaiend netwerk niet.

Als een verouderd netwerk de conflicterende toewijzing bezit, inspecteer dan wie er is aangesloten voordat je het verwijdert. docker network rm weigert zolang er actieve endpoints bestaan, en docker stop neemt containernamen of ID's in plaats van een netwerknaam. Een container stoppen verwijdert ook niet de netwerkdefinitie die de pool vasthoudt.

Een brede prune is geen diagnostisch hulpmiddel. Het reikt tot ongerelateerde projecten en vernietigt het bewijs dat je wilde verzamelen.

Standaardpools helpen alleen de volgende toewijzing

De instelling voor de standaardadrespool van de daemon verbetert toekomstige automatische toewijzingen door ze buiten de bereiken te houden die je reserveert. Hij hernummert bestaande netwerken niet met terugwerkende kracht, en hij lost een expliciet subnet dat een ander expliciet subnet overlapt niet op.

Behandel die instelling als een aparte, geplande wijziging met een eigen herstart, niet als onderdeel van het repareren van één project. De twee door elkaar halen betekent dat een daemon-herstart midden in een ongerelateerd onderzoek valt. Plan hem in een eigen venster. Bevestig daarna dat één nieuwe automatische toewijzing daadwerkelijk buiten de bereiken valt die je hebt gereserveerd.

Als het aanmaken lukt, verifieer dan het subnet dat werkelijk draait en doe dan één echte applicatieaanvraag terwijl de VPN in de beoogde staat is. Als de pool geldig is en toegang nog steeds mislukt, is het resterende werk routekeuze, filtering en de terugweg. Dat is een runtime-onderzoek, en het maakt de toewijzingsfout niet met terugwerkende kracht betekenisloos.

Werkvolgorde: lees de toegewezen pools, kies een prefix dat zowel Docker als de VPN-bestemmingen vermijdt, maak het netwerk bewust opnieuw aan en test dan één aanvraag met de tunnel omhoog.