दुई VPN पूलका लागि स्रोत राउटिङ: तपाईंको नियमले के छुटाउँछ
from स्वरूपको नियमले SNAT फेरि नलेखुन्जेल क्लाइन्ट ठेगानासँग मिल्छ, र गेटवेबाट गरिएको परीक्षण दुवैमध्ये कसैसँग मिल्दैन। हरेक पूलका लागि लुकअप चलाउनुहोस् र सट्टामा प्राथमिकता पढ्नुहोस्।
दुई क्लाइन्ट पूल, एउटा गेटवे र योजना साधारण देखिन्छ: एउटा नियमले पहिलो पूललाई छिटो अपलिङ्कबाट बाहिर पठाउँछ, अर्कोले दोस्रो पूललाई साझेदार टनेलबाट पठाउँछ। त्यसपछि नियमहरू ठाउँमा हुन्छन् र दोस्रो पूल अझै पनि पूर्वनिर्धारित मार्गबाटै बाहिरिन्छ। नियम बिग्रिएको छैन। लुकअप हुने क्षणमा लेखकले अपेक्षा गरेको कुरा प्याकेटको स्रोत हुँदैन, किनकि अनुवाद र लुकअप एउटै प्याकेटको यात्राका फरक बिन्दुमा हुन्छन्, र क्रम धेरैले कोर्ने मानसिक रेखाचित्रको उल्टो हुन्छ।
स्रोत फेरि नलेखिइनु अघि लुकअप हुन्छ
VPN क्लाइन्टबाट अगाडि पठाइने प्याकेटका लागि कर्नेलले एउटा निश्चित क्रम चलाउँछ। त्यो टनेल इन्टरफेसमा आउँछ, conntrack र DNAT रहेको prerouting भएर जान्छ, त्यसपछि राउटिङ निर्णय हुन्छ, त्यसपछि फर्वार्डिङ, त्यसपछि SNAT सबैभन्दा पछि लागू हुने postrouting। 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 म्यानुअल पृष्ठ ले छनोटकर्ता र प्राथमिकताको अर्थ दस्तावेजीकरण गर्छ। यसलाई हरेक पूलको लुकअप परीक्षणसँग जोड्नुहोस्, डिजाइन जाँच्नयोग्य हुन्छ, जुन एक वर्ष टिक्ने नीति राउटिङ र सबैले छुन डराउनेबीचको फरक हो।