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 आणि स्थानिक ब्रिज एकाच हबसाठी वेगवेगळ्या रचना आहेत, आणि ज्या हबला दोन्ही हवेत त्या हबला वेगळी योजना हवी. जाणीवपूर्वक निवडा, का ते लिहा, मग पुढच्या व्यक्तीला चालू कॉन्फिगरेशनमधून उलट अभियांत्रिकी करावी लागणार नाही.