SoftEther स्थानिक ब्रिज की SecureNAT: कोणते चालू करावे

SoftEther Manager उघडा, आणि एखाद्या हबबद्दलचा पहिला खरा निर्णय चेकबॉक्स नसतो, तो टोपोलॉजीचा प्रश्न असतो। स्थानिक ब्रिज त्या हबला भौतिक अडॅप्टरशी जोडतो आणि विद्यमान विभागाला पत्ते देऊ देतो, तर SecureNAT हबला स्वतःचा आभासी राउटर, NAT आणि DHCP देतो। यांतील निवड पत्ते कुठून येतात आणि त्यांना कोणते उपकरण उत्तर देते हे बदलते। दोन्ही चालू करून एक जिंकेल अशी अपेक्षा करणे हा तो मार्ग आहे ज्यामुळे कार्यरत प्रयोगशाळा सपोर्ट थ्रेड होते।

तुम्ही खरोखर संपादित करत असलेल्या हबपासून सुरुवात करा

Manager सर्व्हर आणि हबचे वृक्ष दाखवतो, आणि डीफॉल्ट हब संरचीत करणे सोपे आहे जेव्हा क्लायंट वेगळ्या नावाच्या हबशी जोडले जातात। हबवर क्लिक करा, त्याचे नाव वाचा, आणि खाली सूचीबद्ध केलेली सत्रे तुम्ही सेवा देऊ इच्छित असलेले क्लायंट आहेत याची खात्री करा। ही एकच तपासणी प्रोटोकॉलवर लादल्या जाणाऱ्या बहुतेक गोंधळाला प्रतिबंध करते।

मग दूरच्या टोकाकडून क्लायंटला काय हवे आहे ते ठरवा। ब्रॉडकास्ट आणि LAN सेवांसह सामायिक इथरनेट वर्तन ब्रिजकडे निर्देश करते, लहान पत्ता-श्रेणीकडे राउटेड खाजगी प्रवेश SecureNAT कडे, आणि इंटरनेट एक्झिट हा राउटिंगचा निर्णय आहे जो दोन्ही रचना वाईटपणे पेलू शकतात।

काहीही क्लिक करण्यापूर्वी उत्तर लिहून ठेवा, कारण दोन्ही सेटिंग्ज परस्पर बदलता येत नाहीत आणि पूर्वस्थितीत आणणे निर्णय घेण्यापेक्षा जास्त वेळ घेते। दोन मिनिटांचे लेखन एका तासाचे पुन्हा जोडणे वाचवते।

स्थानिक ब्रिज पत्त्यांबाबत काय करतो

स्थानिक ब्रिज हबला भौतिक अडॅप्टरशी जोडतो, त्यामुळे हब त्या इथरनेट विभागाचा भाग होतो। क्लायंटला आधीच विभागाला सेवा देणाऱ्याकडून पत्ते मिळतात, आणि त्यांचा गेटवे विभागाचा राउटर असतो। क्लायंटच्या दृष्टीने तो कार्यालयीन LAN मध्ये सामील झाला आहे, त्याबरोबर येणाऱ्या सर्व पोहोच आणि सर्व उघडपणासह।

याचा अर्थ ब्रिजला योग्य ड्रायव्हर आधार असलेला खरा अडॅप्टर हवा, आणि प्रशासकाला तो विभाग वाढवण्याचा अधिकार असावा। VPN लॉगिन प्रमाणीकरण सिद्ध करते, उत्पादन VLAN वर होस्ट ठेवण्याचा हक्क नाही। ड्रायव्हरचे नाव तुम्ही हेतू असलेल्या अडॅप्टरशी जुळते का ते तपासा, कारण चुकीचा पोर्ट ब्रिज केल्यास विभाग लवकर बंद पडतो। अडॅप्टरची यादी रिकामी असल्यास किंवा ब्रिज अपयश नोंदवल्यास, कारण सामान्यतः ड्रायव्हर किंवा विशेषाधिकाराशी संबंधित असते, क्रिप्टोग्राफीशी नाही।

ग्राफिकल वृक्ष अस्पष्ट असताना कमांड लाइनवरून ब्रिज तक्ता वाचा। आउटपुट अडॅप्टरचे नाव सांगते, जे वृक्ष नेहमी करत नाही।

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

जोडलेल्या सत्रांसह रिकामी ब्रिज यादी उपयुक्त चित्र आहे: क्लायंट आभासी हबच्या आत आहेत आणि अजून काहीही त्याला विभागापर्यंत वाढवत नाही।

SecureNAT काय जोडतो आणि काय लपवतो

