Docker: nu mai rămân pool-uri de adrese predefinite în timpul unei sesiuni VPN

Defecțiunea este specifică: Docker nu găsește o subrețea automată acceptabilă pentru o rețea de punte nouă. Nu înseamnă că mașina a rămas fără adrese și nu înseamnă că VPN-ul este stricat. Diagnosticul este decis de două întrebări: ce blocuri candidate vede daemonul și pe care dintre ele le exclude alocatorul său în acest mediu. Parcurgeți-le în această ordine, pentru că a doua întrebare nu are sens până când nu primește răspuns prima.

Confirmați ce a eșuat înainte de a schimba ceva

Rulați pașii de mai jos de pe gazda care rulează daemonul. Un shell care vorbește cu un context la distanță descrie o altă mașină, iar această singură greșeală poate pierde o oră.

Notați în același timp versiunea Engine în tichet. Fiecare euristică din restul acestui ghid depinde de versiune, iar o afirmație fără versiune este un zvon.

Numărați alocările pe care le aveți deja

Listați rețelele, apoi inspectați-le pe cele importante: docker network ls, urmat de docker network inspect NETWORK_NAME. Citiți subrețelele IPAM și containerele atașate fiecăreia. Mai multe proiecte Compose consumă mai multe blocuri decât sugerează numărul de containere, pentru că fiecare proiect tinde să își creeze propria rețea implicită. Un container oprit nu eliberează alocarea rețelei sale.

Verificați și configurația pool-ului, deoarece un pool implicit are un interval de bază și o dimensiune de prefix pe rețea. Alocările mari pe rețea epuizează blocurile disponibile mai repede, iar acesta este un fapt de capacitate, nu o problemă de rutare.

Notați numărul. Este linia de bază care vă spune dacă următoarea modificare a ajutat.

Comparați viziunea daemonului asupra rutelor

Un VPN poate influența selecția candidaților, dar implementarea exactă decide cum. În Moby 28.2.2 pe Linux, InferReservedNetworks colectează adrese de servere de nume și anumite rute IPv4 on-link și nu rezervă pur și simplu fiecare rută din fiecare tabelă. Rutele de legătură colectate exclud și o adresă de destinație nespecificată, așa că o singură rută 0.0.0.0/1 nu rezervă toate adresele. Un alt prefix on-link larg, cum ar fi 128.0.0.0/1, poate intersecta intervalele candidate cunoscute 172 și 192.

Comparați ip -4 route show table all înainte și după conectarea VPN-ului, pe gazda daemonului. Delta este dovada, iar versiunea este sfera afirmației.

Nu generalizați euristica unei versiuni la toate versiunile. Așa ajunge un răspuns de forum o schimbare de politică.

Alegeți cea mai mică corectare care funcționează

Dacă o rețea neutilizată confirmată deține un bloc de care aveți nevoie, planificați retragerea ei țintită împreună cu proprietarul, în loc să tăiați larg. Pentru o rețea nouă, o subrețea neutilizată verificată explicit evită complet dependența de selecția automată. Acea subrețea trebuie totuși să evite destinații reale Docker, LAN și VPN obligatorii, pentru că privat nu înseamnă sigur. Rutarea unui prefix la distanță real ar schimba eroarea de alocare pe acces întrerupt.

Schimbarea default-address-pools este o politică mai largă despre alocările viitoare. Alegeți o bază fără conflicte și o dimensiune alocată potrivită, îmbinați-o cu setările existente ale daemonului și planificați impactul documentat al repornirii. Rețelele existente nu sunt renumerotate în tăcere.

Nu dezactivați trimiterea rutelor companiei pentru ca alocarea să reușească. Un plan de adresare explicit rezolvă de obicei problema locală fără a slăbi o politică obligatorie.

Acceptați alocarea și rutarea separat

După modificare, inspectați subrețeaua pe care Docker a creat-o efectiv și testați dependențele de VPN și locale ale aplicației. Alocarea reușită și rutarea corectă în timpul rulării sunt două verificări de acceptare diferite, iar trecerea primei nu este dovadă pentru a doua. Dacă aplicația nu poate ajunge la o resursă din spatele tunelului, aveți o problemă de rutare pe care eroarea pool-ului o ascundea. Înregistrați ambele rezultate în tichet.

Păstrați delta rutelor și numărul pool-ului împreună cu înregistrarea modificării, pentru că următoarea actualizare a clientului VPN poate modifica primul fără să atingă Docker.

Ghidul este complet când altcineva poate repeta aceste două verificări și obține același răspuns.