Dev konteyner faqat VPN orqali ochiladigan xostga yeta olmayapti: qayerga qarash kerak

Xususiy API ish stolidagi brauzeringizda ochiladi va dev konteynerda ishlamaydi. Bu qarama-qarshilik emas va kamdan-kam hollarda VPNning o’zi aybdor. Brauzer so’rovi va muvaffaqiyatsiz so’rov turli jarayonlar tomonidan, turli resolver, proksi va marshrutlar bilan, ko’pincha butunlay boshqa tarmoq nomlar fazosidan yuborilgan. "Mening noutbukimda" iborasi Windows xosti, WSL distributivi, Docker Desktop virtual mashinasi va o’sha VM ichidagi konteynerni anglatishi mumkin, ya’ni bir xil xost nomiga har xil javob beradigan to’rtta kontekst. Bitta sozlamaga tegishdan oldin muvaffaqiyatsiz jarayon qaysi biridan foydalanayotganini aniqlang.

Sozlamani o’zgartirishdan oldin jarayonni toping

VPN mijozi emas, konteyner dvigatelidan boshlang. Buyruq qatori qaysi kontekst bilan gaplashayotganini va bu dvigatel qaysi operatsion tizimda ishlayotganini so’rang, chunki ish stoli VM boshqaradigan Linux konteyner mahalliy demon boshqaradiganidan boshqa yo’l:

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

Windowsda wsl -l -v distributiv WSL 2 ostida ishlayotganini aytadi, bu uni o’zining virtual kommutatori orqasiga qo’yadi. Bu tafsilot konteyner xostning marshrutlash jadvalini bo’lishadimi yoki xostga yetish uchun yo’naltirilgan port yoxud xost nomi kerak bo’ladigan NAT orqasida turibdimi, shuni hal qiladi.

Bitta so’rovni doimiy saqlang va taqqoslang

Xususiy xostda bitta zararsiz oxirgi nuqtani tanlang va har bir taqqoslash uchun undan foydalaning: brauzerdan, xost terminalidan, WSL distributividan va konteyner ichidan. Har bir urinish uchun to’rtta narsani yozib oling: hal qilingan manzil, proksi ishlatilganmi, nosozlik sinfi va o’tgan vaqt. Nom qidiruvi, ulanish o’rnatilishi, TLS tekshiruvi va HTTP holati to’rt xil muammo, ularni "ishlamayapti" deb birlashtirish butun bir ertalabni behuda o’tkazadi.

Taqqoslashni ishlamayotgan konteyner ichida, vaqt chegarasi bilan bajaring, shunda jim tarmoq devori terminalni daqiqalab ushlab turmaydi. Yangi konteyner dvigatelning tarmoq kontekstini qayta hosil qiladi, lekin ilova konteynerining nomlar fazosi, proksi o’zgaruvchilari yoki resolverini emas, shuning uchun haqiqiy konteynerga docker exec qilish vakolatli sinov, yon konteyner esa faqat farq dvigatelda yoki konteynerda ekanini ajratish usuli:

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 asosiy obrazi busyboxni olib yuradi va curl yo’q, va aynan shunday tafsilot ko’chirilgan diagnostika blokini ishlamay qoldiradi: mijozi bor obrazni tanlang yoki uni o’sha ishga tushirish ichida qo’shing. Aloqasiz ommaviy saytlar bilan taqqoslash hech narsani ajratmaydi. Agar https://example.com konteynerdan ishlasa, konteynerda internetga chiqish borligini bildingiz, tunnel orqali xususiy manzilga yeta olishi haqida esa hech narsa. Xuddi shunday, yangi terminal ochish faqat yangi terminal ishlashini isbotlaydi, u ishlamay qolgan ilova bilan bir ish muhitini bo’lishishini emas.

Docker Desktop VPN bilan ishlashi mumkin

