Dev Container nesasniedz tikai VPN pieejamu resursdatoru: kur skatīties

Privātais API atveras darbvirsmas pārlūkā un neizdodas izstrādes konteinerā. Tā nav pretruna, un reti vainīgs ir pats VPN. Pārlūka pieprasījumu un neizdevušos pieprasījumu izveidoja dažādi procesi ar atšķirīgiem resolveriem, proxy un maršrutiem, un bieži vien no pilnīgi atšķirīgām tīkla nosaukumtelpām. “Manā portatīvajā” var nozīmēt Windows resursdatoru, WSL distribūciju, Docker Desktop virtuālo mašīnu un konteineru šajā VM — četri konteksti, no kuriem katrs var atbildēt uz vienu un to pašu resursdatora nosaukumu citādi. Pirms aiztikt kaut vienu iestatījumu, noskaidrojiet, kuru izmanto nespējīgais process.

Atrodiet procesu pirms iestatījuma maiņas

Sāciet ar konteineru dzinēju, nevis VPN klientu. Pajautājiet, ar kuru kontekstu runā komandrinda un kurā operētājsistēmā šis dzinējs darbojas, jo Linux konteiners, ko pārvalda darbvirsmas VM, iet citu ceļu nekā tas, ko pārvalda vietējais dēmons:

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

Windows vidē wsl -l -v pasaka, vai distribūcija darbojas zem WSL 2, kas to novieto aiz sava virtuālā slēdža. Šī detaļa nosaka, vai konteiners dala resursdatora maršrutēšanas tabulu vai atrodas aiz NAT, kuram, lai sasniegtu resursdatoru, nepieciešams pārsūtīts ports vai resursdatora nosaukums.

Turiet vienu pieprasījumu nemainīgu un salīdziniet

Izvēlieties vienu nekaitīgu galapunktu privātajā resursdatorā un izmantojiet to katram salīdzinājumam: no pārlūka, no resursdatora termināļa, no WSL distribūcijas un no konteinera iekšpuses. Katram mēģinājumam pierakstiet četras lietas: atrisināto adresi, vai tika izmantots proxy, kļūdas klasi un pagājušo laiku. Nosaukuma meklēšana, savienojuma izveide, TLS validācija un HTTP statuss ir četras dažādas problēmas, un to sapludināšana vienā “nestrādā” izšķērdē visu rītu.

Veiciet salīdzinājumu neizdevušā konteinera iekšienē, ar taimautu, lai kluss ugunsmūris neturētu termināli minūtēm. Jauns konteiners atveido dzinēja tīkla kontekstu, bet ne lietotnes konteinera nosaukumtelpu, proxy mainīgos vai resolveri, tāpēc docker exec īstajā konteinerā ir autoritatīvais tests, un blakus konteiners ir tikai veids, kā izolēt, vai atšķirība ir dzinējā vai konteinerā:

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 bāzes attēlā ir busybox un nav curl, un tieši šāda detaļa liek nokopētam diagnostikas blokam neizdoties: izvēlieties attēlu ar klientu vai pievienojiet to tajā pašā palaišanā. Salīdzinājums ar nesaistītām publiskām vietnēm neko neizolē. Ja https://example.com darbojas no konteinera, jūs uzzinājāt, ka konteineram ir interneta piekļuve, un neko par to, vai tas sasniedz privātu adresi caur tuneli. Tāpat jauna termināļa atvēršana pierāda tikai to, ka jaunais terminālis darbojas, nevis to, ka tam ir kopīga izpildes vide ar lietotni, kas neizdevās.

Docker Desktop var darboties ar VPN

Pašas Docker dokumentācija par VPN un resursdatora savienojamību to apraksta kā atbalstītu iestatījumu, un godīgais kopsavilkums ir tāds, ka tas darbojas, nevis ir automātiski salauzts. Nepieņemiet, ka darbvirsmas VM pēc konstrukcijas apiet resursdatora tuneli; daudzos iestatījumos trafiks pareizi seko resursdatora tunelim, un tāpēc teika “Docker ignorē VPN” rada pārliecinātus un nepareizus padomus.

Joprojām svarīgi ir izmantotais backend, klienta split-tunnel politika un VM saņemtā resolver konfigurācija. VPN klients, kas instalē maršrutus, bet ne DNS, vai kas uzspiež DNS serveri, kuru VM nevar sasniegt, rada nosaukuma meklēšanas kļūmi konteinerā, kamēr resursdators darbojas, jo tam ir papildu resolveris vai kešatmiņā saglabāta atbilde. Tā ir resolvera problēma konteinera kostīmā. Tā pārdzīvo katru VPN atkārtotu savienojumu, ko mēģināt, jo tunelis jau pārvadā trafiku, ko tam lūdzāt.

Adrešu pārklāšanās un MTU ir dažādas kļūmes

Divas kļūmes ir pelnījušas savu diagnostiku, jo tās bieži jauc ar piekļuves politiku. Pirmā ir adrešu pārklāšanās: ja VPN uzspiež diapazonu, kas saduras ar konteineru tīkla noklusējuma tilta apakštīklu, konteinera maršruts šim diapazonam norāda uz vietējo tiltu un nekad nesasniedz tuneli. Pārbaudiet faktiskos apakštīklus, nevis miniet:

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

Otrā ir MTU problēma. Ja savienojums tiek izveidots un TLS pabeidzas, bet lielākas atbildes iestrēgst, jums ir paketes izmēra problēma, nevis autorizācijas, un DNS ierakstu nomaiņa to nekad neizlabos. Pirms kaut ko mainīt, pārbaudiet ar mazu un lielu pieprasījumu un pierakstiet abus rezultātus.

Pārklāšanās risinājums ir cits konteineru apakštīkls vai ierobežots maršruts, ko izvēlas adrešu plāna īpašnieks. MTU iestrēguma risinājums ir savilkt vai samazināt tuneļa vai saskarnes MTU līdz vērtībai, kas iztur ceļu, piemērojot to slānī, kuru kontrolējat.

Proxy konfigurācija ir katram procesam, nevis mašīnai

Konteinera iekšienē localhost nosauc šī konteinera paša tīkla kontekstu, tāpēc resursdatorā darbojošs proxy tur nav sasniedzams ar šo nosaukumu. Docker Desktop nodrošina host.docker.internal piekļuvei resursdatoram, un Linux vidē jūs to skaidri pievienojat ar --add-host=host.docker.internal:host-gateway. Jebkurā gadījumā šis nosaukums dod jums maršrutu uz resursdatoru; tas neveido proxy pakalpojumu un nedod tiesības to izmantot.

Izmantojiet proxy adresi un portu, kas doti faktiskajai videi, un pārbaudiet, kas tos lasa. Mainīgie, kas eksportēti interaktīvā čaulā, automātiski nekonfigurē katru redaktora paplašinājumu, valodas serveri, būvēšanas rīku un fona dēmonu. Svarīgākais ir process, kas izveidoja neizdevušos pieprasījumu, tāpēc pārbaudiet tā vidi, nevis sava termināļa vidi.

Visbeidzot, ļaujiet labojumam sevi izskaidrot. Noderīgs risinājums nosauc nepareizo robežu, iestatījumu, kas to mainīja, un procesu kopu, uz kuru tas tagad iedarbojas. VPN, redaktora un dzinēja restartēšana pēc kārtas var mainīt simptomu, bet nepaliek nekas, ko nākamais cilvēks varētu izmantot.