Кантэйнер распрацоўкі не дасягае хаста, даступнага толькі праз VPN: дзе шукаць

Прыватны API адкрываецца ў вашым настольным браўзеры і не працуе ў кантэйнеры распрацоўкі. Гэта не супярэчнасць, і рэдка прычына ў самім VPN. Запыт браўзера і запыт, які памыляецца, зрабілі розныя працэсы, з рознымі рэзалверамі, проксі і маршрутамі, а часта і з цалкам розных сеткавых прастораў імёнаў. «На маім ноўтбуку» можа азначаць хост Windows, дыстрыбутыў WSL, віртуальную машыну Docker Desktop і кантэйнер унутры гэтай ВМ — чатыры кантэксты, кожны з якіх можа адказаць на адно і тое ж імя хаста па-рознаму. Высветліце, які з іх выкарыстоўвае працэс, што памыляецца, перш чым кранаць хоць адну наладу.

Знайдзіце працэс, перш чым змяняць наладу

Пачніце з рухавіка кантэйнераў, а не з кліента VPN. Спытайце, з якім кантэкстам размаўляе камандны радок і на якой аперацыйнай сістэме працуе гэты рухавік, бо кантэйнер Linux, якім кіруе настольная ВМ, ідзе іншым шляхам, чым той, якім кіруе лакальны дэман:

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

У Windows wsl -l -v паведамляе, ці працуе дыстрыбутыў пад WSL 2, што ставіць яго за ўласны віртуальны камутатар. Гэтая дэталь вызначае, ці кантэйнер дзеліць табліцу маршрутызацыі хаста, ці сядзіць за NAT, якому патрэбны пракінуты порт або імя хаста, каб дасягнуць хаста.

Трымайце адзін запыт нязменным і параўноўвайце

Выберыце адну бясшкодную канчатковую кропку на прыватным хосце і выкарыстоўвайце яе для кожнага параўнання: з браўзера, з тэрмінала хаста, з дыстрыбутыва WSL і знутры кантэйнера. Запісвайце чатыры рэчы для кожнай спробы: атрыманы адрас, ці выкарыстоўваўся проксі, клас збою і прайшоўшы час. Пошук імені, устанаўленне злучэння, праверка TLS і HTTP-статус — гэта чатыры розныя праблемы, і змешванне іх у «яно не працуе» марнуе раніцу.

Праводзьце параўнанне ўнутры кантэйнера, які памыляецца, з тайм-аўтам, каб маўклівы файрвол не трымаў тэрмінал хвілінамі. Свежы кантэйнер узнаўляе сеткавы кантэкст рухавіка, але не прастору імёнаў кантэйнера додатка, яго зменныя проксі ці рэзалвер, таму docker exec у сапраўдны кантэйнер — гэта аўтарытэтны тэст, а бакавы кантэйнер — толькі спосаб аддзяліць, ці розніца ў рухавіку, ці ў кантэйнеры:

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 мае busybox і не мае curl, і гэта менавіта тая дэталь, з-за якой скапіяваны дыягнастычны блок не працуе: выберыце вобраз з кліентам або дадайце яго ў тым жа запуску. Параўнанне з непаўязанымі публічнымі сайтамі нічога не аддзяляе. Калі https://example.com працуе з кантэйнера, вы даведаліся, што кантэйнер мае доступ у інтэрнэт, і нічога пра тое, ці дасягае ён прыватнага адраса праз тунель. Гэтак жа адкрыццё новага тэрмінала даказвае толькі, што новы тэрмінал працуе, а не што ён дзеліць асяроддзе выканання з додаткам, які памыліўся.

Docker Desktop можа працаваць з VPN

Уласная дакументацыя Docker пра VPN і падключэнне да хаста апісвае гэта як падтрымліваемую канфігурацыю, і сумленнае рэзюмэ такое: яно працуе, а не ламаецца аўтаматычна. Не мяркуйце, што настольная ВМ абыходзіць тунель хаста па задуме; у многіх канфігурацыях трафік правільна ідзе праз тунель хаста, і менавіта таму фальклор «Docker ігнаруе VPN» спараджае ўпэўненыя і няправільныя парады.

Што па-ранейшаму важна — гэта задняя частка, што выкарыстоўваецца, палітыка раздзеленага тунелю кліента і канфігурацыя рэзалвера, якую атрымала ВМ. Кліент VPN, які ўсталёўвае маршруты, але не DNS, або прасоўвае DNS-сервер, недасяжны для ВМ, стварае збой пошуку імені ўнутры кантэйнера, тады як хост працуе, бо ў хаста ёсць дадатковы рэзалвер ці закешаваны адказ. Гэта праблема рэзалвера ў касцюме кантэйнера. Яна перажывае кожнае перападключэнне VPN, якое вы спрабуеце, бо тунель ужо нясе трафік, які вы папрасілі яго несці.

Сутыкненне адрасоў і MTU — розныя збоі

Два збоі заслугоўваюць асобнай дыягностыкі, бо іх часта блытаюць з палітыкай доступу. Першы — сутыкненне адрасоў: калі VPN прасоўвае дыяпазон, што сутыкаецца з падсеткай маста па змаўчанні сеткі кантэйнера, маршрут кантэйнера для гэтага дыяпазону паказвае на лакальны мост і ніколі не дасягае тунеля. Агледзьце фактычныя падсеткі, а не здагадвайцеся:

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

Другі — праблема MTU. Калі злучэнне ўстанаўліваецца і TLS завяршаецца, але буйнейшыя адказы затыкаюцца, у вас праблема памеру пакета, а не аўтарызацыі, і замена DNS-запісаў ніколі гэтага не выправіць. Праверце маленькім запытам і вялікім, перш чым нешта змяняць, і запішыце абодва вынікі.

Вырашэнне сутыкнення — іншая падсетка кантэйнера або абмежаваны маршрут, абраны тым, хто валодае планам адрасоў. Вырашэнне затыку MTU — сціск або памяншэнне MTU тунеля ці інтэрфейса да значэння, якое трымаецца на шляху, ужытае на тым узроўні, які вы кантралюеце.

Канфігурацыя проксі — для кожнага працэса, а не для машыны

Унутры кантэйнера localhost называе ўласны сеткавы кантэкст гэтага кантэйнера, таму проксі, які працуе на хосце, там пад гэтым імем недасяжны. Docker Desktop прадастаўляе host.docker.internal для доступу да хаста, а ў Linux вы дадаяце яго яўна праз --add-host=host.docker.internal:host-gateway. У любым выпадку гэтае імя дае вам маршрут да хаста; яно не стварае службу проксі і не дае права ёю карыстацца.

Выкарыстоўвайце адрас і порт проксі, прадастаўленыя для фактычнага асяроддзя. Зменныя, экспартаваныя ў інтэрактыўнай абалонцы, не наладжваюць аўтаматычна кожнае пашырэнне рэдактара, моўны сервер, інструмент зборкі і фонавы дэман; важны менавіта той працэс, які зрабіў запыт, што памыляецца, таму агледзьце яго асяроддзе, а не асяроддзе вашага тэрмінала.

Нарэшце, няхай выпраўленне само сябе тлумачыць. Карыснае рашэнне называе мяжу, якая была няправільнай, наладу, якая яе змяніла, і набор працэсаў, на якія яно цяпер уплывае. Перазапуск VPN, рэдактара і рухавіка па чарзе можа змяніць сімптом, але не пакідае нічога, чым мог бы скарыстацца наступны чалавек.