Dockerning VPN va xost ulanishi haqidagi o’z hujjati buni qo’llab-quvvatlanadigan sozlama deb ta’riflaydi va halol xulosa shuki, u avtomatik buzilgan emas, ishlaydi. Ish stoli VM dizayn bo’yicha xost tunnelini chetlab o’tadi deb o’ylamang; ko’p sozlamalarda trafik xost tunnelini to’g’ri kuzatadi, shuning uchun "Docker VPNni e’tiborsiz qoldiradi" degan rivoyat ishonchli va noto’g’ri maslahat beradi.

Hali muhim bo’lgan narsa ishlatilayotgan backend, mijozning bo’lingan tunnel siyosati va VM olgan resolver konfiguratsiyasi. Marshrutlarni o’rnatib DNS o’rnatmaydigan yoki VM yeta olmaydigan DNS serverini yuboradigan VPN mijozi, xost ishlab turganda konteyner ichida nom qidiruvi nosozligini keltirib chiqaradi, chunki xostda qo’shimcha resolver yoki keshlangan javob bor. Bu konteyner libosidagi resolver muammosi. U siz urinadigan har bir VPN qayta ulanishida saqlanib qoladi, chunki tunnel allaqachon siz so’ragan trafikni olib yurmoqda.

Manzillar ustma-ustligi va MTU turli nosozliklar

Ikki nosozlik o’z diagnostikasiga loyiq, chunki ular ko’pincha kirish siyosati bilan aralashtiriladi. Birinchisi manzillar ustma-ustligi: agar VPN konteyner tarmog’ining standart ko’prik subneti bilan to’qnashadigan diapazonni yuborsa, konteynerning bu diapazon uchun marshruti mahalliy ko’prikka ishora qiladi va tunnelga hech qachon yetmaydi. Taxmin qilish o’rniga haqiqiy subnetlarni ko’zdan kechiring:

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

Ikkinchisi MTU muammosi. Agar ulanish o’rnatilsa va TLS tugasa, lekin kattaroq javoblar to’xtab qolsa, bu avtorizatsiya emas, paket o’lchami muammosi va DNS yozuvlarini almashtirish uni hech qachon tuzatmaydi. Biror narsani o’zgartirishdan oldin kichik va katta so’rov bilan sinab ko’ring va ikkala natijani yozib oling.

Ustma-ustlikning yechimi boshqa konteyner subneti yoki cheklangan marshrut bo’lib, uni manzil rejasiga ega bo’lgan kishi tanlaydi. MTU to’xtashining yechimi tunnel yoki interfeys MTUsini yo’lni yengadigan qiymatgacha cheklash yoki kamaytirish bo’lib, siz nazorat qiladigan qatlamda qo’llanadi.

Proksi sozlamasi har bir jarayon uchun, mashina uchun emas

Konteyner ichida localhost o’sha konteynerning o’z tarmoq kontekstini nomlaydi, shuning uchun xostda ishlayotgan proksiga u yerda bu nom bilan yetib bo’lmaydi. Docker Desktop xostga kirish uchun host.docker.internal beradi, Linuxda esa uni --add-host=host.docker.internal:host-gateway bilan aniq qo’shasiz. Qanday bo’lmasin, bu nom sizga xostga yo’l beradi; u proksi xizmatini yaratmaydi va undan foydalanishga ruxsat bermaydi.

Haqiqiy muhit uchun berilgan proksi manzili va portidan foydalaning va uni kim o’qiyotganini tekshiring. Interaktiv shellda eksport qilingan o’zgaruvchilar har bir muharrir kengaytmasi, til serveri, qurish vositasi va fon demonini avtomatik sozlamaydi. Muhimi muvaffaqiyatsiz so’rovni yuborgan jarayon, shuning uchun terminalingizning muhitini emas, uning muhitini tekshiring.

Nihoyat, yechim o’zini o’zi tushuntirsin. Foydali yechim noto’g’ri bo’lgan chegarani, uni o’zgartirgan sozlamani va endi ta’sir qiladigan jarayonlar to’plamini nomlaydi. VPN, muharrir va dvigatelni ketma-ket qayta ishga tushirish simptomni o’zgartirishi mumkin, lekin keyingi odam foydalana oladigan hech narsa qoldirmaydi.