సోమవారం ఉదయం: శుక్రవారం పైకి వచ్చిన సొరంగం పోయింది, ఇంటర్‌ఫేస్ ఇంకా జాబితాలో ఉంది, మరియు ఎవరైనా దీన్ని గమనించారని జర్నల్‌లో ఏమీ లేదు. హోస్ట్ ఆన్‌లైన్‌లో ఉంది, డాష్‌బోర్డ్ ఆకుపచ్చగా ఉంది, మరియు వారాంతంలో అది పంపినవన్నీ భౌతిక ఇంటర్‌ఫేస్ ద్వారానే బయటకు వెళ్లాయి. ఇక్కడ రెండు స్వతంత్ర నిర్ణయాలు లేవు: ఒకటి క్లయింట్ ప్రక్రియ తాత్కాలిక వైఫల్యం నుంచి బయటపడుతుందా అనేది, మరొకటి దాని పైన ఉన్న ఏదో ప్రక్రియ బయటకు వెళ్లిన తర్వాత మళ్లీ ప్రారంభిస్తుందా అనేది. ఒకటి మాత్రమే సరిచేస్తే మరో ఖాళీ తెరిచే ఉంటుంది.

మానిటరింగ్ చెప్పేది నుంచి కాదు, యూనిట్ నిజంగా ఏమి చేసింది అనేది నుంచి ప్రారంభించండి. systemctl status openvpn-client@office మరియు journalctl -u openvpn-client@office -n 50 బయటకు వెళ్లిన కారణాన్ని, క్లయింట్ వెళ్లే ముందు రాసిన చివరి పంక్తిని చూపుతాయి.

ఎవరూ గమనించక ముందే ప్రక్రియ బయటకు వెళ్లింది

లోపం లేకుండా మాయమయ్యే క్లయింట్ సాధారణంగా ఉద్దేశపూర్వకంగానే బయటకు వెళ్లి ఉంటుంది. ఈ ప్రవర్తనను ప్రొఫైల్ నిర్ణయిస్తుంది, సేవా నిర్వాహకుడు కాదు: ping-exit ఎదుటి వైపు సమాధానం ఇవ్వడం ఆపిన వెంటనే ప్రక్రియను ముగిస్తుంది, అయితే ping-restart ప్రక్రియను ఉంచుకుని దాని లోపల మళ్లీ కలుపుతుంది. సెషన్ పరిమితులు మరియు నిష్క్రియత టైమర్లు బయటి నుంచి అదే చిత్రాన్ని ఇస్తాయి: సొరంగం లేదు, హెచ్చరికా లేదు.

రెండు ping సూచనలు ఒకే ప్రొఫైల్‌లో కలిసి ఉండలేవు, కాబట్టి ఒకటి ఎంచుకుని ఎంపికను నమోదు చేయండి. సర్వర్‌ను కూడా చూడండి, ఎందుకంటే దాని సొంత ping-exit క్లయింట్ ఏమి అడిగినా సెషన్‌ను మూస్తుంది, ఆ నిర్ణయం ఎవరు తీసుకున్నారో సర్వర్ లాగ్ మాత్రమే నమోదు చేస్తుంది.

ping-exit మరియు ping-restart మధ్య ఎంపిక

తమంత తాము కోలుకోవాల్సిన ల్యాప్‌టాప్ లేదా దూర ప్రాంతం కోసం ping-restart ఎంచుకోండి, చనిపోయిన సొరంగం ప్రక్రియను ఆపి మరేదైనా దానిపై స్పందించాల్సిన సందర్భాలకు ping-exit ఉంచండి. సంఖ్యల కంటే సంబంధం ముఖ్యం: ping 10 తో ping-restart 60 అంటే పరీక్షకు ముందు పది సెకన్ల నిశ్శబ్దం, పునఃప్రారంభానికి ముందు అరవై, ఇది నష్టాలున్న మొబైల్ లింక్‌పై దూకుడుగా, వైర్ లింక్‌పై సమంజసంగా ఉంటుంది. కారణాన్ని పంక్తి పక్కన రాయండి, లేకపోతే తదుపరి పాఠకుడు డిఫాల్ట్ విలువలు ఉద్దేశపూర్వకమని భావిస్తాడు.

తర్వాత బయటకు వెళ్లింది నిజంగా ప్రక్రియేనా అని నిర్ధారించుకోండి. సొరంగం చనిపోయి ఉన్నప్పుడు క్రియాశీలంగా ఉన్నట్టు నివేదించే యూనిట్ మరో వైఫల్యం, అది కింద చర్చించబడింది.

యూనిట్‌ను నిజంగా పునఃప్రారంభించే పర్యవేక్షణ

