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

तीनों खंडों में से हर एक को और गंतव्य नेटवर्क के भीतर वापसी मार्ग को एक स्वामी दें। चार स्वामियों वाला मार्ग उनके बीच के अंतरालों में विफल होता है।