L2TP, GRE या IPsec: सत्र किस परत को ढोना चाहिए?
L2TP PPP सत्र ढोता है, GRE रूट किए गए पैकेट ढोता है, IPsec चुने गए ट्रैफ़िक की रक्षा करता है। हर परत को एक काम दें और हर एक को अलग से जाँचें।
जब भी L2TP, GRE और IPsec एक ही डिज़ाइन नोट में आते हैं, दो सवाल उलझ जाते हैं: मैं कौन-सा सत्र ढो रहा हूँ, और कौन-सी परत उसकी रक्षा करती है? पहला गलत होने पर नीचे का सब कुछ भीतर से सुसंगत बना रहता है, जबकि गलत समस्या हल हो रही होती है — वहाँ रूट किया गया ओवरले बनाया जाता है जहाँ उपयोगकर्ताओं को डायल-इन करना था, या साइट-से-साइट गेटवे की जगह डायल-इन कंसंट्रेटर रख दिया जाता है। नीचे दी गई वर्कशीट किसी के भी डिवाइस में लॉग इन करने से पहले यह भेद करवाती है। इसे क्रम से भरें और हर पंक्ति ऐसी चीज़ बन जाती है जिसे अलग से जाँचा जा सके।
प्रोटोकॉल सूची से नहीं, सत्र से शुरू करें
PPP सत्र वाला दूरस्थ उपयोगकर्ता और दो गेटवे के बीच का रूट किया गया ओवरले अलग-अलग नेटवर्क संबंध हैं, भले ही दोनों अंत में IPsec में लिपटें। पहला प्रति-उपयोगकर्ता लिंक समाप्त करता है और उसे पता आवंटन, किसी व्यक्ति या डिवाइस का प्रमाणीकरण, और ऐसी नीति चाहिए जो बताए कि वह उपयोगकर्ता किन आंतरिक नेटवर्क तक पहुँच सकता है। दूसरा उन साइटों के बीच पैकेट अग्रेषित करता है जहाँ कोई डायल-इन नहीं करता।
एक वाक्य लिखें जो बताए कि आप इन दोनों में से कौन-सा बना रहे हैं, फिर उसे ऐसे पढ़ें जैसे आप वह व्यक्ति हों जिसे उसे चलाना है। अगर वाक्य को 'और' शब्द चाहिए, तो आप दोनों बना रहे हैं, और वर्कशीट को एक समझौता-स्तंभ के बजाय दो स्तंभ चाहिए जो हर एक की आधी सेवा करता है। अगर वह उपयोगकर्ता बताता है पर पता-पूल नहीं, या प्रीफ़िक्स बताता है पर अग्रेषण नीति नहीं, तो वाक्य अब भी अधूरा है। शब्दावली नौकरशाही जैसी लगती है, पर यह ऐसा डिज़ाइन पकड़ने की सबसे सस्ती जगह है जिसे वरना हेल्पडेस्क टिकट खोजेगा।
हर परत को ठीक एक काम दें
L2TPv2 अपने दो सिरों के बीच PPP सत्र ढोता है। PPP लिंक वार्ता चलाता है और, जब वह वार्ता होती है, उपयोगकर्ता प्रमाणीकरण; L2TP कोई क्रिप्टोग्राफ़ी नहीं जोड़ता, इसलिए नंगा L2TP डेमॉन IPsec सुरक्षा संबंध का कोई भाग लागू नहीं करता और केवल उसी लिंक के भीतर रहता है जिस पर आप पहले से भरोसा करते हैं।
GRE दो पतों के बीच एक एनकैप्सुलेशन है। यह तार्किक ओवरले पर नेटवर्क-परत पैकेट ढोता है और अपने आप में न गोपनीयता देता है न प्रमाणित पीयर पहचान। यह दोष नहीं है: हेडर जानबूझकर सरल रखा गया ताकि फ़ॉरवर्डिंग हार्डवेयर पर इसकी प्रोसेसिंग सस्ती रहे। नतीजा यह है कि GRE केवल 'इस पैकेट को दो पतों के बीच कैसे ले जाऊँ' का जवाब देता है और कुछ नहीं — ठीक वही सवाल जो आपको उससे पूछना चाहिए।
इससे IPsec वह परत रह जाती है जो ट्रैफ़िक चुनती है, पीयर का प्रमाणीकरण करती है और जिसे बचाने का निर्देश मिला उसे एन्क्रिप्ट करती है। किस ट्रैफ़िक की रक्षा करनी है यह कॉन्फ़िगरेशन का निर्णय है जो उसी एनकैप्सुलेशन से मेल खाना चाहिए जो सिरे वास्तव में बनाते हैं, क्योंकि GRE के बाहरी पते के लिए लिखी नीति आंतरिक प्रीफ़िक्स के लिए लिखी नीति से अलग व्यवहार करती है। GRE विनिर्देश पेलोड, GRE हेडर और बाहरी डिलीवरी प्रोटोकॉल को स्पष्ट रूप से अलग रखता है, और आपकी नीति को भी वही अलगाव चाहिए।
| Layer | Its one job | What it never does |
|---|---|---|
| PPP | Link negotiation, optional user authentication, address assignment | Protect traffic between gateways |
| L2TPv2 | Carry the PPP session between two endpoints | Encrypt or authenticate peers |
| GRE | Encapsulate network-layer packets between two addresses | Hide or authenticate the payload |
| IPsec | Authenticate peers and encrypt selected traffic | Carry a dial-in user session by itself |
कॉन्फ़िगरेशन से पहले पैकेट पथ लिखें
एक पैकेट लें और हर जोड़ा जाने वाला हेडर उसी क्रम में सूचीबद्ध करें, और बताएँ कौन-सा डिवाइस उसे जोड़ता है। डायल-इन उपयोगकर्ता के लिए आम तौर पर PPP, L2TP के भीतर और वह IPsec के भीतर होता है; साइट ओवरले के लिए आंतरिक IP पैकेट GRE के भीतर और GRE, IPsec के भीतर। अगर दो डिवाइस वही हेडर जोड़ते हैं, तो लूप या दोहरा टनल है, और कोई भी नीति-संपादन उसे ठीक नहीं करेगा।
वही सूची MTU तय करती है, क्योंकि उपयोगी आंतरिक आकार मापी गई पथ-MTU में से अभी गिनाए हेडर घटाकर बचता है और कुछ नहीं। फ़ोरम पोस्ट से संख्या न कॉपी करें: बाहरी IP, UDP और ESP का ओवरहेड जोड़ें, फिर GRE या L2TP, फिर जहाँ लागू हो PPP, और जो पथ-MTU आपने वास्तव में मापी उससे घटाएँ। केवल बड़े स्थानांतरणों में दिखने वाले लक्षण, या ऐसे सत्र जो बनते हैं और पहली बड़ी प्रतिक्रिया पर मर जाते हैं, आम तौर पर इसी जोड़ को अंदाज़े से करने तक जाते हैं।
हर परत को बाहर से भीतर अलग-अलग जाँचें
जाँचें क्रम से चलाएँ और पहली असफल जाँच पर रुकें। हर पंक्ति अलग सवाल का जवाब देती है, इसलिए विफलता यह नहीं कहती कि टनल टूटी है, बल्कि वर्कशीट के एक स्तंभ की ओर इशारा करती है।
ip xfrm state # is the IPsec SA up?
ip -s link show gre1 # does the overlay interface carry packets?
ip route get 10.20.0.5 # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500" # are the L2TP and NAT-T listeners bound?Cisco बॉक्स पर समतुल्य क्रिया भूमिका-विशिष्ट है, और सटीक सिंटैक्स प्लेटफ़ॉर्म और रिलीज़ पर निर्भर करता है: IPsec पीयर के लिए show crypto session, GRE या टनल इंटरफ़ेस के लिए इंटरफ़ेस काउंटर, और डायल-इन भूमिका के लिए VPDN या PPP सत्यापन। PPP समाप्त करने वाला कमांड-सेट GRE समर्थन के बारे में कुछ सिद्ध नहीं करता, और काम करता GRE इंटरफ़ेस PPP सेवा के बारे में कुछ सिद्ध नहीं करता, इसलिए आरेख की भूमिका के बजाय वह भूमिका जाँचें जो आपने वास्तव में कॉन्फ़िगर की।
हर आउटपुट को उस वर्कशीट पंक्ति के पास दर्ज करें जिससे वह संबंधित है। खराबी के जीवित रहते लिए गए नोट्स बाद में स्मृति से फिर बनाए गए टोपोलॉजी से अधिक मूल्यवान हैं।
टियरडाउन का क्रम तय करें, फिर दोबारा सत्यापित करें
टियरडाउन उल्टे क्रम में एक कारण से चलता है: संरक्षित ट्रैफ़िक को IPsec नीति से बाहर निकालें, उस एनकैप्सुलेशन को हटाने से पहले जिसके लिए वह लिखी गई थी, वरना नीति उस इंटरफ़ेस की ओर इशारा करती रहती है जो अब नहीं है और अगला कॉन्फ़िगरेशन लोड कहीं ऐसी जगह विफल होता है जो असंबंधित दिखती है। Linux पर इसका अर्थ है टनल इंटरफ़ेस से पहले state और policy प्रविष्टियाँ हटाना; राउटर पर टनल से पहले crypto map या profile प्रविष्टि हटाना।
पुनर्निर्माण के बाद चार स्वीकृति अवलोकन एक-एक करके दोहराएँ: बाहरी पहुँच, स्थापित IPsec संबंध, जहाँ डिज़ाइन में हो वहाँ स्थापित PPP सत्र, और वास्तविक गंतव्य पते तक आंतरिक अग्रेषण। एक हरी बत्ती बाकी तीन का प्रमाण नहीं है, और यही अंतराल उत्पादन में सबसे लंबा जीवित रहने वाली खराबी है — ऐसी टनल जो चालू, एन्क्रिप्टेड और कुछ भी अग्रेषित नहीं कर रही क्योंकि आंतरिक रूट कभी जोड़ा ही नहीं गया।
भरी हुई वर्कशीट डिवाइस कॉन्फ़िगरेशन के पास रखें। जो भी स्तंभ आप नहीं भर सकते वह बिना सौंपे गए काम वाली परत है, और बिना सौंपे गए काम वाली परत आम तौर पर वह परत होती है जो स्टैक में नहीं होनी चाहिए।