Kāpēc Docker konteiners nesasniedz aiz VPN esošos resursdatorus

Konteiners, kas nesasniedz neko aiz uzņēmuma VPN, parasti dzīvo citā tīkla nosaukumu telpā nekā tunelis. Resursdatora klienta maršruti, DNS serveri un ugunsmūra atzīmes pieder resursdatora steķim; tilta tīkla konteineram ir savs. Šis viens fakts izskaidro lielāko daļu ziņojumu, kas nonāk platformas komandā, un tas arī ir iemesls, kāpēc «VPN ir salūzis» un «Docker apiet VPN» var būt nepareizi vienlaikus. Aiz viena simptoma slēpjas divas ļoti atšķirīgas konfigurācijas, tāpēc noskaidrojiet, kura ir jums, pirms maināt jebkuru iestatījumu.

Noskaidrojiet, kam pieder tuneļa nosaukumu telpa

Docker Desktop macOS vai Windows vidē konteineri darbojas Linux virtuālajā mašīnā. Darbvirsmā instalēts VPN klients izveido tuneli darbvirsmas operētājsistēmā, un virtuālā mašīna to nekad neredz. Neviena konteinera konfigurācija to nelabo, jo saskarne, kas konteineram būtu vajadzīga, tā tīkla nosaukumu telpā vispār nepastāv.

Linux resursdatorā tunelis dzīvo resursdatora nosaukumu telpā, un tilta konteineri to parasti sasniedz caur resursdatora maršrutēšanas tabulu, izejot piemērojot avota NAT. Kad šis ceļš neizdodas, iemesls parasti ir pārsūtīšanas politika, apgrieztā ceļa filtrēšana vai pārklājošs apakštīkls, nevis trūkstošs maršruts. Apstipriniet, kurā no divām pasaulēm jūs esat, pirms lasāt tālāk:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

Atšķirība starp šīm divām maršrutēšanas tabulām ir visa problēma vienā ekrānā. Ja resursdatora skatā ir tuneļa saskarne, bet tilta skatā nav, jūs redzat nosaukumu telpu izolāciju, un viss pārējais ir izvēle par to, kā to šķērsot.

Resursdatora tīkls ir tests, nevis dizains

Konteineru ar resursdatora tīklu, ko Docker dokumentē kā resursdatora tīkla nosaukumu telpas koplietošanu, liek tam tieši mantot tuneļa saskarni un tās maršrutus. Ja tas pats pieprasījums pēc tam izdodas, maršrutu teorija ir apstiprināta, un kļūme ir nosaukumu telpu izolācija, nevis akreditācijas dati, DNS vai piekļuves noteikums.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

Paturiet to kā diagnostiku. Resursdatora tīkls atsakās no portu publicēšanas un lielākās daļas izolācijas, ko vēlējāties no konteinera, un Docker Desktop «host» nozīmē virtuālo mašīnu, nevis darbvirsmu, tāpēc panākumi vai neveiksme tur var jūs maldināt, ja aizmirstat, uz kuru resursdatoru vērsāties.

tun ierīce un tai līdzi nākošās privilēģijas

VPN klientam konteinerā ir vajadzīga tuneļa ierīce un atļauja to konfigurēt. Parastais saīsinājums ir --privileged, kas piešķir visas ierīces un mīkstina drošības politiku visā konteinerā. Tas ir daudz vairāk, nekā prasa šis darbs, un to ir grūti attaisnot pārskatā.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

Šaurākā forma kartē vienu ierīces mezglu un pievieno tikai tīkla administrēšanas iespēju. Vispirms ielādējiet moduli resursdatorā, lai mezgls pastāvētu. Ja konteiners startē un klients ziņo, ka nevar atvērt tuneļa ierīci, pārbaudiet kartējumu, pirms aizdomājaties par profilu, jo šī kļūda parasti ir burtiska.

Šis dizains arī nozīmē, ka klients darbojas katram konteineram. Tā ir pareizā atbilde, kad katram darba slodzei vajadzīgs savs tunelis, un nepareizā, kad jūs tikai gribējāt, lai resursdatora tunelis būtu redzams, ko platformas komanda, iespējams, pieņēma, ka jūs darāt.

Tilta NAT maina avotu, ko redz VPN

Ar noklusējuma tiltu konteinera izejošā plūsma tiek tulkota resursdatora adresē. Tāpēc aiz VPN uzņēmuma puse redz resursdatora tuneļa adresi, nevis konteinera adresi, piekļuves noteikumi pēc avota uzvedas tā, it kā pieprasījumu būtu nosūtījis resursdators, un divi konteineri kļūst neatšķirami VPN serverim.

macvlan vai ipvlan tā vietā piešķir konteineram LAN adresi, kas palīdz atklāt LAN un liek konteineram izskatīties kā līdzvērtīgam segmentā. Tas arī pilnībā apiet resursdatora tuneli, tāpēc šāds konteiners nesasniegs tikai VPN paredzētos prefiksus, ja vien VPN nav sasniedzams arī no šī LAN.

Abas formas ir likumīgas; tās atbild uz dažādām prasībām. Ja prasība ir «šim konteineram jāsasniedz tikai VPN paredzēts pakalpojums», jūs izvēlaties starp maršrutēšanu caur resursdatoru un tuneļa izbeigšanu konteinerā. Pierakstiet šo izvēli pirms izvietošanas, nevis pēc pirmā neveiksmīgā pieprasījuma. Ko vien izvēlētos, pierakstiet avota adresi, ko redzēs tālā puse, jo tieši to rādīs tās piekļuves noteikumi un žurnāli. Dizains, kas nevar nosaukt šo adresi, nav pabeigts.

DNS seko dēmonam, nevis tunelim

Konteiners iegūst savu risinātāja konfigurāciju startējot, nokopētu no dēmona vai attēla. Adreses, ko VPN iebīda pēc savienojuma, pienāk par vēlu šai kopijai, un tās tiek iebīdītas resursdatora risinātājā, nevis konteinerā.

Iestatiet risinātāju skaidri pakalpojumam vai norādiet to uz iekšēju risinātāju, kas sasniedzams caur tuneli. Konteiners, kas privātu vārdu atrisina uz publisku adresi, parasti izmanto publisku risinātāju, nevis cieš no salūzuša maršruta, un labojums pieder compose failam vai dēmona konfigurācijai.

Tas pats pamatojums attiecas uz izejas adreses jautājumu. Ja katram konteineram jāparādās no citas VPN adreses, viens resursdatora tunelis to nevar nodrošināt, jo NAT tos savelk vienā avotā. Darbspējīgās formas ir klients katra konteinera nosaukumu telpā vai sidecar, kas pārvalda tuneli un koplieto savu steķi, un abas maina to, kā lietotne tiek adresēta.

Kontrolsaraksts pirms biļetes aizvēršanas: nosakiet nosaukumu telpu, kas pārvalda tuneli, pierādiet ceļu ar resursdatora tīklu, kartējiet tikai nepieciešamo tun ierīci, atcerieties avota adresi pēc NAT, skaidri iestatiet risinātāju un uzskatiet izejas adreses katram konteineram par arhitektūras lēmumu, nevis karodziņu.