VPN मा Docker कन्टेनर पुग्दैन? सबनेटहरू तुलना गर्नुहोस्
Docker ले एउटा सबनेट दिन्छ जसमा VPN ले पनि दाबी गर्छ। दुवै ठेगाना योजना तुलना गर्नुहोस्, त्यसपछि पुनः जडान पछि पनि टिक्ने मर्मत छान्नुहोस्।
कन्टेनरहरू अफिसको LAN मा जवाफ दिन्छन्, तर कम्पनीको VPN जोडिने क्षणमै जवाफ दिन छोड्छन्। कन्टेनरमा केही पनि बदलिएको छैन: पुनः सुरु नहुने, इमेज अद्यावधिक नहुने, कन्फिगमा सम्पादन नहुने। बदलिएको कुरा होस्टको राउटिङ तालिका हो, जहाँ टनेलले थपेको रुटले अब Docker ले दिएको ठेगाना ढाक्छ। सबनेट सम्पादन गर्नु वा VPN अपवाद माग्नु अघि दुवै ठेगाना योजना सँगसँगै राख्नुहोस्, किनभने हरेक मर्मतले धेरै फरक समय लिन्छ।
कन्फिग बदल्नु अघि रुट पढ्नुहोस्
Docker ले वास्तवमा बनाएको नेटवर्कबाट सुरु गर्नुहोस्। IPAM ब्लक ठेगाना योजना हो, र सबनेट त्यो लाइन हो जुन महत्त्वपूर्ण छ:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose ले नयाँ प्रोजेक्टहरूका लागि पूर्वनिर्धारित रूपमा /16 छुट्याउँछ, त्यसैले दुई सेवा 65,536 ठेगानाको दायराभित्र बस्न सक्छन्। यही चौडाइका कारण ओभरल्याप सामान्य हुन्छ: अनियमित रूपमा छानिएको /16 टनेलबाट पुग्ने साइट निल्न पर्याप्त ठूलो हुन्छ, र टनेल नउठेसम्म कसैले थाहा पाउँदैन।
त्यसपछि एउटा कन्टेनर ठेगानाका लागि रुट छनोट तुलना गर्नुहोस् — एकचोटि टनेल बन्द हुँदा र एकचोटि खुला हुँदा:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1जवाफका दुई आकारले फरक ठाउँमा लैजान्छ। यदि आउटपुटले tun0, wg0 वा अर्को टनेल यन्त्र नाम दिन्छ भने, VPN प्रिफिक्स ब्रिज रुटजत्तिकै विशिष्ट हुन्छ, र प्याकेट कहिल्यै कन्टेनरसम्म पुग्दैन। यदि यसले अझै ब्रिजको नाम दिन्छ भने, होस्ट कन्टेनरसम्म पुग्न सक्छ, र तपाईंको दोष फिल्टरिङ, DNS वा एक दिशामा मात्र असफल हुने फर्कने मार्ग हो।
/16 ठक्कर सजिलै किन हुन्छ
Docker ले निजी पूलबाट ब्रिज नेटवर्क लिन्छ, र पूर्वनिर्धारित पूल 172.16.0.0/12 ब्लकबाट /16 टुक्रामा आउँछ। कर्पोरेट नेटवर्कहरू प्रायः त्यही निजी ठाउँ प्रयोग गर्छन्, र रिमोट-पहुँच VPN ले ती प्रिफिक्स जोडिने हरेक क्लाइन्टमा धकेल्छ। जब दुवै पक्ष आफ्नो 172.18.0.0/16 भएको विश्वास गर्छन्, एउटै राउटिङ तालिकामा दुई विरोधाभासी दाबी रहन्छन्।
प्रिफिक्स लम्बाइले विजेता तय गर्छ, रुटको क्रमले होइन। 10.0.0.0/8 धकेल्ने टनेलले 172.18.0.0/16 को ब्रिज रुटलाई हराउँदैन, किनभने /8 कम विशिष्ट छ। 172.18.0.0/16, वा त्यभित्रको 172.18.5.0/24 धकेल्ने टनेलले हराउँछ। त्यसैले एउटै ल्यापटप अफिस नेटवर्कमा चल्छ र त्यही VPN सँग होटेलको Wi-Fi मा असफल हुन्छ: क्लाइन्टले फरक प्रिफिक्स पाउँछ।
त्यही तालिकाले अर्को दिशा पनि नियन्त्रण गर्छ। 10.8.4.20 मा आन्तरिक होस्ट चाहिने कन्टेनरले प्याकेट आफ्नो ब्रिज गेटवेमा पठाउँछ, र त्यसपछि होस्टले यसलाई टनेलमा रुट गर्छ। होस्टले NAT गर्ने भएकाले त्यो मार्ग सामान्यतया चल्छ, तर कर्पोरेट पक्षले ल्यापटपको VPN ठेगाना मात्र स्वीकार गर्दा, वा रिभर्स-पाथ फिल्टरिङले असममित जवाफ फ्याँक्दा त्यो असफल हुन्छ।
तीन मर्मत तुलना गर्नुहोस्
बाहिर निस्कने तीन मात्र बाटा छन्, र तिनीहरू कसले स्वीकृत गर्नुपर्ने र एउटा लागू गर्दा के बिग्रने भन्नेमा फरक पर्छन्।
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
पुनःनम्बर गर्नु टिकटबिना सकिने एकमात्र मर्मत हो, त्यसैले धेरै लेख त्यहीँ रोकिन्छन्। नयाँ प्रोजेक्टमा यो सस्तो हुन्छ, तर माइग्रेसन उपकरण वा सुरक्षित जडान स्ट्रिङले शाब्दिक ठेगाना देखाउन थालेपछि महँगो हुन्छ। YAML सम्पादन गर्नु अघि ती सन्दर्भ गन्नुहोस्, पछि होइन।
जब ओभरल्याप तपाईंको कम्पनीको साँच्चै स्वामित्वको दायरामा पर्छ, टनेलबाट अपवाद सबैभन्दा सफा उत्तर हो। यो सबैभन्दा ढिलो पनि हो, र क्लाइन्ट प्रोफाइल बदल्न नसक्ने ठेकेदारका लागि यो बेकार छ। प्रकाशित पोर्ट वा सानो रिभर्स प्रोक्सीले यो बहस टार्छ: क्लाइन्टले टनेलले पहिले नै सही रुट गरेको ठेगानासँग कुरा गर्छ, र त्यो पोर्ट मात्र पुग्नयोग्य हुनुपर्छ।
जानाजान दायरा तोक्नुहोस्
एउटा प्रोजेक्टका लागि, compose फाइलमा सबनेट घोषणा गर्नुहोस् ताकि प्रोजेक्टले साझा पूलबाट लिन छोड्छ:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24त्यो दायरा खोज्दा भेटिएको उदाहरणबाट होइन, तपाईंको टोलीले राख्ने दर्ताबाट लिनुहोस्। VPN ले धकेल्ने प्रिफिक्स, मानिसहरू काम गर्ने घरका LAN र एउटै होस्टका अन्य कन्टेनर नेटवर्कसँग यसको जाँच गर्नुहोस्। त्यसपछि पुनःनिर्माण योजना बनाउनुहोस्, किनभने अवस्थित नेटवर्कले आफ्नो पुरानो सबनेट राख्छ: docker compose down, त्यसपछि up -d। इन्डपोइन्ट जोडिएको बेला docker network rm मान्दैन, र फाइलमा भएको कुनै पनि ipv4_address प्रविष्टि नयाँ दायराभित्र पर्नुपर्छ।
Docker ले आफै बनाउने नेटवर्कका लागि, /etc/docker/daemon.json मा डेमन पूल सेट गर्नुहोस्:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}यो पूल डेमन पुनः सुरु भएपछि बनाइने नेटवर्कमा लागू हुन्छ, र पहिले नै भएका ब्रिजहरूले आफ्ना ठेगाना राख्छन्। यो सुविधाजनक र बिर्सन सजिलो छ, त्यसैले कसैले यसको नेटवर्क पुनःनिर्माण नगरेसम्म पुरानो प्रोजेक्टलाई अझै ओभरल्याप भएको मान्नुहोस्। Docker को इन्जिन नेटवर्किङ दस्तावेज समीक्षामा पूलको बचाउ गर्नुपर्ने भएमा बाँडफाँटका नियम वर्णन गर्छ।
Linux ब्रिज र Docker Desktop फरक तरिकाले असफल हुन्छन्
Linux होस्टमा, कन्टेनरहरू होस्ट नेमस्पेसका ब्रिजमा बस्छन्। एउटै तालिकाले सबै तय गर्छ, त्यसैले माथिको तुलना नै पूरा कथा हो: ब्रिज रुट पढ्नुहोस्, टनेल रुट पढ्नुहोस्, र वास्तविक कन्टेनर ठेगानाका लागि कुन जित्छ हेर्नुहोस्।
Docker Desktop ले कन्टेनरहरूलाई आफ्नै NAT भएको VM पछाडि राख्छ। होस्टसँग कन्टेनर ठेगानासम्म कुनै रुट हुँदैन; यसले सेवासम्म प्रकाशित पोर्टबाट पुग्छ, सामान्यतया 127.0.0.1 मा बाँधिएको। त्यसैले VPN क्लाइन्टले कुनै सबनेट ओभरल्यापबिना सेवा बिगार्न सक्छ: VM को आन्तरिक दायराका लागि रुट राखेर वा टनेल जोडिएको बेला loopback ट्राफिक अवरुद्ध गरेर। होस्टमा ip route get ले कन्टेनर ठेगानाका लागि रुट छैन भनी रिपोर्ट गर्छ भने, त्यो अपेक्षित हो, बग होइन।
व्यावहारिक परिणाम तपाईं पहिले कहाँ हेर्नुहुन्छ भन्ने हो। Linux मा, राउटिङ तालिकाबाट सुरु गर्नुहोस्। Desktop मा, प्रकाशित पोर्ट र VPN क्लाइन्टका फायरवाल नियमबाट सुरु गर्नुहोस्, त्यसपछि VM को आन्तरिक सबनेटले टनेलले धकेल्ने कुनै कुरासँग ठक्कर खान्छ कि जाँच्नुहोस्।
टनेल खुला राखेर प्रमाणित गर्नुहोस्
यसलाई मिलाइयो भन्नु अघि VPN दुईचोटि पुनः जोड्नुहोस्, किनभने जोडिँदा रुट थप्ने र विच्छेद हुँदा फिर्ता लिने प्रोफाइल पहिलो प्रयासपछि ठीक देखिन सक्छ। त्यसपछि क्लाइन्टले वास्तवमै गर्ने जाँचहरू गर्नुहोस्:
- कन्टेनरको वास्तविक ठेगाना प्रयोग गरी होस्टबाट
ip route get। - सेवा आफै स्वस्थ छ भनी प्रमाणित गर्न अर्को कन्टेनरबाट अनुरोध।
- टनेल खुला हुँदा क्लाइन्टबाट
curl -sv http://127.0.0.1:8080/, त्यसपछि LAN को मेसिनबाट कन्टेनर ठेगानामाtraceroute -n। - अनुरोध होस्टसम्म पुगेर जवाफ हराउँछ भने
sysctl net.ipv4.conf.all.rp_filter।
अन्तमा, छानिएको दायरा जुन दर्ताबाट छानियो त्यहीँ मिति र यसको स्वामित्व भएको प्रोजेक्टसहित लेख्नुहोस्। अर्को ओभरल्याप कसैले अभिलेख नगरेको प्रोजेक्टबाट आउनेछ, र एकमात्र बचाव भनेको दायरा अनियमित रूपमा नलिई जानाजान आरक्षित गरिएको हुनु हो।