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 इंटरफ़ेस का उपयोग करती है, तो रूट इंटरफ़ेस चुनते हैं जबकि तय की गई नीतियाँ अब भी सीमित करती हैं कि वह क्या ले जाता है। इंटरफ़ेस सुरक्षित दायरे को नहीं बढ़ाता; वह केवल बदलता है कि कर्नेल पैकेट को कैसे उठाता है।

जाल रिकर्शन है। A का B के बाहरी एंडपॉइंट तक रूट अंडरले का पालन करना चाहिए, A जो टनल स्थापित कर रहा है उसका नहीं, वरना एन्कैप्सुलेशन अपने भीतर ही यात्रा करने की कोशिश करता है और कनेक्शन कभी पूरा नहीं होता।

परतें जोड़ने से पहले अनुवाद जाँचें

कुछ और ट्यून करने से पहले A और B पर किसी भी स्रोत NAT को देखें। IPsec नीति लागू होने से पहले C का पता फिर से लिखने वाला नियम सहमत सिलेक्टरों को तोड़ सकता है, और यह भी बदल सकता है कि D दूसरी ओर क्या प्राप्त करता है।

व्यापक मास्करेडिंग दो परतों के होने से अधिक सुरक्षित नहीं हो जाती। यह छिपाती है कि दूर का सिरा कौन-सा पता देखता है, और यह ठीक वही जानकारी है जो आपको तब चाहिए जब टनल चालू हो और ऐप्लिकेशन न हो।

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

fail-closed सिद्ध करें और MTU जाँचें

रूट का गायब होना अपने आप में fail-closed नीति नहीं है। कोई दूसरी तालिका, डिफ़ॉल्ट रूट या नीति-नियम चुपचाप विकल्प दे सकता है, और यह जानने का एकमात्र तरीका है बाहरी टनल नीचे करना और देखना कि ऐप्लिकेशन ट्रैफ़िक क्या करता है। यह जानबूझकर, किसी विंडो में करें, संयोग से खोजने के बजाय।

तीन अवस्थाएँ जाँचें: बाहरी टनल नीचे, भीतरी टनल नीचे, और दोनों के लौटने के बाद पुनर्प्राप्ति। हर गेटवे पर नीति काउंटर का उपयोग करें, क्योंकि दो स्थापित IKE सत्र केवल यह सिद्ध करते हैं कि नियंत्रण तल की बातचीत सफल रही।

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