IPsec भित्र IPsec: बाहिरी सुरुङले कुन ठेगाना बोक्नुपर्छ

नेस्टेड IPsec बारे सोच्न सजिलो हुन्छ जब दुई तह फरक मेसिनमा अन्त्य हुन्छन्। चार गेटवे, दुई सुरुङ र डिजाइन काम गर्छ कि गर्दैन भन्ने निर्णय गर्ने एउटा प्रश्न: भित्री सुरुङले प्याकेट सकाएपछि बाहिरी सुरुङले वास्तवमा के देख्छ? यसको उत्तर दिनुहोस् र सिलेक्टर, रुट तथा समस्या समाधानको क्रम आफैं आउँछ। गल्ती गर्नुभयो भने प्राविधिक रूपमा चालु सुरुङ डिबग गर्दै एक दिन बिताउनुहुनेछ।

चार गेटवेको मोडेल

बाहिरी गेटवे A र B दुई साइटबीच पहिलो सुरुङ बनाउँछन्। A पछाडि ट्रान्जिट ठेगाना 10.60.0.2 भएको भित्री गेटवे C, र B पछाडि ट्रान्जिट ठेगाना 10.70.0.2 भएको भित्री गेटवे D छ। एप्लिकेसन नेटवर्क C र D पछाडि छन्, र उदाहरणको हरेक ठेगाना जानाजानी नमिल्ने छ।

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

तहहरूलाई चार होस्टमा बाँड्नु भनेको हरेक मेसिनले एउटा सिमाना लागू गर्छ। दुवै तह एउटै होस्टमा चलाउँदा एउटै मेसिनमा दुई नीति समूह, दुई रुट तालिका र दुई असफलता मोड मिलाउनुपर्छ, जुन सम्भव छ र अवलोकन गर्न धेरै गाह्रो।

हरेक तहले आफ्नै सुरक्षा मात्र हटाउँछ

C ले D का लागि एप्लिकेसन प्याकेट इन्क्रिप्ट गर्छ। नतिजा C बाट D मा ठेगाना गरिन्छ, र त्यही A सम्म पुग्छ। त्यसपछिको सबै कुरा त्यही पुनर्लेखनमा निर्भर छ।

A ले यसलाई B का लागि फेरि इन्क्रिप्ट गर्छ। B ले बाहिरी तह डिक्रिप्ट गर्छ, C बाट D जाने प्याकेट देख्छ र त्यसलाई अझै इन्क्रिप्टेड रूपमै अगाडि पठाउँछ। D ले भित्री सुरक्षा हटाएर एप्लिकेसन प्याकेट पुर्याउँछ।

त्यसैले A र B ले भित्री अन्त्यबिन्दु र तिनका मेटाडाटा देख्छन्, तर एप्लिकेसन पेलोड डिक्रिप्ट गर्ने पक्ष उनीहरू होइनन्। यो डिजाइनको वास्तविक गुण हो, C, D वा एप्लिकेसन होस्ट विश्वसनीय छन् भन्ने दाबी होइन।

बाहिरी सिलेक्टरले भित्री गेटवेको नाम लिन्छन्

यहीँ यस्ता निर्माणका धेरैजसो असफल हुन्छन्। नीति-आधारित बाहिरी सुरुङका लागि, तपाईंले वार्ता गर्ने सिलेक्टरमा A र B ले वास्तवमा सम्हाल्ने ठेगाना हुनुपर्छ: 10.60.0.2/32 र 10.70.0.2/32, सही स्थानीय र दूरस्थ क्रममा।

अन्तिम एप्लिकेसन सबनेट बाहिरी सिलेक्टरमा राख्नु काम गर्दैन, किनकि प्याकेट A सम्म पुग्दासम्म भित्री इन्क्याप्सुलेसनले A ले सुरक्षित गर्नुपर्ने कुरा पहिले नै पुनर्लेखन गरिसकेको हुन्छ। त्यसपछि बाहिरी नीति कुनैसँग मिल्दैन, र सुरुङ कुनै डाटा नबोकी माथि आउँछ।

बाहिरी अनुमति UDP 500 मा साँघुरो नबनाउनुहोस्। भित्री जडानको आफ्नै डाटा मार्ग छ, जसले वार्ताअनुसार ESP वा UDP इन्क्याप्सुलेसन प्रयोग गर्छ, र बाहिरी नीतिले त्यो प्रोटोकल अनुमति दिनुपर्छ।

