Dev Container ले VPN-only होस्टसम्म पुग्न सक्दैन: कहाँ हेर्ने

निजी 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, एडिटर र इन्जिन क्रमशः पुनः सुरु गर्दा लक्षण बदलिन सक्छ, तर अर्को व्यक्तिले प्रयोग गर्न सक्ने केही छोड्दैन।