A Docker pool-átfedési hibája nem VPN-útvonal-probléma

A Docker megtagadja a hálózat létrehozását azzal az üzenettel, hogy a pool átfed egy másikkal ebben a címterében, és valaki eldönti, hogy a VPN-útvonalnak kell lennie az oknak. Nem lehet az. Ez a hiba a pool kiosztása közben keletkezik, mielőtt egyetlen csomag is létezne, és egy kézi kernel-útvonal nincs hatással rá. A VPN egy lépéssel később számít, amikor egy már címmel rendelkező konténer egy útvonal megjelenése után elérhetetlenné válik. Két probléma, két bizonyítékhalmaz, és ezek keverése olyan változást eredményez, amely egyiket sem javítja.

Két hasonló hiba

A kiosztási hiba aritmetikai. A Docker összehasonlítja a kért alhálózatot az általa már kezelt alhálózatokkal, metszetet talál, és megtagadja. Még semmi sem fut, így nincs útvonal, nincs konténer és nincs forgalom, amit vizsgálni lehetne.

A futásidejű tünet egy elérhetőségi kérdés. Egy tegnap válaszoló konténer most nem válaszol, és valami megváltozott a gazdagép útválasztási táblázatában. A konténer továbbra is megtartja a címét; a kérdés az, hogy ez a cím melyik utat választja.

Mindkettő címterv-probléma. Csak az egyikük Docker-probléma.

Először olvassa el a kiosztott poolokat

Listázza a hálózatokat, és vizsgálja meg azokat, amelyek metszhetik egymást. Az alhálózat az IPAM-konfigurációban él, a csatolt konténereket pedig külön sorolják fel:

docker network ls
docker network inspect EXISTING_NETWORK

Hasonlítsa össze ezt az alhálózatot azzal a pool-lal, amelyet az új hálózat kér, és ne feledje, hogy a Compose projektenként saját alapértelmezett hálózatot hoz létre. Egy elfelejtett projekt okozta ütközés pontosan úgy néz ki, mint egy ütközés a daemonnal.

A szolgáltatáson lévő statikus ipv4_address egy konténer címe, nem a pool definíciója. A megváltoztatása nem szünteti meg az átfedést, mert az átfedés hálózati alhálózatok között van, nem konténerek között. A Docker network-create-referenciája nem átfedő alhálózatokat követel meg a szokásos híd-kiosztáshoz, és dokumentálja, hogyan válasszon egyet kifejezetten.

Válasszon olyan prefixet, amely túléli a VPN-t

A közvetlen ütközést és a jövőbeli útvonalat ugyanaz a választás dönti el, tehát egyszer hozza meg. Hasonlítsa össze a jelölt tartományt a LAN-nal, minden VPN-céllal, amelyet a gazdagép elér, és bármely más használatban lévő overlayjel.

Egy prefix, amely kielégíti a Dockert és ütközik a távoli hálózattal, olyan konténert ad, amely tisztán indul és abban a pillanatban elérhetetlenné válik, amikor az alagút felmegy. Ez a cikk második hibája, és sokkal nehezebb később diagnosztizálni, mint most elkerülni.

Írja fel a választott tartományokat oda, ahonnan a következő projekt elolvashatja őket. A kiosztott prefixek egysoros nyilvántartása olcsóbb, mint egy hét megmagyarázatlan időtúllépés.

A hálózatot szándékosan vonja ki vagy változtassa meg

Új Compose-hálózathoz állítsa be a nem használt prefixet a hálózat IPAM-konfigurációjában. Meglévő projektnél tervezze meg az átszámozást: a fix címeket, a függő szolgáltatásokat és a hálózat újralétrehozásának lépését mind figyelembe kell venni, mert a YAML szerkesztése nem számozza át a futó hálózatot.

Ha egy elavult hálózat birtokolja az ütköző kiosztást, az eltávolítása előtt vizsgálja meg, ki van csatlakoztatva. A docker network rm megtagadja, amíg aktív végpontok léteznek, a docker stop pedig konténerneveket vagy ID-kat fogad el hálózatnév helyett. Egy konténer leállítása sem távolítja el a poolt tartó hálózatdefiníciót.

A széles prune nem diagnosztikai eszköz. Elér a nem kapcsolódó projektekhez, és megsemmisíti a bizonyítékokat, amelyeket éppen gyűjteni készült.

Az alapértelmezett poolok csak a következő kiosztásnak segítenek

A daemon alapértelmezett cím-pool beállítása javítja a jövőbeli automatikus kiosztásokat azzal, hogy a lefoglalt tartományokon kívül tartja őket. Ez nem címez át visszamenőleg már létező hálózatokat, és nem old meg egy kifejezett alhálózatot, amely átfed egy másik kifejezett alhálózattal.

Kezelje ezt a beállítást külön, tervezett változtatásként, saját újraindítással, nem egy projekt javításának részeként. A kettő keverése azt jelenti, hogy egy daemon-újraindítás egy nem kapcsolódó vizsgálat kellős közepére esik. Ütemezze külön ablakban. Utána erősítse meg, hogy egy új automatikus kiosztás valóban a lefoglalt tartományokon kívülre esik.

Miután a létrehozás sikerült, ellenőrizze a ténylegesen futó alhálózatot, majd végezzen egy valódi alkalmazáskérést úgy, hogy a VPN a szándékolt állapotában van. Ha a pool érvényes, és a hozzáférés továbbra is sikertelen, a fennmaradó munka az útvonalválasztás, a szűrés és a visszaút. Ez futásidejű vizsgálat, és nem teszi a kiosztási hibát visszamenőleg értelmetlenné.

A munka sorrendje: olvassa el a kiosztott poolokat, válasszon olyan prefixet, amely elkerüli a Dockert és a VPN-célokat is, szándékosan hozza létre újra a hálózatot, majd teszteljen egy kérést az alagút fentléte mellett.