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

तीन खण्डमध्ये प्रत्येकलाई र गन्तव्य नेटवर्कभित्रको फर्किने रुटलाई मालिक तोक्नुहोस्। चार मालिक भएको मार्ग तिनीबीचको खाली ठाउँमा असफल हुन्छ।