systemd హోస్ట్‌లో అతి చిన్న శాశ్వత మార్పు ఒక drop-in ఫైల్: Restart=on-failure మరియు RestartSec=10 /etc/systemd/system/[email protected]/restart.conf లో ఉన్నాయి. systemd తన స్వంత నిర్వచనాలను మళ్లీ లోడ్ చేసినప్పుడే drop-in చదవబడుతుంది, కాబట్టి దాని తర్వాత systemctl daemon-reload నడపండి. విలువ చేరిందని భావించకుండా systemctl show -p Restart -p ExecMainStatus openvpn-client@office తో ధృవీకరించండి. ఫైల్ పేరులోని ఇన్‌స్టాన్స్ యూనిట్ నిజంగా లోడ్ చేసే ప్రొఫైల్ అయి ఉండాలి, కాబట్టి office కోసం రాసిన ఫైల్ openvpn-client@home కోసం ఏమీ చేయదు.

on-failure ఒక సందర్భాన్ని పట్టించుకోదు: స్థితి సున్నాగా ఉన్న శుభ్రమైన నిష్క్రమణ. కొన్ని విచ్ఛిన్న మార్గాలు అలాగే ముగుస్తాయి, కాబట్టి మాన్యువల్ పేజీ మాటలను నమ్మకుండా నమోదైన స్థితిని చదవండి. మీ క్లయింట్ సున్నాతో లొంగిపోతే, మీకు Restart=always అవసరం, దాని ధర ఏమిటంటే నిజంగా పాడైన ప్రొఫైల్ ప్రారంభ రేటు పరిమితి అమలయ్యే వరకు, జర్నల్ నిండే వరకు మళ్లీ మళ్లీ తిరిగి వస్తుంది.

Restart=always ఉద్దేశపూర్వకంగా ఆపిన తర్వాత కూడా పనిచేస్తుంది. నిర్వహణ కోసం systemctl stop ఉపయోగించండి, మీరు పని చేస్తున్నప్పుడు యూనిట్ కిందే ఉండాల్సి వస్తే దాన్ని మాస్క్ చేయండి.

సొరంగం కింద ఉన్నప్పుడు లీక్‌ను పట్టుకోండి

పర్యవేక్షణ సొరంగాన్ని తిరిగి తెస్తుంది; సొరంగం లేనప్పుడు ట్రాఫిక్ బయటకు వెళ్లడాన్ని అది ఆపదు. persist-tun మళ్లీ కనెక్ట్ అయ్యే మధ్య పరికరాన్ని, దాని మార్గాలను ఉంచుతుంది, ఇది సౌకర్యవంతం మరియు ఒక కిటికీని తెరుస్తుంది. పరికరం నిలిచి ఉంటుంది, మార్గాలు ఇంకా దాని వైపే ఉన్నాయి, ప్యాకెట్లు రక్షణ లేకుండా, నివేదిక లేకుండా బయటకు ప్రవహిస్తాయి. ఇది విధాన ఎంపిక, తటస్థ డిఫాల్ట్ కాదు.

హోస్ట్ రక్షణ లేని ప్యాకెట్లను అసలు పంపకూడదు అని ఉంటే, దాన్ని ఫైర్‌వాల్ మాత్రమే హామీ ఇవ్వగలదు. సొరంగ ఇంటర్‌ఫేస్‌కు, VPN సర్వర్ చిరునామాకు అనుమతి ఇచ్చి మిగతావన్నీ పడేసే అవుట్‌పుట్ నియమం క్లయింట్ చనిపోయిన తర్వాత కూడా వర్తిస్తుంది, క్లయింట్ స్వంత కాన్ఫిగరేషన్‌లో క్లయింట్ మోయని ట్రాఫిక్‌ను ఫిల్టర్ చేయగలిగేది ఏమీ లేదు.

క్లయింట్‌ను ఉద్దేశపూర్వకంగా ఆపి దీన్ని పరీక్షించండి. systemctl stop openvpn-client@office నడపండి, తర్వాత curl -m 5 https://example.com, అది భౌతిక లింక్‌పై విజయవంతం కాకుండా విఫలం కావాలి. విజయం అంటే ఫైర్‌వాల్ నియమం లేదు లేదా చాలా అనుమతించేదిగా ఉంది.

మళ్లీ కనెక్ట్ అవ్వండి, సొరంగం మళ్లీ ట్రాఫిక్ మోస్తున్నదని నిర్ధారించుకోండి, ఆ తర్వాతే తనిఖీని మానిటరింగ్‌కు జోడించండి. cron నుంచి ip addr ను tun పరికరం కోసం అడగడం అత్యధికంగా విఫలమయ్యే పర్యవేక్షణ, ఎందుకంటే persist-tun తో పరికరం సెషన్ కంటే ఎక్కువ కాలం జీవిస్తుంది, ఏమీ మోయనప్పుడు కూడా తనిఖీ ఆరోగ్యంగా ఉందని నివేదిస్తుంది.

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