Wêrom in Docker-kontener hosts efter de VPN net berikke kin

In kontener dy't neat efter de bedriuws-VPN berikke kin, libbet meastentiids yn in oare netwurknammeromte as de tunnel. De rûtes, DNS-tsjinners en firewallmerken fan ’e hostklient hearre ta de stapel fan ’e host; in brêgekontener hat syn eigen. Dat iene feit ferklearret de measte meldingen dy't by in platfoarmteam komme, en it is ek de reden wêrom't «de VPN is stikken» en «Docker giet om de VPN hinne» beide tagelyk ferkeard wêze kinne. Twa hiel ferskillende opsettings skûlje efter ien symptoom, dus identifisearje hokker jo hawwe foardat jo in ynstelling feroarje.

Fyn út hokker nammeromte de tunnel besit

Op Docker Desktop foar macOS of Windows rinne konteners binnen in Linux-firtuele masine. In VPN-klient dy't op ’e buroblêd ynstallearre is, makket in tunnel yn it bestjoeringssysteem fan ’e buroblêd, en de firtuele masine sjocht dy nea. Gjin kontenerkonfiguraasje reparearret dat, om't de ynterface dy't de kontener nedich hawwe soe, hielendal net bestiet yn syn netwurknammeromte.

Op in Linux-host libbet de tunnel yn ’e nammeromte fan ’e host, en brêgekonteners berikke him meastentiids fia de rûtingstabel fan ’e host mei boarne-NAT tapast op ’e wei út. As dat paad mislearret, is de oarsaak meastentiids trochstjoerbelied, filterjen fan ’e omkearde wei of in oerlappende subnet ynstee fan in ûntbrekkende rûte. Befêstigje yn hokker fan ’e twa wrâlden jo binne foardat jo fierder lêze:

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

It ferskil tusken dy twa rûtingstabellen is it hiele probleem op ien skerm. As it byld fan ’e host de tunnelinterface befettet en it byld fan ’e brêge net, sjogge jo nammeromte-isolaasje, en al it oare is in kar oer hoe't jo dy oerstekke.

Host-netwurk is in test, gjin ûntwerp

In kontener mei host-netwurk rinne litte, wat Docker dokumintearret as it dielen fan ’e netwurknammeromte fan ’e host, lit him de tunnelinterface en syn rûtes direkt ervje. As itselde fersyk dan slagget, is de rûteteory befêstige en is de flater nammeromte-isolaasje ynstee fan ynloggegevens, DNS of in tagongsregel.

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

Hâld it as diagnostyk. Host-netwurk jout poartepublikaasje en it measte fan ’e isolaasje dy't jo fan in kontener woene op, en op Docker Desktop betsjut «host» de firtuele masine, net de buroblêd, dus in súkses of mislearring dêr kin jo misliede as jo ferjitte hokker host jo oansprutsen.

In tun-apparaat en de foarrjochten dy't dermei komme

In VPN-klient yn ’e kontener hat in tunnelapparaat en tastimming nedich om it te konfigurearjen. De gewoane fluchwei is --privileged, dat elk apparaat jout en it feilichheidsbelied oer de hiele kontener fersloppet. Dat is folle mear as dizze taak fereasket, en it is dreech te ferantwurdzjen yn in beoardieling.

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

De smeller foarm mapt it iene apparaatknooppunt en foeget allinnich de netwurkbehear-kapasiteit ta. Laad earst de module op ’e host sadat it knooppunt bestiet. As de kontener start en de klient meldt dat er it tunnelapparaat net iepenje kin, kontrolearje dan de mapping foardat jo it profyl fertinke, want dy flater is meastentiids letterlik.

Dit ûntwerp betsjut ek dat de klient per kontener rint. Dat is it goede antwurd as elke wurklêst syn eigen tunnel nedich hat, en it ferkearde as jo gewoan de tunnel fan ’e host sichtber hawwe woene, wat it platfoarmteam wierskynlik oannaam dat jo diene.

Brêge-NAT feroaret de boarne dy't de VPN sjocht

Mei de standertbrêge wurdt útgeand kontenerferkear oerset nei it adres fan ’e host. Efter in VPN sjocht de bedriuwskant dus it tunneladres fan ’e host ynstee fan dat fan ’e kontener, tagongsregels per boarne gedrage har as hie de host it fersyk dien, en twa konteners wurde foar de VPN-tsjinner ûnûnderskiedber.

macvlan of ipvlan jout de kontener ynstee dêrfan in LAN-adres, wat helpt by LAN-ûntdekking en de kontener as in gelikense op it segmint lit lykje. It giet ek folslein om ’e tunnel fan ’e host hinne, dus sa'n kontener sil gjin allinnich-VPN-prefiksen berikke, útsein as de VPN ek fan dat LAN ôf berikber is.

Beide foarmen binne legitime; se beäntwurdzje ferskillende easken. As de eask is «dizze kontener moat in allinnich-VPN-tsjinst berikke», dan kiest jo tusken rûting fia de host en it einigjen fan ’e tunnel yn ’e kontener. Skriuw dy kar op foar de útrulling, net nei it earste mislearre fersyk. Hokker jo ek kieze, notearje it boarneadres dat de fiere kant sjen sil, want dat is wat syn tagongsregels en syn logboeken sjen litte. In ûntwerp dat dat adres net neame kin, is net klear.

DNS folget de daemon, net de tunnel

In kontener krijt syn resolver-konfiguraasje by it starten, kopiearre fan ’e daemon of fan it byld. Adressen dy't de VPN nei it ferbinen push, komme te let foar dy kopy, en se wurde nei de resolver fan ’e host pusht ynstee fan yn ’e kontener.

Stel de resolver eksplisyt yn foar de tsjinst, of wiis him nei in ynterne resolver dy't fia de tunnel berikber is. In kontener dy't in priveename nei in iepenbier adres oplost, brûkt meastentiids in iepenbiere resolver, gjin brutsen rûte, en de ferbettering heart yn it compose-bestân of de daemonkonfiguraasje.

Itselde redenearring jildt foar de fraach fan it útgongsadres. As elke kontener fan in oar VPN-adres ferskine moat, kin ien tunnel fan ’e host dat net leverje, om't NAT se yn ien boarne gearfettet. De wurkbere foarmen binne in klient yn ’e nammeromte fan elke kontener of in sidecar dy't de tunnel besit en syn stapel dielt, en beide feroarje hoe't de applikaasje adressearre wurdt.

Kontrolelist foardat jo it ticket slute: identifisearje de nammeromte dy't de tunnel besit, bewiis it paad mei host-netwurk, map allinnich it tun-apparaat dat jo nedich hawwe, ûnthâld it boarneadres nei NAT, stel de resolver eksplisyt yn en behannelje útgongsadressen per kontener as in arsjitektuerbeslissing ynstee fan in flagge.