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 नियमले फर्वार्ड गरिएको ट्राफिकलाई अधिकृत गर्दैन, र मार्गनिर्देशन सही देखिएपछि प्याकेट फालिनुको यो सामान्य कारण हो।

वास्तविक अनुप्रयोग वास्तविक प्रमाणहरूसँग चलाउनुहोस्, त्यसपछि त्यही कन्टेनरमा रहेको दोस्रो, असम्बन्धित सेवाले तपाईंलाई अझै अस्वीकार गर्छ कि जाँच्नुहोस्। यसलाई काम गराउने एउटै उपाय हरेक फर्वार्डिङ नियम खोल्नु थियो भने, डिजाइन पूरा भएको छैन। सेवाले कुन स्रोत ठेगाना अभिलेख गर्‍यो पनि ख्याल गर्नुहोस्, किनभने अबदेखि उसका आफ्नै पहुँच नियमहरूले त्यही प्रयोग गर्नेछन्।