తెగిపోయిన VPN కోసం OpenConnect ఎంతకాలం మళ్లీ ప్రయత్నించాలి?

--reconnect-timeout ఒక సన్నని ప్రశ్నకు సమాధానం చెబుతుంది: సొరంగం పడిన తర్వాత, ఈ క్లయింట్ ప్రక్రియ వదిలివేసి బయటకు వెళ్లే ముందు ఎంతకాలం ప్రయత్నిస్తుంది. OpenConnect మాన్యువల్ పేజీ ఆ ఎంపికను పోయిన లింక్ లేదా సమాధానం చెప్పడం ఆపిన భాగస్వామి తర్వాత వచ్చే మళ్లీ ప్రయత్నాలకు 300 సెకన్ల పత్రబద్ధ డిఫాల్ట్తో నమోదు చేస్తుంది, మరియు ఈ సంఖ్య ఒక నడుస్తున్న క్లయింట్కు గడువు, VPN చేరుకోగలిగి ఉంటుందనడానికి సాక్ష్యం కాదు. ఇది ప్రక్రియను సజీవంగా ఉంచే విధానం కూడా కాదు, మరియు చాలా గందరగోళం ఇక్కడే మొదలవుతుంది.

పైన రెండవ యంత్రాంగం కూర్చున్నప్పుడు గందరగోళం పెరుగుతుంది. క్లయింట్ను మళ్లీ ప్రారంభించే పర్యవేక్షకుడు, గేట్వేను పింగ్ చేసే పరీక్షకుడు, మరియు అంతర్నిర్మిత మళ్లీ ప్రయత్న విండో — అన్నీ ఒకే వైఫల్యానికి స్పందించగలవు, ఆ తర్వాత సంఘటన ఎవరూ సరిపోల్చలేని మూడు కాలరేఖలను ఇస్తుంది.

పునఃకనెక్షన్ విండో నిజంగా ఏమి పరిమితం చేస్తుంది

యాక్సెస్ నెట్వర్క్ కొన్ని సెకన్ల పాటు మాయమవుతుందని ఊహించండి. క్లయింట్ లింక్ పడిపోవడం చూస్తుంది, లేదా మృత భాగస్వామి సమాధానాలు వినడం ఆపేస్తుంది, మరియు తనకు సాధ్యమైన స్థితిని పట్టుకొని సెషన్ను మళ్లీ నెలకొల్పడం మొదలుపెడుతుంది. గేట్వే మళ్లీ అంగీకరించే వరకు లేదా విండో ముగిసే వరకు ప్రయత్నాలు కొనసాగుతాయి, ముగిసిన విండో సున్నా కాని నిష్క్రమణతో ముగుస్తుంది. ఆ నిష్క్రమణే, కాల పరిమితి విలువ కాదు, జీవిత చక్రం యాజమాన్యం ప్రక్రియను పర్యవేక్షించే వ్యక్తికి మారే స్థలం.

విండో పరీక్షకుడు ఎన్నిసార్లు నడుస్తుందని ఏమీ చెప్పదు, మరియు అది ప్రామాణీకరణను పొడిగించలేదు. గేట్వే సెషన్ను రద్దు చేసి ఉంటే, లేదా ఖాతా ఇప్పుడు కొత్త రెండవ కారకాన్ని కోరుతుంటే, ఎక్కువసేపు వేచి ఉండటం పాత సెషన్ను మళ్లీ చెల్లుబాటు చేయదు. మార్గం తిరిగి వచ్చినప్పుడు, గేట్వే సెషన్ను ఇంకా గుర్తించినప్పుడు, మరియు కోరిన ఆధారాలు ఉపయోగించదగినవిగా ఉన్నప్పుడు మాత్రమే మళ్లీ ప్రయత్నం విజయవంతమవుతుంది, కాబట్టి ఈ సంఖ్యను జీవన విరామం కాదు, గడువుగా చదవండి.

విండో నడుస్తున్నప్పుడు అప్లికేషన్లు ఏమి చేస్తాయో కూడా అది నియంత్రించదు. వేదిక మరియు వైఫల్యం ఎంత దూరం వెళ్లిందనే దానిపై ఆధారపడి, క్లయింట్ మార్గాలు ఇంకా ఇన్స్టాల్ అయి ఉండగానే లేదా అవి తీసివేసిన తర్వాత మళ్లీ కనెక్ట్ కావచ్చు. అందుకే అంతరాయం మధ్యలో జారీ చేసిన అభ్యర్థన త్వరగా విఫలం కాకుండా కాల పరిమితి వరకు వేలాడుతుంది.

పర్యవేక్షక మళ్లీ ప్రారంభాలు మరియు క్లయింట్ మళ్లీ ప్రయత్నాలు రెండు పొరలు

నడుస్తున్న క్లయింట్ తన విండోను ఖర్చు చేయనివ్వండి, సేవా నిర్వాహకుడు నిష్క్రమణకు స్పందించనివ్వండి. systemd కింద మళ్లీ ప్రారంభ విధానంతో ముందు వరుస క్లయింట్ సరిగ్గా ఆ విభజనను ఇస్తుంది: పరిమిత కాలానికి ప్రయత్నాలు, తర్వాత ఒక మళ్లీ ప్రారంభ నిర్ణయం. ఫలితం తర్వాత కూడా పునర్నిర్మించగల ఒకే కాలరేఖ.