SecureNAT हबला आभासी राउटर, NAT कार्य आणि DHCP सेवा देतो, सर्व SoftEther प्रक्रियेच्या आत। क्लायंट आभासी DHCP श्रेणीतून पत्ते घेतात, आभासी राउटर डीफॉल्ट गेटवेसाठी उत्तर देतो, आणि बाहेर जाणाऱ्या रहदारीचे भाषांतर होते। कोणताही भौतिक अडॅप्टर सहभागी नाही, म्हणूनच एक NIC आणि स्विच संरचनेशिवाय होस्टवर हे चालते।

किंमत ही की आभासी पत्ते हबचे आहेत आणि दुसऱ्या कोणाचे नाहीत। कार्यालयीन LAN वरील यंत्र मदतीशिवाय क्लायंटच्या SecureNAT पत्त्याकडे राउट करू शकत नाही, आणि स्रोत पत्ते नोंदवणारे सर्व SoftEther होस्टचे भाषांतरित पत्ते पाहतात। तुमचे प्रवेश नियम किंवा ऑडिट ट्रेल क्लायंटच्या खऱ्या पत्त्यावर अवलंबून असल्यास तो तपशील नाही, रचनेतील बदल आहे। स्रोत-पत्ता नियम क्लायंटला कधी पाहील का हेही यामुळेच ठरते।

ते DHCP सर्व्हरही आहे। आधीच एक असलेल्या विभागावर ते चालवणे, किंवा त्या विभागाचे त्याच वेळी ब्रिज करणे, दोन उत्तरदाते आणि अनपेक्षित लीज तयार करते। पुस्तिका दोन्ही कार्ये स्वतंत्र पर्याय म्हणून पाहते याच कारणासाठी।

इतर काही सक्षम करण्यापूर्वी हब सध्या काय सेवा देत आहे ते तपासा। प्रत्येक आदेश हेतू असलेली नव्हे तर सध्याची स्थिती छापतो।

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

एक चालू करणे, दुसरे न तोडता

रचना निवडा, ती सक्षम करा, आणि दुसरी बंद ठेवा। ज्या हबवर ब्रिज आणि SecureNAT दोन्ही सक्रिय आहेत तो एकाच प्रश्नाची दोन संभाव्य उत्तरे असलेला हब आहे, आणि क्लायंट आधी येणाऱ्यावर विश्वास ठेवेल। एकाकडून दुसऱ्याकडे जाताना जुने कार्य बंद करा आणि क्लायंट पुन्हा जोडा, नवीन सेटिंग विद्यमान सत्रावर लागू होईल असे गृहीत धरण्याऐवजी।

बदल अशा क्रमाने करा की क्लायंट पूल LAN श्रेणीशी ओव्हरलॅप होणार नाही। ओव्हरलॅप होणारी उपजाळे जोडली जाऊन नंतर कुठेही न पोहोचणाऱ्या बोगद्याचे दुसरे सर्वात सामान्य कारण आहेत, आणि दोन्ही पत्ता योजना शेजारी ठेवून तुलना करेपर्यंत ती अदृश्य असतात।

मग क्लायंटकडून पुन्हा जोडा आणि त्याला काय मिळाले ते वाचा, कारण हबचे सत्राकडे पाहणे क्लायंटच्या स्वतःच्या नेटवर्ककडे पाहण्यासारखे नाही। नवीन लीज भाग पाडण्याचा एकमेव विश्वासार्ह मार्ग म्हणजे पुन्हा जोडणे।

क्लायंटवर गेटवे आणि रिझॉल्व्हर तपासा

यशस्वी प्रमाणीकरण सांगते की क्रेडेन्शियल्स चालतात आणि हबने सत्र स्वीकारले। क्लायंट कुठे पोहोचू शकतो हे ते सांगत नाही, कारण ते त्याला मिळालेल्या पत्त्या, मास्क, गेटवे आणि DNS सर्व्हरवर अवलंबून असते। सर्व्हर सेटिंगला पुन्हा हात लावण्यापूर्वी क्लायंटवर ती चार मूल्ये वाचा।

Windows वर अडॅप्टर तपशील लीज आणि रिझॉल्व्हर दाखवतो, आणि रूट तक्ता बोगदा खरोखर डीफॉल्ट मार्ग आहे का हे दाखवतो।

ipconfig /all
route print -4
nslookup intranet.corp.internal

Linux क्लायंटवर तीच माहिती पत्ता, रूट आणि रिझॉल्व्हर फाइलांमधून येते। डीफॉल्ट रूट हे ते मूल्य आहे जे रहदारी बोगद्यातून बाहेर पडते का हे ठरवते। गेटवे कार्यालयीन राउटरकडे दाखवत असेल आणि बोगदा रहदारी वाहून नेण्याची अपेक्षा करत असेल, तर टोपोलॉजी नावाने ब्रिज केलेली आणि प्रत्यक्षात तुटलेली आहे। आधी पत्ता-स्रोत दुरुस्त करा, मग अनुप्रयोग पुन्हा तपासा, आणि त्यानंतरच दुसरी मोड बदलण्याचा विचार करा।