Docker कंटेनर VPN मागील होस्टपर्यंत का पोहोचत नाही

कॉर्पोरेट VPN मागे कशापर्यंतही न पोहोचणारा कंटेनर सामान्यतः टनेलपेक्षा वेगळ्या नेटवर्क नेमस्पेसमध्ये राहतो। होस्ट क्लायंटचे मार्ग, DNS सर्व्हर आणि फायरवॉल खुणा होस्टच्या स्टॅकच्या असतात; ब्रिज नेटवर्क कंटेनरचा स्वतःचा स्टॅक असतो। ही एकच गोष्ट प्लॅटफॉर्म टीमपर्यंत पोहोचणाऱ्या बहुतेक अहवालांचे स्पष्टीकरण देते, आणि «VPN तुटलेला आहे» व «Docker VPN टाळतो» ही दोन्ही एकाच वेळी चुकीची असू शकतात याचेही हेच कारण आहे। एका लक्षणामागे दोन पूर्णपणे वेगळ्या संरचना दडलेल्या आहेत, म्हणून कोणतेही सेटिंग बदलण्यापूर्वी तुमच्याकडे कोणती आहे ते ठरवा।

टनेल कोणाच्या नेमस्पेसची आहे ते शोधा

macOS किंवा Windows साठी Docker Desktop वर कंटेनर Linux व्हर्च्युअल मशीनमध्ये चालतात। डेस्कटॉपवर स्थापित VPN क्लायंट डेस्कटॉप ऑपरेटिंग सिस्टममध्ये टनेल तयार करतो, आणि व्हर्च्युअल मशीन ती कधीही पाहत नाही। कोणतेही कंटेनर कॉन्फिगरेशन ते दुरुस्त करत नाही, कारण कंटेनरला आवश्यक असलेला इंटरफेस त्याच्या नेटवर्क नेमस्पेसमध्ये अजिबात नाही।

Linux होस्टवर टनेल होस्टच्या नेमस्पेसमध्ये राहते, आणि ब्रिज कंटेनर सामान्यतः बाहेर जाताना स्रोत NAT लागू केलेल्या होस्टच्या राउटिंग टेबलमधून तिला पोहोचतात। तो मार्ग अयशस्वी झाल्यावर कारण सामान्यतः गहाळ मार्ग नसून फॉरवर्डिंग धोरण, रिव्हर्स-पाथ फिल्टरिंग किंवा ओव्हरलॅपिंग सबनेट असते। पुढे वाचण्यापूर्वी तुम्ही दोन जगांपैकी कोणत्या मध्ये आहात ते निश्चित करा:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

त्या दोन राउटिंग टेबलमधील फरक म्हणजे एका स्क्रीनवरची संपूर्ण समस्या। होस्टच्या दृश्यात टनेल इंटरफेस असून ब्रिजच्या दृश्यात नसल्यास तुम्ही नेमस्पेस विलगीकरण पाहत आहात, आणि बाकी सर्व ते कसे ओलांडावे याची निवड आहे।

होस्ट नेटवर्किंग ही चाचणी आहे, रचना नाही

कंटेनर होस्ट नेटवर्किंगसह चालवणे, ज्याचे Docker होस्ट नेटवर्क नेमस्पेस सामायिकरण असे दस्तऐवजीकरण करते, त्याला टनेल इंटरफेस आणि त्याचे मार्ग थेट वारसाहक्काने देते। तीच विनंती नंतर यशस्वी झाल्यास मार्ग सिद्धांत पुष्ट होतो आणि अपयश नेमस्पेस विलगीकरण आहे, ओळखपत्रे, DNS किंवा प्रवेश नियम नाही।

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

हे निदान म्हणून ठेवा। होस्ट नेटवर्किंग पोर्ट प्रकाशन आणि कंटेनरकडून तुम्हाला हवे असलेले बहुतेक विलगीकरण सोडते, आणि Docker Desktop वर «host» म्हणजे व्हर्च्युअल मशीन, डेस्कटॉप नाही, त्यामुळे कोणत्या होस्टला संबोधित करत होता हे विसरल्यास तेथील यश किंवा अपयश तुम्हाला दिशाभूल करू शकते।

tun उपकरण आणि त्यासोबत येणारे विशेषाधिकार

कंटेनरमधील VPN क्लायंटला टनेल उपकरण आणि ते कॉन्फिगर करण्याची परवानगी आवश्यक असते। नेहमीचा शॉर्टकट --privileged आहे, जो प्रत्येक उपकरण देतो आणि संपूर्ण कंटेनरमध्ये सुरक्षा धोरण सैल करतो। हे या कामाच्या गरजेपेक्षा खूप जास्त आहे, आणि पुनरावलोकनात त्याचे समर्थन करणे कठीण आहे।

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

