మీ PiVPN ప్రొఫైల్‌ను నిజంగా ఏ OpenVPN ఇన్‌స్టెన్స్ ఉపయోగిస్తోంది?

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

సహాయకుడు మరియు డీమన్ వేర్వేరు వస్తువులు

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

systemd హోస్ట్లో డైరెక్టరీ జాబితాకు బదులుగా యాక్టివ్ యూనిట్ నుండి ప్రారంభించండి. పేరు ప్యాకేజింగ్పై ఆధారపడి ఉంటుంది: Debian మరియు Raspberry Pi OS ఇమేజ్లు సాధారణంగా టెంప్లేట్ ఇన్స్టెన్స్ను అందిస్తాయి, ఉదాహరణకు openvpn-server@server, పాత ఇన్స్టాల్లు openvpn@server ఉపయోగిస్తాయి. ఫైల్ పేరు నుండి ఊహించడం కంటే ఏది నడుస్తోందో నిర్వాహకుడిని అడగండి.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

చదవండి ExecStart= ఆ అవుట్పుట్లో. ఇది ఎక్జిక్యూటబుల్ మరియు నిర్వాహకుడు నిజంగా ప్రారంభించే ఎంపికలను, ఏదైనా --config మార్గంతో సహా పేర్కొంటుంది; దగ్గరలో ఉన్న మరియు ఏ ఆదేశం సూచించని కాన్ఫిగరేషన్ ఫైల్ నడుస్తున్న సొరంగంలో భాగం కాదు.

డీమన్ పరిష్కరించిన కాన్ఫిగ్ గొలుసును అనుసరించండి

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

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

హోమ్ డైరెక్టరీలోని .ovpn ఫైల్ క్లయింట్ కళాఖండం. సర్వర్ డీమన్ దాన్ని ఎప్పుడూ చదవదు, కాబట్టి సర్వర్-వైపు హ్యాండ్షేక్ వైఫల్యాన్ని సరిచేయడానికి ఆ ఫైల్ను సవరించడం ఏమీ సాధించదు.

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

లాగ్ను ప్రక్రియతో జతచేయండి, మీరు గుర్తుంచుకున్న లోపంతో కాదు

రెండు లాగ్ గమ్యస్థానాలు సాధారణం, వాటిలో ఒకటి మాత్రమే journal. log-append సెట్ చేసినప్పుడు డీమన్ ఆ ఫైల్లో రాస్తుంది, journal ప్రారంభ వరుసలకు మించి కొద్దిగా మాత్రమే ఉంచుతుంది. అది లేకుండా journalctl సంఘటనల మూలం.

journalctl -u openvpn-server@server -n 80 --no-pager

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

పాత లాగ్ నమోదు ఐదు నిమిషాల క్రితం డౌన్లోడ్ చేసిన ప్రొఫైల్ గురించి ఏమీ నిరూపించదు. క్లయింట్ ఫైల్ను మళ్లీ సృష్టించి, ఒకసారి కనెక్ట్ అయి, ఆ ప్రయత్నంలో కనిపించిన వరుసలను మాత్రమే చదవండి.

చివరి సాధారణ వైఫల్యానికి బదులుగా మొదటి నిర్దిష్ట వైఫల్యాన్ని నమోదు చేయండి. bind లోపం, ప్రతిస్పందన లేని బాహ్య మార్పిడి, సర్టిఫికెట్ తిరస్కరణ మరియు ఖాతా తిరస్కరణ ప్రతి ఒక్కటి వేరే పొరకు పంపుతాయి, చివరలో వచ్చే టైమౌట్ తరచుగా పైన ఉన్న ఉపయోగకరమైన సంఘటనను దాచుతుంది.

సొరంగాన్ని మళ్లీ నిర్మించడం నిర్ధారణ దశ కాదు

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

అదే tls-auth లేదా tls-crypt నిలిపివేయడం, verify-x509-name సడలించడం, లేదా ఆకుపచ్చ స్థితి కోసం రెండవ కారకాన్ని వదలడం అన్నింటికీ వర్తిస్తుంది. ధృవీకరణ తొలగించబడినందున కనెక్ట్ అయ్యే సొరంగం వేరే వ్యవస్థ, మరమ్మతు చేయబడినది కాదు.

లాగ్ పేర్కొన్న పొరలో ఒక పరిమిత మార్పు చేసి, అదే యూనిట్ను రీస్టార్ట్ చేసి, ఆ ఒకే కనెక్షన్ ప్రయత్నాన్ని పునరావృతం చేయండి. అది పోలికను నిజాయితీగా ఉంచుతుంది, మీరు తిరిగి మార్చగల మార్పును వదిలిస్తుంది.

తదుపరి వ్యక్తికి ఏమి అప్పగించాలి

నాలుగు వాస్తవాలను అవి ఇంకా మీ దగ్గర ఉన్నప్పుడే రాయండి: OpenVPN సంస్కరణ openvpn --version నుండి, యాక్టివ్ యూనిట్, ఇన్క్లూడ్లతో కాన్ఫిగ్ గొలుసు, మరియు ఒక ప్రయత్నాన్ని కవర్ చేసే లాగ్ విండో. ఆ నాలుగు అస్పష్ట ఫిర్యాదును పునరుత్పాదనీయ కేసుగా మారుస్తాయి.

పంచుకునే ముందు సున్నితమైన డేటాను క్షుణ్ణంగా తొలగించండి. ప్రైవేట్ కీలు, auth-user-pass ఫైళ్లు, స్టాటిక్ కీ మెటీరియల్ మరియు పూర్తి క్లయింట్ బండిళ్లు టికెట్లో ఉండకూడదు; ఎంపికల పేర్లు మరియు గొలుసు ఆకారం సాధారణంగా రెండవ జత కళ్లకు సరిపోతాయి.

గొలుసు చెక్కుచెదరకుండా ఉండి లాగ్ ఇంకా నెట్వర్క్ను సూచిస్తే, తదుపరి దశ క్లయింట్ మరియు సర్వర్ మధ్య మార్గం, మరో ఇన్స్టాల్ కాదు. అదే సహాయకుడు ఎప్పుడూ కలిగి లేని కథ భాగం.