Waarom ’n Docker-houer nie hosts agter die VPN kan bereik nie

’n Houer wat niks agter die korporatiewe VPN kan bereik nie, woon gewoonlik in ’n ander netwerknaamruimte as die tonnel. Die host-kliënt se roetes, DNS-bediener en firewall-merke hoort aan die host se stapel; ’n brugnetwerk-houer het sy eie. Daardie enkele feit verduidelik die meeste verslae wat ’n platformspan bereik, en dit is ook hoekom “die VPN is stukkend” en “Docker omseil die VPN” albei op dieselfde tyd verkeerd kan wees. Twee baie verskillende opstellings skuil agter een simptoom, so identifiseer watter een jy het voordat jy ’n instelling verander.

Vind uit wie se naamruimte die tonnel besit

Op Docker Desktop vir macOS of Windows hardloop houers binne ’n Linux-virtuele masjien. ’n VPN-kliënt wat op die rekenaar geïnstalleer is, skep ’n tonnel in die rekenaar se bedryfstelsel, en die virtuele masjien sien dit nooit. Geen houerkonfigurasie herstel dit nie, want die koppelvlak wat die houer nodig sou hê, bestaan glad nie in sy netwerknaamruimte nie.

Op ’n Linux-host woon die tonnel in die host-naamruimte, en brug-houers bereik dit gewoonlik deur die host se roetertabel met bron-NAT wat op pad uit toegepas word. Wanneer daardie pad faal, is die oorsaak gewoonlik deurvorwardingsbeleid, tru-pad-filtrering of ’n oorvleuelende subnet eerder as ’n ontbrekende roete. Bevestig in watter van die twee wêrelde jy is voordat jy verder lees:

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

Die verskil tussen daardie twee roetertabelle is die hele probleem op een skerm. As die host-aansig die tonnelkoppelvlak bevat en die brug-aansig nie, kyk jy na naamruimte-isolasie, en alles anders is ’n keuse oor hoe om dit oor te steek.

Host-netwerking is ’n toets, nie ’n ontwerp nie

Om ’n houer met host-netwerking te laat hardloop, wat Docker dokumenteer as deel van die host se netwerknaamruimte, laat dit die tonnelkoppelvlak en sy roetes direk erf. As dieselfde versoek dan slaag, is die roete-teorie bevestig en is die fout naamruimte-isolasie eerder as geloofsbriewe, DNS of ’n toegangsreël.

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

Hou dit as ’n diagnostiese middel. Host-netwerking gee poortpublikasie en die meeste isolasie wat jy van ’n houer wou hê prys, en op Docker Desktop beteken “host” die virtuele masjien, nie die rekenaar nie, so ’n sukses of mislukking daar kan jou mislei as jy vergeet watter host jy aangespreek het.

’n tun-toestel en die voorregte wat daarmee saamkom

’n VPN-kliënt binne die houer het ’n tonneltoestel en toestemming nodig om dit te konfigureer. Die algemene kortpad is --privileged, wat elke toestel toestaan en sekuriteitsbeleid oor die hele houer verslap. Dit is veel meer as wat hierdie taak vereis, en dit is moeilik om in ’n resensie te regverdig.

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

Die nouer vorm karteer die enkele toestelknoop en voeg net die netwerkadministrasie-vermoë by. Laai eers die module op die host sodat die knoop bestaan. As die houer begin en die kliënt meld dat hy die tonneltoestel nie kan oopmaak nie, kyk na die kartering voordat jy die profiel verdink, want daardie fout is gewoonlik letterlik.

Hierdie ontwerp beteken ook die kliënt hardloop per houer. Dit is die regte antwoord wanneer elke werklading sy eie tonnel nodig het, en die verkeerde antwoord wanneer jy net wou hê die host se tonnel moet sigbaar wees, wat die platformspan waarskynlik aangeneem het jy doen.

Brug-NAT verander die bron wat die VPN sien

Met die standaardbrug word uitgaande houerverkeer na die host-adres vertaal. Agter ’n VPN sien die korporatiewe kant dus die host se tonneladres eerder as die houer s’n, reëls per bron tree op asof die host die versoek gemaak het, en twee houers word vir die VPN-bediener ononderskeibaar.

macvlan of ipvlan gee die houer eerder ’n LAN-adres, wat met LAN-ontdekking help en die houer soos ’n eweknie op die segment laat lyk. Dit omseil ook die host-tonnel heeltemal, so so ’n houer sal nie VPN-alleen-prefikse bereik nie tensy die VPN ook van daardie LAN af bereikbaar is.

Beide vorms is geldig; hulle antwoord verskillende vereistes. As die vereiste “hierdie houer moet ’n VPN-alleen-diens bereik” is, kies jy tussen roetering deur die host en die beëindiging van die tonnel binne die houer. Skryf daardie keuse neer voor die ontplooiing, nie ná die eerste mislukte versoek nie. Watter een jy ook al kies, teken die bronadres aan wat die ander kant sal sien, want dit is wat sy toegangsreëls en sy logboeke sal wys. ’n Ontwerp wat nie daardie adres kan noem nie, is nie klaar nie.

DNS volg die daemon, nie die tonnel nie

’n Houer kry sy resolver-konfigurasie wanneer dit begin, gekopieer van die daemon of van die beeld. Adresse wat die VPN ná verbinding stoot, kom te laat vir daardie kopie, en hulle word na die host-resolver gestoot eerder as in die houer in.

Stel die resolver eksplisiet vir die diens, of wys dit na ’n interne resolver wat deur die tonnel bereikbaar is. ’n Houer wat ’n private naam na ’n publieke adres oplos, gebruik gewoonlik ’n publieke resolver, nie ’n gebreekte roete nie, en die regstelling hoort in die compose-lêer of daemon-konfigurasie.

Dieselfde redenering geld vir die uitgangsadres-vraag. As elke houer van ’n ander VPN-adres moet verskyn, kan een host-tonnel dit nie lewer nie, want NAT vou hulle in een bron saam. Die werkbare vorms is ’n kliënt in elke houer se naamruimte of ’n sidecar wat die tonnel besit en sy stapel deel, en albei verander hoe die toepassing geadresseer word.

Kontrolelys voordat jy die kaartjie sluit: identifiseer die naamruimte wat die tonnel besit, bewys die pad met host-netwerking, karteer net die tun-toestel wat jy nodig het, onthou die bronadres ná NAT, stel die resolver eksplisiet, en behandel uitgangsadresse per houer as ’n argitektuur-besluit eerder as ’n vlag.