Ang error sa pool overlap ng Docker ay hindi problema sa ruta ng VPN

Tumanggi ang Docker na gumawa ng network na may mensaheng nagsasapawan ang pool sa isa pa sa address space na ito, at may nagpasya na ang ruta ng VPN ang dapat na dahilan. Hindi ito maaaring mangyari. Ang error na iyon ay nabuo habang inilalaan ang isang pool, bago pa man umiral ang isang pakete, at ang manu-manong kernel route ay walang epekto dito. Mahalaga ang VPN isang hakbang mamaya, kapag ang isang container na mayroon nang address ay hindi na maabot pagkatapos lumitaw ang isang ruta. Dalawang problema, dalawang set ng ebidensya, at ang paghahalo sa kanila ay lumilikha ng pagbabagong hindi nag-aayos sa alinman.

Dalawang error na magkamukha

Ang error sa paglalaan ay aritmetika. Inihahambing ng Docker ang subnet na hiniling mo sa mga subnet na pinamamahalaan na nito, nakakahanap ng intersection at tumatanggi. Wala pang tumatakbo, kaya walang ruta, walang container at walang trapikong susuriin.

Ang sintomas sa runtime ay tanong ng maaabot. Ang container na sumagot kahapon ay hindi sumasagot ngayon, at may nagbago sa routing table ng host. Hawak pa rin ng container ang address nito; ang tanong ay aling landas ang tinatahak ng address na iyon.

Parehong problema sa plano ng address. Isa lamang sa kanila ang problema ng Docker.

Basahin muna ang mga inilaang pool

Ilista ang mga network at suriin ang mga maaaring magsalubong. Ang subnet ay nasa configuration ng IPAM, at ang mga nakakabit na container ay nakalista nang hiwalay:

docker network ls
docker network inspect EXISTING_NETWORK

Ihambing ang subnet na iyon sa pool na hinihiling ng bagong network, at tandaan na gumagawa ang Compose ng sarili nitong default na network bawat proyekto. Ang salungatan sa isang proyektong nakalimutan mo ay mukhang eksaktong salungatan sa daemon.

Ang static na ipv4_address sa isang serbisyo ay address ng isang container, hindi ang depinisyon ng pool. Ang pagbabago nito ay hindi nag-aalis ng overlap, dahil ang overlap ay sa pagitan ng mga subnet ng network at hindi sa pagitan ng mga container. Ang reference na network-create ng Docker ay nangangailangan ng mga subnet na hindi nagsasapawan para sa ordinaryong paglalaan sa tulay at nagdodokumento kung paano tahasang pumili ng isa.

Pumili ng prefix na nakakaligtas sa VPN

Ang agarang salungatan at ang hinaharap na ruta ay pinagpapasyahan ng parehong pagpili, kaya gawin ito nang isang beses. Ihambing ang hanay ng kandidato sa LAN, sa bawat destinasyon ng VPN na maaabot ng host, at sa anumang iba pang overlay na ginagamit.

Ang prefix na nakakasiya sa Docker at bumabangga sa malayong network ay nagbibigay sa iyo ng container na malinis na nagsisimula at nagiging hindi maaabot sa sandaling tumaas ang tunnel. Iyon ang pangalawang error sa artikulong ito, at mas mahirap itong i-diagnose mamaya kaysa iwasan ngayon.

Isulat ang mga piniling hanay sa isang lugar kung saan mababasa ito ng susunod na proyekto. Ang isang linyang rehistro ng mga inilaang prefix ay mas mura kaysa isang linggong hindi maipaliwanag na timeout.

Iretiro o baguhin ang network nang sinasadya

Para sa bagong network ng Compose, itakda ang hindi ginamit na prefix sa configuration ng IPAM ng network. Para sa umiiral na proyekto, planuhin ang muling pagbilang: ang mga fixed address, ang mga serbisyong nakadepende at ang hakbang ng muling paggawa ng network ay dapat isaalang-alang lahat, dahil ang pag-edit ng YAML ay hindi nagbibigay ng bagong bilang sa tumatakbong network.

Kung ang isang lipas na network ang nagmamay-ari ng sumasalungat na paglalaan, suriin kung sino ang nakakabit bago ito alisin. Ang docker network rm ay tumatanggi habang may mga aktibong endpoint, at ang docker stop ay tumatanggap ng mga pangalan o ID ng container sa halip na pangalan ng network. Ang paghinto ng container ay hindi rin nag-aalis ng depinisyon ng network na may hawak ng pool.

Ang malawak na prune ay hindi kasangkapan sa diagnosis. Umaabot ito sa mga hindi kaugnay na proyekto at sinisira ang ebidensyang sasamahin mo pa lang.

Ang mga default na pool ay nakakatulong lamang sa susunod na paglalaan

Ang setting ng default na pool ng address ng daemon ay nagpapabuti sa mga susunod na awtomatikong paglalaan sa pamamagitan ng paglalagay sa kanila sa labas ng mga hanay na inilalaan mo. Hindi ito muling nagbibigay ng address sa mga network na umiiral na nang paurong, at hindi nito nalulutas ang isang tahasang subnet na nagsasapawan sa isa pang tahasang subnet.

Ituring ang setting na iyon na hiwalay at planadong pagbabago na may sariling restart, hindi bahagi ng pagkumpuni ng isang proyekto. Ang paghahalo ng dalawa ay nangangahulugan na ang restart ng daemon ay nahuhulog sa gitna ng isang walang kaugnayang pagsisiyasat. I-iskedyul ito sa sarili nitong window. Pagkatapos ay kumpirmahin na ang isang bagong awtomatikong paglalaan ay talagang nahuhulog sa labas ng mga hanay na inilaan mo.

Kapag nagtagumpay ang paggawa, i-verify ang subnet na aktwal na tumatakbo at pagkatapos ay gumawa ng isang tunay na kahilingan ng aplikasyon habang ang VPN ay nasa nilalayong estado. Kung valid ang pool at nabigo pa rin ang pag-access, ang natitirang gawain ay pagpili ng ruta, pag-filter at ang daan pabalik. Iyon ay pagsisiyasat sa runtime, at hindi nito ginagawang walang saysay ang error sa paglalaan nang paurong.

Ayos ng gawain: basahin ang mga inilaang pool, pumili ng prefix na umiiwas sa Docker at sa mga destinasyon ng VPN, muling buuin ang network nang sinasadya, pagkatapos ay subukan ang isang kahilingan habang nakaangat ang tunnel.