Dev-kontti ei tavoita vain VPN:n kautta saatavaa hostia: mistä etsiä

Yksityinen API avautuu työpöytäselaimessasi ja epäonnistuu kehityskontissa. Se ei ole ristiriita, ja harvoin syy on itse VPN. Selainpyynnön ja epäonnistuvan pyynnön tekivät eri prosessit, joilla oli eri resolverit, proxyt ja reitit, ja usein täysin eri verkon nimiavaruudet. „Läppärilläni“ voi tarkoittaa Windows-hostia, WSL-jakelua, Docker Desktopin virtuaalikonetta ja konttia kyseisen VM:n sisällä – neljää kontekstia, joista jokainen voi vastata samaan hostinimeen eri tavalla. Selvitä, mitä niistä epäonnistuva prosessi käyttää, ennen kuin kosket yhteenkään asetukseen.

Paikanna prosessi ennen asetuksen muuttamista

Aloita konttimoottorista, älä VPN-asiakkaasta. Kysy, mihin kontekstiin komentorivi puhuu ja millä käyttöjärjestelmällä tuo moottori toimii, koska työpöytä-VM:n hallitsema Linux-kontti kulkee eri polkua kuin paikallisen daemonin hallitsema:

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

Windowsissa wsl -l -v kertoo, toimiiko jakelu WSL 2:n alla, mikä asettaa sen oman virtuaalikytkimensä taakse. Tämä yksityiskohta ratkaisee, jakautuuko kontti hostin reititystaulukon kanssa vai istuuko se NAT:n takana, joka tarvitsee välitetyn portin tai hostinimen päästäkseen hostiin.

Pidä yksi pyyntö vakiona ja vertaa

Valitse yksi vaaraton päätepiste yksityiseltä hostilta ja käytä sitä jokaiseen vertailuun: selaimesta, hostin terminaalista, WSL-jakelusta ja kontin sisältä. Kirjaa jokaisesta yrityksestä neljä asiaa: ratkaistu osoite, käytettiinkö proxyä, virheluokka ja kulunut aika. Nimenhaku, yhteyden muodostus, TLS-vahvistus ja HTTP-tila ovat neljä eri ongelmaa, ja niiden sekoittaminen muotoon „ei toimi“ tuhlaa aamupäivän.

Suorita vertailu epäonnistuvan kontin sisällä aikakatkaisulla, jotta hiljainen palomuuri ei pidä terminaalia minuuttikaupalla. Tuore kontti toistaa moottorin verkkokontekstin mutta ei sovelluskontin nimiavaruutta, proxy-muuttujia tai resolveria, joten docker exec oikeaan konttiin on auktoritatiivinen testi ja sivukontti on vain tapa eristää, onko ero moottorissa vai kontissa:

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

alpine-peruskuva sisältää busyboxin eikä curl:ia, ja juuri sellainen yksityiskohta kaataa kopioidun diagnostiikkablokin: valitse kuva, jossa asiakas on, tai lisää se samaan ajoon. Vertailu asiaankuulumattomiin julkisiin sivustoihin ei eristä mitään. Jos https://example.com toimii kontista, olet oppinut, että kontilla on internetyhteys, etkä mitään siitä, tavoittaako se yksityisen osoitteen tunnelin kautta. Samoin uuden terminaalin avaaminen todistaa vain, että uusi terminaali toimii, ei sitä, että se jakaa ajonaikaisen ympäristön epäonnistuneen sovelluksen kanssa.

Docker Desktop voi toimia VPN:n kanssa

Dockerin oma dokumentaatio VPN:stä ja host-yhteydestä kuvaa tämän tuetuksi kokoonpanoksi, ja rehellinen yhteenveto on, että se toimii sen sijaan että olisi automaattisesti rikki. Älä oleta, että työpöytä-VM ohittaa hostin tunnelin suunnittelun vuoksi; monissa kokoonpanoissa liikenne seuraa hostin tunnelia oikein, ja siksi satu „Docker jättää VPN:n huomiotta“ tuottaa itsevarmoja ja vääriä neuvoja.

Yhä merkityksellistä on käytetty backend, asiakkaan split-tunnel-käytäntö ja resolver-kokoonpano, jonka VM sai. VPN-asiakas, joka asentaa reitit mutta ei DNS:ää, tai työntää DNS-palvelinta, johon VM ei pääse, tuottaa nimihaun epäonnistumisen kontin sisällä, kun taas host toimii, koska sillä on ylimääräinen resolveri tai välimuistiin tallennettu vastaus. Se on resolver-ongelma konttipuvussa. Se selviää jokaisesta VPN-yhdistämisestä, jota yrität, koska tunneli kuljettaa jo pyytämäsi liikenteen.

Osoitteiden päällekkäisyys ja MTU ovat eri vikoja

Kaksi vikaa ansaitsee oman diagnoosin, koska ne sekoitetaan usein käyttöoikeuskäytäntöön. Ensimmäinen on osoitteiden päällekkäisyys: jos VPN työntää alueen, joka törmää konttiverkon oletussillan aliverkkoon, kontin reitti kyseiselle alueelle osoittaa paikalliseen siltaan eikä koskaan saavuta tunnelia. Tarkastele todelliset aliverkot sen sijaan että arvaisit:

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

Toinen on MTU-ongelma. Jos yhteys muodostuu ja TLS valmistuu, mutta suuremmat vastaukset juuttuvat, sinulla on pakettikoko-ongelma, ei valtuutusongelma, eikä DNS-tietueiden korvaaminen korjaa sitä koskaan. Testaa pienellä ja suurella pyynnöllä ennen kuin muutat mitään, ja kirjaa molemmat tulokset.

Päällekkäisyyden korjaus on eri kontin aliverkko tai rajattu reitti, jonka valitsee osoitesuunnitelman omistaja. MTU-juuttumisen korjaus on tunnelin tai liitännän MTU:n kiristäminen tai pienentäminen arvoon, joka kestää polun, sovellettuna kerroksessa, jota hallitset.

Proxy-kokoonpano on prosessikohtainen, ei konekohtainen

Kontin sisällä localhost nimeää kyseisen kontin oman verkkokontekstin, joten hostilla toimiva proxy ei ole siellä saatavilla tuolla nimellä. Docker Desktop tarjoaa host.docker.internal host-käyttöön, ja Linuxissa lisäät sen eksplisiittisesti komennolla --add-host=host.docker.internal:host-gateway. Kummassakin tapauksessa nimi antaa reitin hostiin; se ei luo proxy-palvelua eikä valtuuta sinua käyttämään sellaista.

Käytä proxy-osoitetta ja porttia, jotka on annettu todelliselle ympäristölle, ja tarkista, kuka niitä lukee. Interaktiivisessa kuoressa viedyt muuttujat eivät automaattisesti kokoonpane jokaista editorin laajennusta, kielipalvelinta, build-työkalua ja taustadaemonia. Merkitsevä on prosessi, joka teki epäonnistuneen pyynnön, joten tarkastele sen ympäristöä äläkä päätteesi ympäristöä.

Tee lopuksi korjauksesta itsensä selittävä. Hyödyllinen ratkaisu nimeää rajan, joka oli väärä, asetuksen, joka muutti sen, ja joukon prosesseja, joihin se nyt vaikuttaa. VPN:n, editorin ja moottorin uudelleenkäynnistys peräkkäin voi muuttaa oiretta, mutta se ei jätä mitään, mitä seuraava ihminen voisi käyttää.