साइट-से-साइट VPN के अंदर NAT कब अपनी जगह बनाता है

दो साइटें दोनों एक ही निजी रेंज का उपयोग करती हैं, और टनल ऊपर आ जाती है जबकि उससे होकर कुछ भी उपयोगी नहीं गुजरता। अनुवाद ही सामान्य उत्तर है, और यह वास्तविक उत्तर है: दूर के पक्ष को अलग रेंज दिखाना किसी ओवरलैप या ऐसे रिटर्न पथ को हल कर सकता है जिसे दूसरा नेटवर्क रूट नहीं कर सकता। जो हिस्सा छूट जाता है वह यह है कि अनुवाद उन पतों को बदल देता है जो हर बाद का निर्णय देखता है। इसे लिखित मैपिंग वाला प्रलेखित डिज़ाइन निर्णय मानें, ऐसा नियम नहीं जो ping सफल होने तक जोड़ा जाता रहे।

तय करें कि कौन-सा पता फिर से लिखा जाता है

स्रोत अनुवाद बदलता है कि दूर की सेवा और उसके लॉग किसे क्लाइंट के रूप में देखते हैं, इसलिए शाखा होस्ट आते ही गेटवे पता बन जाता है। गंतव्य या प्रीफ़िक्स अनुवाद इसके बजाय दूर के संसाधन के लिए वैकल्पिक पता प्रस्तुत करता है। कुछ परिनियोजनों को दो अन्यथा समान नेटवर्क अलग करने के लिए दोनों तरफ़ समन्वित अनुवाद चाहिए, और अधिकांश भ्रम इसी संयोजन से शुरू होता है।

अनुवाद से पहले स्रोत, अनुप्रयोग जिस नाम से गंतव्य कहता है, और वह पता-युग्म लिखें जिससे हर गेटवे मेल खाता है। तीन कॉलम पर्याप्त हैं, और तीसरा कॉलम वही है जिसे लोग छोड़ देते हैं।

सिलेक्टर का क्रम भी मायने रखता है। IPsec नीति का चयन और अनुवाद निर्धारित चरणों में होते हैं, इसलिए अनुवाद-पूर्व पतों के लिए लिखा गया सिलेक्टर आपके अनुमानित चरण पर पैकेट से कभी नहीं मिल सकता। जो नीति स्थापित है उसे जाँचें, उस नीति को नहीं जिसे स्थापित करने का इरादा था, क्योंकि दोनों ठीक तब अलग होती हैं जब एक घटक नियम स्वीकार करता है और दूसरा उसे अनदेखा कर देता है:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

पेलोड और रिटर्न पथ का पालन करें

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

जो प्रोटोकॉल अपने पेलोड के अंदर पते ले जाते हैं उन्हें अलग योजना चाहिए, क्योंकि बाहरी हेडर फिर से लिखने से भीतरी संदर्भ नहीं छूता। सक्रिय FTP, SIP और कुछ दूरस्थ-पहुँच उत्पाद क्लासिक मामले हैं, और इन्हें अनदेखा करने वाला डिज़ाइन वेब ट्रैफ़िक के लिए काम करेगा और उस अनुप्रयोग के लिए विफल होगा जो मायने रखता था।

रिटर्न ट्रैफ़िक स्टेटफुल मैपिंग पर निर्भर है। गेटवे फेलओवर उस स्थिति को खो सकता है, असममित रूटिंग उसे बायपास कर सकती है, और पुनःआरंभ उसे मिटा सकता है जबकि दूर के पक्ष पर सत्र खुले रहते हैं। इसीलिए गंतव्य तक पहुँचने वाला अनुरोध और पूरा होने वाला सत्र दो अलग स्वीकृति परिणाम हैं।

साइट के पुनःक्रमांकन के विरुद्ध इसे तौलें

एक टकराव वाली साइट का पुनःक्रमांकन मैपिंग को पूरी तरह हटा देता है और ऐसी पता योजना छोड़ता है जिसे अनुवाद तालिकाओं के बिना पढ़ा जा सकता है। यह परिचालन रूप से महँगा है: DNS रिकॉर्ड, स्थिर आवंटन, फ़ायरवॉल नियम और हर प्रलेखित पता एक साथ बदलना पड़ता है। लागत एक बार, नियोजित विंडो में, स्पष्ट अंतिम स्थिति के साथ आती है। आप जो खरीदते हैं वह वर्षों बाद लुकअप तालिका के बिना पैकेट कैप्चर पढ़ने की क्षमता है।

अनुवाद अधिकांश स्थानीय परिवर्तनों से बचता है और ऐसी मैपिंग बनाता है जिसे DNS, प्रलेखन और समस्या-निवारण में हमेशा बनाए रखना पड़ता है। लागत लगातार आती है, हर भावी इंजीनियर के रूप में, जिसे सीखना पड़ता है कि एक प्रीफ़िक्स टनल के अंदर कुछ और मतलब रखता है।

अस्थायी कनेक्शन या ऐसे साझेदार नेटवर्क के लिए जिसे आप नियंत्रित नहीं करते, निरंतर लागत आमतौर पर उचित होती है। जिन दो साइटों के आप मालिक हैं और वर्षों तक रहेंगे, उनके लिए माइग्रेशन की ईमानदारी से गणना करने पर पुनःक्रमांकन अक्सर सस्ता निर्णय होता है।

वास्तविक सत्र से दोनों दिशाएँ सिद्ध करें

एकल प्रोब के बजाय अनुप्रयोग सत्र का परीक्षण करें। सफल इको अनुरोध सिद्ध करता है कि एक प्रोटोकॉल की एक दिशा काम करती है, और यह ऐसे रिटर्न पथ के साथ पूरी तरह संगत है जो स्टेटफुल किसी भी चीज़ के लिए विफल होता है। उसी सेवा का उपयोग करें जिसने डिज़ाइन को प्रेरित किया, और दूर के सिरे पर उसका लॉग पढ़कर देखें कि उसने कौन-सा स्रोत पता दर्ज किया।

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

फिर पुष्टि करें कि मैपिंग के पार केवल इच्छित सेवाएँ ही पहुँच में हैं। अनुवाद पता-निर्धारण बदलता है और प्राधिकरण के लिए कुछ नहीं करता, इसलिए फ़ायरवॉल नीति ही तय करती है कि क्या अनुमत है। जो डिज़ाइन अस्पष्ट अनूदित प्रीफ़िक्स को अपने एक्सेस नियंत्रण के रूप में भरोसा करता है, उसके पास कोई एक्सेस नियंत्रण ही नहीं है।

मैपिंग, परीक्षित सत्र और हर पक्ष द्वारा देखे गए पते दर्ज करें। इस टनल को डीबग करने वाले अगले व्यक्ति को कॉन्फ़िगरेशन फ़ाइल से अधिक उन तीन तथ्यों की ज़रूरत है।