OpenVPN पछाडिको Docker र VM ट्राफिक: रुट कि पुनःनम्बर?

होस्ट सुरुङबाट ब्राउज गर्छ तर छेउको कन्टेनर कतै पुग्दैन। आफ्नै VPN क्लाइन्ट चलाउने कन्टेनरबाट पोर्ट प्रकाशित गर्नु अझ नराम्रो हुन्छ: अनुरोध आउँछ र जवाफ कहिल्यै बाहिर जाँदैन। दुवै होस्टमा रुटिङका निर्णय हुन्, र Docker केवल सन्देशवाहक हो।

तीन प्रश्नले तपाईं यी दुईमध्ये कुन अवस्था हेर्दै हुनुहुन्छ भन्ने निर्धारण गर्छन्, र यसलाई लगभग एक मिनेट लाग्छ।

एउटै देखिने दुई खराबी

पहिलो फिर्ती मार्गको समस्या हो। प्रकाशित पोर्ट कन्टेनरमा अनुवाद हुन्छ, अनुरोध आउँछ, र जवाफ होस्टको पूर्वनिर्धारित मार्गबाट पठाइन्छ, जसलाई OpenVPN क्लाइन्टले tun0 तिर फर्काएको छ। जवाफ टाढाको साथीले नअपेक्षा गरेको ठेगानाबाट बाहिरिन्छ, र त्यसलाई खारेज गरिन्छ। दोस्रो उपसर्ग ठोक्किने समस्या हो: Docker को पूर्वनिर्धारित ब्रिजले 172.17.0.0/16 ओगट्छ र कर्पोरेट सुरुङले त्यही दायरा धकेल्छ।

एउटा रुट तालिकाले सुधारिन्छ, अर्को ब्रिज पुनःनम्बर गरेर। कुन कुन हो भन्ने थाहा पाउनुअघि सम्पादन गर्नु नै चलिरहेको कन्टेनर बिगार्ने तरिका हो।

तीन प्रश्नले निर्णय गर्नुहोस्

प्रश्न एक: VPN रोक्दा खराबी हराउँछ? सुरुङ बन्द हुँदा सबै चल्छ भने फिर्ती मार्गमा शंका गर्नुहोस्। प्रश्न दुई: के ip route show table all ले उही उपसर्ग दुई पटक सूचीबद्ध गर्छ, एक पटक ब्रिजमा र एक पटक tun0 मा? त्यही ठोक्किने हो। प्रश्न तीन: प्रभावित ठेगाना कन्टेनर हो, NAT पाहुना हो कि ब्रिज गरिएको पाहुना?

तेस्रो प्रश्न महत्त्वपूर्ण छ किनभने प्रत्येकको फरक सही समाधान छ, र कन्टेनरको समाधान libvirt पाहुनामा लगाउनु एउटा साँझ बर्बाद गर्छ।

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

फिर्ती मार्ग: एउटा स्रोत ठेगानाका लागि तालिका

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

जसको स्रोत त्यो ठेगाना हो, त्यो हरेक प्याकेटले पहिले तालिका 10 हेर्छ, र तालिका 10 ले त्यसलाई सुरुङको सट्टा ब्रिज गेटवेमा पठाउँछ।

यसले पुष्टि गर्नुहोस्: ip route get 1.1.1.1 from 172.22.0.3। जवाफमा ब्रिज इन्टरफेसको नाम हुनुपर्छ, tun0 होइन। यसरी थपिएका नियम रिबुटमा हराउँछन्, त्यसैले तिनीहरूलाई कन्टेनरको मालिक unit वा नेटवर्क हुकमा राख्नुहोस्।

उही ढाँचा WireGuard कन्टेनरका लागि पनि काम गर्छ, जहाँ जवाफ मार्गलाई पनि स्पष्ट नियम चाहिन्छ।

उपसर्ग ठोक्किने: ब्रिज पुनःनम्बर गर्नुहोस्

रुट तालिकाले एउटा उपसर्ग एउटै ठाउँमा पठाउँछ। यदि VPN ले 172.17.0.0/16 धकेल्छ र Docker को ब्रिज पहिले नै त्यहाँ छ भने कम मेट्रिक जित्छ: Docker ले आफ्नो जोडिएको मार्ग मेट्रिक 0 मा राख्छ, र धकेलिएको मार्ग 50 मा आउँछ। तब Docker चलिरहँदा पनि सुरुङ बिग्रिएको देखिन्छ, वा उल्टो, इन्स्टलेसन क्रमअनुसार। मेट्रिकसँग लड्नुको सट्टा ब्रिज पुनःनम्बर गर्नुहोस्।

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

परिवर्तनपछि Docker पुनः सुरु गर्नुहोस् र पुरानो पूलले बनाइएका नेटवर्क फेरि बनाउनुहोस्। सट्टा मेट्रिक बदल्नाले द्वन्द्व अर्को बुटमा सर्छ मात्र।

VM लाई फेरि अर्कै जवाफ चाहिन्छ

पूर्वनिर्धारित NAT नेटवर्कको libvirt पाहुनाले होस्टको रुटिङ उत्तराधिकारमा पाउँछ र होस्टको सुरुङले पूर्वनिर्धारित मार्ग ओगट्ने बित्तिकै बाहिर पुग्न छाड्छ। पाहुनालाई ब्रिज वा macvtap यन्त्रमा सार्दा भौतिक नेटवर्कमा आफ्नै बाटो मिल्छ। virt-manager मा हार्डवेयर थप्नुहोस्, Network छान्नुहोस्, स्रोत macvtap होस्ट यन्त्रमा राख्नुहोस्, मोडेलको रूपमा virtio राख्नुहोस्, त्यसपछि पुरानो NAT इन्टरफेस निष्क्रिय गर्नुहोस्।

macvtap पाहुना सामान्यतया आफ्नै होस्टसम्म पुग्न सक्दैन। यो खराबी होइन, अपेक्षित व्यवहार हो, र यो तपाईंले छोड्ने टिप्पणीमा हुनुपर्छ।

होस्टको LAN मात्र चाहिने पाहुनाका लागि विक्रेताको क्लाइन्टमा हराएको स्विच हुन सक्छ: Mullvad सँग mullvad lan set allow ले libvirt लाई छुनुबिना स्थानीय पहुँच पुनर्स्थापित गर्छ। र कन्टेनर सुरुङबाट मात्र पहुँचयोग्य हुनुपर्ने भए, प्रकाशित पोर्टलाई सुरुङ ठेगानामा बाँध्नुहोस्, -p 10.8.0.5:8080:8080। हरेक ठेगानामा प्रकाशित गर्नुको सट्टा।