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 ग्राहकमा त्यही जानकारी ठेगाना, रुट र रिजोल्भर फाइलहरूबाट आउँछ। पूर्वनिर्धारित रुट त्यो मान हो जसले ट्राफिक टनेलबाट बाहिर जान्छ कि जाँदैन निर्धारण गर्छ। यदि गेटवेले कार्यालयको राउटरतिर संकेत गर्छ र टनेलले ट्राफिक बोक्ने अपेक्षा गर्छ भने, टोपोलोजी नाममा ब्रिज भएको र व्यवहारमा टुटेको छ। पहिले ठेगाना-स्रोत सुधार्नुहोस्, त्यसपछि अनुप्रयोग फेरि जाँच्नुहोस्, र त्यसपछि मात्र अर्को मोड बदल्ने विचार गर्नुहोस्।