Kial Docker-kontenero ne povas atingi gastigantojn malantaŭ la VPN

Kontenero, kiu atingas nenion malantaŭ la entreprena VPN, kutime loĝas en alia reta nomspaco ol la tunelo. La itineroj, DNS-serviloj kaj fajroŝirmaj markoj de la gastiganta kliento apartenas al la stako de la gastiganto; ponta kontenero havas sian propran. Tiu unu fakto klarigas la plej multajn raportojn, kiuj atingas platforman teamon, kaj ĝi ankaŭ klarigas, kial «la VPN estas rompita» kaj «Docker preterpasas la VPN» povas ambaŭ esti malĝustaj samtempe. Du tre malsamaj agordoj kaŝiĝas malantaŭ unu simptomo, do identigu, kiun vi havas, antaŭ ol ŝanĝi agordon.

Eltrovu, kies nomspaco posedas la tunelon

En Docker Desktop por macOS aŭ Windows la konteneroj kuras ene de Linux-virtuala maŝino. VPN-kliento instalita sur la labortablo kreas tunelon en la labortabla operaciumo, kaj la virtuala maŝino neniam vidas ĝin. Neniu kontenera agordo tion riparas, ĉar la interfaco, kiun la kontenero bezonus, tute ne ekzistas en ĝia reta nomspaco.

Sur Linux-gastiganto la tunelo loĝas en la nomspaco de la gastiganto, kaj pontaj konteneroj kutime atingas ĝin per la itinera tabelo de la gastiganto kun fonta NAT aplikata ĉe la eliro. Kiam tiu vojo malsukcesas, la kaŭzo kutime estas plusendada politiko, inversa voja filtrado aŭ interkovra subreto anstataŭ mankanta itinero. Konfirmu, en kiu el la du mondoj vi estas, antaŭ ol legi plu:

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

La diferenco inter tiuj du itinera tabeloj estas la tuta problemo sur unu ekrano. Se la vido de la gastiganto enhavas la tunelan interfacon kaj la vido de la ponto ne, vi rigardas nomspacan izolitecon, kaj ĉio alia estas elekto pri kiel transiri ĝin.

Gastiganta retado estas testado, ne dezajno

Ruli konteneron kun gastiganta retado, kiun Docker dokumentas kiel kunhavigon de la reta nomspaco de la gastiganto, igas ĝin rekte heredi la tunelan interfacon kaj ĝiajn itinerojn. Se la sama peto tiam sukcesas, la itinera teorio estas konfirmita kaj la fiasko estas nomspaca izoliteco anstataŭ legitimiloj, DNS aŭ alirregulo.

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

Konservu ĝin kiel diagnozon. Gastiganta retado rezignas pri havena publikigado kaj pri la plej granda parto de la izoliteco, kiun vi volis de kontenero, kaj en Docker Desktop «host» signifas la virtualan maŝinon, ne la labortablon, do sukceso aŭ fiasko tie povas misgvidi vin, se vi forgesas, kiun gastiganton vi alparolis.

tun-aparato kaj la privilegioj, kiuj venas kun ĝi

VPN-kliento ene de la kontenero bezonas tunelan aparaton kaj permeson agordi ĝin. La kutima mallongigo estas --privileged, kiu donas ĉiun aparaton kaj malstreĉas la sekurecan politikon tra la tuta kontenero. Tio estas multe pli ol tiu ĉi tasko postulas, kaj malfacilas pravigi en revizio.

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

La pli mallarĝa formo mapas la unuopan aparatan nodon kaj aldonas nur la retadministran kapablon. Unue ŝargu la modulon sur la gastiganto, por ke la nodo ekzistu. Se la kontenero startas kaj la kliento raportas, ke ĝi ne povas malfermi la tunelan aparaton, kontrolu la mapadon antaŭ ol suspekti la profilon, ĉar tiu eraro kutime estas laŭvorta.

Tiu ĉi dezajno ankaŭ signifas, ke la kliento kuras por ĉiu kontenero. Tio estas la ĝusta respondo, kiam ĉiu laborŝarĝo bezonas sian propran tunelon, kaj la malĝusta, kiam vi nur volis, ke la tunelo de la gastiganto estu videbla, kion la platforma teamo verŝajne supozis, ke vi faras.

Ponta NAT ŝanĝas la fonton, kiun la VPN vidas

Kun la defaŭlta ponto, elira kontenera trafiko tradukiĝas al la adreso de la gastiganto. Malantaŭ VPN la entreprena flanko do vidas la tunelan adreson de la gastiganto anstataŭ tiun de la kontenero, alirreguloj laŭ fonto kondutas kvazaŭ la gastiganto faris la peton, kaj du konteneroj fariĝas nedistingeblaj por la VPN-servilo.

macvlan aŭ ipvlan anstataŭe donas al la kontenero LAN-adreson, kio helpas LAN-malkovron kaj igas la konteneron aspekti kiel samtavolano en la segmento. Ĝi ankaŭ tute preterpasas la tunelon de la gastiganto, do tia kontenero ne atingos prefiksojn nur-VPN, krom se la VPN estas atingebla ankaŭ el tiu LAN.

Ambaŭ formoj estas legitimaj; ili respondas al malsamaj postuloj. Se la postulo estas «tiu ĉi kontenero devas atingi servon nur-VPN», vi elektas inter enrompado tra la gastiganto kaj finado de la tunelo ene de la kontenero. Skribu tiun elekton antaŭ la surmeto, ne post la unua malsukcesa peto. Kion ajn vi elektos, notu la fontan adreson, kiun la malproksima flanko vidos, ĉar ĝuste tion montros ĝiaj alirreguloj kaj ĝiaj protokoloj. Dezajno, kiu ne povas deklari tiun adreson, ne estas finita.

DNS sekvas la demonon, ne la tunelon

Kontenero ricevas sian solvilan agordon ĉe starto, kopiitan de la demono aŭ de la bildo. Adresoj, kiujn la VPN puŝas post konektiĝo, alvenas tro malfrue por tiu kopio, kaj ili estas puŝataj al la solvilo de la gastiganto anstataŭ en la konteneron.

Agordu la solvilon eksplicite por la servo, aŭ direktu ĝin al interna solvilo atingebla tra la tunelo. Kontenero, kiu solvas privatan nomon al publika adreso, kutime uzas publikan solvilon, ne suferas pro rompita itinero, kaj la korekto apartenas al la compose-dosiero aŭ al la demona agordo.

La sama rezonado validas por la demando pri elira adreso. Se ĉiu kontenero devas aperi de malsama VPN-adreso, unu gastiganta tunelo ne povas tion liveri, ĉar NAT kunpremas ilin en unu fonton. La fareblaj formoj estas kliento en la nomspaco de ĉiu kontenero aŭ flanka servilo, kiu posedas la tunelon kaj kunhavigas sian stakon, kaj ambaŭ ŝanĝas kiel la aplikaĵo estas adresita.

Kontrollisto antaŭ ol fermi la bileton: identigu la nomspacon, kiu posedas la tunelon, pruvu la vojon per gastiganta retado, mapu nur la bezonatan tun-aparaton, memoru la fontan adreson post NAT, agordu la solvilon eksplicite kaj traktu elirajn adresojn por kontenero kiel arkitekturan decidon anstataŭ kiel ŝaltilon.