बूट पर 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 सर्वर के बिना पता ऐसी टनल बनाता है जो हर लिंक जाँच पास करती है और फिर भी नाम नहीं खोल सकती।

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

खाते का नाम, सेवा शुरू करने का आदेश और इंटरफ़ेस का नाम एक साथ दर्ज करें, क्योंकि पुनर्निर्मित होस्ट खाते का डेटा बहाल करता है पर वह ऑपरेटिंग सिस्टम हुक नहीं जो डेमॉन को शुरू करता है। वे अलग-अलग जगहों पर रहते हैं और आमतौर पर अलग-अलग लोग उनका बैकअप लेते हैं।

फ़्लैग फिर से लागू करने की एक पंक्ति है और भूलना आसान है।

क्रम बनाए रखें: फ़्लैग, सेवा, पता, रूट। बीच से शुरू होने वाली जाँच-सूची बहुत सारे आत्मविश्वासी गलत उत्तर देती है।