Docker: no queden pools d’adreces predefinits durant una sessió de VPN
L’error del pool predefinit fa referència a l’assignació automàtica, no a les adreces públiques. Compteu les assignacions, compareu les rutes on-link i manteniu la política de VPN intacta.
La fallada és específica: Docker no troba una subxarxa automàtica acceptable per a una xarxa de pont nova. No vol dir que la màquina s’hagi quedat sense adreces, ni que la VPN estigui espatllada. Dues preguntes decideixen el diagnòstic: quins blocs candidats pot veure el dimoni i quins d’ells exclou el seu assignador en aquest entorn. Recorreu-les en aquest ordre, perquè la segona pregunta no té sentit fins que no es respongui la primera.
Confirmeu què ha fallat abans de canviar res
Executeu els passos següents des de l’amfitrió que executa el dimoni. Un intèrpret que parla amb un context remot descriu una altra màquina, i aquest error sol pot fer perdre una hora.
Anoteu també la versió d’Engine al tiquet. Cada heurística de la resta d’aquest manual depèn de la versió, i una afirmació sense versió és un rumor.
Compteu les assignacions que ja teniu
Lliste les xarxes i després inspeccioneu les que importen: docker network ls seguit de docker network inspect NETWORK_NAME. Llegiu-ne les subxarxes IPAM i els contenidors connectats a cadascuna. Diversos projectes de Compose consumeixen més blocs del que suggereixen els seus recomptes de contenidors, perquè cada projecte tendeix a crear la seva pròpia xarxa per defecte. Un contenidor aturat no allibera l’assignació de la seva xarxa.
Reviseu també la configuració del pool, ja que un pool per defecte té un rang base i una mida de prefix per xarxa. Les assignacions grans per xarxa esgoten els blocs disponibles més de pressa, i això és un fet de capacitat, no un problema d’encaminament.
Anoteu el recompte. És la línia base que us diu si el canvi següent ha ajudat.
Compareu la visió que el dimoni té de les rutes
Una VPN pot influir en la selecció de candidats, però la implementació exacta decideix com. A Moby 28.2.2 a Linux, InferReservedNetworks recull adreces de servidors de noms i certes rutes IPv4 on-link, i no reserva simplement cada ruta de cada taula. Les rutes d’enllaç recollides també exclouen una adreça de destinació no especificada, de manera que una ruta 0.0.0.0/1 sola no reserva totes les adreces. Un altre prefix on-link ampli, com ara 128.0.0.0/1, pot intersectar els rangs candidats habituals 172 i 192.
Compareu ip -4 route show table all abans i després que la VPN es connecti, a l’amfitrió del dimoni. El delta és l’evidència, i la versió és l’abast de l’afirmació.
No generalitzeu les heurístiques d’una versió a totes les versions. Així és com una resposta de fòrum es converteix en un canvi de política.
Trieu la correcció més petita que funcioni
Si una xarxa no utilitzada confirmada té un bloc que necessiteu, planifiqueu-ne la retirada dirigida amb el propietari en lloc de podar àmpliament. Per a una xarxa nova, una subxarxa no utilitzada revisada explícitament evita del tot dependre de la selecció automàtica. Aquesta subxarxa encara ha d’evitar destinacions reals de Docker, LAN i VPN necessàries, perquè privat no vol dir segur. Encaminar un prefix remot real canviaria l’error d’assignació per un accés trencat.
Canviar default-address-pools és una política més àmplia sobre assignacions futures. Trieu una base sense conflictes i una mida assignada adequada, fusiona-la amb la configuració existent del dimoni i planifiqueu l’impacte documentat del reinici. Les xarxes existents no es renumeren en silenci.
No desactiveu els enviaments de rutes de l’empresa per fer que l’assignació tingui èxit. Un pla d’adreces explícit normalment resol el problema local sense debilitar una política obligatòria.
Accepteu l’assignació i l’encaminament per separat
Després del canvi, inspeccioneu la subxarxa que Docker ha creat realment i proveu les dependències de VPN i locals de l’aplicació. Una assignació correcta i un encaminament correcte en execució són dues comprovacions d’acceptació diferents, i superar la primera no és evidència de la segona. Si l’aplicació no pot arribar a un recurs darrere del túnel, teniu un problema d’encaminament que l’error del pool amagava. Registreu tots dos resultats al tiquet.
Conserveu el delta de rutes i el recompte del pool amb el registre del canvi, perquè la propera actualització del client VPN pot alterar el primer sense tocar Docker.
El manual està complet quan algú altre pot repetir aquestes dues comprovacions i obtenir la mateixa resposta.