Ubuntu అప్‌గ్రేడ్ తర్వాత OpenVPN కనెక్ట్ కావడం ఎందుకు ఆగిపోయింది?

గత వారం పనిచేసిన VPN ప్రొఫైల్‌లు Ubuntu విడుదల అప్‌గ్రేడ్ తర్వాత విరిగిపోతాయి, లాగ్ ఆ అప్‌గ్రేడ్‌ను అరుదుగా ప్రస్తావిస్తుంది. అది పేరు చెప్పేది విఫలమైన పొరను: TLS హ్యాండ్‌షేక్, డేటా ఛానెల్ కోసం చర్చించిన సైఫర్, ఇన్‌స్టాల్ చేసిన ప్యాకేజీ, లేదా బైనరీ ప్రారంభంలో లోడ్ చేసే OpenSSL కాపీ. ప్రతి పొరకు దాని స్వంత లోప రూపం మరియు స్వంత మరమ్మత్తు ఉంటాయి, అందువల్ల వర్గీకరణ మొదటి పని, సవరణ రెండవ పని. లాగ్ దానిని పేరు చెప్పే వరకు ప్రొఫైల్‌ను నిర్దోషిగా పరిగణించండి.

ఏ పొర విఫలమైంది: హ్యాండ్‌షేక్, సైఫర్, ప్యాకేజీ లేదా లైబ్రరీ

ప్రొఫైల్‌ను తాకే ముందు క్లయింట్ లాగ్ చదవండి. అవుట్‌పుట్‌లోని మొదటి లోపం పొరను గుర్తిస్తుంది; తర్వాత ముద్రించబడేదంతా సాధారణంగా ఆ మొదటి వైఫల్యం పరిణామం. క్లయింట్ అసలు ప్రారంభం కాకపోతే, VPN లాగ్ తెరవడానికి తప్పు ఫైల్.

సర్టిఫికెట్‌లు మరియు సంతకాల గురించిన ఫిర్యాదులు, లేదా కీ పొడవు గురించిన సందేశం, నియంత్రణ ఛానెల్ నుండి మరియు దానిని నియంత్రించే లైబ్రరీ విధానం నుండి వస్తాయి. కానీ DEPRECATED OPTION తో ప్రారంభమయ్యే హెచ్చరిక డేటా-ఛానెల్ చర్చలకు చెందుతుంది.

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

హ్యాండ్‌షేక్ విఫలమైనప్పుడు, TLS విధానం సర్టిఫికెట్‌ను తిరస్కరిస్తుంది

Ubuntu 22.04 సిస్టమ్‌ను OpenSSL 3కి తరలించింది, ఆ శాఖలో డిఫాల్ట్ భద్రతా స్థాయి సర్టిఫికెట్ సంతకాలు మరియు కీ పరిమాణాల విషయంలో 20.04 కంటే కఠినంగా ఉంది. పాత డైజెస్ట్‌తో సంతకం చేసిన CA సర్టిఫికెట్, లేదా ప్రస్తుత పరిమితి కంటే తక్కువ కీ, ఇప్పుడు హ్యాండ్‌షేక్ సమయంలో విఫలమవుతాయి. ఇంకా ఏదీ ధృవీకరించబడనందున, లోపం తప్పు పాస్‌వర్డ్ లేదా చనిపోయిన సర్వర్‌లా చదవబడుతుంది.

ఇరుకైన మరమ్మత్తు ఈ కనెక్షన్‌కు మాత్రమే సైఫర్ స్ట్రింగ్‌ను జోడిస్తుంది. డెస్క్‌టాప్ ఎడిటర్‌లో ప్రొఫైల్ తెరిచి, అధునాతన సెట్టింగ్‌లకు వెళ్లి, DEFAULT:@SECLEVEL=0 ను TLS సైఫర్ ఫీల్డ్‌లో ఉంచండి. NetworkManager కీ-ఫైల్ [vpn] కింద అదే విలువను తీసుకుంటుంది:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

NetworkManagerను పునఃప్రారంభించి మళ్లీ కనెక్ట్ అవ్వండి, ఎందుకంటే డీమన్ పార్స్ చేసిన ప్రొఫైల్‌లను క్యాష్ చేస్తుంది, లేకపోతే ఇప్పటికే ఉన్న కాపీని వాడుతూనే ఉంటుంది. పంక్తిని ఉంచే ముందు అది ఏమి చేస్తుందో తెలుసుకోండి: ఆ సెట్టింగ్ సైఫర్ పేరు కాదు, అనేక సర్టిఫికెట్ మరియు కీ పారామితులపై ఒక పరిమితి, కాబట్టి దాన్ని తగ్గించడం ఒకే ప్రొఫైల్ అంగీకరించే పరిధిని విస్తరిస్తుంది. ఏ సర్వర్ దాన్ని కోరిందో గుర్తించి, ఆపరేటర్ ప్రస్తుత సామగ్రిని మళ్లీ విడుదల చేసినప్పుడు సెట్టింగ్‌ను వదిలేయండి. కానీ /etc/ssl/openssl.cnf మార్చడం ఆ ఫైల్ చదివే ప్రతి ప్రోగ్రామ్‌కు అదే పరిమితిని చేరుతుంది, ఇది VPN కంటే చాలా దూరం.