నేపథ్య క్లయింట్తో పాటు ఇంటర్ఫేస్ కనిపించనప్పుడు మరో ప్రతిని ప్రారంభించే స్వతంత్ర పోలర్ — ఇదే తప్పుగా సాగే నమూనా. అప్పుడు రెండు ప్రక్రియలు ఒకే పరికర నోడ్, మార్గాలు మరియు రిజాల్వర్ సెట్టింగ్ల కోసం పోటీపడతాయి. నిజంగా డీమన్ కావాలంటే, క్లయింట్ నిజంగా ప్రారంభమయ్యే కమాండ్ లైన్పై ఆ ఎంపికను పెట్టండి:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

ఆ వరుసలో రెండు వివరాలకు బరువు ఉంది. --background ప్రక్రియను వేరు చేస్తుంది, కాబట్టి pid ఫైల్ దానిపై ఏకైక నమ్మదగిన పట్టుగా మారుతుంది, మరియు కాల పరిమితి అదే ప్రక్రియ సజీవంగా ఉన్నంత కాలమే ఖర్చవుతుంది; దాన్ని చంపే పర్యవేక్షకుడు కొనసాగించడానికి ఎలాంటి బడ్జెట్ను విడిచిపెట్టడు.

ఉద్దేశపూర్వక డిస్కనెక్ట్లకు తమ సొంత సంకేతం కావాలి. ప్రణాళికాబద్ధ విరామం మరియు నిజమైన అంతరాయం అమాయక పరిశీలకుడికి ఒకేలా కనిపిస్తాయి, రెండూ «కనెక్ట్ కాలేదు» అని చదవబడతాయి. విరామాన్ని పర్యవేక్షకుడి ఆపే చర్య లేదా ర్యాపర్ అర్థం చేసుకునే గుర్తు ద్వారా నడపండి, ఉద్దేశపూర్వక ఆపు ఎవరూ అడగని మళ్లీ ప్రారంభాన్ని రేకెత్తించకుండా.

హ్యాండ్ఆఫ్ మళ్లీ ప్రయత్న లూప్తో పోటీపడకుండా నిరోధించడం

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

ప్రాంప్ట్లను తగ్గించడానికి సర్వర్ ధృవీకరణను సడలించకూడదు. గేట్వేను ధృవీకరించే పిన్ లేదా విశ్వాస లంగరే స్వయంచాలక పునఃకనెక్షన్ను సురక్షితం చేస్తుంది, మరియు ధృవపత్ర ప్రశ్నను తప్పించుకోవడానికి దాన్ని నిలిపివేయడం కనిపించే అంతరాయాన్ని కనిపించని దానితో మార్చుతుంది. ధృవీకరించిన గుర్తింపును ఉంచి బదులుగా ప్రాంప్ట్ను సరిచేయండి; ఏ గేట్వేతో అయినా కనెక్ట్ అవ్వడానికి సిద్ధమైన క్లయింట్ ఆగి వేచి ఉండే దాని కంటే అధ్వాన్నం.

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

అంతరాయం సమయంలో మరియు తర్వాత ఏమి ధృవీకరించాలి

నాలుగు సంఘటనలను వేర్వేరు పరీక్షలుగా నడపండి: విండో కంటే చిన్న అంతరాయం, దాని కంటే పొడవైన అంతరాయం, ప్రామాణీకరణ వైఫల్యం, మరియు ఉద్దేశపూర్వక ఆపు. ప్రతిదీ భిన్నమైన, ముందుగా చెప్పగలిగే స్థితిలో ముగియాలి, మరియు మొదటి రెండింటి మధ్య సరిహద్దే విలువను ఎంచుకోవడానికి మొత్తం కారణం.

తనిఖీలను బయటకు ముఖం చేసి ఉంచండి, ఎందుకంటే ప్రక్రియ పట్టిక తనంతట తానే చాలా తక్కువ నిరూపిస్తుంది. చిన్న అంతరాయం అంతటా pid స్థిరంగా ఉందో చూడండి, తర్వాత పొడవైన దాని తర్వాత అది పోయిందని, ఒకసారి భర్తీ చేయబడిందని నిర్ధారించండి:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

ఉద్దేశపూర్వక ఆపు కోసం ఆరోగ్య URL చేరుకోలేనిదిగా ఉండాలి, ప్రక్రియ కిందనే ఉండాలి. తర్వాత అప్లికేషన్ వైపు నుండి లూప్ను మూసివేయండి: అదే అభ్యర్థన సొరంగం లేనప్పుడు విఫలం కావాలి, తిరిగి వచ్చిన తర్వాత మీ విధానం ఆశించే మూల చిరునామా నుండి విజయవంతం కావాలి. ఆకుపచ్చ సొరంగ చిహ్నం సాక్ష్యం కాదు, కానీ పూర్తయిన అభ్యర్థన సాక్ష్యం.