SoftEther SecureNAT: DHCP र NAT दुई छुट्टाछुट्टै निर्णय हुन्

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

एउटा चेकबक्सपछाडि दुई सेवा

भर्चुअल DHCP पक्षले कन्फिगरेसन प्रश्नको जवाफ दिन्छ: यो क्लाइन्टले यो भर्चुअल हबभित्र कुन सेटिङ पाउँछ। भर्चुअल NAT पक्षले फर्वार्डिङ प्रश्नको जवाफ दिन्छ: क्लाइन्टले हबबाहिरको ठेगानामा प्याकेट पठाउँदा सर्भरले त्यसको अनुवाद गरेर पठाउँछ कि पठाउँदैन। पहिलो हबका लागि स्थानीय हो र माथिल्लो नेटवर्क चाहिँदैन। दोस्रो पूर्ण रूपमा होस्टमा निर्भर छ।

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

निर्णय 1: ठेगाना कसले दिन्छ

भर्चुअल DHCP सक्रिय छ भने, क्लाइन्टहरूले तपाईंले कन्फिगर गरेको पूलमा लिज पाउनुपर्छ, गेटवेका रूपमा भर्चुअल होस्ट इन्टरफेस र रिजोल्भरका रूपमा तपाईंले दिएको। क्लाइन्टको स्ट्याटस टेक्स्ट होइन, लिज जाँच्नुहोस्, किनकि «जोडिएको» ले टनेल वर्णन गर्छ, ठेगाना बाँडफाँट होइन:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

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

ओभरल्याप हुने पूल पनि यहीँ पर्छन्। भर्चुअल DHCP पूल होस्टको LAN सबनेट वा अर्को हबको पूलसँग ओभरल्याप भयो भने क्लाइन्टले अस्पष्ट रूपमा रुट हुने ठेगाना पाउँछ, र पछिको हरेक परीक्षण अनिर्णायक हुन्छ।

निर्णय 2: भर्चुअल गेटवेभन्दा पर कसले पठाउँछ

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

दोस्रो निर्णयलाई हब छोड्नैपर्ने कुराले परीक्षण गर्नुहोस्, हबभित्रको कुराले होइन। भर्चुअल गेटवेमा पिङ गर्नुले पहिलो कडी मात्र प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

नाम रिजोल्युसन काम गर्छ तर सार्वजनिक ठेगानासँगको जडान असफल हुन्छ भने तपाईं DHCP मा होइन, फर्वार्डिङ शृंखलामा हुनुहुन्छ। दुवै असफल भए पहिले रिजोल्भर जाँच्नुहोस्, किनकि पुग्न नसकिने आन्तरिक ठेगानाका रूपमा पठाइएको रिजोल्भरले काम गर्ने मार्गलाई पूर्ण रूपमा भाँचिएको देखाउँछ।

SecureNAT को फर्वार्डिङ सर्भर प्रक्रियाले लागू गर्छ, ब्रिजसँग प्रयोग गर्ने कर्नेल फर्वार्डिङ मार्गले होइन। यो सुविधाजनक छ र ब्रिजिङभन्दा ढिलो, र यसको अर्थ होस्टका आफ्नै फायरवाल नियम र रुटिङ निर्णयहरू अनुवादित ट्राफिकमा अझै लागू हुन्छन्। भर्चुअल NAT ले होस्टको नीति बाइपास गर्दैन; त्यसैको प्रयोग गर्छ।

होस्टको आफ्नै मार्ग तेस्रो कुरा हो

माथिको सबैले सर्भर होस्ट गन्तव्यमा पुग्न सक्छ भनी मान्छ। काम गर्ने माथिल्लो मार्ग नभएको, कडा बाहिर जाने नीति भएको, वा आफूसँग नभएको ठेगाना परिवार भएको होस्ट हब कन्फिगरेसन जतिसुकै सही भए पनि दोस्रो निर्णयमा असफल हुन्छ। होस्टलाई छुट्टै, टनेलबाहिर जाँच्नुहोस्, यसको असफलताको दोष SoftEtherलाई दिनुअघि।

SecureNAT सर्भरसँग जोडिएको हरेक नेटवर्कमा पुग्ने अधिकार पनि होइन। यसले आफूसम्म पुग्ने ट्राफिकको अनुवाद र फर्वार्डिङ गर्छ; होस्ट केसम्म पुग्न सक्छ भन्ने निर्णय अझै होस्टको फायरवाल र रुटिङको काम हो, र पहुँच दिन टनेलमा भर पर्ने डिजाइन धेरै दिनबाट एक नराम्रो नियम मात्र टाढा छ।

ठेगाना परिवारले आफ्नै जाँच पाउनुपर्छ। काम गर्ने IPv4 DHCP उदाहरणले तपाईंको बिल्डमा हरेक IPv6 क्षमता छ भनी प्रमाणित गर्दैन, त्यसैले दोहोरो स्ट्याक व्यवहारको वाचा गर्नुअघि तपाईंले साँच्चै चलाउने संस्करणको म्यानुअल पढ्नुहोस्। म्यानुअलको SecureNAT खण्ड ले हालको रिलिजका लागि भर्चुअल NAT र DHCP कार्यहरू समेट्छ।

हरेक निर्णयलाई त्यसैको परीक्षणले प्रमाणित गर्नुहोस्

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

त्यसपछि विभाजन डिजाइन नोटमा लेख्नुहोस्: कुन कम्पोनेन्टले ठेगाना दिन्छ, कुनले फर्वार्ड गर्छ, र ट्राफिक कुन होस्ट इन्टरफेसबाट बाहिर जान्छ। रिस्टार्टले व्यवहार बदल्दा त्यो नोटले तीनमध्ये कुन हेर्ने भनी बताउँछ, सबै रिस्टार्ट गरेर लक्षण सर्ला भनी आशा गर्नुको सट्टा।

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