Dev-container bereikt geen alleen-via-VPN-host: waar je moet kijken

De privé-API opent in je desktopbrowser en faalt in de ontwikkelcontainer. Dat is geen tegenspraak, en zelden is de VPN zelf de oorzaak. Het browserverzoek en het falende verzoek zijn gedaan door verschillende processen, met verschillende resolvers, proxies en routes, en vaak vanuit volledig verschillende netwerknaamruimten. ‘Op mijn laptop’ kan de Windows-host, een WSL-distributie, de Docker Desktop-VM en een container binnen die VM betekenen — vier contexten die elk dezelfde hostnaam anders kunnen beantwoorden. Zoek uit welke het falende proces gebruikt voordat je één instelling aanraakt.

Vind het proces voordat je een instelling wijzigt

Begin bij de containermotor, niet bij de VPN-client. Vraag met welke context de commandoregel praat en op welk besturingssysteem die motor draait, want een Linux-container die door een desktop-VM wordt beheerd, volgt een ander pad dan een die door een lokale daemon wordt beheerd:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Op Windows vertelt wsl -l -v of de distributie onder WSL 2 draait, wat hem achter zijn eigen virtuele switch plaatst. Dat detail bepaalt of de container de routetabel van de host deelt of achter een NAT zit die een doorgestuurde poort of een hostnaam nodig heeft om de host te bereiken.

Houd één verzoek constant en vergelijk

Kies één onschadelijk eindpunt op de privé-host en gebruik het voor elke vergelijking: vanuit de browser, vanuit een hostterminal, vanuit de WSL-distributie en van binnenuit de container. Noteer vier dingen per poging: het opgeloste adres, of een proxy is gebruikt, de foutklasse en de verstreken tijd. Naamopzoeking, verbindingsopbouw, TLS-validatie en een HTTP-status zijn vier verschillende problemen, en ze tot ‘het werkt niet’ vermengen kost een ochtend.

Voer de vergelijking uit in de container die faalt, met een time-out zodat een stille firewall de terminal niet minutenlang bezet houdt. Een verse container reproduceert de netwerkcontext van de motor, maar niet de naamruimte, proxyvariabelen of resolver van de applicatiecontainer, dus docker exec in de echte container is de gezaghebbende test, en een sidecar is alleen een manier om te isoleren of het verschil in de motor of in de container zit:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

De alpine-basisimage bevat busybox en geen curl, en dat is precies het soort detail waardoor een gekopieerd diagnoseblok faalt: kies een image met de client, of voeg hem in dezelfde uitvoering toe. Een vergelijking met ongerelateerde openbare sites isoleert niets. Als https://example.com vanuit de container werkt, heb je geleerd dat de container internettoegang heeft, en niets over of hij via de tunnel een privéadres bereikt. Evenzo bewijst het openen van een nieuwe terminal alleen dat de nieuwe terminal werkt, niet dat hij een runtime deelt met de applicatie die faalde.

Docker Desktop kan met een VPN werken

Dockers eigen documentatie over VPN en hostconnectiviteit beschrijft dit als een ondersteunde opstelling, en de eerlijke samenvatting is dat het werkt in plaats van automatisch stuk te zijn. Ga er niet van uit dat de desktop-VM de tunnel van de host ontwerpmatig omzeilt; in veel opstellingen volgt het verkeer de tunnel van de host correct, en daarom levert het verhaal ‘Docker negeert de VPN’ zelfverzekerd en onjuist advies op.

Wat nog steeds telt, is de gebruikte backend, het split-tunnelbeleid van de client en de resolverconfiguratie die de VM heeft ontvangen. Een VPN-client die routes installeert maar geen DNS, of die een DNS-server pusht die de VM niet kan bereiken, produceert een naamopzoekingfout in de container, terwijl de host werkt omdat die een extra resolver of een gecachet antwoord heeft. Dat is een resolverprobleem in containerkostuum. Het overleeft elke VPN-herverbinding die je probeert, omdat de tunnel al het verkeer draagt dat je hem vroeg te dragen.

Adresoverlap en MTU zijn verschillende fouten

Twee fouten verdienen hun eigen diagnose omdat ze vaak voor toegangsbeleid worden aangezien. De eerste is een adresoverlap: als de VPN een bereik pusht dat botst met de standaardbridge-subnet van een containernetwerk, wijst de route van de container voor dat bereik naar de lokale bridge en bereikt de tunnel nooit. Inspecteer de werkelijke subnetten in plaats van te gokken:

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

De tweede is een MTU-probleem. Als de verbinding tot stand komt en TLS voltooit maar grotere antwoorden vastlopen, heb je een pakketgrootteprobleem, geen autorisatieprobleem, en DNS-records vervangen lost het nooit op. Test met een klein en een groot verzoek voordat je iets wijzigt, en noteer beide resultaten.

De oplossing voor een overlap is een ander containersubnet of een beperkte route, gekozen door wie het adresplan bezit. De oplossing voor een MTU-vastloper is het knijpen of verlagen van de MTU van de tunnel of interface tot een waarde die het pad overleeft, toegepast op de laag die je beheert.

Proxyconfiguratie is per proces, niet per machine

Binnen een container verwijst localhost naar de eigen netwerkcontext van die container, dus een proxy die op de host draait is daar onder die naam niet bereikbaar. Docker Desktop biedt host.docker.internal voor hosttoegang, en op Linux voeg je die expliciet toe met --add-host=host.docker.internal:host-gateway. Hoe dan ook, die naam geeft je een route naar de host; hij maakt geen proxydienst en geeft je niet het recht er een te gebruiken.

Gebruik het proxyadres en de poort die voor de werkelijke omgeving zijn opgegeven, en controleer wie ze leest. Variabelen die in een interactieve shell worden geëxporteerd, configureren niet automatisch elke editor-extensie, taalserver, buildtool en achtergronddaemon. Het gaat om het proces dat het falende verzoek deed, dus inspecteer de omgeving daarvan en niet die van je terminal.

Laat de fix ten slotte zichzelf uitleggen. Een bruikbare oplossing noemt de grens die fout was, de instelling die hem veranderde en de set processen die er nu door wordt beïnvloed. De VPN, de editor en de motor achter elkaar herstarten kan het symptoom veranderen, maar laat niets achter dat de volgende persoon kan gebruiken.