Zakaj vsebnik Docker ne doseže gostiteljev za VPN

Vsebnik, ki ne doseže ničesar za poslovnim VPN, običajno živi v drugem omrežnem imenskem prostoru kot tunel. Poti, strežniki DNS in oznake požarnega zidu gostiteljskega odjemalca pripadajo gostiteljevemu skladu; vsebnik v mostni mreži ima svojega. To eno dejstvo pojasnjuje večino poročil, ki prispejo do platformne ekipe, in je tudi razlog, da sta lahko „VPN je pokvarjen“ in „Docker obide VPN“ napačna hkrati. Za enim simptomom se skrivata dve zelo različni konfiguraciji, zato ugotovite, katero imate, preden spremenite nastavitev.

Ugotovite, čigav imenski prostor ima tunel

V Docker Desktop za macOS ali Windows vsebniki tečejo v virtualnem stroju Linux. Odjemalec VPN, nameščen na namizju, ustvari tunel v operacijskem sistemu namizja, virtualni stroj pa ga nikoli ne vidi. Nobena konfiguracija vsebnika tega ne popravi, ker vmesnik, ki bi ga vsebnik potreboval, v njegovem omrežnem imenskem prostoru sploh ne obstaja.

Na gostitelju Linux tunel živi v gostiteljevem imenskem prostoru, vsebniki v mostni mreži pa ga običajno dosežejo prek gostiteljeve usmerjevalne tabele z NAT vira, uporabljenim na izhodu. Ko ta pot odpove, je vzrok običajno politika posredovanja, filtriranje povratne poti ali prekrivajoče se podomrežje, ne manjkajoča pot. Potrdite, v katerem od dveh svetov ste, preden berete naprej:

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

Razlika med tema dvema usmerjevalnima tabelama je celoten problem na enem zaslonu. Če pogled gostitelja vsebuje vmesnik tunela, pogled mostu pa ne, gledate izolacijo imenskih prostorov, vse ostalo pa je izbira, kako jo prečkati.

Gostiteljsko omrežje je preizkus, ne zasnova

Zagon vsebnika z gostiteljskim omrežjem, ki ga Docker dokumentira kot deljenje gostiteljskega omrežnega imenskega prostora, povzroči, da neposredno podeduje vmesnik tunela in njegove poti. Če ista zahteva nato uspe, je teorija poti potrjena in napaka je izolacija imenskih prostorov, ne poverilnice, DNS ali pravilo dostopa.

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

Obdržite to kot diagnostiko. Gostiteljsko omrežje se odreče objavljanju vrat in večini izolacije, ki ste jo želeli od vsebnika, v Docker Desktop pa „host“ pomeni virtualni stroj, ne namizje, zato vas lahko uspeh ali neuspeh tam zavede, če pozabite, na kateri gostitelj ste naslavljali.

Naprava tun in privilegiji, ki pridejo z njo

Odjemalec VPN znotraj vsebnika potrebuje tunelsko napravo in dovoljenje za njeno konfiguracijo. Običajna bližnjica je --privileged, ki podeli vsako napravo in omili varnostno politiko v celotnem vsebniku. To je veliko več, kot zahteva ta naloga, in težko upravičljivo pri pregledu.

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

Ožja oblika preslika posamezno vozlišče naprave in doda le zmožnost upravljanja omrežja. Najprej naložite modul na gostitelja, da vozlišče obstaja. Če se vsebnik zažene in odjemalec sporoči, da ne more odpreti tunelske naprave, preverite preslikavo, preden sumite na profil, ker je ta napaka običajno dobesedna.

Ta zasnova pomeni tudi, da odjemalec teče za vsak vsebnik. To je pravi odgovor, ko vsaka delovna obremenitev potrebuje svoj tunel, in napačen, ko ste želeli le, da bi bil gostiteljev tunel viden, kar je platformna ekipa verjetno predpostavila, da počnete.

NAT mostu spremeni vir, ki ga VPN vidi

Pri privzetem mostu se odhodni promet vsebnika prevede na gostiteljev naslov. Zato za VPN poslovna stran vidi naslov gostiteljevega tunela in ne vsebnikovega, pravila dostopa po viru se obnašajo, kot da bi zahtevo poslal gostitelj, in dva vsebnika postaneta za strežnik VPN nerazločljiva.

macvlan ali ipvlan namesto tega vsebniku dodeli naslov LAN, kar pomaga pri odkrivanju v LAN in naredi vsebnik videti kot enakovrednega v segmentu. Prav tako popolnoma obide gostiteljev tunel, zato tak vsebnik ne bo dosegel predpon samo za VPN, razen če je VPN dosegljiv tudi iz tega LAN.

Obe obliki sta legitimni; odgovarjata na različne zahteve. Če je zahteva „ta vsebnik mora doseči storitev samo za VPN“, izbirate med usmerjanjem skozi gostitelja in končanjem tunela znotraj vsebnika. Zapišite to izbiro pred uvedbo, ne po prvi neuspešni zahtevi. Karkoli izberete, zabeležite izvorni naslov, ki ga bo videla oddaljena stran, ker bodo prav to pokazala njena pravila dostopa in njeni dnevniki. Zasnova, ki ne more navesti tega naslova, ni dokončana.

DNS sledi demonu, ne tunelu

Vsebnik dobi konfiguracijo razreševalnika ob zagonu, kopirano iz demona ali iz slike. Naslovi, ki jih VPN potisne po povezavi, prispejo prepozno za to kopijo in se potisnejo v gostiteljev razreševalnik, ne v vsebnik.

Nastavite razreševalnik izrecno za storitev ali ga usmerite na notranji razreševalnik, dosegljiv skozi tunel. Vsebnik, ki zasebno ime razreši v javni naslov, običajno uporablja javni razreševalnik, ne trpi zaradi pokvarjene poti, popravek pa sodi v datoteko compose ali konfiguracijo demona.

Ista logika velja za vprašanje izhodnega naslova. Če se mora vsak vsebnik pojaviti z drugega naslova VPN, en gostiteljev tunel tega ne more zagotoviti, ker jih NAT stisne v en vir. Izvedljivi obliki sta odjemalec v imenskem prostoru vsakega vsebnika ali sidecar, ki ima tunel in deli svoj sklad, in oba spremenita način naslavljanja aplikacije.

Kontrolni seznam pred zaprtjem zahtevka: ugotovite imenski prostor, ki ima tunel, dokažite pot z gostiteljskim omrežjem, preslikajte le potrebno napravo tun, zapomnite si izvorni naslov po NAT, nastavite razreševalnik izrecno in obravnavajte izhodne naslove za vsebnik kot arhitekturno odločitev, ne kot zastavico.