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, प्रत्येक पत्त्यावर प्रकाशित करण्याऐवजी.