L2TP, GRE की IPsec: सेशन कोणता स्तर वाहून नेले पाहिजे?

एकाच रचना टिपेत L2TP, GRE आणि IPsec एकत्र आले की दोन प्रश्न गुंततात: मी कोणते सेशन वाहून नेत आहे आणि ते कोणता स्तर संरक्षित करतो? पहिले चुकले तर खालील सर्व आंतरिकदृष्ट्या सुसंगत राहते, पण चुकीची समस्या सोडवते — वापरकर्त्यांना डायल-इन करायचे होते तिथे बांधलेला मार्गित आच्छादन, किंवा साइट-ते-साइट प्रवेशद्वाराच्या जागी उभा असलेला डायल-इन केंद्रक। खालील कार्यपत्रक कोणीही उपकरणात लॉग इन करण्यापूर्वी हा फरक सक्तीने करते। ते क्रमाने भरा आणि प्रत्येक ओळ स्वतंत्रपणे तपासता येणारी गोष्ट बनेल।

प्रोटोकॉलच्या यादीपासून नाही, सेशनपासून सुरुवात करा

PPP सेशन धारण करणारा दूरस्थ वापरकर्ता आणि दोन प्रवेशद्वारांमधील मार्गित आच्छादन हे दोन्ही शेवटी IPsec मध्ये गुंडाळले गेले तरी वेगवेगळे जाळीचे संबंध आहेत। पहिले प्रत्येक वापरकर्त्याची लिंक संपवते आणि पत्ता वाटप, व्यक्ती किंवा उपकरणाचे प्रमाणीकरण, आणि त्या वापरकर्त्याला कोणत्या आंतरिक जाळ्यांपर्यंत पोहोचता येईल हे नामनिर्देशित करणारे धोरण आवश्यक करते। दुसरे अशा साइट्समध्ये पॅकेट पुढे पाठवते जिथे कोणीही डायल-इन करत नाही।

तुम्ही दोनपैकी कोणते बांधत आहात हे नामनिर्देशित करणारे एक वाक्य लिहा, नंतर ते चालवावे लागणारे व्यक्ती तुम्हीच आहात अशा पद्धतीने वाचा। वाक्याला «आणि» हा शब्द लागत असेल तर तुम्ही दोन्ही बांधत आहात, आणि कार्यपत्रकाला प्रत्येकाला अर्धी सेवा देणारा एक तडजोडीचा स्तंभ नव्हे तर दोन स्तंभ लागतात। ते वापरकर्त्याचे नाव घेते पण पत्ता तलाव नाही, किंवा उपसर्ग घेते पण पुढे पाठवण्याचे धोरण नाही, तर वाक्य अजून अपूर्ण आहे। शब्दरचना नोकरशाही वाटते, पण अन्यथा मदत कक्ष तिकिटातून उघड होणारी रचना पकडण्याची ही सर्वात स्वस्त जागा आहे।

प्रत्येक स्तराला नेमके एक काम द्या

L2TPv2 त्याच्या दोन टोकांमध्ये PPP सेशन वाहून नेते। PPP लिंक वाटाघाटी आणि ती वाटाघाटी झाल्यावर वापरकर्त्याचे प्रमाणीकरण चालवते; L2TP कोणतेही गुप्तलेखन जोडत नाही, म्हणून नुसते L2TP डेमॉन IPsec च्या सुरक्षा संबंधाचा एकही भाग अंमलात आणत नाही आणि तुम्ही आधीच विश्वास ठेवता अशा लिंकच्या आतच राहते।

GRE म्हणजे दोन पत्त्यांमधील आवेष्टन। तो जाळी स्तराचे पॅकेट तार्किक आच्छादनातून वाहून नेतो आणि स्वतःहून गोपनीयता किंवा प्रमाणित भागीदार ओळख यापैकी काहीही देत नाही। हा दोष नाही: शीर्षलेख साधा ठेवण्यासाठी रचला गेला आहे जेणेकरून पुढे पाठवण्याच्या हार्डवेअरवर प्रक्रिया स्वस्त राहील। परिणाम असा की GRE फक्त हे पॅकेट दोन पत्त्यांमध्ये कसे हलवायचे या प्रश्नाचे उत्तर देतो आणि दुसऱ्या कशाचेही नाही, आणि त्याला विचारायला हवा असलेला प्रश्न नेमका तोच आहे।

मग IPsec हा स्तर राहतो जो रहदारी निवडतो, भागीदारांचे प्रमाणीकरण करतो आणि संरक्षण करायला सांगितलेले गुप्तलेखन करतो। कोणती रहदारी संरक्षित करायची हे संरचनेचे ठरवणे आहे जे टोकांनी प्रत्यक्षात निर्माण केलेल्या आवेष्टनाशी जुळले पाहिजे, कारण GRE च्या बाह्य पत्त्यासाठी लिहिलेले धोरण आंतरिक उपसर्गांसाठी लिहिलेल्यापेक्षा वेगळे वागते। GRE तपशील भार, GRE शीर्षलेख आणि बाह्य वितरण प्रोटोकॉल दृश्यमानपणे वेगळे ठेवतो, आणि तुमच्या धोरणालाही तीच फारकत लागते।

संरचनेपूर्वी पॅकेटचा मार्ग लिहा

एक पॅकेट घ्या आणि जोडला जाणारा प्रत्येक शीर्षलेख जोडला जाण्याच्या क्रमाने यादी करा, आणि तो जोडणारे उपकरण नामनिर्देशित करा। डायल-इन वापरकर्त्यासाठी हे सहसा IPsec मधील L2TP मधील PPP असते; साइट आच्छादनासाठी हे IPsec मधील GRE मधील आंतरिक IP पॅकेट असते। दोन उपकरणे एकच शीर्षलेख जोडत असतील तर तुमच्याकडे पळवाट किंवा दुहेरी बोगदा आहे, आणि कितीही धोरण संपादन केले तरी ते सुधारणार नाही।

तीच यादी 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 वर याचा अर्थ बोगदा इंटरफेसपूर्वी स्थिती आणि धोरण नोंदी हटवणे; मार्गकावर, बोगद्यापूर्वी क्रिप्टो नकाशा किंवा प्रोफाइल नोंद काढणे।

पुन्हा बांधल्यावर, स्वीकृतीची चार निरीक्षणे एक एक करून पुन्हा करा: बाह्य पोहोच, स्थापित IPsec एकजूट, रचनेत समाविष्ट असेल तिथे स्थापित PPP सेशन, आणि खऱ्या गंतव्य पत्त्यापर्यंत आंतरिक पुढे पाठवणे। एक हिरवा दिवा उरलेल्या तिघांसाठी पुरावा नाही, आणि तोच फट हा उत्पादनात सर्वाधिक टिकणारा बिघाड — बोगदा वर आहे, गुप्तलेखित आहे, आणि काहीही पुढे पाठवत नाही कारण आंतरिक मार्ग कधीच जोडला गेला नाही।

भरलेले कार्यपत्रक उपकरणाच्या संरचनेच्या शेजारी ठेवा। तुम्ही भरू शकत नाही असा कोणताही स्तंभ म्हणजे काम नेमून न दिलेला स्तर, आणि काम नसलेला स्तर सहसा असा स्तर असतो जो रचनेत नसावा।