बूट होताना 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 सर्व्हरशिवाय पत्ता अशी टनेल तयार करतो जी प्रत्येक लिंक तपासणी पास होते आणि तरीही नाव उघडू शकत नाही।

चारही तपासण्या पुनर्निर्माण टिपांमध्ये लिहा

खात्याचे नाव, सेवा सुरू करण्याचा आदेश आणि इंटरफेसचे नाव एकत्र नोंदवा, कारण पुनर्निर्मित होस्ट खात्याचा डेटा पुनर्संचयित करतो पण डीमन सुरू करणारा ऑपरेटिंग सिस्टम हुक पुनर्संचयित करत नाही। ते वेगवेगळ्या ठिकाणी राहतात आणि सामान्यतः वेगवेगळे लोक त्यांचा बॅकअप घेतात।

फ्लॅग पुन्हा लागू करण्याची एक ओळ आहे आणि विसरणे सोपे आहे।

क्रम ठेवा: फ्लॅग, सेवा, पत्ता, मार्ग। मध्यापासून सुरू होणारी तपासणी यादी भरपूर आत्मविश्वासपूर्ण चुकीची उत्तरे देते।