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 न करणारा VPN क्लायंट, किंवा VM पोहोचू शकत नाही असा DNS सर्व्हर ढकलणारा क्लायंट, कंटेनरच्या आत नाव शोध अपयश निर्माण करतो, तर होस्ट चालते कारण त्याला अतिरिक्त 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 पत्ता आणि पोर्ट वापरा, आणि तो कोण वाचत आहे ते तपासा. परस्परसंवादी शेलमध्ये निर्यात केलेले चल प्रत्येक एडिटर विस्तार, भाषा सर्व्हर, बिल्ड साधन आणि पार्श्वभूमी डेमॉन स्वयंचलितपणे संरचित करत नाहीत. महत्त्वाची गोष्ट म्हणजे अपयशी विनंती करणारी प्रक्रिया, त्यामुळे तुमच्या टर्मिनलचे नाही, तिच्या वातावरणाची तपासणी करा.

शेवटी, दुरुस्तीने स्वतःचे स्पष्टीकरण द्यावे. उपयुक्त उपाय चुकीची सीमा, ती बदलणारी सेटिंग आणि आता तिचा परिणाम होणाऱ्या प्रक्रियांचा संच नावाने सांगतो. VPN, एडिटर आणि इंजिन क्रमाने पुन्हा सुरू केल्यास लक्षण बदलू शकते, पण पुढच्या व्यक्तीला उपयोगी पडेल असे काहीही सोडत नाही.