Dev Container ne atingas hoston nur-VPNan: kie rigardi

La privata API malfermiĝas en via labortabla retumilo kaj malsukcesas en la evoluiga ujo. Tio ne estas kontraŭdiro, kaj malofte la VPN mem estas la kaŭzo. La peto de la retumilo kaj la malsukcesa peto estis faritaj de malsamaj procezoj, kun malsamaj solviloj, prokuraĵoj kaj vojoj, kaj ofte el tute malsamaj retaj nomspacoj. „Sur mia tekkomputilo“ povas signifi la Windows-gastiganton, WSL-distribuaĵon, la virtualan maŝinon Docker Desktop kaj ujon ene de tiu VM — kvar kuntekstoj, kiuj ĉiu povas respondi al la sama gastigantnomo malsame. Trovu, kiun uzas la malsukcesa procezo, antaŭ ol tuŝi eĉ unu agordon.

Trovu la procezon antaŭ ol ŝanĝi agordon

Komencu per la uja motoro, ne per la VPN-kliento. Demandu, al kiu kunteksto parolas la komandlinio kaj sur kiu operaciumo tiu motoro funkcias, ĉar Linux-ujo administrata de labortabla VM sekvas alian vojon ol tiu administrata de loka demono:

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

En Windows, wsl -l -v diras al vi, ĉu la distribuaĵo funkcias sub WSL 2, kio metas ĝin malantaŭ sia propra virtuala ŝaltilo. Tiu detalo decidas, ĉu la ujo dividas la enkursigan tabelon de la gastiganto aŭ sidas malantaŭ NAT, kiu bezonas plusenditan pordon aŭ gastigantnomon por atingi la gastiganton.

Tenu unu peton konstanta kaj komparu

Elektu unu senriskan finpunkton sur la privata gastiganto kaj uzu ĝin por ĉiu komparo: el la retumilo, el gastiganta terminalo, el la WSL-distribuaĵo kaj el interne de la ujo. Notu kvar aferojn por ĉiu provo: la solvitan adreson, ĉu prokuraĵo estis uzita, la fiaskklason kaj la pasintan tempon. Nomsolvo, konekta starigo, TLS-validaĵo kaj HTTP-stato estas kvar malsamaj problemoj, kaj miksi ilin en „ĝi ne funkcias“ malŝparas matenon.

Rulu la komparon ene de la malsukcesa ujo, kun tempolimo, por ke silenta fajroŝirmilo ne tenu la terminalon dum minutoj. Freŝa ujo reproduktas la retan kuntekston de la motoro, sed ne la nomspacon, la prokuraĵajn variablojn aŭ la solvilon de la aplikaĵa ujo, do docker exec en la realan ujon estas la aŭtoritata testo, kaj flanka ujo estas nur maniero izoli, ĉu la diferenco estas en la motoro aŭ en la ujo:

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

La baza bildo alpine portas busybox kaj neniun curl, kaj ĝuste tia detalo igas kopiitan diagnozan blokon malsukcesi: elektu bildon kun la kliento, aŭ aldonu ĝin en la sama rulo. Komparo kun nerilataj publikaj retejoj izolas nenion. Se https://example.com funkcias el la ujo, vi lernis, ke la ujo havas interretan aliron, kaj nenion pri tio, ĉu ĝi atingas privatan adreson tra la tunelo. Same, malfermi novan terminalon pruvas nur, ke la nova terminalo funkcias, ne ke ĝi dividas rulmedianon kun la aplikaĵo, kiu malsukcesis.

Docker Desktop povas funkcii kun VPN

La propra dokumentaro de Docker pri VPN kaj gastiganta konektebleco priskribas tion kiel subtenatan agordon, kaj la honesta resumo estas, ke ĝi funkcias anstataŭ esti aŭtomate rompita. Ne supozu, ke la labortabla VM preterpasas la tunelon de la gastiganto pro dizajno; en multaj agordoj la trafiko sekvas la tunelon de la gastiganto ĝuste, kaj tial la folkloro „Docker ignoras la VPN“ produktas memfidajn kaj malĝustajn konsilojn.

Kio ankoraŭ gravas, estas la uzata malantaŭaĵo, la disigita-tunela politiko de la kliento kaj la solvila agordo, kiun la VM ricevis. VPN-kliento, kiu instalas vojojn sed ne DNS, aŭ kiu puŝas DNS-servilon, kiun la VM ne povas atingi, produktas nomsolvan fiaskon ene de la ujo, dum la gastiganto funkcias ĉar ĝi havas plian solvilon aŭ kaŝmemorigitan respondon. Tio estas solvila problemo portanta ujan kostumon. Ĝi postvivas ĉiun VPN-rekonekton, kiun vi provas, ĉar la tunelo jam portas la trafikon, kiun vi petis ĝin porti.

Adresaj koincidoj kaj MTU estas malsamaj fiaskoj

Du fiaskoj meritas propran diagnozon, ĉar oni ofte konfuzas ilin kun alirpolitiko. La unua estas adresa koincido: se la VPN puŝas gamon, kiu kolizias kun la defaŭlta ponto-subreto de uja reto, la vojo de la ujo por tiu gamo montras al la loka ponto kaj neniam atingas la tunelon. Inspektu la efektivajn subretojn anstataŭ diveni:

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

La dua estas MTU-problemo. Se la konekto stariĝas kaj TLS finiĝas, sed pli grandaj respondoj haltas, vi havas problemon de paketa grando, ne de rajtigo, kaj anstataŭigi DNS-rikordojn neniam riparos ĝin. Testu per malgranda peto kaj granda antaŭ ol ŝanĝi ion ajn, kaj notu ambaŭ rezultojn.

La solvo por koincido estas alia uja subreto aŭ limigita vojo, elektita de tiu, kiu posedas la adresplanon. La solvo por MTU-halto estas mallarĝigi aŭ malpliigi la MTU de la tunelo aŭ interfaco al valoro, kiu postvivas la vojon, aplikita ĉe la tavolo, kiun vi kontrolas.

Prokuraĵa agordo estas por procezo, ne por maŝino

Ene de ujo, localhost nomas la propran retan kuntekston de tiu ujo, do prokuraĵo funkcianta sur la gastiganto ne estas atingebla tie sub tiu nomo. Docker Desktop provizas host.docker.internal por gastiganta aliro, kaj en Linux vi aldonas ĝin eksplicite per --add-host=host.docker.internal:host-gateway. Ĉiel ajn, tiu nomo donas al vi vojon al la gastiganto; ĝi ne kreas prokuran servon kaj ne rajtigas vin uzi unu.

Uzu la prokuran adreson kaj pordon provizitajn por la efektiva medio, kaj kontrolu, kiu legas ilin. Variabloj eksportitaj en interaga ŝelo ne aŭtomate agordas ĉiun redaktilan kromprogramon, lingvan servilon, konstruilon kaj fona demonon. Gravas la procezo, kiu faris la malsukcesan peton, do inspektu ĝian medion anstataŭ tiun de via terminalo.

Fine, lasu la riparon klarigi sin mem. Utila solvo nomas la limon, kiu estis malĝusta, la agordon, kiu ŝanĝis ĝin, kaj la aron da procezoj, kiujn ĝi nun tuŝas. Restartigi la VPN, la redaktilon kaj la motoron sinsekve povas ŝanĝi la simptomon, sed ĝi lasas nenion, kion la sekva persono povus uzi.