Docker: wala nang natitirang paunang tinukoy na pool ng address sa isang sesyon ng VPN

Ang pagkabigo ay tiyak: hindi makahanap ang Docker ng katanggap-tanggap na awtomatikong subnet para sa bagong network ng tulay. Hindi ito nangangahulugang naubos na ang mga address ng makina, at hindi rin nangangahulugang sira ang VPN. Dalawang tanong ang nagtatakda ng diagnosis: aling mga bloke ng kandidato ang nakikita ng daemon, at alin sa mga ito ang ibinubukod ng tagapaglaan nito sa kapaligirang ito. Isa-isahin ang mga ito sa ganoong pagkakasunod-sunod, dahil walang saysay ang ikalawang tanong hangga’t hindi nasasagot ang una.

Tiyakin kung ano ang nabigo bago baguhin ang anuman

Patakbuhin ang mga hakbang sa ibaba mula sa host na nagpapatakbo ng daemon. Ang isang shell na nakikipag-usap sa malayong konteksto ay naglalarawan ng ibang makina, at ang pagkakamaling iyon lamang ay maaaring mag-aksaya ng isang oras.

Itala rin ang bersyon ng Engine sa ticket sa parehong oras. Ang bawat heuristic sa natitirang bahagi ng gabay na ito ay nakatali sa bersyon, at ang pag-aangkin na walang bersyon ay tsismis.

Bilangin ang mga paglalaan na mayroon ka na

Ilista ang mga network, pagkatapos suriin ang mahahalaga: docker network ls na sinusundan ng docker network inspect NETWORK_NAME. Basahin ang kanilang mga subnet ng IPAM at ang mga container na nakakabit sa bawat isa. Maraming proyekto ng Compose ang kumokonsumo ng mas maraming bloke kaysa sa ipinahihiwatig ng bilang ng kanilang mga container, dahil bawat proyekto ay may tendensiyang gumawa ng sarili nitong default na network. Ang nakaahintong container ay hindi nagpapalaya ng paglalaan ng network nito.

Suriin din ang pagsasaayos ng pool, dahil ang default na pool ay may batayang saklaw at sukat ng prefix bawat network. Ang malalaking paglalaan bawat network ay mas mabilis na nag-ubos ng mga magagamit na bloke, at iyon ay katotohanan ng kapasidad, hindi problema sa routing.

Isulat ang bilang. Iyon ang batayang linya na nagsasabi kung nakatulong ang susunod na pagbabago.

Ihambing ang pananaw ng daemon sa mga ruta

Ang VPN ay maaaring makaimpluwensiya sa pagpili ng kandidato, ngunit ang eksaktong implementasyon ang nagtatakda kung paano. Sa Moby 28.2.2 sa Linux, ang InferReservedNetworks ay nangongolekta ng mga address ng nameserver at ilang rutang IPv4 na on-link, at hindi lamang nito inilalaan ang bawat ruta mula sa bawat talahanayan. Ang mga nakolektang ruta ng link ay nagbubukod din ng hindi tinukoy na address ng destinasyon, kaya ang isang rutang 0.0.0.0/1 lamang ay hindi naglalaan ng lahat ng address. Ang isa pang malawak na prefix na on-link, tulad ng 128.0.0.0/1, ay maaaring magsalubong sa pamilyar na mga saklaw ng kandidato 172 at 192.

Ihambing ang ip -4 route show table all bago at pagkatapos kumonekta ang VPN, sa host ng daemon. Ang delta ang ebidensiya, at ang bersyon ang saklaw ng pag-aangkin.

Huwag gawing pangkalahatan ang heuristic ng isang release sa lahat ng release. Ganyan nagiging pagbabago ng patakaran ang isang sagot sa forum.

Piliin ang pinakamaliit na pagwawastong gumagana

Kung ang isang kumpirmadong hindi ginagamit na network ay may hawak na bloke na kailangan mo, planuhin ang target na pagreretiro nito kasama ang may-ari sa halip na magtabas nang malawak. Para sa bagong network, ang isang malinaw na sinuri na hindi ginagamit na subnet ay ganap na umiiwas sa pagdepende sa awtomatikong pagpili. Kailangan pa ring iwasan ng subnet na iyon ang tunay na destinasyon ng Docker, LAN at kinakailangang VPN, dahil ang pribado ay hindi nangangahulugang ligtas. Ang pag-route ng tunay na malayong prefix ay ipagpapalit ang error sa paglalaan para sa sirang access.

Ang pagbabago ng default-address-pools ay isang mas malawak na patakaran tungkol sa mga susunod na paglalaan. Pumili ng base na walang salungatan at angkop na inilaang sukat, pagsamahin ito sa umiiral na mga setting ng daemon, at planuhin ang dokumentadong epekto ng pag-restart. Ang umiiral na mga network ay hindi tahimik na muling binibilang.

Huwag huwag paganahin ang pagtulak ng ruta ng kumpanya para magtagumpay ang paglalaan. Ang malinaw na plano ng address ay kadalasang lumulutas ng lokal na problema nang hindi pinapahina ang isang ipinag-uutos na patakaran.

Tanggapin nang hiwalay ang paglalaan at routing

Pagkatapos ng pagbabago, suriin ang subnet na aktwal na ginawa ng Docker at subukan ang mga dependency ng aplikasyon sa VPN at lokal. Ang matagumpay na paglalaan at tamang routing habang tumatakbo ay dalawang magkaibang pagsusuri sa pagtanggap, at ang pagpasa sa una ay hindi ebidensiya para sa pangalawa. Kung hindi maabot ng app ang isang resource sa likod ng tunnel, mayroon kang problema sa routing na itinatago ng error ng pool. Itala ang parehong resulta sa ticket.

Itago ang delta ng ruta at ang bilang ng pool kasama ng talaan ng pagbabago, dahil ang susunod na update ng kliyente ng VPN ay maaaring baguhin ang una nang hindi hinahawakan ang Docker.

Kumpleto ang gabay kapag may ibang makakagawa muli ng dalawang pagsusuring iyon at makakuha ng parehong sagot.