बुटमा SoftEther क्लाइन्ट: AccountStartupSet र डेमोनको क्रम

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

खाता स्वचालित सुरुवातका लागि चिन्ह लगाइएको छ भनी पुष्टि गर्नुहोस्

झन्डा क्लाइन्टको आफ्नै कन्फिगरेसनभित्रको खाता रेकर्डमा बस्छ, त्यसैले क्लाइन्ट पुनः स्थापना गर्दा वा खाली डाइरेक्टरी पुनर्स्थापना गर्दा त्यो मेटिन्छ। अरू केही बदल्नु अघि व्यवस्थापन कन्सोल खोल्नुहोस् र खाताहरूको सूची हेर्नुहोस्।

cd /opt/softether/vpnclient
./vpncmd

VPN क्लाइन्ट व्यवस्थापनका लागि 2 छान्नुहोस् र Enter थिचेर स्थानीय सर्भर स्वीकार गर्नुहोस्।

AccountStartupSet
office-hub
exit

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

सेवा सुरु हुन्छ कि हुँदैन, र पर्याप्त चाँडो हुन्छ कि हुँदैन भनी पुष्टि गर्नुहोस्

Linux मा क्लाइन्ट आफ्नै डाइरेक्टरीबाट डेमोनका रूपमा चल्छ, र बुटको कुनै पनि चरणले खाता प्रयोग गर्न खोज्नुअघि यो चलिरहेको हुनुपर्छ। डाइरेक्टरी बदलेर यसलाई सुरु गर्ने छोटो हुक अझै rc.local चलाउने प्रणालीमा पर्याप्त हुन्छ।

cd /opt/softether/vpnclient
./vpnclient start

जहाँ rc.local छैन, त्यहाँ स्पष्ट WorkingDirectory र रिस्टार्ट नीतिसहितको systemd युनिट लेख्नुहोस्। बाइनरीले आफ्नो कन्फिगरेसन सुरु हुने ठाउँको सापेक्षतामा समाधान गर्छ, त्यसैले त्यो सेटिङ नभएको युनिट सफलतापूर्वक सुरु भएर केही पनि पढ्न सक्दैन। क्रम समस्याको दोस्रो आधा हो: डेमोन सुन्न थाल्नुअघि चल्ने जडान प्रयास बेलाबेलामा असफल हुन्छ, जसको निदान निरन्तर असफलताभन्दा धेरै गाह्रो हुन्छ। रिस्टार्ट नीतिले तेस्रो अवस्था समेट्छ, जहाँ डेमोन घण्टौंपछि शान्त रूपमा मर्छ।

अघिल्लो बुटले छोडेको pid फाइलमा भरोसा गर्नुको सट्टा प्रक्रियाहरूको सूची जाँच्नुहोस्।

एडाप्टरले ठेगाना पायो भनी पुष्टि गर्नुहोस्

खाता जोडिएपछि क्लाइन्टले भर्चुअल एडाप्टर देखाउँछ र एडाप्टरलाई अझै ठेगाना चाहिन्छ। SecureNAT चलाउने हबले सामान्यतया DHCP लाई जवाफ दिन्छ; भौतिक LAN मा ब्रिज गरिएको हबले यसको सट्टा त्यो LAN को सर्भरले जवाफ दिने अपेक्षा गर्छ।

ip -brief address
dhclient vpn_vpn1

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

ठेगानाविनाको एडाप्टर सूचीको सबैभन्दा शान्त असफलता हो, किनकि खाताले अझै जोडिएको भनी रिपोर्ट गर्छ।

मार्ग तपाईंले सोचेको ठाउँमा जान्छ भनी पुष्टि गर्नुहोस्

स्वस्थ लिङ्क र मान्य ठेगाना हुँदा पनि ट्राफिक असफल हुन सक्छ। हबको सबनेटभित्रको गन्तव्यका लागि कर्नेलले कुन इन्टरफेस प्रयोग गर्छ भनी सोध्नुहोस्, त्यसपछि त्यो उत्तरलाई टनेलसँग तुलना गर्नुहोस्।

ip route get 10.10.20.15

हबको दायरासँग ओभरल्याप हुने स्थानीय सबनेट जित्छ, किनकि त्यसको मार्ग बढी विशिष्ट छ र पहिले नै स्थापित छ।

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

चारै जाँच पुनर्निर्माण टिप्पणीमा लेख्नुहोस्

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

झन्डा फेरि लागू गर्ने एक लाइन हो र बिर्सन सजिलो छ।

क्रम कायम राख्नुहोस्: झन्डा, सेवा, ठेगाना, मार्ग। बीचबाट सुरु हुने जाँचसूचीले धेरै आत्मविश्वासी गलत उत्तर दिन्छ।