Dev-konteiner ei jõua VPN-i kaudu kättesaadava hostini: kust otsida

Privaatne API avaneb teie töölaua brauseris ja ebaõnnestub arenduskonteineris. See ei ole vastuolu ja harva on süüdi VPN ise. Brauseri päringu ja ebaõnnestuva päringu tegid erinevad protsessid, erinevate resolverite, puhverserverite ja marsruutidega, ja sageli täiesti erinevatest võrgu nimeruumidest. „Minu sülearvutis“ võib tähendada Windowsi hosti, WSL-i distributsiooni, Docker Desktopi virtuaalmasinat ja konteinerit selle VM-i sees — neli konteksti, millest igaüks võib samale hostinimele erinevalt vastata. Tehke kindlaks, millist neist ebaõnnestuv protsess kasutab, enne kui puudutate ühtki seadet.

Leidke protsess enne seade muutmist

Alustage konteinerimootorist, mitte VPN-kliendist. Küsige, millise kontekstiga käsurida räägib ja millisel operatsioonisüsteemil see mootor töötab, sest töölaua VM-i hallatav Linuxi konteiner läbib teistsuguse tee kui kohaliku deemoniga hallatav:

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

Windowsis ütleb wsl -l -v, kas distributsioon töötab WSL 2 all, mis paneb selle oma virtuaalse lüliti taha. See üksikasj otsustab, kas konteiner jagab hosti marsruutimistabelit või istub NAT-i taga, mis vajab hostini jõudmiseks edastatud porti või hostinime.

Hoidke üks päring muutumatuna ja võrrelge

Valige privaatsel hostil üks kahjutu lõpp-punkt ja kasutage seda iga võrdluse jaoks: brauserist, hosti terminalist, WSL-i distributsioonist ja konteineri seest. Märkige iga katse kohta neli asja: lahendatud aadress, kas kasutati puhverserverit, tõrke klass ja kulunud aeg. Nimeotsing, ühenduse loomine, TLS-i valideerimine ja HTTP olek on neli erinevat probleemi ning nende segamine lausesse „ei tööta“ raiskab hommiku.

Käivitage võrdlus ebaõnnestuva konteineri sees, koos ajapiiranguga, et vaikne tulemüür ei hoiaks terminali minuteid kinni. Värske konteiner taastoodab mootori võrgukonteksti, kuid mitte rakenduskonteineri nimeruumi, puhverserveri muutujaid ega resolverit, seega docker exec päris konteinerisse on autoriteetne test ning kõrvalkonteiner on vaid viis eraldada, kas erinevus on mootoris või konteineris:

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-baaskujutis sisaldab busyboxi ja mitte curl-i, ja just selline üksikasj ajab kopeeritud diagnostikabloki nurja: valige kujutis, milles on klient, või lisage see samas käivituses. Võrdlus mitteseotud avalike saitidega ei eralda midagi. Kui https://example.com töötab konteinerist, olete õppinud, et konteineril on internetiühendus, ja mitte midagi selle kohta, kas see jõuab tunneliga privaatse aadressini. Samuti tõestab uue terminali avamine vaid seda, et uus terminal töötab, mitte et see jagab käituskeskkonda rakendusega, mis ebaõnnestus.

Docker Desktop võib VPN-iga töötada

Dockeri enda dokumentatsioon VPN-i ja hosti ühenduvuse kohta kirjeldab seda toetatud seadistusena ning aus kokkuvõte on, et see töötab, mitte ei ole automaatselt katki. Ärge eeldage, et töölaua VM mööda läheb hosti tunnelist disaini tõttu; paljudes seadistustes järgib liiklus hosti tunnelit õigesti ja seetõttu annab folkloor „Docker eirab VPN-i“ enesekindlat ja vale nõu.

Oluline on endiselt kasutatav backend, kliendi split-tunneli poliitika ja resolveri konfiguratsioon, mille VM sai. VPN-klient, mis paigaldab marsruudid, kuid mitte DNS-i, või lükkab peale DNS-serveri, mida VM ei saa kätte, tekitab nimeotsingu tõrke konteineri sees, samal ajal kui host töötab, sest hostil on täiendav resolver või vahemällu salvestatud vastus. See on resolveri probleem konteineri kostüümis. See elab üle iga VPN-i uuestiühenduse, mida proovite, sest tunnel kannab juba liiklust, mida palusite tal kanda.

Aadresside kattumine ja MTU on erinevad tõrked

Kaks tõrget väärib oma diagnostikat, sest neid aetakse sageli segamini juurdepääsupoliitikaga. Esimene on aadresside kattumine: kui VPN lükkab peale vahemiku, mis põrkub konteinervõrgu vaikimisi silla alamvõrguga, osutab konteineri marsruut selle vahemiku jaoks kohalikule sillale ega jõua kunagi tunnelisse. Kontrollige tegelikke alamvõrke, selle asemel et oletada:

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

Teine on MTU probleem. Kui ühendus luuakse ja TLS lõpeb, kuid suuremad vastused takerduvad, on teil paketi suuruse probleem, mitte autoriseerimise probleem, ja DNS-kirjete asendamine ei paranda seda kunagi. Testige väikese ja suure päringuga enne, kui midagi muudate, ja registreerige mõlemad tulemused.

Kattumise lahendus on teine konteineri alamvõrk või piiratud marsruut, mille valib aadressiplaani omanik. MTU takerdumise lahendus on tunneli või liidese MTU kärpimine või vähendamine väärtuseni, mis teel vastu peab, rakendatuna kihil, mida te kontrollite.

Puhverserveri konfiguratsioon on protsessi, mitte masina kohta

Konteineri sees nimetab localhost selle konteineri enda võrgukonteksti, seega hostil töötav puhverserver ei ole seal selle nime all kättesaadav. Docker Desktop pakub hostile juurdepääsuks host.docker.internal ja Linuxis lisate selle selgesõnaliselt --add-host=host.docker.internal:host-gateway abil. Igal juhul annab see nimi teile marsruudi hostini; see ei loo puhverserveri teenust ega anna teile õigust seda kasutada.

Kasutage puhverserveri aadressi ja porti, mis on antud tegeliku keskkonna jaoks, ja kontrollige, kes neid loeb. Interaktiivses kestas eksporditud muutujad ei konfigureeri automaatselt iga redaktori laiendust, keeleserverit, ehitustööriista ja taustadeemonit. Oluline on protsess, mis tegi ebaõnnestuva päringu, seega kontrollige selle keskkonda, mitte oma terminali oma.

Lõpuks laske parandusel end selgitada. Kasulik lahendus nimetab piiri, mis oli vale, seade, mis seda muutis, ja protsesside hulga, mida see nüüd mõjutab. VPN-i, redaktori ja mootori järjestikune taaskäivitamine võib sümptomit muuta, kuid ei jäta midagi, mida järgmine inimene saaks kasutada.