अधिक अरुंद स्वरूप एकच उपकरण नोड नकाशावर ठेवते आणि केवळ नेटवर्क प्रशासन क्षमता जोडते। नोड अस्तित्वात असण्यासाठी प्रथम होस्टवर मॉड्यूल लोड करा। कंटेनर सुरू होऊन क्लायंटने टनेल उपकरण उघडू शकत नाही असे नोंदवल्यास प्रोफाइलवर संशय घेण्यापूर्वी मॅपिंग तपासा, कारण ती त्रुटी सामान्यतः शब्दशः असते।

या रचनेचा अर्थ असाही आहे की क्लायंट प्रत्येक कंटेनरसाठी चालतो। प्रत्येक वर्कलोडला स्वतःची टनेल हवी असल्यास हे योग्य उत्तर आहे, आणि तुम्हाला फक्त होस्टची टनेल दिसावी असे वाटत होते तेव्हा अयोग्य उत्तर आहे — प्लॅटफॉर्म टीमने बहुधा तुम्ही तसेच करत आहात असे गृहीत धरले असेल।

ब्रिज NAT VPN दिसणारा स्रोत बदलते

डीफॉल्ट ब्रिजसह कंटेनरचा बाहेर जाणारा रहदारी होस्टच्या पत्त्यावर भाषांतरित होतो। त्यामुळे VPN मागे कॉर्पोरेट बाजू कंटेनरचा नाही, होस्टच्या टनेलचा पत्ता पाहते, स्रोत-आधारित प्रवेश नियम विनंती होस्टने पाठवल्यासारखे वागतात, आणि दोन कंटेनर VPN सर्व्हरसाठी अविभेद्य होतात।

macvlan किंवा ipvlan त्याऐवजी कंटेनरला LAN पत्ता देते, ज्यामुळे LAN शोधण्यास मदत होते आणि कंटेनर विभागात समकक्ष दिसतो। ते होस्टची टनेल पूर्णपणे टाळते, त्यामुळे अशा कंटेनरला केवळ-VPN उपसर्ग मिळणार नाहीत, जोपर्यंत VPN त्या LAN वरूनही उपलब्ध नाही।

दोन्ही स्वरूप वैध आहेत; ते वेगवेगळ्या गरजांना उत्तर देतात। गरज «या कंटेनरने केवळ-VPN सेवेपर्यंत पोहोचले पाहिजे» असेल, तर तुम्ही होस्टमधून राउटिंग आणि कंटेनरमध्ये टनेल संपवणे यामध्ये निवड करता। ही निवड तैनातीपूर्वी लिहा, पहिल्या अयशस्वी विनंतीनंतर नाही। तुम्ही काहीही निवडा, दूरच्या टोकाला दिसणारा स्रोत पत्ता नोंदवा, कारण त्याचे प्रवेश नियम आणि त्याचे लॉग तेच दाखवतील। तो पत्ता सांगू न शकणारी रचना पूर्ण नाही।

DNS डिमनचे अनुसरण करते, टनेलचे नाही

कंटेनर सुरू होताना आपले रिझोल्व्हर कॉन्फिगरेशन घेते, ते डिमन किंवा इमेजमधून नकल केलेले असते। VPN जोडल्यानंतर ढकलणारे पत्ते त्या नकलासाठी खूप उशिरा येतात, आणि ते कंटेनरमध्ये नाही, होस्ट रिझोल्व्हरमध्ये ढकलले जातात।

सेवेसाठी रिझोल्व्हर स्पष्टपणे सेट करा, किंवा टनेलमधून उपलब्ध अंतर्गत रिझोल्व्हरकडे निर्देश करा। खाजगी नाव सार्वजनिक पत्त्यावर सोडवणारा कंटेनर सामान्यतः सार्वजनिक रिझोल्व्हर वापरतो, तुटलेल्या मार्गाने त्रास होत नाही, आणि दुरुस्ती compose फाइल किंवा डिमन कॉन्फिगरेशनमध्ये आहे।

हाच तर्क बाहेर जाण्याच्या पत्त्याच्या प्रश्नालाही लागू होतो। प्रत्येक कंटेनर वेगळ्या VPN पत्त्यावरून दिसावा लागत असेल, तर एका होस्ट टनेलला ते देता येत नाही कारण NAT त्यांना एका स्रोतात आवळते। व्यवहार्य स्वरूपे म्हणजे प्रत्येक कंटेनरच्या नेमस्पेसमधील क्लायंट किंवा टनेलची मालकी असलेला आणि आपला स्टॅक सामायिक करणारा साइडकार, आणि दोन्ही अनुप्रयोग कसा संबोधला जातो ते बदलतात।

तिकीट बंद करण्यापूर्वीची तपासणी सूची: टनेलची मालकी असलेले नेमस्पेस ओळखा, होस्ट नेटवर्किंगने मार्ग सिद्ध करा, फक्त आवश्यक tun उपकरण नकाशावर ठेवा, NAT नंतरचा स्रोत पत्ता लक्षात ठेवा, रिझोल्व्हर स्पष्टपणे सेट करा आणि प्रति-कंटेनर बाहेर जाणारे पत्ते ध्वज नसून स्थापत्य निर्णय म्हणून घ्या।