OpenVPN 2.6 చర్చల కోసం సైఫర్ జాబితా చేయాలని కోరుతుంది

Ubuntu 22.10 OpenVPN 2.6 తెచ్చింది, ఆ విడుదలలో --cipher తనంతట తాను డేటా ఛానెల్‌ను ఎంచుకోవడం ఆపేస్తుంది. సైఫర్ చర్చించిన data-ciphers జాబితాలో కూడా ఉండాలి, లేకపోతే క్లయింట్ పాతబడిన హెచ్చరికను ముద్రించి తర్వాత టన్నెల్‌ను పైకి లేపలేదు.

అదే కాలానికి చెందిన NetworkManager ప్లగిన్ ఇంకా పాత ఆదేశాన్ని మాత్రమే రాసింది. ఈ వివరం నిర్ధారణను విభజిస్తుంది, ఎందుకంటే చేతితో సరిదిద్దిన ప్రొఫైల్ షెల్ నుండి కనెక్ట్ కావచ్చు, డెస్క్‌టాప్ యాప్‌లెట్ నుండి ఇంకా విఫలమవచ్చు. జాబితాను కనెక్షన్ ఫైల్‌లో [vpn] కింద జోడించండి:

data-ciphers=AES-256-CBC

సర్వర్ ప్రకటించే విలువను వాడండి, మీకు గుర్తున్నది కాదు; AES-256-GCM అందించే సర్వర్ CBC మాత్రమే పేరు చెప్పే క్లయింట్ జాబితాతో చర్చలు జరపదు. మేనేజర్‌ను పునఃప్రారంభించి మళ్లీ కనెక్ట్ అవ్వండి, తర్వాత షెల్ నుండి ప్రయత్నాన్ని పునరావృతం చేయండి మరియు సైఫర్‌ను చర్చలు మరియు ప్రత్యామ్నాయం రెండింటికీ స్పష్టంగా ఇవ్వండి:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

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

ప్యాకేజీ మరియు ప్లగిన్ లోపాలు VPN లోపాలలా కనిపిస్తాయి

అప్‌గ్రేడ్ తర్వాత ప్రతి వైఫల్యం గూఢలిపి సంబంధితం కాదు. విడుదల ఉపయోగించని కోడ్ పేరు కింద జోడించిన OpenVPN రిపాజిటరీ ఎప్పుడూ ఇన్‌స్టాల్ కాని ప్యాకేజీని ఇస్తుంది, కాబట్టి lsb_release -a ఏమి నివేదిస్తుందో మీరు జోడించిన జాబితా ఫైల్‌తో పోల్చండి. తప్పిపోయిన universe భాగం లేదా భద్రతా జేబు అసలు కనుగొనలేని ప్యాకేజీని ఇస్తుంది. రెండు సందర్భాలలో ప్రొఫైల్ తాకబడకుండా, టన్నెల్ అసాధ్యంగా ఉంటుంది.

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

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

విక్రేత లైబ్రరీ విధాన లోపం వెనుక దాగవచ్చు

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

VPN ప్యాకేజీని మళ్లీ ఇన్‌స్టాల్ చేయడం ఏ లైబ్రరీ మొదట కనుగొనబడుతుందో మార్చదు, TLS స్థాయిని తగ్గించడం సిస్టమ్ నుండి ఎప్పుడూ రాని లైబ్రరీని చేరుకోలేదు. బైనరీ నిజంగా ఏ గూఢలిపి వస్తువులను పరిష్కరిస్తుందో లోడర్‌ను అడగండి:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

విక్రేత కాపీని తొలగించి లేదా మళ్లీ మళ్లించి, తర్వాత అదే తనిఖీని మళ్లీ నడపండి. ప్రొఫైల్‌కు తిరిగి వెళ్లే ముందు ఆశించిన సంస్కరణే వాడుకలో ఉండాలి.

పాత క్లయింట్‌ను పిన్ చేయడం సమయాన్ని కొంటుంది, పరిష్కారాన్ని కాదు

మునుపటి క్లయింట్ సంస్కరణను ఉంచుకోవడం పట్టు ఉన్నంత కాలం టన్నెల్‌ను పునరుద్ధరిస్తుంది. అది ఆ ప్యాకేజీ భద్రతా నవీకరణలను స్తంభింపజేస్తుంది మరియు తదుపరి అప్‌గ్రేడ్‌కు అదే విరిగిపోవడాన్ని ప్లాన్ చేస్తుంది, కాబట్టి దీన్ని పరిష్కారంగా కాక తేదీ ఉన్న తాత్కాలిక చర్యగా పరిగణించండి.

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

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