दो VPN पूल के लिए स्रोत रूटिंग: आपका नियम क्या चूकता है
from रूप का नियम SNAT के फिर से लिखने से पहले क्लाइंट पते से मेल खाता है, और गेटवे से की गई जाँच दोनों में से किसी से मेल नहीं खाती। हर पूल के लिए लुकअप चलाइए और इसके बजाय प्राथमिकताएँ पढ़िए।
दो क्लाइंट पूल, एक गेटवे, और योजना साधारण लगती है: एक नियम पहले पूल को तेज़ अपलिंक से बाहर भेजता है, दूसरा दूसरे पूल को पार्टनर टनल से भेजता है। फिर नियम जगह पर आ जाते हैं और दूसरा पूल फिर भी डिफ़ॉल्ट रूट से निकलता है। नियम टूटा नहीं है। पैकेट का स्रोत वह नहीं है जिसकी लेखक ने लुकअप के क्षण में अपेक्षा की थी, क्योंकि अनुवाद और लुकअप एक ही पैकेट की यात्रा के अलग-अलग बिंदुओं पर होते हैं, और क्रम उस मानसिक चित्र का उल्टा है जो अधिकांश लोग बनाते हैं।
लुकअप स्रोत के फिर से लिखे जाने से पहले होता है
VPN क्लाइंट से आगे भेजे गए पैकेट के लिए कर्नेल एक निश्चित क्रम चलाता है। यह टनल इंटरफ़ेस पर आता है, prerouting से गुज़रता है जहाँ conntrack और DNAT रहते हैं, फिर रूटिंग निर्णय होता है, फिर फ़ॉरवर्डिंग, फिर postrouting जहाँ SNAT सबसे अंत में लागू होता है। from रूप का नियम उसी रूटिंग निर्णय के दौरान देखा जाता है, यानी वह क्लाइंट का मूल पता देखता है, अनुवादित नहीं।
इसलिए masquerade नियम जोड़ने से यह नहीं बदलता कि बाहर जाते प्रवाह से कौन-सी नीति मेल खाती है। जो बदलता है वह है दूर का सिरा क्या देखता है, और इसलिए कौन-सा वापसी मार्ग मौजूद है। ये दो अलग परिणाम हैं, और बदलाव समीक्षाएँ इन्हें लगातार मिला देती हैं। इन्हें अलग कीजिए और डिज़ाइन आम तौर पर एक मिनट में स्पष्ट हो जाता है।
उत्तर की दिशा में ही अनुवादित पता नियमों में दिखता है। गेटवे पर लौटता पैकेट अनुवादित पते पर संबोधित होता है, और यदि आपके पास गंतव्य या जिस इंटरफ़ेस से वह आया उस पर आधारित नीति नियम हैं, तो वही मान आप मिलाएँगे। एक ही कनेक्शन, हर दिशा में सत्य का अलग स्रोत।
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
इसलिए अलग स्रोत वाले दो पूलों को वाकई अलग टेबल चाहिए, और डिज़ाइन सही है। ऊपर की टेबल जिसे रद्द करती है वह यह शॉर्टकट है कि दूर की साइट को क्या मिला यह देखकर नियम का अनुमान लगाया जाए।
गेटवे से की गई जाँच पूल की जाँच नहीं है
गेटवे स्वयं जो ट्रैफ़िक बनाता है वह कभी prerouting से नहीं गुज़रता, क्योंकि वह किसी इंटरफ़ेस पर आया ही नहीं। वह आउटपुट पथ में रूट होता है, स्रोत के रूप में गेटवे का अपना पता लेकर, और क्लाइंट श्रेणी पर बना from नियम मेल नहीं खाएगा। इस क्षेत्र का हर टिकट जो कहता है कि बॉक्स से काम करता है पर क्लाइंट से नहीं, उसी तथ्य की पुनरुक्ति है।
क्लाइंट का अनुमान लगाने के बजाय उसका अनुकरण कीजिए। रूटिंग लुकअप को सीधे पूछा जा सकता है, स्रोत और इनग्रेस इंटरफ़ेस देकर:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201इसे हर पूल के लिए एक बार चलाइए। यदि दोनों कमांड एक ही इंटरफ़ेस लौटाते हैं, तो नियम पूलों को अलग नहीं कर रहे, और कारण या तो गायब नियम है या दोनों से मेल खाता उच्च प्राथमिकता वाला नियम। यदि वे अलग इंटरफ़ेस लौटाते हैं पर क्लाइंट फिर भी विफल होता है, तो खराबी लुकअप के बाद है और आप नियम देखना बंद कर सकते हैं।
प्राथमिकता, फ़ाइल में स्थान नहीं
नियम प्राथमिकता के बढ़ते क्रम में मूल्यांकित होते हैं, और संख्या मायने रखती है, वह क्रम नहीं जिसमें आपने उन्हें टाइप किया। local टेबल प्राथमिकता 0 पर, main टेबल 32766 पर और डिफ़ॉल्ट नियम 32767 पर है, इसलिए डिफ़ॉल्ट प्राथमिकता से जोड़ा गया नियम सूची के अंत के पास पड़ता है और लगभग सबसे हार जाता है।
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201स्पष्ट प्राथमिकता इच्छित क्रम को फ़ाइल में और समीक्षा में दृश्य बनाती है। यह बाद के किसी जोड़ को चुपचाप मौजूदा नियम से आगे कूदने से भी रोकती है, जो असंबंधित बदलाव के बाद काम करती नीति के बंद हो जाने का सबसे सामान्य कारण है।
अपूर्ण टेबल की ओर इशारा करता मेल खाता नियम दूसरा जाल है। यदि टेबल 201 में डिफ़ॉल्ट रूट है पर गंतव्य का रूट नहीं, तो पैकेट गिरा दिया जाता है या गलत जगह भेजा जाता है, और नियम अलग से पूरी तरह सही दिखता है। टेबल पढ़िए, सिर्फ़ नियम नहीं। नियम एक संकेतक है, और खाली टेबल कुछ नहीं की ओर संकेतक।
वापसी मार्ग फिर भी होना चाहिए
स्रोत नीति एक निकास चुनती है। वह वापसी मार्ग नहीं बनाती। यदि दूसरा पूल पार्टनर टनल से निकलता है, तो पार्टनर को जानना होगा कि 172.31.8.0/24 तक कैसे पहुँचना है, या तो गेटवे की ओर वापसी रूट से या ऐसे अनुवादित पते पाकर जिन्हें वह पहले से जानता है।
इनके बीच चुनाव दृश्य परिणामों वाला डिज़ाइन निर्णय है। क्लाइंट श्रेणी को वापस रूट करने से पार्टनर के पास हर क्लाइंट की पहचान बनी रहती है और उसे आपका प्रीफ़िक्स स्वीकार करना पड़ता है। अनुवाद पूल को एक पते के पीछे छिपाता है और पार्टनर को केवल वही पता स्वीकार करना पड़ता है, इस कीमत पर कि आपके और उसके लॉग अब इस पर सहमत नहीं होंगे कि कौन जुड़ा।
आप जो भी चुनें, उसे पूल की परिभाषा के पास लिखिए। केवल किसी की स्मृति में मौजूद वापसी रूट ठीक वही चीज़ है जो पार्टनर के फ़ायरवॉल बदलने तक टिकती है, और फिर दोबारा बनाने में एक दिन लगता है।
नीति में गेटवे की अपनी टनल को न पकड़िए
क्लाइंट के लिए लिखे नियम गेटवे द्वारा बनाए ट्रैफ़िक पर भी लागू होते हैं, जब तक आप उसे बाहर न रखें। मार्क या आउटपुट इंटरफ़ेस पर बना व्यापक नियम गेटवे का पार्टनर से अपना कनेक्शन पकड़ सकता है, और फिर जो टनल नीति ढोती है वही नीति से रूट हो जाती है। इससे लूप या आउटेज बनता है जो प्रदाता की खराबी जैसा दिखता है।
हर नियम को उतना संकीर्ण रखिए जितना डिज़ाइन अनुमति दे: स्रोत प्रीफ़िक्स, इनग्रेस इंटरफ़ेस और जहाँ समर्थित हो वह मार्क जो केवल क्लाइंट पैकेट ढोते हैं। फिर हर नियम बदलाव के बाद गेटवे की अपनी कनेक्टिविटी जाँचिए, क्योंकि खराबी स्व-संदर्भी है और क्लाइंट जाँच में नहीं दिखती।
ip-rule का मैनुअल पृष्ठ चयनकर्ता और प्राथमिकता की अर्थ-व्यवस्था का दस्तावेज़ीकरण करता है। इसे हर पूल के लुकअप परीक्षण के साथ जोड़िए और डिज़ाइन जाँचने योग्य हो जाता है, जो एक साल टिकने वाली नीति रूटिंग और उसके बीच का अंतर है जिसे सभी छूने से डरते हैं।