Houer bereik nie die VPN-only API nie? Proxy dit op die gasheer

Die tonnel woon op die gasheer, so die houer het geen roete na die private adres nie. Publiseer ’n smal omgekeerde proxy en roep dit as host.docker.internal.

Jou Compose-diens hou aan om te time-out teen ’n API wat die blaaier op dieselfde masjien sonder enige klagte oopmaak. Daardie verskil is die leidraad: die versoek wat werk, verlaat ’n gasheer met ’n VPN-tonnel, en die versoek wat hang, verlaat ’n houer met sy eie netwerkstapel. Niks binne die houer ken die tonnel se roetes nie, so die private bestemming bly onbereikbaar, hoe die naam ook al gespel word. Die regstelling is ’n doelbewuste sprong deur die gasheer, nie ’n slimmer roetetabel nie.

Begin met waarom die twee paadjies verskil, en besluit dan waar die tonnel moet woon.

Waarom die gasheer werk en die houer nie

Om die tonnel op te bring gee die gasheer ’n koppelvlak, ’n stel roetes en gewoonlik ’n resolver-inskrywing wat deur die VPN verskaf word. ’n Houer erf niks daarvan nie: dit begin met een koppelvlak op die enjin se brug en ’n verstekroete wat na daardie brug wys. Roetes wat op die gasheer geïnstalleer is, is onsigbaar vir enigiets wat binne daardie naamruimte hardloop.

Dit is waarom die simptome onsamehangend lyk eerder as bloot stukkend. Die gasheer los die private naam op en konnekteer, want beide die naam en die roete bestaan daar. Die houer stuur sy pakkie na ’n private adres wat niks op die brugpad kan bereik nie, en die versoek time-out. Om die naam by die houer se hosts-lêer te voeg, verander niks, want die adres self is onbereikbaar van waar die houer sit.

Bereik die gasheer van binne die houer

’n Proses in die houer wat localhost skakel, skakel die houer. Docker Desktop publiseer host.docker.internal as ’n naam wat terugwys na die masjien wat die enjin laat loop; Linux-enjins laat dit ongedefinieerd tensy die diens daarom vra, en dit is wat die kartering hieronder doen. Met dit in plek mik die toepassing op ’n naam en ’n poort in plaas van die private adres.

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

Die tonnel bly aan die gasheerkant van die sprong, en die poort in daardie veranderlike is die een waarop die proxy sal luister. ’n Houer wat die tonnel verloor, faal nou by ’n enkele bekende sprong in plaas daarvan om ’n roete te probeer wat hy nooit gehad het nie.

Kies waar die tonnel woon

Drie vorms is moontlik vir ’n Compose-diens wat ’n private API nodig het, en hulle verskil in watter proses die tonnel besit. ’n VPN-kliënt kan binne die houerbeeld hardloop, wat vereis dat ’n tonneltoestel blootgestel word en dat die netwerkadministrasie-vermoë wat daarmee saamgaan, toegeken word. Die toepassing kan die netwerknaamruimte van ’n aparte tonnelhouer deel, sodat beide prosesse een stapel en een roetetabel sien. Of die tonnel kan op die gasheer bly, met ’n smal deurvoerder van die gasheer na die houer.

Die eerste twee trek profiellêers, herverbindingsgedrag en resolver-beleid in die projek in, en hulle maak elke diens in die lêer afhanklik van die tonnel se gesondheid. Dit is baie koppeling vir een API-oproep. Vir ’n ontwikkelingstapel wat een enkele interne eindpunt lees, is die gasheerkant-deurvoerder die kleinste verandering wat steeds geloofsbriewe hou waar die platformspan hulle bestuur.

Publiseer een smal pad op die gasheer

Begin by wat die deurvoerder erf: laat dit loop onder die rekening wat die tonnel besit, en sy uitgaande sokkels neem die gasheer se roetes en die gasheer se resolver oor. Een nginx location-blok dek een pad.

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

Behandel die adres en die poort as plekhouers en vervang dit met die paar waarop die API werklik luister. Elke verdere upstream verdien sy eie location-blok, en elke blok moet slegs die paaie toelaat wat hierdie diens roep, sodat die proxy nie ’n algemene deur na die private netwerk kan word nie. Bind die luisteraar aan die brugadres vir kliënte wat deur host-gateway aankom, aan loopback slegs wanneer die kliënt die gasheer se netwerknaamruimte deel, en nooit aan 0.0.0.0 nie. Kies ook ’n poort wat nog vry is: ’n nommer wat reeds geneem is, laat die proxy nie luister nie terwyl die houer aanhou time-out, wat nie van die netwerkfout waarmee jy begin het, te onderskei is nie.

Poorte, name en die TLS-besluit

Naamresolusie splits op dieselfde manier as roetering. Die houer se publieke opsoeke gaan deur die enjin se resolver, so ’n private naam wat op die gasheer oplos, sal nie binne die houer oplos nie. Die proxy is die komponent wat die private naam oplos, want dit erf die gasheer se resolver.

TLS is die besluit wat uitgestel word en dan die volgende fout verduidelik. As die proxy grepe onaangeraak deurstuur, sien die houer die API se eie sertifikaat en het die interne CA in sy vertrouensberg nodig. As die proxy TLS termineer, skuif daardie vertroue na die gasheer en begin die toepassing skakels bou uit die host-opskrif wat dit ontvang. Kies een reëling en pas dit op elke hulpbron toe, want ’n herleiding wat deur die ander een uitgereik word, wys na ’n gasheernaam wat die houer nie kan oplos nie.

Verifieer van binne die diens

Stuur die versoek uit die houer, nie uit die gasheer nie: ’n gewone curl teen die proxy-pad, dan die toepassing se eie gesondheidstoets. Wanneer die proxy antwoord maar die toepassing steeds faal, vergelyk drie dinge: die basis-URL wat dit bou, enige proxy-veranderlike in sy omgewing, en die CA wat dit vertrou. Almal sit in die houer se omgewing en logs, en om enige een reg te maak, laat die VPN ongemoeid.

Skryf die gekose reëling in die projek se README terwyl dit vars is. Die volgende persoon wat hierdie time-out tref, sal andersins dieselfde middag spandeer om te herontdek dat die tonnel op die gasheer woon.

Verwante artikels