एक Linux गेटवे पर दो OpenVPN क्लायंट: नीति बाँटें

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

कर्नेल तय करता है, डेमॉन नहीं

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

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

हर इंस्टेंस को उसका अपना संसाधन-समूह दें

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull सर्वर के धकेले हुए रूट को स्थानीय तालिका से बाहर रखता है, और जब नीति तालिकाएँ स्पष्ट होनी चाहिए तब आप यही चाहते हैं। क्या कोई दिया हुआ सर्वर redirect-gateway विकल्प भी धकेलता है, और क्या आपका क्लायंट संस्करण फ़िल्टर रूप को सपोर्ट करता है, यह मानने के बजाय मैनुअल में जाँचना बेहतर है।

मैट्रिक्स लिखें: स्रोत, तालिका, डिवाइस

हर क्लायंट समूह के लिए, स्रोत पते से तालिका चुनने वाला नियम जोड़ें, फिर इच्छित रास्ता उस तालिका में रखें:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

टनल का अपना परिवहन क्लायंट समूह में नहीं है

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

स्थानीय प्रबंधन सत्र और अंडरले पथ को नीति तालिकाओं से स्पष्ट रूप से बाहर रखें। उन अपवादों को मैट्रिक्स के बगल में लिखें; वे डिज़ाइन का हिस्सा हैं, कोई ऐसा उपाय नहीं जिसे किसी घटना के दौरान फिर से खोजना पड़े।

रास्ता चुनना उसकी अनुमति नहीं देता

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

स्रोत अनुवाद तीसरा फ़ैसला है, और इसे स्रोत समूह और उस टनल डिवाइस तक सीमित रखना चाहिए जो वास्तव में इसे ले जाता है। दोनों इंस्टेंस के लिए समर्पित श्रृंखला जोड़ें, postrouting श्रृंखला को खाली करने के बजाय, क्योंकि असंबंधित सेवाओं की वहाँ प्रविष्टियाँ हो सकती हैं और खाली करना उन्हें चुपचाप हटा देता है।

जब एक टनल गिरे तो क्या होता है

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

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