Dev Container VPN аркылуу гана жеткиликтүү хостко жетпейт: кайдан кароо керек

Жеке API жумуш үстөлүңүздүн браузеринде ачылат, ал эми иштеп чыгуу контейнеринде ийгиликсиз болот. Бул карама-каршылык эмес жана сейрек учурда себеп VPN өзү болот. Браузердин сурамы менен ийгиликсиз сурамды ар башка процесстер жасаган, алардын resolver, proxy жана маршруттары ар башка, көбүнчө толугу менен башка тармактык ат мейкиндиктеринен. «Менин ноутбугумда» деген Windows хосту, WSL бөлүштүрүүсү, Docker Desktop виртуалдык машинасы жана ошол VM ичиндеги контейнер болушу мүмкүн — бир эле хост атына ар кайсынысы башкача жооп бере алган төрт контекст. Бир да параметрди кармабастан мурун ийгиликсиз процесстин кайсынысын колдонуп жатканын аныктаңыз.

Параметрди өзгөртүүдөн мурун процессти табыңыз

VPN кардарынан эмес, контейнер кыймылдаткычынан баштаңыз. Буйрук сабы кайсы контекст менен сүйлөшүп жатканын жана ошол кыймылдаткыч кайсы операциялык системада иштеп жатканын сураңыз, анткени жумуш үстөлүнүн VM башкарган Linux контейнери жергиликтүү демон башкаргандан башка жол менен жүрөт:

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

Windows'то wsl -l -v бөлүштүрүүнүн WSL 2 астында иштеп жатканын айтат, бул аны өзүнүн виртуалдык коммутаторунун артына коёт. Бул деталь контейнердин хосттун маршруттоо таблицасын бөлүшөөрүн же хостко жетүү үчүн багытталган порт же хост аты талап кылынган NAT артында отурганын чечет.

Бир сурамды туруктуу кармап, салыштырыңыз

Жеке хосттогу бир зыянсыз акыркы чекитти тандап, аны ар бир салыштыруу үчүн колдонуңуз: браузерден, хосттун терминалынан, WSL бөлүштүрүүсүнөн жана контейнердин ичинен. Ар бир аракет үчүн төрт нерсени жазып алыңыз: чечилген дарек, proxy колдонулганы, ката классы жана өткөн убакыт. Ат издөө, байланыш түзүү, TLS текшерүү жана HTTP абалы — төрт башка маселе, аларды «иштебейт» деп аралаштыруу жарым күндү текке кетирет.

Салыштырууну ийгиликсиз болуп жаткан контейнердин ичинде, таймаут менен жүргүзүңүз, үнсүз брандмауэр терминалды мүнөттөп кармабашы үчүн. Жаңы контейнер кыймылдаткычтын тармактык контекстин кайра жаратат, бирок колдонмо контейнеринин ат мейкиндигин, proxy өзгөрмөлөрүн же resolver'ин эмес, ошондуктан чыныгы контейнерге 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 жана хостко туташуу тууралуу документтери муну колдоого алынган конфигурация катары сүрөттөйт, ал эми акыйкат жыйынтык — ал автоматтык түрдө бузулбайт, иштейт. Жумуш үстөлүнүн VM дизайны боюнча хосттун туннелин айланып өтөт деп ойлобоңуз; көп конфигурацияларда трафик хосттун туннелинен туура өтөт, ошондуктан «Docker VPNди этибарга албайт» деген уламыш ишенимдүү жана туура эмес кеңеш берет.

Дагы маанилүүсү — колдонулган backend, кардардын split-tunnel саясаты жана VM алган resolver конфигурациясы. Маршруттарды орноткон, бирок DNS орнотпогон же VM жете албаган DNS серверин түрткөн VPN кардары контейнердин ичинде ат издөө катасын пайда кылат, ал эми хост иштейт, анткени анын кошумча resolver'и же кэштеги жообу бар. Бул контейнер кийимин кийген resolver маселеси. Ал сиз аракет кылган ар бир 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'сун жолго чыдаган мааниге кысуу же азайтуу, аны өзүңүз көзөмөлдөгөн катмарда колдонуу.

Proxy конфигурациясы машина боюнча эмес, процесс боюнча

Контейнердин ичинде localhost ошол контейнердин өзүнүн тармактык контекстин атайт, ошондуктан хостто иштеген proxy ал жерде бул ат менен жеткиликсиз. Docker Desktop хостко кирүү үчүн host.docker.internal сунуштайт, ал эми Linux'та сиз аны --add-host=host.docker.internal:host-gateway аркылуу ачык кошосуз. Кандай болбосун, бул ат сизге хостко маршрут берет; ал proxy кызматын түзбөйт жана аны колдонууга укук да бербейт.

Чыныгы чөйрө үчүн берилген proxy дарегин жана портун колдонуңуз жана аларды ким окуп жатканын текшериңиз. Интерактивдүү shell'де экспорттолгон өзгөрмөлөр ар бир редактор кеңейтүүсүн, тил серверин, build куралын жана фондук демонду автоматтык түрдө конфигурациялабайт. Маанилүүсү — ийгиликсиз сурамды жасаган процесс, ошондуктан анын чөйрөсүн текшериңиз, өз терминалыңыздыкын эмес.

Акырында, оңдоо өзүн өзү түшүндүрсүн. Пайдалуу чечим ката болгон чекти, аны өзгөрткөн параметрди жана азыр ага таасир эткен процесстердин жыйындысын атайт. VPN'ди, редакторду жана кыймылдаткычты кезеги менен кайра иштетүү симптомду өзгөртүшү мүмкүн, бирок кийинки адамга керекте турган эч нерсе калтырбайт.