NAT VPN सर्वर पर या राउटर पर? दोनों काम कर सकते हैं

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

मिथक: क्लाइंट रूट ही निकास बनाता है

फ़ोर्स टनलिंग क्लाइंट पक्ष की नीति है: यह तय करती है कि ट्रैफ़िक भौतिक एडाप्टर की बजाय VPN एडाप्टर पर जाएगा। माइक्रोसॉफ़्ट का VPN रूटिंग दस्तावेज़ उस विभाजन और फ़ोर्स व्यवहार का वर्णन करता है, और यह क्लाइंट की रूट तालिका के बारे में कथन है, सर्वर के फ़ॉरवर्डिंग नियमों के बारे में नहीं। क्लाइंट की दृष्टि से सुरंग वह जगह है जहाँ इंटरनेट रहता है; गेटवे की दृष्टि से एक पैकेट ऐसे पते से आया जिसके बारे में ऊपर किसी ने कभी नहीं सुना। कोई भी पक्ष अकेले में गलत कॉन्फ़िगर नहीं है, और इसीलिए लैपटॉप पर बैठे व्यक्ति को यह विफलता टूटे सर्वर जैसी लगती है।

यही असंगति वह पूरी समस्या है जिसे इस लेख का बाकी हिस्सा हल करता है। कुछ ऐसा होना चाहिए जो क्लाइंट के निजी पते को वापसी योग्य बनाए, और चुनाव यह है कि कहाँ।

पहले उत्तर का मार्ग बनाएँ

किसी भी सेटिंग को छूने से पहले मार्ग को वास्तविक पतों के साथ लिखें, और उस पर दो संभावित अनुवाद बिंदु चिह्नित करें। यह प्रयोगशाला 10.70.0.0/24 का VPN पूल उपयोग करती है जिसमें एक क्लाइंट 10.70.0.37 पर, सर्वर का LAN पता 172.16.40.10, राउटर 172.16.40.1 पर और सार्वजनिक निकास 203.0.113.40 पर है।

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

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

विकल्प A: VPN सर्वर पर अनुवाद

यहाँ सर्वर पैकेट राउटर को सौंपने से पहले क्लाइंट के स्रोत का अपने LAN पते में अनुवाद करता है, और राउटर बाहर जाते समय अपना सामान्य अनुवाद लागू करता है। उत्तर पर राउटर का मैपिंग सर्वर का पता बहाल करता है और सर्वर का मैपिंग क्लाइंट का पता बहाल करता है। श्रेणी में दो स्टेटफुल अनुवाद सामान्य और व्यवहार्य हैं, बशर्ते दोनों दर्ज हों; राउटर को कभी पूल तक रूट की आवश्यकता नहीं होती, और यही इस व्यवस्था का आकर्षण है।

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

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

विकल्प B: पूल को राउटर तक ले जाना

दूसरी व्यवस्था में सर्वर क्लाइंट का असली स्रोत पता आगे भेजता है, और राउटर उसका अनुवाद करता है। इससे किनारे पर क्लाइंट पूल दिखाई देता रहता है, जो तब मदद करता है जब राउटर ही ट्रैफ़िक नीति, लॉगिंग या निरीक्षण की जगह हो। इसका यह भी अर्थ है कि राउटर को 10.70.0.0/24 के लिए 172.16.40.10 की ओर इशारा करने वाला वापसी रूट चाहिए, साथ ही एक इंटरनेट नीति जो वास्तव में उस प्रीफ़िक्स को शामिल करे; LAN सबनेट के लिए लिखा नियम चुपचाप पूल तक नहीं फैलता।

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

DNS, IPv6 और स्वीकृति को स्पष्ट करें

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

IPv6 को डिज़ाइन में अपना अनुच्छेद चाहिए। काम करने वाला IPv4 अनुवाद इस बारे में कुछ नहीं कहता कि IPv6 क्लाइंट के पास रूट, वैध सार्वजनिक स्रोत या सुरंग गिरने पर उन्हें अवरुद्ध करने वाली नीति है या नहीं। इसे अनकहा छोड़ने का अर्थ है कि आधे क्लाइंट चुपचाप गेटवे को बाईपास करते हैं जबकि बाकी आधे काम करते हैं।

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