Eroarea de suprapunere a pool-urilor din Docker nu este o problemă de rută VPN

Docker refuză să creeze o rețea cu mesajul că pool-ul se suprapune cu altul în acest spațiu de adrese, iar cineva decide că ruta VPN trebuie să fie cauza. Nu poate fi. Acea eroare este produsă în timp ce un pool este alocat, înainte de a exista un singur pachet, iar o rută manuală de kernel nu are nicio influență asupra ei. VPN-ul contează un pas mai târziu, când un container care are deja o adresă încetează să fie accesibil după ce apare o rută. Două probleme, două seturi de dovezi, iar amestecarea lor produce o schimbare care nu repară niciuna.

Două erori care arată la fel

Eroarea de alocare este aritmetică. Docker compară subrețeaua cerută cu subrețelele pe care le administrează deja, găsește o intersecție și refuză. Încă nu rulează nimic, deci nu există rută, container sau trafic de inspectat.

Simptomul în timpul rulării este o întrebare de accesibilitate. Un container care răspundea ieri nu mai răspunde acum, iar ceva s-a schimbat în tabela de rutare a gazdei. Containerul își păstrează în continuare adresa; întrebarea este ce cale ia acea adresă.

Ambele sunt probleme de plan de adrese. Doar una dintre ele este o problemă Docker.

Citiți mai întâi pool-urile alocate

Listați rețelele și inspectați-le pe cele care s-ar putea intersecta. Subrețeaua trăiește în configurația IPAM, iar containerele conectate sunt listate separat:

docker network ls
docker network inspect EXISTING_NETWORK

Comparați acea subrețea cu pool-ul cerut de noua rețea și rețineți că Compose creează propria rețea implicită pentru fiecare proiect. Un conflict cu un proiect uitat arată exact ca un conflict cu daemonul.

Un ipv4_address static pe un serviciu este adresa unui container, nu definiția pool-ului. Schimbarea lui nu elimină o suprapunere, pentru că suprapunerea este între subrețele de rețea, nu între containere. Referința network-create a Docker cere subrețele care nu se suprapun pentru alocarea obișnuită prin punte și documentează cum să selectați una explicit.

Alegeți un prefix care rezistă la VPN

Conflictul imediat și ruta viitoare sunt hotărâte de aceeași alegere, așa că faceți-o o dată. Comparați intervalul candidat cu LAN-ul, cu fiecare destinație VPN pe care gazda o poate atinge și cu orice alt overlay în uz.

Un prefix care satisface Docker și se ciocnește cu rețeaua îndepărtată vă dă un container care pornește curat și devine inaccesibil în momentul în care tunelul este ridicat. Aceasta este a doua eroare din acest articol și este mult mai greu de diagnosticat mai târziu decât de evitat acum.

Notați intervalele alese undeva unde proiectul următor le poate citi. Un registru de o linie al prefixelor alocate este mai ieftin decât o săptămână de expirări inexplicabile.

Retrageți sau schimbați o rețea în mod deliberat

Pentru o rețea Compose nouă, setați prefixul neutilizat în configurația IPAM a rețelei. Pentru un proiect existent, planificați renumerotarea: adresele fixe, serviciile dependente și pasul de recreare a rețelei trebuie toate luate în calcul, pentru că editarea YAML nu renumerotează o rețea în funcțiune.

Dacă o rețea învechită deține alocarea conflictuală, inspectați cine este conectat înainte de a o elimina. docker network rm refuză cât timp există endpoint-uri active, iar docker stop preia nume sau ID-uri de containere, nu un nume de rețea. Oprirea unui container nu elimină nici definiția de rețea care ține pool-ul.

Un prune larg nu este un instrument de diagnosticare. Ajunge la proiecte nelegate și distruge dovezile pe care urma să le colectați.

Pool-urile implicite ajută doar următoarea alocare

Setarea pool-ului de adrese implicit al daemonului îmbunătățește alocările automate viitoare ținându-le în afara intervalelor pe care le rezervați. Ea nu readresează retroactiv rețelele care există deja, și nu rezolvă o subrețea explicită care se suprapune cu altă subrețea explicită.

Tratați acea setare ca o schimbare separată și planificată, cu repornirea ei proprie, nu ca parte din repararea unui proiect. Amestecarea celor două înseamnă că o repornire a daemonului cade în mijlocul unei investigații nelegate. Programați-o în fereastra ei. Apoi confirmați că o nouă alocare automată cade într-adevăr în afara intervalelor pe care le-ați rezervat.

După ce crearea reușește, verificați subrețeaua care rulează efectiv și apoi faceți o singură cerere reală a aplicației cu VPN-ul în starea prevăzută. Dacă pool-ul este valid și accesul tot eșuează, munca rămasă este selectarea rutei, filtrarea și calea de întoarcere. Aceasta este o investigație în timpul rulării și nu face eroarea de alocare retroactiv lipsită de sens.

Ordinea de lucru: citiți pool-urile alocate, alegeți un prefix care evită atât Docker, cât și destinațiile VPN, recreați rețeaua în mod deliberat, apoi testați o cerere cu tunelul ridicat.