macvlan कंटेनर VPN क्लायंटला उत्तर का देऊ शकत नाही

VPN संपवणारा आणि त्याच वेळी macvlan नेटवर्कवर कंटेनर चालवणारा Linux होस्ट कल्पना करा। LAN 192.168.60.0/24 आहे, कंटेनरकडे 192.168.60.210 आहे, आणि VPN क्लायंट 10.95.0.0/24 वरून येतात। क्लायंट सेवेपर्यंत पोहोचतो, उत्तर कधीही परत येत नाही, आणि होस्टवरील प्रत्येक फायरवॉल नियम बरोबर दिसतो। दोन वेगळ्या मर्यादा हा लक्षण निर्माण करतात, आणि एक दुरुस्त केल्यावर दुसरी तिच्या जागी राहते।

दोन मर्यादा, एक लक्षण

पहिली मर्यादा अलगाव आहे: Docker चा macvlan ड्रायव्हर कंटेनरला पालक इंटरफेसद्वारे स्वतःच्या होस्टशी बोलू देत नाही। होस्ट स्टॅक आणि कंटेनरमधील रहदारीला मार्ग नाही, होस्टवरील मार्ग कसेही लिहिले असले तरी।

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

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

होस्टच्या बाजूचा shim अरुंदपणे बनवा

त्याच पालकाला ब्रिज मोडमध्ये जोडलेला दुसरा macvlan इंटरफेस होस्ट स्टॅकला त्या LAN विभागात स्वतःची ओळख देतो। त्यासाठी DHCP पूलबाहेर आणि कंटेनरच्या श्रेणीबाहेर पत्ता राखीव ठेवा, आणि फक्त कंटेनर त्यातून जाऊ द्या।

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

पहिला आदेश इंटरफेस ब्रिज मोडमध्ये तयार करतो, जो या ड्रायव्हरसाठी दस्तऐवजी डीफॉल्ट आहे आणि होस्ट-कंटेनर रहदारीसाठी तुम्हाला हवा असलेला मोड आहे। दुसरा /32 नेमतो जेणेकरून पत्ता LAN प्रीफिक्सशी टकराव होणार नाही, आणि चौथा shimमधून फक्त कंटेनरचा पत्ता पाठवतो।

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

हे आदेश चालू होस्टवरील नेटवर्क संरचना बदलतात। उपकरण किंवा व्यवस्थापित प्लॅटफॉर्मवर त्या प्लॅटफॉर्मची समर्थित कॉन्फिगरेशन पद्धत वापरा, कारण root-shellमधील इंटरॅक्टिव्ह बदल अपग्रेडनंतर टिकून राहील याची खात्री नाही।

स्रोत कसा जपला जाईल हे ठरवा

shim जागेवर असल्यावर कंटेनर होस्टपर्यंत पोहोचू शकतो, आणि प्रश्न असा होतो की उत्तर कोणता स्रोत पत्ता वाहून नेतो। मूळ VPN स्रोत जपणे हे स्वच्छ मॉडेल आहे: कंटेनरला क्लायंटचा खरा पत्ता दिसतो, आणि सेवेचे लॉग व प्रवेश नियम त्याचा वापर करू शकतात।

ते कार्य करण्यासाठी कंटेनरच्या नेटवर्क कॉन्फिगरेशनने या मार्गासाठी 10.95.0.0/24 ची रहदारी 192.168.60.250 वर त्याचा गेटवे म्हणून पाठवली पाहिजे। हे कंटेनरच्या स्वतःच्या कॉन्फिगरेशनमधील समर्थित मार्ग किंवा गेटवे सेटिंग आहे, होस्टच्या बाजूची युक्ती नाही। सेटिंग लागू झाली असे गृहीत धरण्याऐवजी कंटेनरच्या आतून त्याची पुष्टी करा। जो डीफॉल्ट गेटवे अजूनही LAN राउटरकडे निर्देश करतो तो उत्तरे त्याच छिद्रात पाठवत राहील।

मंजूर रचना त्याऐवजी VPN स्रोत लपवत असेल, तर भाषांतर अरुंदपणे मर्यादित करा: खरा VPN पूल, बाहेर जाणारा इंटरफेस म्हणून shim, आणि विशिष्ट कंटेनर व सेवा।

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

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

क्लायंटकडून तपासा, होस्टकडून नाही

होस्टकडूनच shimच्या पत्त्यावर बांधलेली विनंती shim कंटेनरपर्यंत पोहोचू शकतो हे सिद्ध करते। पण जपलेल्या 10.95.0.x स्रोताकडे कंटेनर रहदारी परत पाठवू शकतो हे ते सिद्ध करत नाही, कारण त्या चाचणीतील स्रोत पत्ता shimचाच आहे।

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

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

होस्टवर फॉरवर्डिंग सक्षम असणे आवश्यक आहे, आणि फॉरवर्डिंग मार्गाला सेवा पोर्टवर VPN पूलकडून shimकडे परवानगी तसेच प्रस्थापित उत्तरांसाठी परवानगी लागते। होस्टवरील INPUT नियम फॉरवर्ड केलेल्या रहदारीला अधिकृत करत नाही, आणि मार्गनिर्देशन बरोबर दिसल्यानंतर पॅकेट टाकून दिले जाण्याचे हे सामान्य कारण आहे।

खरे अनुप्रयोग खऱ्या ओळखपत्रांसह चालवा, नंतर त्याच कंटेनरवरील दुसरी, असंबंधित सेवा तुम्हाला अजूनही नाकारते का ते तपासा। ते कार्यान्वित करण्याचा एकमेव मार्ग प्रत्येक फॉरवर्डिंग नियम उघडणे असेल, तर रचना पूर्ण झालेली नाही। सेवेने कोणता स्रोत पत्ता नोंदवला तेही लक्षात घ्या, कारण यापुढे तिचे स्वतःचे प्रवेश नियम तोच वापरतील।