Pse një kontejner Docker nuk arrin hostet prapa VPN-së

Një kontejner që nuk arrin asgjë prapa VPN-së së korporatës zakonisht jeton në një hapësirë emrash rrjeti të ndryshme nga tuneli. Rrugët, serverat DNS dhe shenjat e firewall-it të klientit të hostit i përkasin stakut të hostit; një kontejner në rrjetin urë ka të vetin. Ky fakt i vetëm shpjegon shumicën e raporteve që arrijnë në një ekip platforme, dhe është gjithashtu arsyeja pse «VPN-ja është prishur» dhe «Docker anashkalon VPN-në» mund të jenë të dyja të gabuara në të njëjtën kohë. Dy konfigurime shumë të ndryshme fshihen pas një simptome, prandaj identifikoni cilën keni përpara se të ndryshoni ndonjë cilësim.

Zbuloni të kujt i përket hapësira e emrave e tunelit

Në Docker Desktop për macOS ose Windows, kontejnerët ekzekutohen brenda një makine virtuale Linux. Një klient VPN i instaluar në desktop krijon një tunel në sistemin operativ të desktopit, dhe makina virtuale nuk e sheh kurrë. Asnjë konfigurim kontejneri nuk e rregullon këtë, sepse ndërfaqja që kontejneri do të kishte nevojë nuk ekziston fare në hapësirën e tij të emrave të rrjetit.

Në një host Linux tuneli jeton në hapësirën e emrave të hostit, dhe kontejnerët në urë zakonisht e arrijnë atë përmes tabelës së rrugëtimit të hostit me NAT burimi të aplikuar në dalje. Kur ajo rrugë dështon, shkaku zakonisht është politika e përcjelljes, filtrimi i rrugës së kundërt ose një nënrrjet që mbivendoset, jo një rrugë që mungon. Konfirmoni në cilën nga dy botët jeni përpara se të lexoni më tej:

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

Diferenca midis këtyre dy tabelave të rrugëtimit është i gjithë problemi në një ekran. Nëse pamja e hostit përmban ndërfaqen e tunelit dhe pamja e urës jo, ju po shihni izolim të hapësirave të emrave, dhe gjithçka tjetër është një zgjedhje se si ta kaloni atë.

Rrjeti i hostit është një provë, jo një dizajn

Ekzekutimi i një kontejneri me rrjetin e hostit, të cilin Docker e dokumenton si ndarje të hapësirës së emrave të rrjetit të hostit, e bën atë të trashëgojë drejtpërdrejt ndërfaqen e tunelit dhe rrugët e tij. Nëse i njëjti kërkesë pastaj ka sukses, teoria e rrugëve konfirmohet dhe dështimi është izolim i hapësirave të emrave, jo kredencialet, DNS ose një rregull aksesi.

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

Mbajeni si diagnostikim. Rrjeti i hostit heq dorë nga publikimi i porteve dhe nga pjesa më e madhe e izolimit që dëshironit nga një kontejner, dhe në Docker Desktop «host» nënkupton makinën virtuale, jo desktopin, kështu që një sukses ose dështim atje mund t'ju mashtrojë nëse harroni cilin host po adresonit.

Një pajisje tun dhe privilegjet që vijnë me të

Një klient VPN brenda kontejnerit ka nevojë për një pajisje tuneli dhe leje për ta konfiguruar atë. Shkurtesa e zakonshme është --privileged, e cila jep çdo pajisje dhe zbut politikën e sigurisë në të gjithë kontejnerin. Kjo është shumë më tepër sesa kërkon kjo detyrë, dhe është e vështirë të justifikohet në një rishikim.

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

Forma më e ngushtë harton nyjën e vetme të pajisjes dhe shton vetëm aftësinë e administrimit të rrjetit. Ngarkoni fillimisht modulin në host që nyja të ekzistojë. Nëse kontejneri niset dhe klienti raporton se nuk mund të hapë pajisjen e tunelit, kontrolloni hartëzimin përpara se të dyshoni për profilin, sepse ai gabim zakonisht është literal.