हरेक गेटवेमा swanctl --list-sas प्रयोग गरी नतिजा जाँच्नुहोस् र चाइल्ड सुरक्षा-सम्बन्धले तपाईंले लक्ष्य गरेका ठेगाना रिपोर्ट गर्छन्, अनुमान गरेका होइनन् भनी पुष्टि गर्नुहोस्। यदि सूचीले एप्लिकेसन सबनेट देखाउँछ भने बाहिरी नीति गलत तहका लागि लेखिएको छ। रुटिङ डिबग गर्नुअघि सिलेक्टर सुधार्नुहोस्, किनकि रुटिङ ठीक देखिनेछ र काउन्टर सर्ने छैनन्।

फर्वार्डिङ र पुनरावृत्तिको जाल

सिलेक्टरले रुटिङको ठाउँ लिँदैनन्। A र B ले C र D बीच दुवै दिशामा ट्राफिक फर्वार्ड गर्नुपर्छ, अर्थात् IP फर्वार्डिङ सक्रिय, सुरुङतर्फ देखाउने रुट र अर्कोतिर रहेको फिर्ती मार्ग।

बाहिरी सुरुङले XFRM इन्टरफेस प्रयोग गर्छ भने, रुटले इन्टरफेस छान्छन् र वार्ता भएका नीतिले अझै के बोक्ने भन्ने सीमित गर्छन्। इन्टरफेसले सुरक्षित दायरा फराकिलो बनाउँदैन; यसले कर्नेलले प्याकेट कसरी उठाउँछ भन्ने मात्र बदल्छ।

जाल पुनरावृत्ति हो। B को बाहिरी अन्त्यबिन्दुतर्फ A को रुटले A बनाइरहेको सुरुङ होइन, तल्लो नेटवर्क पछ्याउनुपर्छ, नत्र इन्क्याप्सुलेसन आफैंभित्र यात्रा गर्न खोज्छ र जडान कहिल्यै पूरा हुँदैन।

तह थप्नुअघि अनुवाद जाँच्नुहोस्

अरू केही ट्युन गर्नुअघि A र B मा कुनै पनि स्रोत NAT हेर्नुहोस्। IPsec नीति लागू हुनुअघि C को ठेगाना पुनर्लेखन गर्ने नियमले सहमत सिलेक्टर तोड्न सक्छ, र D अर्कोतिर के प्राप्त गर्छ त्यो पनि बदल्न सक्छ।

दुई तह हुँदैमा फराकिलो मास्करेडिङ बढी सुरक्षित हुँदैन। यसले दूरको छेउले कुन ठेगाना देख्छ लुकाउँछ, र सुरुङ चालु भई एप नचल्दा ठ्याक्कै त्यही जानकारी चाहिन्छ।

NAT नियम साँच्चै आवश्यक भए, हरेक पक्षले कुन ठेगानासँग बोलिरहेको छु भनी ठान्छ लेख्नुहोस्। त्यो एउटै लाइनले सुरुङ वा अनुवाद कुन दोषी भन्ने बहसको धेरैजसो हल गर्छ। एक वर्षपछि नियम हटाउँदा अर्को इन्जिनियरले कहाँ हेर्ने भनी पनि बताउँछ। पिङले यीमध्ये केही पनि गर्दैन।

fail-closed प्रमाणित गर्नुहोस् र MTU जाँच्नुहोस्

रुट हराउनु आफैंमा fail-closed नीति होइन। अर्को तालिका, पूर्वनिर्धारित रुट वा नीति नियमले चुपचाप विकल्प दिन सक्छ, र यो थाहा पाउने एक मात्र तरिका बाहिरी सुरुङ तल झारेर एप्लिकेसन ट्राफिक के गर्छ हेर्नु हो। दुर्घटनावश पत्ता लगाउनुको सट्टा मर्मत विन्डोमा जानाजानी गर्नुहोस्।

तीन अवस्था परीक्षण गर्नुहोस्: बाहिरी सुरुङ तल, भित्री सुरुङ तल, र दुवै फर्केपछिको पुनःस्थापना। हरेक गेटवेमा नीति काउन्टर प्रयोग गर्नुहोस्, किनकि दुई स्थापित IKE सत्रले नियन्त्रण तहको वार्ता सफल भयो भन्ने मात्र प्रमाणित गर्छ।

दुवै इन्क्याप्सुलेसनका लागि बजेट राख्नुहोस्। चल्ने IKE सानो प्याकेटको नतिजा हो, र दुई हेडर थपिएपछि पूर्ण आकारका एप्लिकेसन प्याकेट अझै असफल हुन सक्छन्; संख्याहरू जोडिन्छन् भनी मान्नुको सट्टा वास्तविक मार्गमा ज्ञात पेलोड आकारसँग परीक्षण गर्नुहोस्। गणित सजिलो छ, मार्ग होइन।