OpenVPN tls-ciphersuites vs tls-version-min: ప్రతి ఒక్కటి ఏమి అమలు చేస్తుంది

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

ఏ జాబితాను చదవడానికి ముందు బిల్డ్‌ను తనిఖీ చేయండి

ప్రోటోకాల్ మద్దతు లేని బైనరీకి కాన్ఫిగరేషన్ సూచన దానిని జోడించలేదు. కంపైల్ చేసిన క్రిప్టో లైబ్రరీ పేరును తెలిపే వెర్షన్ బ్యానర్‌తో ప్రారంభించండి:

openvpn --version

OpenSSL తో లింక్ చేసిన 2.6 బిల్డ్ tls-cipher మరియు tls-ciphersuites రెండింటినీ అంగీకరిస్తుంది. mbed TLS తో బిల్డ్‌లో TLS 1.3 సూట్ ఎంపిక అసలు లేదు, మరియు 2.6 మాన్యువల్ tls-ciphersuites ను OpenSSL ఎంపికగా గుర్తిస్తుంది. సర్వర్ మరొక బ్యాకెండ్‌తో తిరిగి నిర్మించబడితే, అదే ప్రొఫైల్ కాన్ఫిగరేషన్ ఒక పంక్తి కూడా మారకుండా దాని ప్రవర్తనను మార్చగలదు.

మీరు ఇక్కడ ఉన్నప్పుడు openvpn --show-tls ను అమలు చేసి అవుట్‌పుట్‌ను ఉంచండి. అదే తర్వాత పోల్చుకునే జాబితా, మరియు ఎవరైనా ప్రొఫైల్‌లను సవరించడం ప్రారంభించక ముందు దాన్ని పట్టుకోవడం చవక.

బ్యానర్ మరియు జాబితాను చాట్ విండోలో కాదు, మార్పు టికెట్‌లో రాయండి. ఆరు వారాల తర్వాత క్లయింట్ సూట్ అందించగలదా అని ఇద్దరు వాదించినప్పుడు, పట్టుకున్న అవుట్‌పుట్ దాన్ని ఒక పంక్తిలో నిర్ణయిస్తుంది.

వెర్షన్ పరిమితులను సైఫర్ జాబితాల నుండి వేరుగా ఉంచండి

2.6 మాన్యువల్‌లో ఇవి ఒకటి కాదు, మూడు నియంత్రణలు:

• tls-cipher TLS 1.2 మరియు అంతకు ముందు వాటికి సైఫర్ విధానాన్ని నిర్ణయించి OpenSSL సైఫర్ జాబితాకు పంపబడుతుంది;
• tls-ciphersuites TLS 1.3 సూట్‌లను ఎంచుకుంటుంది;
• tls-version-min మరియు tls-version-max కనెక్షన్ ఉపయోగించగల ప్రోటోకాల్ వెర్షన్‌లను పరిమితం చేస్తాయి.

కాబట్టి జాగ్రత్తగా కత్తిరించిన TLS 1.3 సూట్ జాబితా పాత వెర్షన్ ఇంకా అనుమతించబడుతుందని ఏమీ నిరూపించదు. అవసరం «TLS 1.3 మాత్రమే» అయితే, దాన్ని మోసేది వెర్షన్ దిగువ పరిమితి, మరియు సూట్ జాబితా ఆ పరిమితి లోపల ఎంపికలను మాత్రమే సంకోచిస్తుంది:

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

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

డేటా ఛానెల్ నాల్గవ నియంత్రణ. data-ciphers సొరంగం లోపల సమరూప సైఫర్‌పై చర్చలు చేస్తుంది, మరియు దాని ఫలితం నియంత్రణ ఛానెల్ యొక్క TLS వెర్షన్ గురించి ఏమీ చెప్పదు. సెషన్ సారాంశంలో AES-256-GCM కనిపించడం ఏ దిశలోనూ TLS 1.3 కి సాక్ష్యం కాదు.

show-tls ను స్థానిక జాబితాగా చదవండి

--show-tls ఈ బైనరీ లింక్ చేయబడిన క్రిప్టో లైబ్రరీ మద్దతిచ్చే సూట్‌లను ప్రాధాన్య క్రమంలో జాబితా చేస్తుంది. ఇది గేట్‌వే నుండి వచ్చిన నివేదిక కాదు. జాబితా స్థానిక లైబ్రరీ నుండి వస్తుందని మాన్యువల్ స్పష్టంగా చెబుతుంది, అంటే OpenSSL 3.x ఉన్న ల్యాప్‌టాప్ మరియు పాత బిల్డ్ ఉన్న రౌటర్ ఒకే సర్వర్‌తో మాట్లాడుతూ వేర్వేరు జాబితాలను ముద్రిస్తాయి.

