अलग इग्रेस: usb0 पर VPN पूल, eth0 पर गेटवे ट्रैफ़िक

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

पुष्टि करें कि स्रोत पता रूटिंग निर्णय तक बना रहता है

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

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

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

एक पूरी चयनित तालिका बनाएँ

तालिका किसी मित्र के साथ डिफ़ॉल्ट रूट नहीं है। इसे पर्याप्त रूट चाहिए ताकि हर लुकअप उसके भीतर ही हल हो, जिसमें WAN सबनेट का जुड़ा हुआ रूट भी शामिल है ताकि अगला हॉप पहुँच योग्य हो। tun1 पर 10.77.0.0/24 पूल, अगले हॉप 203.0.113.1 के साथ WAN पता 203.0.113.20/24, और तालिका 600 के लिए:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

नियम किसी भी मौजूदा सब-कुछ-पकड़ने वाले नियम से नीची प्राथमिकता पर बैठता है, इसलिए मेल खाते क्लाइंट पहले तालिका 600 पर पहुँचते हैं और बाकी सब मुख्य तालिका में गिर जाता है। ip-rule संदर्भ क्रमबद्ध लुकअप मॉडल और सिलेक्टर सिंटैक्स का पूरा वर्णन करता है।

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

श्रोता के अपने ट्रैफ़िक को नीति से बाहर रखें

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

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

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

फ़ॉरवर्डिंग और अनुवाद को रूट के साथ मिलाएँ

रूटिंग एक अपलिंक चुनती है; यह फ़ॉरवर्ड करने की अनुमति नहीं देती। कर्नेल में IPv4 फ़ॉरवर्डिंग सक्षम होना चाहिए, और फ़ायरवॉल को क्लाइंट से WAN दिशा और वापसी ट्रैफ़िक स्वीकार करना चाहिए। फ़्लो को गिराने वाली FORWARD चेन के साथ सही तालिका वही लक्षण देती है जो गुम रूट देता है, इसलिए दोनों एक ही पास में जाँचे जाते हैं।

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

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

पथ अलग होते ही टनल ओवरहेड पर भी ध्यान देना होता है। अगर क्लाइंट बड़ा TCP MSS तय करते हैं और वैकल्पिक WAN का MTU कम है या उसके भीतर टनल है, तो बड़े सेगमेंट अटक जाते हैं जबकि छोटे काम करते हैं। फ़ॉरवर्डिंग पथ पर MSS क्लैंप करने से वह रुक-रुक कर अटकने के बजाय अनुमानित व्यवहार बन जाता है।

तय करें कि usb0 गायब होने पर क्या होता है

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

जहाँ यह वापस गिरना अस्वीकार्य है, वहाँ तालिका 600 में स्पष्ट टर्मिनल रूट जोड़ें, जैसे blackhole डिफ़ॉल्ट, या इंटरफ़ेस के बंद रहते पूल को फ़ायरवॉल में गिरा दें। दोनों में से कोई भी ऐसा निर्णय है जिसे आप लिख सकते हैं; मौन नहीं।

स्थायित्व आख़िरी मद है। दोनों लिंक का मालिक जो भी हो, चाहे नेटवर्क प्रबंधक हो, डिस्पैचर स्क्रिप्ट हो या कनेक्शन का जीवनचक्र, उसे हर पुनःकनेक्शन पर बिना नकल जोड़े रूट और नियम फिर से बनाने होंगे। किसी वास्तविक क्लाइंट से अनुरोध और गेटवे से अलग अनुरोध के साथ सत्यापित करें, दोनों में देखा गया इग्रेस पुष्ट करें, फिर दूसरा WAN खींचें और देखें कि आपके डिज़ाइन किए दोनों परिणामों में से कौन सा वास्तव में होता है। IPv6 को अपनी तालिका, नियम और अनुवाद चाहिए; ऊपर का IPv4 नियम उसके बारे में कुछ नहीं कहता।