Ky dizajn gjithashtu do të thotë që klienti ekzekutohet për çdo kontejner. Kjo është përgjigja e saktë kur çdo ngarkesë pune ka nevojë për tunelin e vet, dhe përgjigja e gabuar kur thjesht dëshironit që tuneli i hostit të ishte i dukshëm, gjë që ekipi i platformës me gjasë supozonte se po bënit.

NAT-i i urës ndryshon burimin që sheh VPN-ja

Me urën e parazgjedhur, trafiku dalës i kontejnerit përkthehet në adresën e hostit. Prandaj prapa një VPN, ana e korporatës sheh adresën e tunelit të hostit dhe jo atë të kontejnerit, rregullat e aksesit sipas burimit sillen sikur hosti e dërgoi kërkesën, dhe dy kontejnerë bëhen të padallueshëm për serverin VPN.

macvlan ose ipvlan i jep kontejnerit një adresë LAN në vend të kësaj, gjë që ndihmon zbulimin në LAN dhe e bën kontejnerin të duket si një bashkëmohues në segment. Ai gjithashtu anashkalon plotësisht tunelin e hostit, kështu që një kontejner i tillë nuk do të arrijë prefikset vetëm-VPN nëse VPN-ja nuk është e arritshme edhe nga ai LAN.

Të dyja format janë legjitime; ato u përgjigjen kërkesave të ndryshme. Nëse kërkesa është «ky kontejner duhet të arrijë një shërbim vetëm-VPN», ju zgjidhni midis rrugëtimit përmes hostit dhe përfundimit të tunelit brenda kontejnerit. Shkruajeni këtë zgjedhje përpara vendosjes, jo pas kërkesës së parë të dështuar. Çfarëdo që të zgjidhni, regjistroni adresën e burimit që do të shohë skaji i largët, sepse pikërisht atë do të tregojnë rregullat e tij të aksesit dhe regjistrat e tij. Një dizajn që nuk mund të deklarojë atë adresë nuk është i përfunduar.

DNS ndjek daemon-in, jo tunelin

Një kontejner merr konfigurimin e zgjidhësit në nisje, të kopjuar nga daemon-i ose nga imazhi. Adresat që VPN-ja shtyn pas lidhjes vijnë shumë vonë për atë kopje, dhe ato shtyhen në zgjidhësin e hostit dhe jo brenda kontejnerit.

Vendosni zgjidhësin në mënyrë eksplicite për shërbimin, ose drejtojeni atë në një zgjidhës të brendshëm të arritshëm përmes tunelit. Një kontejner që zgjidh një emër privat në një adresë publike zakonisht përdor një zgjidhës publik, nuk vuan nga një rrugë e prishur, dhe korrigjimi i takon skedarit compose ose konfigurimit të daemon-it.

I njëjti arsyetim vlen për çështjen e adresës së daljes. Nëse çdo kontejner duhet të shfaqet nga një adresë VPN e ndryshme, një tunel i vetëm hosti nuk mund ta ofrojë atë sepse NAT-i i bashkon në një burim të vetëm. Format e zbatueshme janë një klient në hapësirën e emrave të çdo kontejneri ose një sidecar që zotëron tunelin dhe ndan stakun e tij, dhe të dyja ndryshojnë mënyrën se si adresohet aplikacioni.

Listë kontrolli përpara mbylljes së tiketit: identifikoni hapësirën e emrave që zotëron tunelin, provoni rrugën me rrjetin e hostit, hartoni vetëm pajisjen tun të nevojshme, mbani mend adresën e burimit pas NAT, vendosni zgjidhësin në mënyrë eksplicite dhe trajtoni adresat e daljes për kontejner si një vendim arkitekturor dhe jo si një flamur.