NAT VPN सर्भरमा कि राउटरमा? दुवै काम गर्न सक्छन्

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

भ्रम: क्लाइन्ट मार्गले नै निकास बनाउँछ

जबरजस्ती सुरुङ गर्नु क्लाइन्ट-पक्षको नीति हो: यसले ट्राफिक भौतिक एडाप्टरमा होइन, VPN एडाप्टरमा जाने निर्णय गर्छ। Microsoft को 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 क्लाइन्टसँग मार्ग, वैध सार्वजनिक स्रोत वा सुरुङ खस्दा तिनलाई रोक्ने नीति छ कि छैन भन्नेबारे केही भन्दैन। यसलाई नभनेर छोड्नु भनेको आधा क्लाइन्टले शान्त रूपमा गेटवे छल्छन् र बाँकी आधा काम गर्छन् भन्ने हो।

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