Docker: VPN-munkamenet alatt nem marad előre meghatározott címtartomány

A hiba konkrét: a Docker nem talál elfogadható automatikus alhálózatot egy új hídhálózathoz. Ez nem azt jelenti, hogy a gépből elfogytak a címek, és nem azt sem, hogy a VPN elromlott. Két kérdés dönti el a diagnózist: mely jelöltblokkokat látja a démon, és ezek közül melyeket zár ki a foglalója ebben a környezetben. Ebben a sorrendben haladjon végig rajtuk, mert a második kérdésnek nincs értelme, amíg az elsőre nem született válasz.

Erősítse meg, mi hibázott, mielőtt bármit módosítana

Futtassa az alábbi lépéseket azon a gazdagépen, amely a démont futtatja. Egy távoli környezettel beszélő shell egy másik gépet ír le, és ez a hiba önmagában egy órát elpazarolhat.

Ugyanekkor jegyezze fel az Engine verzióját a jegybe. A kézikönyv többi részének minden heurisztikája verzióhoz kötött, a verzió nélküli állítás pedig pletyka.

Számolja meg a már meglévő kiosztásokat

Listázza a hálózatokat, majd vizsgálja meg a fontosakat: docker network ls, majd docker network inspect NETWORK_NAME. Olvassa ki azok IPAM-alhálózatait és a hozzájuk csatolt konténereket. Több Compose-projekt több blokkot fogyaszt, mint amennyit a konténerszámuk sugall, mert minden projekt hajlamos saját alapértelmezett hálózatot létrehozni. Egy leállított konténer nem szabadítja fel a hálózata kiosztását.

Ellenőrizze a tartomány konfigurációját is, mert az alapértelmezett tartománynak van alap tartománya és hálózatonkénti előtagmérete. A nagy hálózatonkénti kiosztások gyorsabban merítik ki a rendelkezésre álló blokkokat, és ez kapacitástény, nem útválasztási probléma.

Írja fel a számot. Ez az az alapszint, amely megmondja, segített-e a következő változtatás.

Hasonlítsa össze, hogyan látja a démon az útvonalakat

A VPN befolyásolhatja a jelöltek kiválasztását, de a pontos megvalósítás dönti el, hogyan. A Moby 28.2.2 Linuxon verzióban a InferReservedNetworks névszerver-címeket és bizonyos on-link IPv4-útvonalakat gyűjt, és nem egyszerűen foglalja le az összes tábla minden útvonalát. A gyűjtött kapcsolatútvonalak a nem meghatározott célcímet is kizárják, így egyetlen 0.0.0.0/1 útvonal nem foglalja le az összes címet. Egy másik széles on-link előtag, például a 128.0.0.0/1, átvághatja a megszokott 172 és 192 jelölttartományokat.

Hasonlítsa össze a ip -4 route show table all kimenetét a VPN csatlakozása előtt és után, a démon gazdagépén. Az eltérés a bizonyíték, a verzió pedig az állítás hatóköre.

Ne általánosítsa egy kiadás heurisztikáját minden kiadásra. Így válik egy fórumválaszból szabályzatmódosítás.

Válassza a legkisebb működő javítást

Ha egy igazoltan használaton kívüli hálózat olyan blokkot tart, amelyre szüksége van, tervezze meg annak célzott kivonását a tulajdonossal, ne széles körű nyesést. Új hálózat esetén egy kifejezetten átvizsgált használaton kívüli alhálózat teljesen elkerüli az automatikus választástól való függést. Ennek az alhálózatnak azonban továbbra is el kell kerülnie a valódi Docker-, LAN- és szükséges VPN-célokat, mert a privát nem jelent biztonságosat. Egy valódi távoli előtag útválasztása a kiosztási hibát törött hozzáférésre cserélné.

A default-address-pools módosítása szélesebb szabályzat a jövőbeli kiosztásokról. Válasszon ütközésmentes alapot és megfelelő kiosztott méretet, fésülje össze a meglévő démonbeállításokkal, és tervezze meg a dokumentált újraindítási hatást. A meglévő hálózatok nem számozódnak át csendben.

Ne kapcsolja ki a vállalati útvonalak továbbítását, hogy a kiosztás sikerüljön. Egy kifejezett címterv általában megoldja a helyi problémát anélkül, hogy gyengítené a kötelező szabályzatot.

A kiosztást és az útválasztást külön fogadja el

A módosítás után vizsgálja meg az alhálózatot, amelyet a Docker ténylegesen létrehozott, és tesztelje az alkalmazás VPN- és helyi függőségeit. A sikeres kiosztás és a helyes futásidejű útválasztás két külön elfogadási ellenőrzés, és az első átmenése nem bizonyíték a másodikra. Ha az alkalmazás nem ér el egy erőforrást az alagút mögött, útválasztási problémája van, amelyet a tartományhiba elrejtett. Rögzítse mindkét eredményt a jegyben.

Őrizze meg az útvonaleltérést és a tartomány számát a változásrekorddal együtt, mert a következő VPN-kliensfrissítés módosíthatja az elsőt anélkül, hogy hozzányúlna a Dockerhez.

A kézikönyv akkor teljes, ha valaki más is meg tudja ismételni ezt a két ellenőrzést, és ugyanazt a választ kapja.