Dev Container bereik nie 'n VPN-alleen-gasheer nie: waar om te kyk

Die private API open in jou lessenaar se blaaier en misluk in die ontwikkelhouer. Dit is nie 'n teenstrydigheid nie, en dit is selde die VPN self. Die blaaier se versoek en die versoek wat misluk, is deur verskillende prosesse gemaak, met verskillende resolveerders, proxy's en roetes, en dikwels heeltemal uit verskillende netwerknaamruimtes. “Op my skootrekenaar” kan die Windows-gasheer, 'n WSL-verspreiding, die Docker Desktop virtuele masjien en 'n houer binne daardie VM beteken — vier kontekste wat elkeen dieselfde gasheernaam anders kan beantwoord. Vind uit watter een die mislukkende proses gebruik voordat jy aan 'n enkele instelling raak.

Vind die proses voordat jy 'n instelling verander

Begin by die houerenjin eerder as by die VPN-kliënt. Vra aan watter konteks die opdragreël praat, en op watter bedryfstelsel daardie enjin loop, want 'n Linux-houer wat deur 'n lessenaar-VM bestuur word, is 'n ander pad as een wat deur 'n plaaslike daemon bestuur word:

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

Op Windows sê wsl -l -v vir jou of die verspreiding onder WSL 2 loop, wat dit agter sy eie virtuele skakelaar plaas. Daardie besonderheid bepaal of die houer die gasheer se roetetabel deel of agter 'n NAT sit wat 'n deurgevoerde poort of 'n gasheernaam nodig het om die gasheer te bereik.

Hou een versoek konstant en vergelyk

Kies een onskadelike eindpunt op die private gasheer en gebruik dit vir elke vergelyking: vanuit die blaaier, vanuit 'n gasheerterminale, vanuit die WSL-verspreiding en van binne die houer. Teken vier dinge vir elke poging aan: die opgeloste adres, of 'n proxy gebruik is, die foutklas en die verstreke tyd. Naamopsoeking, verbindingopbou, TLS-validering en 'n HTTP-status is vier verskillende probleme, en om hulle tot “dit werk nie” te vermeng, mors 'n oggend.

Voer die vergelyking binne die houer uit wat misluk, met 'n tydperk sodat 'n stille firewall nie die terminale vir minute beset nie. 'n Vars houer reproduseer die enjin se netwerkkonteks, maar nie die toepassinghouer se naamruimte, proxyveranderlikes of resolveerder nie, so docker exec in die regte een in is die gesaghebbende toets, en 'n sidecar is net 'n manier om te isoleer of die verskil by die enjin of by die houer lê:

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

Die alpine-basisbeeld dra busybox en geen curl nie, en dit is juis die soort besonderheid wat 'n gekopieerde diagnostiese blok laat misluk: kies 'n beeld met die kliënt, of voeg dit in dieselfde lopie by. 'n Vergelyking met onverwante openbare werwe isoleer niks. As https://example.com van die houer af werk, het jy geleer die houer het internettoegang, en niks daaroor of dit 'n private adres deur die tonnel kan bereik nie. Net so bewys die oopmaak van 'n nuwe terminale net dat die nuwe terminale werk, nie dat dit 'n looptyd met die toepassing deel wat misluk het nie.

Docker Desktop kan met 'n VPN werk

Docker se eie dokumentasie oor VPN en gasheerverbinding beskryf dit as 'n ondersteunde opstelling, en die eerlike samevatting is dat dit werk eerder as om outomaties te breek. Moenie aanvaar die lessenaar-VM omseil die gasheertonnel as 'n ontwerpkwessie nie; in baie opstellings volg die verkeer die gasheer se tonnel korrek, en daarom lewer die volksverhaal “Docker ignoreer die VPN” selfversekerde en verkeerde advies.

Wat steeds saak maak, is die backend wat gebruik word, die kliënt se split-tonnel-beleid en die resolveerder-konfigurasie wat die VM ontvang het. 'n VPN-kliënt wat roetes installeer maar nie DNS nie, of wat 'n DNS-bediener stoot wat die VM nie kan bereik nie, veroorsaak 'n naamopsoekfout binne die houer terwyl die gasheer werk omdat die gasheer 'n ekstra resolveerder of 'n gekasde antwoord het. Dit is 'n resolveerderprobleem in 'n houerkostuum. Dit oorleef elke VPN-herverbinding wat jy probeer, want die tonnel dra reeds die verkeer wat jy gevra het dit moet dra.

Adresoorvleueling en MTU is verskillende foute

Twee foute verdien hulle eie diagnose, want hulle word dikwels as toegangsbeleid misverstaan. Die eerste is 'n adresoorvleueling: as die VPN 'n reeks stoot wat met 'n houernetwerk se verstekbrug-subnet bots, wys die houer se roete vir daardie reeks na die plaaslike brug en bereik nooit die tonnel nie. Ondersoek die werklike subnette eerder as om te raai:

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

Die tweede is 'n MTU-probleem. As die verbinding tot stand kom en TLS voltooi, maar groter antwoorde vasval, het jy 'n pakketgrootte-kwessie, nie 'n magtigingskwessie nie, en die vervanging van DNS-rekords sal dit nooit regmaak nie. Toets met 'n klein versoek en 'n groot een voordat jy enigiets verander, en teken albei uitkomste aan.

Die oplossing vir 'n oorvleueling is 'n ander houersubnet of 'n beperkte roete, gekies deur wie ook al die adresplan besit. Die oplossing vir 'n MTU-vasvalling is om die tonnel- of koppelvlak-MTU te knyp of te verlaag tot 'n waarde wat die pad oorleef, toegepas op die laag wat jy beheer.

Proxy-konfigurasie is per proses, nie per masjien nie

Binne 'n houer verwys localhost na daardie houer se eie netwerkkonteks, so 'n proxy wat op die gasheer loop, is daar nie onder daardie naam bereikbaar nie. Docker Desktop verskaf host.docker.internal vir gasheertoegang, en op Linux voeg jy dit eksplisiet by met --add-host=host.docker.internal:host-gateway. Hoe dit ook al sy, daardie naam gee jou 'n roete na die gasheer; dit skep nie 'n proxydiens nie en magtig jou ook nie om een te gebruik nie.

Gebruik die proxy-adres en -poort wat vir die werklike omgewing verskaf word, en kyk wie dit lees. Veranderlikes wat in 'n interaktiewe skulp uitgevoer word, konfigureer nie outomaties elke redigeerderuitbreiding, taalserver, bougereedskap en agtergronddaemon nie. Die een wat saak maak, is die proses wat die mislukte versoek gemaak het, so ondersoek sy omgewing eerder as jou terminale s'n.

Laastens, laat die oplossing homself verduidelik. 'n Nuttige oplossing noem die grens wat verkeerd was, die instelling wat dit verander het, en die stel prosesse wat dit nou raak. Om die VPN, die redigeerder en die enjin in volgorde te herbegin, kan die simptoom verander, maar dit laat niks agter wat die volgende persoon kan gebruik nie.