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।
शेवटी, निवडलेली श्रेणी जिथून निवडली त्या रजिस्ट्रीत तारीख आणि तिच्या मालकीचा प्रकल्प यासह लिहा। पुढील ओव्हरलॅप कोणीही दस्तऐवजीकरण न केलेल्या प्रकल्पातून येईल, आणि एकमेव बचाव म्हणजे श्रेणी यादृच्छिकपणे न घेता हेतुपुरस्सर राखीव ठेवली गेली होती।