Docker: VPN sesijas laikā vairs nav palicis neviena iepriekš definēta adrešu kopa

Kļūme ir konkrēta: Docker nevar atrast pieņemamu automātisku apakštīklu jaunam tilta tīklam. Tas nenozīmē, ka mašīnai ir beigušās adreses, un nenozīmē, ka VPN ir salūzis. Diagnozi nosaka divi jautājumi: kādus kandidātblokus dēmons redz un kurus no tiem tā piešķīrējs šajā vidē izslēdz. Izskatiet tos tieši šādā secībā, jo otrajam jautājumam nav jēgas, kamēr nav atbildēts uz pirmo.

Pirms kaut ko mainīt, apstipriniet, kas neizdevās

Izpildiet tālāk minētās darbības tajā resursdatorā, kurā darbojas dēmons. Apvalks, kas sarunājas ar attālinātu kontekstu, apraksta citu mašīnu, un vien šī kļūda var izšķērdēt stundu.

Vienlaikus ierakstiet biļetē Engine versiju. Katra šīs rokasgrāmatas atlikušās daļas heiristika ir saistīta ar versiju, un apgalvojums bez versijas ir bauma.

Saskaitiet piešķīrumus, kas jums jau ir

Uzskaitiet tīklus un pēc tam pārbaudiet svarīgos: docker network ls, pēc tam docker network inspect NETWORK_NAME. Izlasiet to IPAM apakštīklus un katram pievienotos konteinerus. Vairāki Compose projekti patērē vairāk bloku, nekā liecina to konteineru skaits, jo katrs projekts mēdz izveidot savu noklusējuma tīklu. Apturēts konteiners neatbrīvo sava tīkla piešķīrumu.

Pārbaudiet arī kopas konfigurāciju, jo noklusējuma kopai ir bāzes diapazons un prefiksa lielums vienam tīklam. Lieli piešķīrumi vienam tīklam izsmeļ pieejamos blokus ātrāk, un tas ir ietilpības fakts, nevis maršrutēšanas problēma.

Pierakstiet skaitli. Tā ir bāzes līnija, kas pasaka, vai nākamā izmaiņa palīdzēja.

Salīdziniet, kā dēmons redz maršrutus

VPN var ietekmēt kandidātu atlasi, bet kā tieši — to nosaka konkrētā implementācija. Moby 28.2.2 uz Linux InferReservedNetworks apkopo nosaukumu serveru adreses un noteiktus on-link IPv4 maršrutus, un tas vienkārši nerezervē katru maršrutu no katras tabulas. Apkopotie saites maršruti arī izslēdz nenorādītu galamērķa adresi, tāpēc viens 0.0.0.0/1 maršruts vien pats nerezervē visas adreses. Cits plašs on-link prefikss, piemēram, 128.0.0.0/1, var šķērsot ierastos kandidātu diapazonus 172 un 192.

Salīdziniet ip -4 route show table all pirms un pēc tam, kad VPN izveido savienojumu, dēmona resursdatorā. Starpība ir pierādījums, un versija ir apgalvojuma tvērums.

Nevispāriniet vienas versijas heiristiku uz visām versijām. Tā foruma atbilde kļūst par politikas izmaiņu.

Izvēlieties mazāko labojumu, kas darbojas

Ja apstiprināts neizmantots tīkls tur jums vajadzīgo bloku, plānojiet tā mērķtiecīgu izņemšanu kopā ar īpašnieku, nevis plašu apcirpšanu. Jaunam tīklam skaidri pārskatīts neizmantots apakštīkls pilnībā izvairās no atkarības no automātiskas atlases. Šim apakštīklam tomēr jāizvairās no reāliem Docker, LAN un nepieciešamajiem VPN galamērķiem, jo privāts nenozīmē drošs. Reāla attālināta prefiksa maršrutēšana apmainītu piešķīruma kļūdu pret pārtrauktu piekļuvi.

default-address-pools maiņa ir plašāka politika par turpmākiem piešķīrumiem. Izvēlieties nekolidējošu bāzi un piemērotu piešķirto lielumu, apvienojiet to ar esošajiem dēmona iestatījumiem un plānojiet dokumentēto restartēšanas ietekmi. Esošie tīkli netiek klusi pārnumurēti.

Neizslēdziet uzņēmuma maršrutu nosūtīšanu, lai piešķīrums izdotos. Skaidrs adrešu plāns parasti atrisina vietējo problēmu, nevājinot obligāto politiku.

Pieņemiet piešķīrumu un maršrutēšanu atsevišķi

Pēc izmaiņām pārbaudiet apakštīklu, ko Docker faktiski izveidoja, un pārbaudiet lietotnes VPN un vietējās atkarības. Veiksmīgs piešķīrums un pareiza maršrutēšana darbības laikā ir divas dažādas pieņemšanas pārbaudes, un pirmās izturēšana nav otrās pierādījums. Ja lietotne nevar sasniegt resursu aiz tuneļa, jums ir maršrutēšanas problēma, ko kopas kļūda slēpa. Ierakstiet abus rezultātus biļetē.

Saglabājiet maršrutu starpību un kopas skaitu kopā ar izmaiņu ierakstu, jo nākamais VPN klienta atjauninājums var mainīt pirmo, neaiztiekot Docker.

Rokasgrāmata ir pabeigta, kad kāds cits var atkārtot šīs divas pārbaudes un iegūt to pašu atbildi.