एक ही Linux होस्ट पर दो OpenVPN सुरंगें: मार्ग किसका है?

दो प्रोफ़ाइल जुड़े हुए हैं, और उनमें से एक चुपचाप दूसरे के लिए निर्धारित ट्रैफ़िक ले जा रहा है। Linux होस्ट दोनों OpenVPN क्लाइंट एक साथ बिना किसी कठिनाई के चला सकता है। जो वह नहीं कर सकता, वह यह तय करना है कि कौन-सी प्रक्रिया कौन-सा प्रीफ़िक्स दावा कर सकती है। यह निर्णय दूसरी सुरंग के ऊपर आने से पहले लेना होगा, किसी संसाधन के जवाब देना बंद करने के बाद नहीं।

दूसरी लिंक को जो काम करना है उसी से शुरू करें

एक प्रोफ़ाइल से पहुँचने योग्य कार्यालय और दूसरे से पहुँचने योग्य प्रयोगशाला के लिए दोनों सुरंगें ऊपर होनी चाहिए और कोई भी सब कुछ दावा न करे। दूसरे प्रोफ़ाइल से बाहर निकलने वाले एक ज़िद्दी ऐप को दूसरे डिफ़ॉल्ट के बजाय नीति नियम चाहिए। स्टैंडबाय लिंक को एक समय में केवल एक सुरंग चालू चाहिए, इसलिए अतिरिक्त को मशीन के साथ शुरू नहीं होना चाहिए।

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

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

पहला कमांड चल रहे इंस्टेंस की सूची देता है, जिसमें मैनेजर के बाहर हाथ से शुरू किए गए भी शामिल हैं। दूसरा वर्तमान डिफ़ॉल्ट दावा छापता है, और यही वह स्थिति है जिसे आपको बाद में समझाना होगा।

ओवरलैप करते पूल रूटिंग से पहले टूटते हैं

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

स्थानीय LAN को भी देखें। 192.168.1.0/24 संख्या वाला घरेलू LAN, जिसे एक सुरंग भी उजागर करती है, वही अस्पष्टता पैदा करता है, और लक्षण यह है कि होस्टनाम हल हो जाता है जबकि कनेक्शन कभी पूरा नहीं होता। यह मार्गों को छापने तक नाम-समाधान खराबी जैसा दिखता है।

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

क्लाइंट को छूने से पहले दोनों आउटपुट की तुलना दोनों सर्वर कॉन्फ़िगरेशन से करें। यदि प्रीफ़िक्स ओवरलैप करते हैं, तो रुकें और फिर से क्रमांकित करें, क्योंकि कितने भी रीस्टार्ट उन्हें अलग नहीं करेंगे।

हर प्रोफ़ाइल को उसकी यूनिट और हर प्रीफ़िक्स को स्वामी दें

हर प्रोफ़ाइल को अपना इंस्टेंस नाम और अपनी कॉन्फ़िगरेशन फ़ाइल मिलती है, इसलिए office नाम का इंस्टेंस office.conf लोड करता है जबकि lab नाम वाला lab.conf लोड करता है। डायरेक्टरी सूची पर भरोसा करने के बजाय सेवा मैनेजर के माध्यम से उस मैपिंग की पुष्टि करें, क्योंकि drop-in यह बदल सकता है कि कौन-सी फ़ाइल लोड होती है। मैपिंग गलत होने का मतलब है कि आप उस प्रोफ़ाइल को ट्यून कर रहे हैं जो चल नहीं रहा।

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

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

पहला यूनिट को उसके आर्ग्युमेंट बदलने वाले किसी भी ओवरराइड के साथ दिखाता है। दूसरा दिखाता है कि प्रोफ़ाइल धकेले गए मार्ग बिलकुल स्वीकार करता है या नहीं, और यही वह स्विच है जो आगे सब कुछ तय करता है।

मार्क जवाबों को उसी इंटरफ़ेस पर रखते हैं जहाँ से वे आए

जब हर सुरंग अलग-अलग स्रोतों की सेवा करती है, तो जवाब गलत लिंक से बाहर जा सकता है और पहले पैकेट के बाद कनेक्शन मर जाता है। जो पैटर्न टिकता है वह है आने वाले पैकेट को इनपुट इंटरफ़ेस के अनुसार मार्क करना, जवाब पर वह मार्क बहाल करना, और हर मार्क को अपने डिफ़ॉल्ट गेटवे वाली तालिका देना।

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

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

दूसरा जोड़ने से पहले मौजूदा नियम पढ़ें। दोहरी प्राथमिकताएँ और भूली हुई तालिकाएँ ही आम कारण हैं कि मार्क नीति का बिलकुल असर नहीं दिखता।

एक लिंक रोककर अलगाव सिद्ध करें

दोनों सुरंगें ऊपर होने पर हर इंटरफ़ेस का पता, हर सुरंग के पीछे एक होस्ट तक का मार्ग, और किसी असंबंधित गंतव्य का रास्ता दर्ज करें। एक तालिका पढ़ने के बजाय कर्नेल से लुकअप माँगें, क्योंकि एक तालिका कभी अंतिम निर्णय नहीं दिखाती।

फिर एक इंस्टेंस रोकें और देखें कि उसका इंटरफ़ेस और मार्ग गायब हो जाते हैं जबकि दूसरा चलता रहता है। बचे हुए में टूटन का मतलब है कि दोनों अब भी कोई डिवाइस नाम, मार्ग या फ़ायरवॉल नियम साझा करते हैं जिसे किसी ने अलग नहीं किया।

रोकी गई प्रोफ़ाइल वापस लाएँ और वही जाँच दोहराएँ। जब सुरंग रीबूट के बाद केवल पहले स्टार्ट पर टिकती है, तो आप रूटिंग डिज़ाइन नहीं बल्कि जीवन-चक्र दोष देख रहे हैं।