macvlan कंटेनर VPN क्लाइंट को जवाब क्यों नहीं दे सकता

ऐसे Linux होस्ट की कल्पना करें जो VPN समाप्त करता है और साथ ही macvlan नेटवर्क पर एक कंटेनर चलाता है। LAN 192.168.60.0/24 है, कंटेनर के पास 192.168.60.210 है, और VPN क्लाइंट 10.95.0.0/24 से आते हैं। क्लाइंट सेवा तक पहुँचता है, जवाब कभी वापस नहीं आता, और होस्ट पर हर फ़ायरवॉल नियम सही दिखता है। दो अलग बाधाएँ इस लक्षण को पैदा करती हैं, और एक को ठीक करने से दूसरी अपनी जगह रहती है।

दो बाधाएँ, एक लक्षण

पहली बाधा अलगाव है: Docker का macvlan ड्राइवर कंटेनर को पैरेंट इंटरफ़ेस से अपने ही होस्ट से बात करने नहीं देता। होस्ट स्टैक और कंटेनर के बीच ट्रैफ़िक का कोई रास्ता नहीं है, चाहे होस्ट पर रूट कैसे भी लिखे गए हों।

दूसरी बाधा वापसी का रास्ता है। कंटेनर का डिफ़ॉल्ट गेटवे आम तौर पर LAN राउटर होता है, इसलिए VPN क्लाइंट के लिए भेजा गया जवाब उसी राउटर से बाहर जाता है। अगर राउटर के पास VPN पूल तक वापस जाने का कोई रूट नहीं है, तो जवाब बीच में कहीं गिरा दिया जाता है।

क्लाइंट की नज़र से ये दोनों विफलताएँ एक जैसी दिखती हैं: एक अनुरोध आता है और एक जवाब कभी नहीं आता। इन्हें अलग-अलग मरम्मत चाहिए, और एक व्यापक masquerade नियम छिपा सकता है कि इनमें से कौन अभी टूटा है। इसीलिए पहला परीक्षण कंटेनर की तरफ़ कैप्चर है, न कि फ़ायरवॉल में एक और बदलाव। अगर अनुरोध वहाँ कभी नहीं दिखता, तो अलगाव की बाधा ही चल रही है।

होस्ट की तरफ़ का शिम संकीर्ण रूप से बनाएँ

होस्ट पर दूसरा 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 प्रीफ़िक्स से न टकराए, और चौथा केवल कंटेनर का पता शिम से गुज़ारता है।

पूरे LAN को नए इंटरफ़ेस से रीडायरेक्ट न करें। सामान्य कनेक्टेड रूट जैसा है वैसा ही रहता है, और होस्ट रूट जानबूझकर संकीर्ण है ताकि एक कंटेनर को रास्ता मिले पर सेगमेंट के बाकी हिस्से का व्यवहार न बदले। शिम की ओर इशारा करने वाला डिफ़ॉल्ट रूट अलग परिणामों वाला अलग डिज़ाइन होता। इसे विशिष्ट रखें और नुकसान का दायरा छोटा ही रहता है।

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

तय करें कि स्रोत कैसे सुरक्षित रहेगा

शिम मौजूद होने पर कंटेनर होस्ट तक पहुँच सकता है, और सवाल यह हो जाता है कि जवाब कौन-सा स्रोत पता ले जाता है। मूल VPN स्रोत सुरक्षित रखना अधिक स्वच्छ मॉडल है: कंटेनर असली क्लाइंट पता देखता है, और सेवा के लॉग तथा एक्सेस नियम उसका उपयोग कर सकते हैं।

इसके लिए कंटेनर की नेटवर्क कॉन्फ़िगरेशन को इस रास्ते के लिए 10.95.0.0/24 का ट्रैफ़िक 192.168.60.250 पर अपने गेटवे के रूप में भेजना होगा। यह कंटेनर की अपनी कॉन्फ़िगरेशन के भीतर एक समर्थित रूट या गेटवे सेटिंग है, होस्ट की तरफ़ की कोई तरकीब नहीं। सेटिंग लागू हुई मान लेने के बजाय कंटेनर के अंदर से इसकी पुष्टि करें। जो डिफ़ॉल्ट गेटवे अभी भी LAN राउटर की ओर इशारा करता है, वह जवाब उसी छेद में भेजता रहेगा।

अगर स्वीकृत डिज़ाइन इसके बजाय VPN स्रोतों को छिपाता है, तो अनुवाद को संकीर्ण रखें: असली VPN पूल, आउटगोइंग इंटरफ़ेस के रूप में शिम, और विशिष्ट कंटेनर तथा सेवा।

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

शिम को इग्रेस इंटरफ़ेस के रूप में मिलाएँ, टनल के रूप में नहीं। जो नियम टनल को आउटगोइंग इंटरफ़ेस कहता है, वह कंटेनर की ओर जाते पैकेट से मेल नहीं खाएगा, और इस तरह की सेटिंग में आम तौर पर यही गलती होती है। नियम को ऊपर के वाक्य जितना संकीर्ण रखें और पूल बदलने पर उसकी समीक्षा करें।

क्लाइंट से जाँचें, होस्ट से नहीं

होस्ट से ही शिम के पते पर बँधा अनुरोध साबित करता है कि शिम कंटेनर तक पहुँच सकता है। यह साबित नहीं करता कि कंटेनर सुरक्षित 10.95.0.x स्रोत तक ट्रैफ़िक वापस भेज सकता है, क्योंकि उस परीक्षण में स्रोत पता शिम का अपना है।

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 क्लाइंट के अनुरोध करते समय शिम से वास्तव में क्या गुज़रता है। अंदर आने के रास्ते पर स्रोत पता देखें और यह कि उसी प्रवाह के साथ जवाब दिखता है या नहीं।

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

असली एप्लिकेशन असली क्रेडेंशियल के साथ चलाएँ, फिर जाँचें कि उसी कंटेनर पर दूसरी, असंबंधित सेवा अभी भी आपको मना करती है। अगर इसे काम कराने का एकमात्र तरीका हर फ़ॉरवर्डिंग नियम खोलना था, तो डिज़ाइन पूरा नहीं है। यह भी नोट करें कि सेवा ने कौन-सा स्रोत पता दर्ज किया, क्योंकि अब से उसके अपने एक्सेस नियम उसी का उपयोग करेंगे।