యంత్రాన్ని రీబూట్ చేయడం దాన్ని టన్నెల్ కింద ఉన్న స్థితిలోనే తిరిగి నెట్వర్క్లో వదిలివేస్తుంది. 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 సర్వర్ లేని చిరునామా ప్రతి లింక్ తనిఖీని దాటి ఇంకా పేరు తెరవలేని టన్నెల్ను సృష్టిస్తుంది.

నాలుగు తనిఖీలను పునర్నిర్మాణ గమనికల్లో రాయండి

ఖాతా పేరు, సేవ ప్రారంభించే ఆదేశం మరియు ఇంటర్ఫేస్ పేరును కలిసి నమోదు చేయండి, ఎందుకంటే పునర్నిర్మించిన హోస్ట్ ఖాతా డేటాను పునరుద్ధరిస్తుంది కానీ డీమన్ను ప్రారంభించే ఆపరేటింగ్ సిస్టమ్ హుక్ను పునరుద్ధరించదు. అవి వేర్వేరు ప్రదేశాల్లో నివసిస్తాయి, సాధారణంగా వేర్వేరు వ్యక్తులు వాటిని బ్యాకప్ చేస్తారు.

జెండా మళ్లీ వర్తింపజేయాల్సిన ఒక లైన్, మరచిపోవడం సులభం.

క్రమాన్ని నిలబెట్టుకోండి: జెండా, సేవ, చిరునామా, మార్గం. మధ్య నుండి ప్రారంభమయ్యే తనిఖీ జాబితా చాలా ఆత్మవిశ్వాసంతో కూడిన తప్పు సమాధానాలను ఇస్తుంది.

సంబంధిత వ్యాసాలు