OpenVPN TLS సైఫర్ లోపం: మొదట రెండు వైపులా పోల్చండి

«ఉమ్మడి సైఫర్ లేదు» అనే లోపం ఒకే సెట్టింగ్ మార్చితే సరిపోతుందని అనిపిస్తుంది, కానీ చాలామంది మార్చే సెట్టింగే తప్పు. OpenVPN TLS హ్యాండ్షేక్ చేసే నియంత్రణ ఛానెల్కు మరియు టన్నెల్ లోపల ప్యాకెట్లను మోసుకెళ్లే డేటా ఛానెల్కు వేర్వేరు విధానాలను ఉంచుతుంది, లోపం మొదటిదాన్ని సూచిస్తుండగా ప్రజలు రెండోదాన్ని సవరిస్తారు. ప్రతి వైపు ఏమి అనుమతిస్తుందో సరైన క్రమంలో పోల్చడం ఊహను రెండు లేదా మూడు నిర్ణయాలుగా మారుస్తుంది: సంస్కరణ, తర్వాత సూట్ జాబితా, తర్వాత ఆధారాలు.

ఈ క్రమం తప్పితే ఎప్పుడూ చూడని జాబితాకు AES పేరు జోడించడంలో ఒక గంట వృథా కావచ్చు.

రెండు సైఫర్ జాబితాలు, హ్యాండ్షేక్ను విరిచేది ఒకటే

నియంత్రణ ఛానెల్ TLS సెషన్పై చర్చిస్తుంది, దాని విధానం దీనితో వ్రాయబడుతుంది: tls-cipher TLS 1.2 కోసం మరియు tls-ciphersuites TLS 1.3 కోసం. డేటా ఛానెల్ విడిగా దీనితో కాన్ఫిగర్ చేయబడుతుంది: data-ciphers, ఇక్కడ అసమానత్వం ఏర్పడిన కనెక్షన్ స్థాపించబడి తర్వాత ట్రాఫిక్ దాటలేకపోతుంది. రెండూ సైఫర్ను ప్రస్తావించే లోపాలను ఇస్తాయి, అందుకే అవి గందరగోళానికి గురవుతాయి. ఎప్పటికీ పూర్తికాని హ్యాండ్షేక్ నియంత్రణ ఛానెల్ను సూచిస్తుంది, కానీ స్థాపిత టన్నెల్ ప్యాకెట్లను పడేస్తే అది డేటా ఛానెల్ను సూచిస్తుంది.

మొదటి పంక్తి కాదు, మొత్తం సందేశాన్ని చదవండి. సంస్కరణ అసమానత్వం, లేని సూట్, వైపు తిరస్కరించే ధృవపత్రం సంతకం అల్గోరిథం, మరియు హోస్ట్నామ్ ధృవీకరణ వైఫల్యం—అన్నీ TLS లోపంతో ముగుస్తాయి, వాటిలో ఒకటి మాత్రమే మీ సూట్ జాబితాకు సంబంధించినది. ఈ వర్గాలను వేరు చేయడమే నిర్ధారణలో పెద్ద భాగం.

సూట్లను పోల్చే ముందు సంస్కరణలను పోల్చండి

TLS 1.2 వరకు పరిమితమైన వైపు మరియు 1.3 అవసరమని భావించే వైపు ఉమ్మడి సంస్కరణను పంచుకోవు, ఏ సైఫర్ స్ట్రింగ్ కూడా దాన్ని కలపదు. రెండు వైపులా tls-version-min మరియు tls-version-max నమోదు చేయండి, లేదా ఉపయోగిస్తున్న బిల్డ్ల డిఫాల్ట్లు, ఎందుకంటే పంపిణీ యొక్క OpenSSL విధానం ఏ OpenVPN ఎంపిక చెప్పకుండా కనిష్ఠ పరిమితిని పెంచవచ్చు. ఒక వైపు పరికరం లేదా మూడవ పక్ష క్లయింట్ అయితే, దాని విండో దాని ఫర్మ్వేర్ అనుమతించేది. విండోలు ఒకదానిపై ఒకటి అతివ్యాప్తి చెందిన తర్వాతే సూట్ పోలికకు అర్థం ఉంటుంది.

ఆ రికార్డులు నిజమైన బైనరీ ఫైళ్లను కూడా పేర్కొనాలి. మీ ల్యాప్టాప్లో కమాండ్లైన్ openvpn దిగుమతి చేసిన ప్రొఫైల్ను నిర్వహించే క్లయింట్ కాకపోవచ్చు.

TLS 1.2 మరియు TLS 1.3 జాబితాలు కలవవు

TLS 1.2 సూట్ పేర్లు ఇలా ఉంటాయి: ECDHE-RSA-AES256-GCM-SHA384 మరియు అవి tls-cipher లో చేరతాయి, అది OpenSSL సైఫర్ స్ట్రింగ్ను తీసుకుంటుంది. TLS 1.3 సూట్ల పేరు ఇలా ఉంటుంది: TLS_AES_256_GCM_SHA384 మరియు అవి tls-ciphersuites లో చేరతాయి; 1.2 స్ట్రింగ్కు ఒకటి జోడించడం 1.3 జాబితాను కాన్ఫిగర్ చేయదు, పార్సర్ ఎప్పుడూ సరిపోల్చకుండానే వచనాన్ని అంగీకరించవచ్చు. ఒక సంస్కరణకు సరైన ఫిల్టర్ మరొకదాని గురించి ఏమీ చెప్పదు. ఏ జాబితా ఏ సంస్కరణకు అని రాసి ఉంచండి.

openvpn --show-tls స్థానిక బిల్డ్ ఏమి మద్దతిస్తుందో ముద్రిస్తుంది, అది జాబితా, వాగ్దానం కాదు: దూరపు వైపు ఆ సూట్లను అనుమతించకపోవచ్చు, సక్రియ ప్రొఫైల్ వాటిని ప్రారంభించకపోవచ్చు. ఏ సూట్నూ అందించలేని బిల్డ్ను మినహాయించడానికి దీన్ని వాడి, తర్వాత కాన్ఫిగర్ చేసిన జాబితాలను పోల్చండి.

కొత్త కనెక్షన్పై చర్చను నిరూపించండి

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

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

మార్పు టికెట్లో చర్చించిన సంస్కరణ, సూట్ మరియు డేటా సైఫర్ను నమోదు చేయండి. తదుపరిసారి TLS లోపాన్ని ఎదుర్కొనే వ్యక్తి ఫోరం పోస్ట్లో దొరికిన సైఫర్ స్ట్రింగ్ నుండి కాదు, ఆ రికార్డు నుండి ప్రారంభిస్తారు.