OpenVPN సేవ ప్రైవేట్ కీ పాస్‌వర్డ్ అడిగినప్పుడు ఆగిపోతుంది: ఎలా పరిష్కరించాలి
సేవకు టెర్మినల్ లేదు, కాబట్టి ఎన్‌క్రిప్ట్ చేసిన కీకి askpass మరియు చదవగలిగే ఫైల్ అవసరం. కీ పాస్‌ఫ్రేజ్‌ను సర్వర్ లాగిన్ నుండి వేరు చేసి unit తనిఖీ చేయండి.
OpenVPN స్థానిక మెషీన్‌లో ప్రైవేట్ కీ పాస్‌ఫ్రేజ్‌ను అడుగుతుంది, కాబట్టి పనిచేసే లాగిన్ ఫైల్ దానికి ఎప్పటికీ సమాధానం ఇవ్వదు. సేవలో టైప్ చేయడానికి టెర్మినల్ ఉండదు, మరియు ప్రారంభం గానీ వేలాడుతుంది లేదా కారణాన్ని కాకుండా ఇన్‌పుట్‌ను పేర్కొనే journal ఎంట్రీతో విఫలమవుతుంది. ఇక్కడ రెండు రహస్యాలు ఉన్నాయి, మరియు unit తిరిగి ప్రారంభించే ముందు ప్రతిదానికీ దాని సొంత చదవగలిగే మూలం అవసరం. క్రింది దశలు వాటిని వేరు చేసి, తర్వాత ప్రతి ఫైల్‌ను నిజంగా తెరిచే గుర్తింపును తనిఖీ చేస్తాయి.
రెండు అభ్యర్థనలను వేరు చేయండి
కీ పాస్‌ఫ్రేజ్ స్థానిక ప్రైవేట్ కీని డీక్రిప్ట్ చేస్తుంది; ఖాతా ఆధారాలు సర్వర్‌తో సెషన్‌ను ధృవీకరిస్తాయి. అవి వేర్వేరు ప్రదేశాల నుండి వస్తాయి, వేర్వేరు క్షణాల్లో విఫలమవుతాయి మరియు వేర్వేరు సందేశాలు ఇస్తాయి. వాటిని కలిపేయడం వల్ల ప్రజలు పాస్‌వర్డ్ రీసెట్ వెతకడానికి వెళ్తారు, కానీ ఖాతా అందులో లేదు. ఏ రహస్యం లేదో తెలిపే ఏకైక నమ్మదగిన సూచన పదాలే, కాబట్టి ఏదైనా ఎంపికను మార్చే ముందు అభ్యర్థన పాఠ్యాన్ని చదవండి.
Community OpenVPN 2.x లో askpass మొదటి పంక్తిలో కీ పాస్‌ఫ్రేజ్ ఉన్న ఫైల్‌ను సూచిస్తుంది, auth-user-pass ఒక పంక్తిలో వినియోగదారు పేరు మరియు తదుపరి పంక్తిలో పాస్‌వర్డ్ ఉన్న ఫైల్‌ను సూచిస్తుంది. ఏ ఫైల్ కూడా మరొక ఎంపికను తృప్తిపరచదు. డెస్క్‌టాప్ యాప్ లేదా NetworkManager ప్రొఫైల్ రెండింటినీ తన సొంత రహస్య నిల్వలో ఉంచుకోవచ్చు, దాన్ని కమాండ్-లైన్ క్లయింట్ ఎప్పటికీ చదవదు, కాబట్టి ఏదైనా మార్గం రాయడానికి ముందు మీరు ఏ క్లయింట్‌ను కాన్ఫిగర్ చేస్తున్నారో గుర్తించండి.
రెండు ఎంపికలను చదవగలిగే ఫైళ్ల వైపు మళ్లించండి
రెండు ఇన్‌పుట్‌లు అవసరమయ్యే ప్రొఫైల్ చివరికి మూడు ఫైల్ సూచనలతో మిగులుతుంది: ఎన్‌క్రిప్ట్ చేసిన కీ, దాన్ని తెరిచే పాస్‌ఫ్రేజ్ మరియు లాగిన్ జోడి. CA మరియు గుర్తింపు తనిఖీలను తాకకుండా వాటిని జోడించండి, ఎందుకంటే అవి సర్వర్ ఎవరో నిర్ణయిస్తాయి మరియు ఈ సమస్యలో భాగం కావు. డిప్లాయ్‌మెంట్ ఖాతా ఆధారాలను అసలు ఉపయోగించకపోతే, auth-user-pass జోడించడం ఎవరూ అందించలేని ఇన్‌పుట్‌ను సృష్టిస్తుంది.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authవాదన లేని ఎంపికలు మార్గం ఉన్న ఎంపికలకు భిన్నంగా ప్రవర్తిస్తాయి, సేవలో ఈ భేదం ముఖ్యం. వాదన లేని askpass ఇప్పటికీ కన్సోల్ చదుతుంది, మరియు వినియోగదారు పేరు మాత్రమే ఉన్న auth-user-pass ఫైల్ ఇప్పటికీ పాస్‌వర్డ్ అభ్యర్థనను నిరీక్షణలో వదిలేస్తుంది. క్లయింట్ డీమన్ అయిన తర్వాత టెర్మినల్ నుండి ఇన్‌పుట్ అడగలేదు, కాబట్టి ఈ విధంగా కాన్ఫిగర్ చేసిన సేవ లేవదు.
సంపూర్ణ మార్గాలు పని డైరెక్టరీ ప్రశ్నను తొలగిస్తాయి కానీ ప్రవేశం ఇవ్వవు. తర్వాత యాజమాన్యం, మోడ్ మరియు ప్రయాణం వస్తాయి, మూడూ ప్రక్రియ నడిచే ఖాతాకు వ్యతిరేకంగా తనిఖీ చేయబడతాయి.
ప్రొఫైల్‌కు ముందు unit కాన్ఫిగరేషన్ చదవండి
ఏ కాన్ఫిగరేషన్‌ను ఇన్‌స్టాన్స్ లోడ్ చేస్తుందో unit నిర్ణయిస్తుంది, మీరు సవరిస్తున్న ఫైల్ కాదు. దాని కమాండ్ లైన్ మరియు అన్ని drop-in చదివి, తర్వాత పని డైరెక్టరీ ద్వారా నిజంగా ఉపయోగించే ప్రొఫైల్ వరకు వెళ్లండి. మరొక .ovpn ఫైల్‌కు జోడించిన పాస్‌ఫ్రేజ్ సూచన ఈ ఇన్‌స్టాన్స్‌కు ఏమీ మార్చదు.
మూడు చదవడం-మాత్రమే ఆదేశాలు దానిలో ఎక్కువ భాగానికి సమాధానం ఇస్తాయి. మొదటిది unit మరియు అన్ని drop-in ముద్రిస్తుంది, రెండవది ప్రక్రియను బంధించే గుర్తింపు మరియు sandbox సెట్టింగ్‌లను, మూడవది చివరి ప్రారంభం నిజంగా ఏమి గురించి ఫిర్యాదు చేసిందో ముద్రిస్తుంది. హోస్ట్‌లో ఉన్న ఇన్‌స్టాన్స్ పేరును ఉపయోగించండి:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome మరియు ప్రొఫైల్ సొంత user, group మరియు chroot ఎంపికలపై శ్రద్ధ పెట్టండి. హోమ్ డైరెక్టరీ కింద ఉన్న ఫైల్ మీ shell లో చదవగలిగేదిగా ఉండవచ్చు మరియు హోమ్ డైరెక్టరీలు దాచబడినప్పుడు సేవలో కనిపించకుండా పోవచ్చు. systemd ప్రారంభించే ఖాతా ఎప్పుడూ కీని చివరిలో తెరిచే ఖాతా కాదు.
రన్‌టైమ్ గుర్తింపు రెండు ఫైళ్లను తెరవగలదని నిరూపించండి
మోడ్ చదవడం సరిపోదు, ఎందుకంటే మార్గంలోని ప్రతి డైరెక్టరీ అదే గుర్తింపుతో దాటగలిగేదిగా ఉండాలి. మార్గాన్ని భాగం భాగంగా నడవండి, తర్వాత ప్రక్రియ ఉపయోగించే ఖాతాగా తెరవడాన్ని పరీక్షించండి. root యాజమాన్యంలోని 600 మోడ్ ఫైల్ ప్రక్రియ ఇంకా root గా ఉన్నంత వరకు మాత్రమే పనిచేస్తుంది, చాలా ప్రొఫైళ్లు చేసే అధికార తగ్గింపు తర్వాత అది నిజం కాదు. రెండు ఆదేశాలు ప్రయాణాన్ని మరియు తెరవడాన్ని కవర్ చేస్తాయి:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableమొదటి ఆదేశం ప్రతి భాగం మోడ్‌ను ముద్రిస్తుంది మరియు ఖాతా దాటలేని చోట విఫలమవుతుంది; రెండవది ఏకైక ముఖ్యమైన ప్రశ్నకు సమాధానం ఇస్తుంది, అంటే రన్‌టైమ్ గుర్తింపు ఫైల్‌ను చదవడానికి తెరవగలదా అని. రెండూ ఫైల్ విషయాన్ని ముద్రించవు, ఫైల్‌లో పాస్‌ఫ్రేజ్ ఉన్నప్పుడు అదే ప్రధాన విషయం. లాగిన్ ఫైల్‌కు కూడా పరీక్షను పునరావృతం చేయండి, ఎందుకంటే రెండూ తరచుగా వేర్వేరు యాజమాన్యంతో నిల్వ చేయబడతాయి.
ప్రక్రియ chroot లేదా పరిమిత namespace ఉపయోగిస్తే, అదే పరీక్షను ఆ వీక్షణ లోపలి నుండి నడపండి, లేకపోతే సమాధానం తప్పు ఫైల్‌సిస్టమ్‌ను వివరిస్తుంది. దాచిన హోమ్ డైరెక్టరీ కింద నిల్వ చేసిన పాస్‌ఫ్రేజ్, unit వెలుపల పాస్ అయి లోపల విఫలమయ్యే పరీక్షకు సాధారణ ఉదాహరణ.
మొదటి ప్రారంభాన్ని తనిఖీ చేయండి, తర్వాత పునఃకనెక్షన్
ఇన్‌స్టాన్స్‌ను ఒకసారి ప్రారంభించి చివరిది కాదు, మొదటి వైఫల్యాన్ని చదవండి. తప్పిపోయిన ఇన్‌పుట్ ఫైల్, విఫలమైన కీ డీక్రిప్షన్ మరియు సర్వర్ నుండి AUTH_FAILED మూడు వేర్వేరు సంఘటనలు, మూడు వేర్వేరు పరిష్కారాలతో. అనుమతి హెచ్చరికను సరిచేయడం కీ తెరవబడిందా అనే దాని గురించి ఏమీ నిరూపించదు.
journal పంక్తి మూడింటిలో ఏది ఉందో చెబుతుంది. ఏ ఇన్‌పుట్ విఫలమైంది అనే దాని నుండి పరిష్కారం వస్తుంది:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
తర్వాత మీకు నిజంగా అవసరమైన జీవిత చక్రాన్ని పరీక్షించండి: బూట్‌లో ప్రారంభం మరియు మద్దతు ఉన్న ఏదైనా పునఃకనెక్షన్, మీ shell నుండి చేతితో ప్రారంభించడం మాత్రమే కాదు. auth-nocache ఉన్నప్పుడు ఇన్‌పుట్‌లు మొదటి వినియోగం తర్వాత విసిరివేయబడతాయి, కాబట్టి తర్వాతి పునఃకనెక్షన్‌కు ఇంకా చదవగలిగే మూలం అవసరం. డెస్క్‌టాప్ లాగిన్‌లో తెరిచే కీరింగ్ ఎవరూ లాగిన్ చేయకముందే ప్రారంభమైన సేవకు అందుబాటులో ఉండదు, చేతి పరీక్ష పాస్ అయి రీబూట్ విఫలమవడానికి ఇదే సాధారణ కారణం. మొదటి ప్రారంభం విజయవంతమై తర్వాతి పునఃకనెక్షన్ విఫలమైతే, అనుమతులను మళ్లీ మార్చే ముందు పునఃకనెక్షన్ సంఘటన కోసం journal చదవండి.
కీ పక్కన పాస్‌ఫ్రేజ్ ఉంచడం ఎన్‌క్రిప్షన్ ఇచ్చేదాన్ని తగ్గిస్తుంది, కాబట్టి ఆ ఫైల్‌ను మరియు దాని బ్యాకప్‌లను పరిమితం చేయండి. కీ పాస్‌ఫ్రేజ్‌ను తీసివేయడాన్ని తప్పిపోయిన ఇన్‌పుట్‌కు పరిష్కారంగా కాకుండా ప్రత్యేక ఆధారాల నిర్ణయంగా పరిగణించండి. మానవ ఆమోదం లేదా ఇంటరాక్టివ్ MFAపై ఆధారపడే డిప్లాయ్‌మెంట్‌కు దాని మద్దతు ఉన్న ఏజెంట్ లేదా నిర్వహణ ఇంటిగ్రేషన్ అవసరం; శాశ్వతంగా నిల్వ చేసిన ఒక-సారి కోడ్ సమానమైన ప్రత్యామ్నాయం కాదు.