OpenVPN auth-user-pass: ఫైల్, stdin లేదా ప్రాంప్ట్? ఎలా ఎంచుకోవాలి

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

దీన్ని నిర్ణయించే మూడు షరతులు

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

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

• కన్సోల్ వద్ద మనిషి, ఆటోమేషన్ లేదు: పరస్పర ప్రాంప్ట్.
• పర్యవేక్షణ లేని ప్రారంభం, రహస్యాన్ని నిల్వ చేయవచ్చు: మోడ్ 0600 ఆధారాల ఫైల్.
• పర్యవేక్షణ లేని ప్రారంభం, రహస్యాన్ని నిల్వ చేయలేము: ప్రక్రియ ప్రత్యామ్నాయం లేదా రహస్య ఏజెంట్ రాసే fd.
• క్లయింట్ మరో ప్రక్రియ స్వంతం: నిర్వహణ ఇంటర్ఫేస్.

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

ప్రతి ఇన్పుట్ మార్గం నిజంగా ఏమి చేస్తుంది

--auth-user-pass ఒంటరిగా కన్సోల్లో వినియోగదారు పేరు మరియు పాస్వర్డ్ అడుగుతుంది. ఫైల్ పేరు ఇస్తే, క్లయింట్ మొదటి పంక్తిని వినియోగదారు పేరుగా, రెండవ పంక్తిని పాస్వర్డ్గా తీసుకుంటుంది; కోట్లు, వ్యాఖ్యలు లేదా కీ-విలువ సింటాక్స్కు ఏ మద్దతూ లేదు. ఇదే మొత్తం ఫార్మాట్, కాబట్టి INI ఫైల్ ఆశించి దీన్ని సవరించే ఎవరైనా దాన్ని పాడు చేస్తారు. ఇన్లైన్ <auth-user-pass> బ్లాక్ అదే రెండు పంక్తులను ప్రొఫైల్ లోపల ఉంచుతుంది, ఇది ప్రొఫైల్ను స్వయంగా రహస్యంగా మార్చి, ప్రైవేట్ కీతో సమానమైన నిర్వహణ తరగతిలో ఉంచుతుంది.

మిగిలిన రెండు మార్గాలు స్ట్రీమ్ మరియు సాకెట్. OpenVPN కు చదవగలిగే ఫైల్ డిస్క్రిప్టర్ మాత్రమే కావాలి, కాబట్టి ప్రక్రియ ప్రత్యామ్నాయం, పైప్ మద్దతు ఉన్న /dev/fd నమోదు లేదా నిజానికి FIFO అయిన ఫైల్ పేరును అంగీకరిస్తుంది. నిర్వహణ ఇంటర్ఫేస్ స్వభావంలో భిన్నం: క్లయింట్ విలువలను తానే చదవకుండా పర్యవేక్షణ ప్రక్రియను అడుగుతుంది. తిరిగి కనెక్ట్ అయ్యేటప్పుడు ఆ భేదం ముఖ్యం: ఆధారాల ఫైల్, రహస్య సహాయకుడు మళ్లీ రాయగల FIFO, మరియు నిర్వహణ ఇంటర్ఫేస్ మనిషి లేకుండా మళ్లీ సరఫరా చేయగలవు; ప్రక్రియ ప్రత్యామ్నాయం చేయలేదు, ఎందుకంటే డిస్క్రిప్టర్ మొదటి పఠనంలోనే ఖర్చవుతుంది.

ఫైల్ సరిగ్గా రెండు పంక్తులు ఉండాలి

పాడైన ఆధారాల ఫైళ్లలో చాలావాటిని రెండు వైఫల్య విధానాలు కవర్ చేస్తాయి. Windows ఎడిటర్ CRLF ముగింపులను వదిలిస్తుంది, క్యారేజ్ రిటర్న్ పాస్వర్డ్లో భాగమవుతుంది, మరియు స్క్రీన్పై సరిగ్గా కనిపించే విలువను సర్వర్ తిరస్కరిస్తుంది. ఖాళీ రెండవ పంక్తి - పాస్వర్డ్ ఉండాల్సిన చోట ఖాళీ పంక్తి - క్లయింట్ను ఖాళీ పాస్వర్డ్తో వదిలిస్తుంది, స్క్రీన్పై విలువ సరిగ్గా కనిపించినా సర్వర్ దాన్ని తిరస్కరిస్తుంది. పాస్వర్డ్ తర్వాత అదనపు కొత్త పంక్తి హానికరం కాదు. ఫైల్ను ఎడిటర్ నుండి కాకుండా shell నుండి రాయండి మరియు బైట్లను తనిఖీ చేయండి:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

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

సర్వర్ను నిందించే ముందు ఫైల్ను పరీక్షించండి. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 నడిపితే ఫైల్ తెరవబడిందా మరియు తర్వాత ఆధారాలు అంగీకరించబడ్డాయా అని ముద్రిస్తుంది, ఇది తర్వాత ఏ పొరను మార్చాలో చెబుతుంది.

స్ట్రీమ్లు, stdin మరియు అవి ఉత్పత్తి చేసే లోపాలు

పాస్వర్డ్ను పైపులో పంపడం చాలామంది మొదట ప్రయత్నించే విషయం మరియు అత్యధిక ఆశ్చర్యాల మార్గం. ప్రక్రియ ప్రత్యామ్నాయం పని చేస్తుంది ఎందుకంటే క్లయింట్కు చదవగలిగే డిస్క్రిప్టర్ మాత్రమే కావాలి: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin పంపడం క్లయింట్ అడిగే క్షణంలో stdin ఇంకా తెరిచి, చదవగలిగి ఉన్నప్పుడే పని చేస్తుంది, ఇప్పటికే దాన్ని వినియోగించిన పైప్లైన్లో ఇది నిజం కాదు.

