रुट-आधारित वि. नीति-आधारित साइट-देखि-साइट 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काम गर्दा सुरुङमा निर्भर नहुने व्यवस्थापन मार्ग राख्नुहोस्। गेटवेको आफ्नै पहुँच तपाईंले डिबग गरिरहेको जडानमा नचढेको खण्डमा फर्काउन सजिलो हुन्छ।