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 और स्थानीय ब्रिज एक ही हब के लिए अलग डिज़ाइन हैं, और जिस हब को दोनों चाहिए, उसे अलग योजना चाहिए। सचेत होकर चुनें, कारण लिखें, तो अगले व्यक्ति को चालू कॉन्फ़िगरेशन से इसे उलटा इंजीनियर नहीं करना पड़ेगा।