VPN साइट विस्तार: गेटवेच्या पलीकडे परतीच्या मार्गाचा अनुसरा करा

शाखेचा रहदारी अशा गेटवेवर संपतो ज्याच्या LAN मध्ये तुम्हाला पोहोचायला सांगितलेले ॲप्लिकेशन नाही। सर्व्हर दुसऱ्या डेटा सेंटरमध्ये आहे, VPN ने कधीही कॉन्फिगर न केलेल्या अंतर्गत दुव्याच्या पलीकडे। जवळच्या गेटवेवर आणखी एक प्रीफिक्स जोडल्याने त्या प्रकरणात काहीही होत नाही, कारण दूरचा गेटवे शेवटचा राउटर नसून एन्क्रिप्शनचा शेवटचा बिंदू आहे। मार्गाला पुढचा मार्ग, दूरच्या सुरक्षा सीमेवर प्रवेश आणि गंतव्याच्या स्वतःच्या नेटवर्कमध्ये परतीचा निर्णय लागतो।

दूरचा गेटवे एन्क्रिप्शनचा शेवटचा बिंदू आहे

गेटवे-ते-गेटवे IPsec दोन सुरक्षा उपकरणांमधील रहदारीचे रक्षण करते, आणि अंतर्गत पत्ते त्या विभागातून एन्क्रिप्ट होऊन जातात। दूरच्या गेटवेच्या पलीकडे सामान्य राउटिंग ताबा घेते, डेटा सेंटरांमध्ये असलेल्या कोणत्याही धोरणासह। त्यामुळे संरक्षित विभाग प्रवासाचा एक भाग व्यापतो, उर्वरित नाही। उलट गृहीत धरणे म्हणजे निरोगी टनेल आणि अगम्य ॲप्लिकेशनसह रचना संपण्याचा मार्ग।

मार्ग तीन तुकड्यांत काढा: शाखेपासून जवळच्या गेटवेपर्यंत, जवळच्यापासून दूरच्यापर्यंत, दूरच्या गेटवेपासून ॲप्लिकेशनपर्यंत। प्रत्येक तुकड्याचा स्वतःचा मालक आणि स्वतःची अपयश पद्धत आहे।

टनेल धोरणाच्या दोन्ही दिशा वाचा

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

स्रोत आणि गंतव्य साइट नावांऐवजी पत्ते म्हणून लिहा। येथील अस्पष्टता नंतर गोंधळात टाकणारी असममिती म्हणून परत येते।

पुढचा मार्ग जोडा आणि प्रवेशाची पुष्टी करा

दूरच्या गेटवेला ॲप्लिकेशन सबनेटकडे मार्ग लागतो, आणि त्यांच्यातील प्रत्येक राउटरने शाखेच्या स्रोताला परवानगी दिली पाहिजे। आकृती जे दावा करते ते नव्हे, दूरच्या गेटवेकडे प्रत्यक्षात काय आहे हे तपासा।

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

पहिला आदेश त्या स्रोतासाठी दूरचा गेटवे निवडणारा निर्गम इंटरफेस आणि पुढचा हॉप सांगतो, हा असा प्रश्न आहे ज्याचे उत्तर सामान्य राउटिंग तक्ता देऊ शकत नाही। ट्रेस दाखवतो की पॅकेट कुठे थांबतात, आणि दूरच्या गेटवेनंतरचा खंड टनेलऐवजी अंतर्गत ट्रान्झिटकडे निर्देश करतो। मार्ग असूनही रहदारी गायब होत असेल, तर दूरच्या गेटवेवर कॅप्चर करा आणि येणारा स्रोत पत्ता वाचा, कारण अनपेक्षित पत्ता म्हणजे कुठेतरी नियोजन न करता भाषांतर होत आहे। येथील सर्व पत्ते प्लेसहोल्डर आहेत, म्हणून खरे शाखा, ट्रान्झिट आणि ॲप्लिकेशन सबनेट ठेवा।

शाखेतून चाचणी करा, नंतर जुना मार्ग पुन्हा चाचणी करा

स्वीकृतीसाठी दूरच्या गेटवेकडून तपासणी नव्हे, खरा स्रोत लागतो। शाखेच्या होस्टवरून तपासणी चालवा आणि पूर्वी काम करणारी गंतव्ये त्याच चाचणीत ठेवा।

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

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

तीनही विभागांपैकी प्रत्येकाला आणि गंतव्य नेटवर्कमधील परतीच्या मार्गाला मालक नेमा। चार मालक असलेला मार्ग त्यांच्यातील अंतरांमध्ये अपयशी ठरतो।