બૂટ વખતે 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 સર્વર વગરનું સરનામું એવી ટનલ બનાવે છે જે દરેક લિંક તપાસ પસાર કરે છે અને છતાં નામ ખોલી શકતું નથી.

ચાર તપાસો પુનર્નિર્માણ નોંધમાં લખો

ખાતાનું નામ, સેવા શરૂ કરવાનો આદેશ અને ઇન્ટરફેસનું નામ સાથે નોંધો, કારણ કે પુનર્નિર્મિત હોસ્ટ ખાતાનો ડેટા પુનઃસ્થાપિત કરે છે પણ ડીમન શરૂ કરતો ઓપરેટિંગ સિસ્ટમ હૂક પુનઃસ્થાપિત કરતું નથી. તે અલગ અલગ જગ્યાએ રહે છે અને સામાન્ય રીતે અલગ લોકો તેનો બેકઅપ લે છે.

ફ્લેગ ફરી લાગુ કરવાની એક લાઇન છે અને ભૂલી જવો સહેલો છે.

ક્રમ રાખો: ફ્લેગ, સેવા, સરનામું, રૂટ. વચ્ચેથી શરૂ થતી ચેકલિસ્ટ ઘણા આત્મવિશ્વાસપૂર્ણ ખોટા જવાબો આપે છે.