క్లయింట్ A, B మరియు C సూట్‌లకు మద్దతిస్తుంది మరియు ఒక సెషన్ B ను ఎంచుకుంటుందని అనుకుందాం. సర్వర్ A లేదా C కి అనుమతిస్తుందా, లేదా B దాని ఏకైక అనుమతించిన ఎంపికా అనేది అది ఏమీ నిర్ధారించదు. మూడు వరుసలను వేరుగా ఉంచండి, గందరగోళ TLS చర్చలలో చాలావరకు తమంతట తామే పరిష్కారమవుతాయి.

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

గేట్‌వేను అది సమాధానమివ్వగలిగే ఏదైనా అడగండి

మీరు సేవను నిర్వహిస్తే, డిస్క్‌లోని ఫైల్ కాదు, నడుస్తున్న ఇన్‌స్టాన్స్ యొక్క ప్రభావవంతమైన కాన్ఫిగరేషన్‌ను తనిఖీ చేయండి. OpenVPN మరొక --config మార్గంతో ప్రారంభించబడి ఉండవచ్చు, ఇన్‌క్లూడ్‌లను లాగవచ్చు, మరియు సవరణ తర్వాత పునఃప్రారంభించబడకపోవచ్చు. క్లయింట్‌లు ఎదుర్కొనేది నడుస్తున్న డీమన్ విధానం.

మీరు దాన్ని నిర్వహించకపోతే, ఆపరేటర్‌ను మద్దతు ఉన్న క్లయింట్ అవసరాలు లేదా పరిమిత ఆమోద పరీక్షను అడగండి. తిరస్కరించబడిన ప్రయత్నం స్వయంచాలకంగా తిరస్కరించబడిన సూట్ కాదు: వెర్షన్ దిగువ పరిమితి, remote-cert-tls వంటి సర్టిఫికెట్ గుర్తింపు తనిఖీలు, లేదా tls-auth మరియు tls-crypt మధ్య అసమతుల్యత సూట్ ఎంపిక ముఖ్యమయ్యే ముందే మార్పిడిని ముగించగలవు. క్లయింట్ జాబితాను మార్చే ముందు సర్వర్ లోపాన్ని చదవండి, ఎందుకంటే «handshake failed» నాలుగు వేర్వేరు కారణాలను కవర్ చేస్తుంది మరియు వాటిలో ఒకటి మాత్రమే సైఫర్ అసమతుల్యత.

VPN పోర్ట్ వైపు openssl s_client చూపించడం కూడా ప్రశ్నను పునరుత్పత్తి చేయదు. నియంత్రణ ఛానెల్ OpenVPN యొక్క స్వంత ఫ్రేమింగ్ లోపల నడుస్తుంది, కాబట్టి ముడి TLS ప్రోబ్ వేరే ఏదో ఆశించే పోర్ట్‌లో వేరే ప్రోటోకాల్‌ను పరీక్షిస్తుంది. దాని నుండి తీసుకున్న ఏ నిర్ణయమైనా ప్రోబ్ గురించే, సొరంగం గురించి కాదు.

రెండు ఫలితాలను నమోదు చేసి వాటిని వేరుగా ఉంచండి

కొత్తగా అనుమతించబడిన సెషన్ ప్రోటోకాల్ వెర్షన్ మరియు ఎంచుకున్న సైఫర్‌ను తెలిపే నియంత్రణ ఛానెల్ పంక్తిని, మరియు సొరంగం సైఫర్‌ను తెలిపే ప్రత్యేక డేటా ఛానెల్ పంక్తిని ఉత్పత్తి చేస్తుంది. రెండింటినీ క్లయింట్ వెర్షన్ మరియు ప్రొఫైల్ పేరుతో పట్టుకోండి, మరియు ఏ సర్వర్ ఇన్‌స్టాన్స్ సమాధానమిచ్చిందో గుర్తించండి:

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

తర్వాత ఆ రెండు పంక్తులను జ్ఞాపకం నుండి కాదు, ఆ ఫైల్ నుండి చదవండి. జోడీయే సాక్ష్యం; సూట్ పేరు మాత్రమే ప్రాధాన్యత, మరియు వెర్షన్ పరిమితి సర్వర్ ఏమి తిరస్కరిస్తుందనే దానిపై ప్రత్యేక ప్రకటన.

తనిఖీలను ఈ క్రమంలో చేయండి. --version తో బిల్డ్ మరియు బ్యాకెండ్‌ను నిర్ధారించండి. ఏదైనా మార్చే ముందు --show-tls ను పట్టుకోండి. అవసరమైన వెర్షన్ దిగువ పరిమితిని సూట్ జాబితా నుండి వేరుగా తెలియజేయండి. నడుస్తున్న ఇన్‌స్టాన్స్ యొక్క ప్రభావవంతమైన విధానాన్ని దాని యజమానితో నిర్ధారించండి. ఒక అనుమతించబడిన సెషన్‌ను మరియు ప్రణాళిక అనుమతిస్తే పాత వెర్షన్‌తో ఒక తిరస్కరించబడిన ప్రయత్నాన్ని గమనించండి. నియంత్రణ ఛానెల్ మరియు డేటా ఛానెల్ ఫలితాలను ప్రత్యేక కనుగొన్న అంశాలుగా నమోదు చేయండి.

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