Kin de container it API dat allinnich fia VPN te berikken is, net berikke? Proxy it op de host

De tunnel libbet op de host, dus de container hat gjin rûte nei it privee-adres. Publisearje in smelle omkearde proxy en rop dy oan as host.docker.internal.

Jo Compose-tsjinst rint yn in tiidlimit tsjin in API dat de browser op deselde masine sûnder kleien iepenet. Dat ferskil is de oanwizing: it fersyk dat wurket ferlit in host mei in VPN-tunnel, en it fersyk dat hinget ferlit in container mei syn eigen netwurkstapel. Nimmen yn de container ken de rûtes fan de tunnel, dus de priveebestimming bliuwt ûnberikber hoe’t de namme ek skreaun wurdt. De oplossing is in bewuste sprong troch de host, net in tûnere rûtetabel.

Begjin mei wêrom’t de twa paden ferskille, en beslute dan wêr’t de tunnel libje moat.

Wêrom’t de host wurket en de container net

It oprjochtsjen fan de tunnel jout de host in ynterface, in set rûtes en meastentiids in resolver-ynskriuwing fan it VPN. In container erft dêr neat fan: hy begjint mei ien ynterface op ‘e brêge fan ‘e motor en in standertrûte dy’t nei dy brêge wiist. Rûtes dy’t op ‘e host ynstalleare binne, binne ûnsichtber foar alles wat binnen dy nammeromte rint.

Dêrom lykje de symptomen ynkonsistint ynstee fan gewoan stikken. De host lost de priveenamme op en ferbynt, om’t sawol de namme as de rûte dêr bestiet. De container stjoert syn pakket nei in privee-adres dat nimmen op it brêgepaad berikke kin, en it fersyk rint yn in tiidlimit. It tafoegjen fan de namme oan it hosts-bestân fan ‘e container feroaret neat, om’t it adres sels ûnberikber is fan wêr’t de container sit.

Berik de host fan binnen de container

In proses yn ‘e container dat localhost skillet, skillet de container. Docker Desktop publisearret host.docker.internal as in namme dy’t werom wiist nei de masine dy’t de motor rint; Linux-motoren litte it ûndefiniearre oant de tsjinst derom freget, en dat is wat de mapprint hjirûnder docht. Dêrmei rjochtet de applikaasje him op in namme en in poarte ynstee fan it privee-adres.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

De tunnel bliuwt oan ‘e hostkant fan ‘e sprong, en de poarte yn dy fariabele is dejinge dêr’t de proxy op harkje sil. In container dy’t de tunnel ferliest, mislearret no by ien bekende sprong ynstee fan in rûte te besykjen dy’t er nea hie.

Kies wêr’t de tunnel libbet

Trije foarmen binne mooglik foar in Compose-tsjinst dy’t in privee-API nedich hat, en se ferskille yn hokker proses de tunnel besit. In VPN-klant kin yn it containerbyld rinne, wat freget om in tunnelapparaat bleat te lizzen en de netwurkadministraasjekapasiteit dy’t dêrmei heart ta te kennen. De applikaasje kin de netwurknammeromte fan in aparte tunnelcontainer diele, sadat beide prosessen ien stapel en ien rûtetabel sjogge. Of de tunnel kin op ‘e host bliuwe, mei in smelle trochstjoerder fan ‘e host nei de container.

De earste twa lûke profylbestannen, werferbyningsgedrach en resolverbelied it projekt yn, en se meitsje elke tsjinst yn it bestân ôfhinklik fan ‘e sûnens fan ‘e tunnel. Dat is in soad keppeling foar ien API-oprop. Foar in ûntwikkelingsstapel dy’t ien yntern einpunt lêst, is de trochstjoerder oan ‘e hostkant de lytste feroaring dy’t de bewiisstikken dochs hâldt wêr’t it platfoarmteam se beheart.

Publisearje ien smel paad op ‘e host

Begjin mei wat de trochstjoerder erft: rin him as it akkount dat de tunnel besit, en syn útgeande sockets nimme de rûtes fan ‘e host en de resolver fan ‘e host oer. Ien nginx location-blok dekt ien paad.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

Behannelje it adres en de poarte as ferfangers en set it pear dêr’t de API wier op harket. Eltse folgjende upstream fertsjinnet syn eigen location-blok, en elk blok moat allinnich de paden tastean dy’t dizze tsjinst ropt, sadat de proxy gjin algemiene doar nei it priveenetwurk wurde kin. Bynt de harker oan it brêge-adres foar kliïnten dy’t fia host-gateway komme, oan loopback allinnich as de kliïnt de netwurknammeromte fan ‘e host dielt, en nea oan 0.0.0.0. Kies ek in poarte dy’t noch frij is: in nûmer dat al nommen is, lit de proxy net harkje wylst de container yn in tiidlimit bliuwt rinnen, wat net te ûnderskieden is fan ‘e netwurkskuerre dêr’t jo mei begûnen.

Poarten, nammen en it TLS-beslút

Nammeroplossing splitset itselde as rûtering. De iepenbiere sykopsjes fan ‘e container geane fia de resolver fan ‘e motor, dus in priveenamme dy’t op ‘e host oplost, sil binnen de container net oplosse. De proxy is it ûnderdiel dat de priveenamme oplost, om’t it de resolver fan ‘e host erft.

TLS is it beslút dat útsteld wurdt en dan de folgjende mislearring ferklearret. As de proxy bytes ûnoantaaste trochstjoert, sjocht de container it eigen sertifikaat fan ‘e API en hat de ynterne CA yn syn fertrouwensopslach nedich. As de proxy TLS beëiniget, ferhuist dat fertrouwen nei de host en begjint de applikaasje keppelingen te bouwen fan ‘e host-kop dy’t er krijt. Kies ien regeling en pas dy op elke boarne ta, om’t in omlieding fan ‘e oare wiist nei in hostnamme dy’t de container net oplosse kin.

Ferifiearje fan binnen de tsjinst

Stjoer it fersyk fan ‘e container, net fan ‘e host: in gewoane curl tsjin it proxypaad, dan de eigen sûnenscheck fan ‘e applikaasje. As de proxy antwurdet mar de applikaasje mislearret noch, fergelykje trije dingen: de basis-URL dy’t er bout, hokker proxyfariabele dan ek yn syn omjouwing, en de CA dy’t er fertrout. Alle sitte se yn ‘e omjouwing en logs fan ‘e container, en it reparearjen fan ien fan se lit it VPN gewurde.

Skriuw de keazen regeling yn ‘e README fan it projekt wylst se farsk is. Oars sil de folgjende persoan dy’t dizze tiidlimit treft deselde middei trochbringe mei it werûntdekken dat de tunnel op ‘e host libbet.

Relatearre artikelen