रूट-आधारित बनाम नीति-आधारित साइट-टू-साइट VPN: क्या अलग है
नीति-आधारित IPsec चयनक द्वारा ट्रैफ़िक चुनता है; रूट-आधारित उसे टनल इंटरफ़ेस से भेजता है। दोनों को अब भी फ़ायरवॉल नियम और वापसी रूट चाहिए।
दोनों डिज़ाइन उसी ट्रैफ़िक को उसी IPsec मशीनरी से सुरक्षित करते हैं, और उनमें यह अंतर है कि कौन-सा पैकेट टनल में प्रवेश करेगा, यह क्या तय करता है। नीति-आधारित कनेक्शन में बातचीत किए गए ट्रैफ़िक चयनक यह काम करते हैं; रूट-आधारित में टनल इंटरफ़ेस की ओर इशारा करने वाला रूट यह काम करता है। दोनों को मिला देना वही परिचित सहायता थ्रेड बनाता है जिसमें टनल स्थापित होने की सूचना देता है जबकि एप्लिकेशन कहीं नहीं पहुँचता। यह अंतर सबसे ज़्यादा तब मायने रखता है जब आप कोई नेटवर्क जोड़ते हैं, रूटिंग प्रोटोकॉल चलाते हैं, या ऐसे मार्ग को डीबग करते हैं जो चुपचाप गलत निकास से बाहर निकल जाता है।
टनल में क्या प्रवेश करेगा, यह तय करने के दो तरीके
नीति-आधारित VPN एक सुरक्षा नीति बनाता है जो स्रोत और गंतव्य प्रीफ़िक्स से मेल खाती है, फिर जो भी फ़िट बैठे उसे एन्क्रिप्ट करता है। साथी को संगत चयनकों पर बातचीत करनी होती है, इसलिए प्रभावी दायरा अंततः दोनों पक्षों के प्रस्ताव का प्रतिच्छेद बन जाता है। उस प्रतिच्छेद से बाहर कुछ भी सुरक्षित नहीं है, रूटिंग तालिका चाहे जो कहे।
रूट-आधारित VPN टनल का प्रतिनिधित्व करने वाला इंटरफ़ेस बनाता है और रूटिंग तालिका को उसमें ट्रैफ़िक भेजने देता है। IKE डेमन अब भी स्थिति और प्रति-इंटरफ़ेस नीति स्थापित करता है, और यही वह बारीकी है जिसे लोग तब छोड़ देते हैं जब वे तय करते हैं कि रूट ने एन्क्रिप्शन की जगह ले ली है। दोनों डिज़ाइन IPsec से एन्क्रिप्ट करते हैं; केवल चयन तंत्र अलग है।
नीचे दी गई तुलना को स्कोरकार्ड नहीं, विफलता-हस्ताक्षरों का समूह मानकर पढ़ें, क्योंकि कोई भी स्तंभ अपने आप में नहीं जीतता।
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
नीति-आधारित: चयनक ही अनुबंध है
चयनकों पर बातचीत होती है, केवल कॉन्फ़िगर नहीं किया जाता। एक ओर 10.10.0.0/16 और दूसरी ओर 10.10.1.0/24 प्रस्तावित करें, और एसोसिएशन वही कवर करेगा जिस पर बातचीत स्थिर हुई, जबकि हर दूसरा मेज़बान बाहर रहेगा।
कॉन्फ़िगरेशन फ़ाइल की जगह स्थापित स्थिति पढ़ें। Linux साथी पर कर्नेल की अपनी तालिकाएँ ही ज़मीनी सच्चाई हैं, और वे दिखाती हैं कि बातचीत से क्या बचा। ऐसी नीति जो सही प्रीफ़िक्स बताती है पर मेल खाती स्थिति नहीं रखती, का अर्थ है कि एसोसिएशन कभी बना ही नहीं। गलत प्रीफ़िक्स के लिए नीति के साथ जुड़ी स्थिति उलटी समस्या है, और यह वह टनल बनाती है जो स्वस्थ दिखती है जबकि एक सबनेट कहीं नहीं पहुँच पाता।
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasदोनों आउटपुट की उन प्रीफ़िक्स से तुलना करें जिन्हें आप सुरक्षित मानते हैं। यही एक तुलना काम करती टनल और अगम्य सर्वर की अधिकांश रिपोर्टें सुलझा देती है। यह यह भी बताती है कि कौन-सा साथी बदलना है, क्योंकि बेमेल आमतौर पर एक ही दिशा में दिखता है।
रूट-आधारित: इंटरफ़ेस ही अनुबंध है
XFRM इंटरफ़ेस टनल को नाम और पहचान देता है, और ट्रैफ़िक उस तक पहुँचता है क्योंकि रूटिंग तालिका ऐसा कहती है। तब कई दूरस्थ प्रीफ़िक्स चयनक की समस्या के बजाय रूटिंग की समस्या बन जाते हैं, और रूटिंग प्रोटोकॉल उन्हें विज्ञापित कर सकता है। असली लाभ यही है, एन्क्रिप्शन नहीं।
इंटरफ़ेस नीति की ज़रूरत नहीं हटाता। डेमन इंटरफ़ेस की पहचान से बंधे नियम हर इंटरफ़ेस के लिए स्थापित करता है, इसलिए गलत इंटरफ़ेस पर आने वाला पैकेट फिर भी विफल होता है। जिस स्रोत पते को साथी स्वीकार नहीं करेगा वह भी विफल होता है, चाहे रूट उत्तम हो। रूट-आधारित का अर्थ है कि रूट प्रवेश तय करता है, यह नहीं कि नीति गायब हो गई।
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10रूट लगने के बाद इंटरफ़ेस काउंटरों पर नज़र रखें। रूट मौजूद है पर काउंटर शून्य पर टिके हैं, इसका अर्थ है कि टनल में कुछ भी मिलाया नहीं जा रहा, जो आमतौर पर गायब रूट के बजाय गायब स्थिति की ओर इशारा करता है।
दोनों डिज़ाइन वास्तव में कहाँ अलग होते हैं
नेटवर्क जोड़ना यह जाँचने का सबसे साफ़ परीक्षण है कि कौन-सा मॉडल आपके लिए उपयुक्त है। रूट-आधारित डिज़ाइन एक रूट जोड़ता है और अधिकतम एक बार चयनक चौड़ा करता है, जबकि नीति-आधारित डिज़ाइन दोनों साथियों पर प्रीफ़िक्स जोड़े संपादित करता है और फिर से बातचीत करता है। दो स्थिर सबनेट उस संपादन को तुच्छ बनाते हैं, और बीस उसे एक परियोजना बना देते हैं।
कोई भी मॉडल फ़ायरवॉल की जगह नहीं लेता, और तुलनाएँ आमतौर पर इस बिंदु से पहले रुक जाती हैं। चौड़ा चयनक या चौड़ा रूट तय करता है कि क्या एन्क्रिप्ट होगा, यह नहीं कि क्या अनुमत है।
MTU का व्यवहार भी व्यवहार में अलग है। एनकैप्सुलेशन उपयोगी पेलोड घटाता है, और रूट-आधारित इंटरफ़ेस अपना MTU रखता है, इसलिए दोनों गेटवे पर MSS क्लैंप करना उस ब्लैक-होल लक्षण से बचाता है जिसमें छोटे उत्तर आते हैं और बड़े गायब हो जाते हैं। नीति-आधारित टनल दूसरी ओर से उसी दीवार से टकराती हैं, क्योंकि चयनक पैकेट के आकार के बारे में कुछ नहीं कहता। साथी को दोष देने के बजाय क्लैंप जानबूझकर सेट करें।
वापसी मार्ग खोए बिना माइग्रेशन
कुछ भी बदलने से पहले मौजूदा प्रीफ़िक्स जोड़े दर्ज करें, फिर एक एप्लिकेशन मार्ग ले जाएँ और उसे शुरू से अंत तक देखें। स्थापित होने वाली टनल वह टनल नहीं है जो आगे भेजती है, और यह अंतर उत्तर की दिशा में दिखता है।
जब साथी जुड़ते हैं पर LAN मेज़बान नहीं, तो वापसी रूट और उस स्रोत पते की जाँच करें जिसका दूरस्थ मेज़बान उपयोग करेगा। दो इंटरफ़ेस वाला मेज़बान गलत इंटरफ़ेस से उत्तर दे सकता है, और कोई चयनक परिवर्तन उसे ठीक नहीं करता। एल्गोरिदम संपादित करने से पहले दोनों सिरों पर ट्रैफ़िक कैप्चर करें।
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsकाम करते समय एक प्रबंधन मार्ग रखें जो टनल पर निर्भर न हो। पीछे लौटना आसान है जब गेटवे की अपनी पहुँच उस कनेक्शन पर न चले जिसे आप डीबग कर रहे हैं।