Prečo kontajner Docker nedosiahne hosty za VPN

Kontajner, ktorý nedosiahne nič za firemnou VPN, zvyčajne žije v inom sieťovom mennom priestore než tunel. Trasy, servery DNS a značky firewallu klientského hostiteľa patria jeho zásobníku; kontajner v mostovej sieti má svoj. Tento jediný fakt vysvetľuje väčšinu hlásení, ktoré sa dostanú k platformovému tímu, a je aj dôvodom, prečo „VPN je pokazená“ a „Docker obchádza VPN“ môžu byť nesprávne súčasne. Za jedným príznakom sa skrývajú dve veľmi odlišné konfigurácie, preto zistite, ktorú máte, skôr než zmeníte nastavenie.

Zistite, čí menný priestor tunel vlastní

V Docker Desktop pre macOS alebo Windows bežia kontajnery v linuxovom virtuálnom stroji. Klient VPN nainštalovaný na počítači vytvorí tunel v operačnom systéme počítača a virtuálny stroj ho nikdy nevidí. Žiadna konfigurácia kontajnera to nenapraví, pretože rozhranie, ktoré by kontajner potreboval, v jeho sieťovom mennom priestore vôbec neexistuje.

Na hostiteľovi Linux tunel žije v mennom priestore hostiteľa a kontajnery v mostovej sieti sa k nemu zvyčajne dostanú cez smerovaciu tabuľku hostiteľa s NAT zdroja na odchádzajúcej ceste. Keď táto cesta zlyhá, príčinou je zvyčajne politika presmerovania, filtrovanie spätnej cesty alebo prekrývajúca sa podsieť, nie chýbajúca trasa. Potvrďte, v ktorom z dvoch svetov ste, skôr než budete čítať ďalej:

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

Rozdiel medzi týmito dvoma smerovacími tabuľkami je celý problém na jednej obrazovke. Ak pohľad hostiteľa obsahuje tunelové rozhranie a pohľad mosta nie, pozeráte sa na izoláciu menných priestorov a všetko ostatné je voľba, ako ju prekonať.

Hostiteľská sieť je test, nie návrh

Spustenie kontajnera s hostiteľskou sieťou, ktorú Docker dokumentuje ako zdieľanie sieťového menného priestoru hostiteľa, spôsobí, že priamo zdedí tunelové rozhranie a jeho trasy. Ak tá istá požiadavka potom uspeje, teória trás je potvrdená a zlyhaním je izolácia menných priestorov, nie prihlasovacie údaje, DNS alebo pravidlo prístupu.

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

Ponechajte to ako diagnostiku. Hostiteľská sieť sa vzdáva publikovania portov a väčšiny izolácie, ktorú ste od kontajnera chceli, a v Docker Desktop „host“ znamená virtuálny stroj, nie počítač, takže úspech alebo zlyhanie tam vás môže zmiasť, ak zabudnete, ktorého hostiteľa oslovujete.

Zariadenie tun a oprávnenia, ktoré s ním prichádzajú

Klient VPN vnútri kontajnera potrebuje tunelové zariadenie a oprávnenie na jeho konfiguráciu. Bežnou skratkou je --privileged, ktorý udeľuje každé zariadenie a uvoľňuje bezpečnostnú politiku v celom kontajneri. To je oveľa viac, než táto úloha vyžaduje, a v recenzii sa to ťažko obhajuje.

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

Užšia forma mapuje jediný uzol zariadenia a pridáva iba schopnosť správy siete. Najprv načítajte modul na hostiteľovi, aby uzol existoval. Ak sa kontajner spustí a klient hlási, že nemôže otvoriť tunelové zariadenie, skontrolujte mapovanie, skôr než budete podozrievať profil, pretože táto chyba je zvyčajne doslovná.

Tento návrh tiež znamená, že klient beží pre každý kontajner. To je správna odpoveď, keď každá pracovná záťaž potrebuje vlastný tunel, a nesprávna, keď ste len chceli, aby bol tunel hostiteľa viditeľný, čo platformový tím pravdepodobne predpokladal, že robíte.

NAT mosta mení zdroj, ktorý VPN vidí

Pri predvolenom moste sa odchádzajúca prevádzka kontajnera prekladá na adresu hostiteľa. Preto za VPN firemná strana vidí adresu tunela hostiteľa, nie kontajnera, pravidlá prístupu podľa zdroja sa správajú, ako keby požiadavku poslal hostiteľ, a dva kontajnery sa pre server VPN stanú nerozoznateľnými.

macvlan alebo ipvlan namiesto toho dá kontajneru adresu LAN, čo pomáha objavovaniu v LAN a robí kontajner rovnocenným v segmente. Obchádza aj tunel hostiteľa úplne, takže takýto kontajner nedosiahne prefixy iba pre VPN, ak VPN nie je dostupná aj z tejto LAN.

Obe formy sú legitímne; odpovedajú na rôzne požiadavky. Ak je požiadavkou „tento kontajner musí dosiahnuť službu iba pre VPN“, vyberáte medzi smerovaním cez hostiteľa a ukončením tunela v kontajneri. Zapíšte túto voľbu pred nasadením, nie po prvej neúspešnej požiadavke. Čokoľvek si vyberiete, zaznamenajte zdrojovú adresu, ktorú uvidí vzdialená strana, pretože práve to ukážu jej pravidlá prístupu a jej záznamy. Návrh, ktorý nedokáže túto adresu uviesť, nie je hotový.

DNS nasleduje démona, nie tunel

Kontajner dostane konfiguráciu resolvera pri štarte, skopírovanú z démona alebo z obrazu. Adresy, ktoré VPN odošle po pripojení, prichádzajú pre túto kópiu príliš neskoro a posielajú sa resolveru hostiteľa, nie do kontajnera.

Nastavte resolver výslovne pre službu alebo ho nasmerujte na interný resolver dostupný cez tunel. Kontajner, ktorý prekladá súkromné meno na verejnú adresu, zvyčajne používa verejný resolver a netrpí pokazenou trasou, a oprava patrí do súboru compose alebo konfigurácie démona.

Rovnaká úvaha platí pre otázku výstupnej adresy. Ak sa každý kontajner musí objavovať z inej adresy VPN, jeden tunel hostiteľa to nedokáže poskytnúť, pretože NAT ich zlúči do jedného zdroja. Fungujúce formy sú klient v mennom priestore každého kontajnera alebo sidecar, ktorý tunel vlastní a zdieľa svoj zásobník, a obe menia spôsob adresovania aplikácie.

Kontrolný zoznam pred uzavretím tiketu: určite menný priestor, ktorý tunel vlastní, preukážte cestu hostiteľskou sieťou, namapujte len potrebné zariadenie tun, zapamätajte si zdrojovú adresu po NAT, nastavte resolver výslovne a berte výstupné adresy pre kontajner ako architektonické rozhodnutie, nie ako prepínač.