ERROR: could not read Auth username from stdin కు రెండు భిన్న కారణాలు ఉన్నాయి. కొన్ని 2.3.x క్లయింట్లలో సందేశం stdin నిర్వహణ లోపం నుండి వచ్చింది, తర్వాతి 2.3 విడుదలలు దాన్ని సరిచేశాయి, కాబట్టి అంత పాత క్లయింట్ అప్గ్రేడ్ ద్వారా మాత్రమే మెరుగుపడుతుంది. ప్రస్తుత క్లయింట్లో అదే పదబంధం అంటే క్లయింట్ కన్సోల్ ఇన్పుట్ అడిగింది మరియు stdin టెర్మినల్ కాదు - సరిగ్గా systemd యూనిట్, cron పని లేదా -t లేకుండా ప్రారంభించిన కంటైనర్లో ఉండే స్థితి.

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

ప్రాంప్ట్ మరో ప్రక్రియ స్వంతమైనప్పుడు నిర్వహణ ఇంటర్ఫేస్

టన్నెల్ను ఇప్పటికే పర్యవేక్షిస్తున్న నియంత్రకం దాని ప్రశ్నలకూ సమాధానం చెప్పగలదు. క్లయింట్ను --management 127.0.0.1 7505 తో ప్రారంభించండి, స్థితి పంక్తులను చదవండి, >PASSWORD:Need 'Auth' username/password పై దృష్టి పెట్టండి. నియంత్రకం వేర్వేరు ఆదేశ పంక్తులపై username "Auth" alice మరియు తర్వాత password "Auth" ... తో సమాధానం చెబుతుంది. 'Auth' టోకెన్ అభ్యర్థన నుండి గుర్తింపుదారును పునరావృతం చేస్తుంది, అది సరిపోలాలి, లేకపోతే సమాధానం నిర్లక్ష్యం చేయబడుతుంది మరియు క్లయింట్ నిరీక్షిస్తుంది.

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

ఆధార సమస్య లాగా కనిపించే వైఫల్యాలు

ఎప్పటికీ పూర్తికాని TLS కరచాలనం, లేదా VERIFY ERROR: depth=0, error=certificate signature failure, విశ్వాస సమస్య మరియు ఏ వినియోగదారు పేరు చదవబడక ముందే జరుగుతుంది. UDP శ్రోత వైపు లక్ష్యంగా ఉన్న proto tcp క్లయింట్ కూడా అదే చోట విఫలమవుతుంది: ప్యాకెట్లు ఎప్పటికీ ధృవీకరణ దశకు చేరవు, కాబట్టి ప్రతి పాస్వర్డ్ సంబంధం వల్ల తప్పుగా కనిపిస్తుంది. ఆధారాలు పంపే ముందు సర్టిఫికెట్ ధృవీకరణను ఆన్లో ఉంచండి; పరిచిత ప్రాంప్ట్ పాస్వర్డ్ను ఎవరు పొందుతారనే దాని గురించి ఏమీ చెప్పదు. ఆధారాన్ని తాకే ముందు సర్టిఫికెట్ గొలుసు, సాధారణ పేరు మరియు రవాణాను తనిఖీ చేయండి.

ప్రొఫైల్ను కలిపే స్క్రిప్ట్లోని shell లోపాలు రెండవ తప్పుడు ఆనవాలు. [ ! -f "$file" ] లోపల తప్పిపోయిన ఖాళీ command not found ను ఉత్పత్తి చేస్తుంది, స్క్రిప్ట్ ముందుగానే ఆగిపోతుంది, ప్రొఫైల్ ఎప్పటికీ పునర్నిర్మించబడదు, క్లయింట్ మునుపటితో ప్రారంభమవుతుంది. ఆ లోపం shell ది, ధృవీకరణది కాదు, పాస్వర్డ్ను ఎన్నిసార్లు తిరిగి టైప్ చేసినా అది తుడిచిపోదు.

ఈ ప్రవాహంలోని ప్రతి ప్రాంప్ట్ ఈ ఆధారం కాదు. ప్రైవేట్ కీ పాస్ఫ్రేజ్, HTTP ప్రాక్సీ లాగిన్ మరియు సేవ పాస్వర్డ్ వేర్వేరు దశల్లో అడిగే మూడు వేర్వేరు రహస్యాలు, కీ పాస్ఫ్రేజ్ను సాధారణంగా auth-user-pass కాకుండా క్లయింట్ లేదా ఏజెంట్ నిర్వహిస్తుంది. TLS సెషన్ ఏర్పడక ముందే ప్రాంప్ట్ కనిపిస్తే, మీరు తప్పు ప్రశ్నకు సమాధానం చెబుతున్నారు, ఏ ఖాతా రీసెట్ సహాయపడదు. తప్పు ప్రాంప్ట్ తొలగించిన తర్వాత, మిగిలిన తనిఖీలు అత్యంత మునుపటి పొర నుండి ప్రారంభమవుతాయి:

• చివరి ఆధార పంక్తి కాదు, మొదటి ప్రోటోకాల్ లోపాన్ని చదవండి: TLS, తర్వాత ధృవీకరణ, తర్వాత push.
• ఫైల్ రెండు పంక్తులు, క్యారేజ్ రిటర్న్లు లేవు, పూర్తి మార్గంతో సూచించబడిందని నిర్ధారించండి.
• ప్రొఫైల్ మరియు ఆదేశ పంక్తి ఆదేశం గురించి విభేదించవని నిర్ధారించండి.
• "ఆధారాలు అంగీకరించబడ్డాయి" మరియు "ట్రాఫిక్ ప్రవహిస్తోంది" వేరు చేయండి - రూటింగ్ మరియు DNS తర్వాతి పొర.

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