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

प्रोटोकलको सूचीबाट होइन, सत्रबाट सुरु गर्नुहोस्

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

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

प्रत्येक तहलाई ठ्याक्कै एउटा काम दिनुहोस्

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

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

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

LayerIts one jobWhat it never does
PPPLink negotiation, optional user authentication, address assignmentProtect traffic between gateways
L2TPv2Carry the PPP session between two endpointsEncrypt or authenticate peers
GREEncapsulate network-layer packets between two addressesHide or authenticate the payload
IPsecAuthenticate peers and encrypt selected trafficCarry a dial-in user session by itself

कन्फिगरेसनअघि प्याकेटको बाटो लेख्नुहोस्

एउटा प्याकेट लिनुहोस् र थपिने प्रत्येक शीर्षलेख थपिने क्रममा सूचीबद्ध गर्नुहोस्, र त्यो थप्ने उपकरणको नाम दिनुहोस्। डायल-इन प्रयोगकर्ताका लागि यो सामान्यतया 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 सत्र, र वास्तविक गन्तव्य ठेगानामा आन्तरिक अगाडि पठाउने। एउटा हरियो बत्ती बाँकी तीनका लागि प्रमाण होइन, र त्यही खाडल उत्पादनमा सबैभन्दा लामो टिक्ने असफलता हो — सुरुङ उठेको, गुप्तलेखित, र केही पनि अगाडि नपठाउने, किनकि आन्तरिक मार्ग कहिल्यै थपिएको थिएन।

भरिएको कार्यपत्र उपकरणको कन्फिगरेसनको छेउमा राख्नुहोस्। तपाईं भर्न नसक्ने जुनसुकै स्तम्भ काम तोकिएको नभएको तह हो, र काम नभएको तह सामान्यतया स्ट्याकमा हुनु नहुने तह हो।

सम्बन्धित लेखहरू