tls-auth key-direction: 0 మరియు 1 భిన్నంగా ఉండాలి, సరిపోలకూడదు
tls-auth తో రెండు చివరలకూ వ్యతిరేక దిశలు కావాలి, 0 మరియు 1, లేదా రెండూ సెట్టింగ్‌ను వదిలేయాలి. అదే సంఖ్య విఫలమవుతుంది, tls-crypt దాన్ని ఎప్పుడూ ఉపయోగించదు.
సొరంగం ఒక వైపు మరో వైపు ఎప్పుడూ తనిఖీ చేయని కీ స్లాట్‌తో నియంత్రణ ఛానెల్‌పై సంతకం చేస్తుంది, ఒకే ఒక సర్టిఫికెట్ కూడా మార్పిడి కాకముందే కనెక్షన్ ప్రామాణీకరణ లోపంతో మరణిస్తుంది. tls-auth దిశ అసమతుల్యత ఇలాగే కనిపిస్తుంది, అది నిర్ణాయకం: అదే రెండు ఫైళ్లు ప్రతి ప్రయత్నంలో, ఏ నెట్‌వర్క్ నుండైనా విఫలమవుతాయి. లాగ్‌లో మీరు వెతుకుతున్న ఎంపిక పేరు లేదు, అందుకే ప్రజలు ఎప్పుడూ పగలని కీలను మళ్లీ నిర్మిస్తారు, సర్టిఫికెట్లను మళ్లీ జారీ చేస్తారు. పరిష్కారం రెండు చివరలను పూరకంగా చేయడం, లేదా రెండింటినీ ద్విదిశగా వదిలేయడం, ధృవీకరణను బలహీనపరచడం కాదు.
వైఫల్యం సర్టిఫికెట్లకు ముందే సంభవిస్తుంది
tls-auth తో రెండు పీర్లు ఒకే పంచుకున్న కీని కలిగి ఉంటాయి, ప్రతి ఒక్కటి దాని నుండి ఉత్పన్నమైన రెండు స్లాట్లలో ఒకటి ఉపయోగిస్తుంది: ఒక స్లాట్ బయటకు వెళ్లే నియంత్రణ ప్యాకెట్లపై సంతకం చేస్తుంది, మరొకటి లోపలికి వచ్చే వాటిని ధృవీకరిస్తుంది. దిశ 0 మరియు దిశ 1 ఈ పాత్రలను వ్యతిరేక క్రమంలో కేటాయిస్తాయి, కాబట్టి HMAC తనిఖీలు సరిపోలాలంటే జంట పూరకంగా ఉండాలి. ఒక వైపు కేటాయింపు తిరగబడితే, గ్రహీత తప్పు స్లాట్‌లో సంతకం వెతికి ప్యాకెట్‌ను తిరస్కరిస్తాడు. అక్కడే సెషన్ ముగుస్తుంది, అందుకే లోపం ప్యాకెట్ ప్రామాణీకరణకు సంబంధించినది, సర్టిఫికెట్ నిల్వ ఉత్పత్తి చేసే దానికి కాదు.
నిర్ణాయకత నిర్ధారణకు ముఖ్యం, ఎందుకంటే సమయం లేదా మార్గ సమస్య వేరే గుర్తును వదిలిస్తుంది: అప్పుడప్పుడు కోతలు, ఒక దిశ విఫలం కావడం, లేదా నిర్దిష్ట నెట్‌వర్క్‌లో మాత్రమే మరణించే సెషన్. దిశ అసమతుల్యత ప్రతిసారీ మొదటి హ్యాండ్‌షేక్‌లో విఫలమవుతుంది, అదే రెండు ఫైళ్లు ఉన్న మరో యంత్రంలోనూ అలాగే విఫలమవుతుంది. --verb 4 వద్ద లాగ్ చదివి చివరి పంక్తికి బదులు మొదటి తిరస్కరించిన ప్యాకెట్‌ను కనుగొనండి. ఆ తిరస్కరణ ఏదైనా సర్టిఫికెట్ మార్పిడికి ముందే జరిగితే, పంచుకున్న కీ మరియు దాని దిశ తనిఖీ చేయదగిన రెండు విషయాలు.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
సంఖ్య ఎక్కడ నివసిస్తుంది
OpenVPN 2.6 మాన్యువల్ దిశ కోసం రెండు స్థలాలను నమోదు చేస్తుంది: కీ ప్రత్యేక ఫైల్‌లో ఉన్నప్పుడు tls-auth యొక్క రెండవ ఆర్గ్యుమెంట్, కీ ప్రొఫైల్‌లో ఇన్‌లైన్‌గా ఉన్నప్పుడు ప్రత్యేక key-direction పంక్తి. రెండూ ఒకే విలువను సెట్ చేస్తాయి, కాబట్టి ప్రొఫైల్ ఒక రూపాన్ని లేదా మరొకదాన్ని ఉపయోగించాలి, ఎప్పుడూ రెండింటినీ కాదు. వదిలేయడం కూడా ఒక ఎంపిక, అది రెండు పీర్లను ద్విదిశ అమరికలో ఉంచుతుంది, ఏ వైపూ దిశను పేర్కొననప్పుడు అది పని చేస్తుంది. ఒకే సంఖ్య ఉన్న రెండు పీర్లు ఆ అమరికలో లేవు: ప్రతి ఒక్కటి ఒక స్లాట్‌లో సంతకం చేసి మరొకదానిలో ధృవీకరించాలని ఆశిస్తుంది, రెండూ అదే విధంగా చేస్తాయి.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
ఇన్‌లైన్ రూపం తన సొంత పంక్తిలో ఒక సూచన, కీ బ్లాక్ యొక్క తెరిచే ట్యాగ్‌పై లక్షణం కాదు, ఆ ట్యాగ్‌కు ఆర్గ్యుమెంట్ జోడించడం లోపం, దిశ మార్పు కాదు. స్థానం కూడా ముఖ్యం: సూచన తాను చెందిన బ్లాక్ వెలుపల ఉంటుంది, కాబట్టి బ్లాక్ లోపల రాసిన విలువ కీ పదార్థంగా చదవబడుతుంది. ప్రొఫైల్ పంపిణీదారు ఉద్దేశించిన అమరికను కాపీ చేయండి, జంటను కల్పించడం బదులు, ఎందుకంటే ఒక సర్వర్‌కు వ్యతిరేకంగా పని చేసే ప్రొఫైల్ ఇప్పటికే మరో వైపు ప్రతిబింబించి ఉండవచ్చు.
ఎంపిక ఏమి తాకదు
ఇది అప్లికేషన్ ట్రాఫిక్‌ను ఎన్‌క్రిప్ట్ చేయదు. tls-auth నియంత్రణ ఛానెల్ ప్యాకెట్ల చుట్టూ HMAC పెడుతుంది, డేటా ఛానెల్ హ్యాండ్‌షేక్ సమయంలో సమావేశమైన సెషన్ కీలతో రక్షించబడుతుంది, కాబట్టి నిర్గమనం లేదా సైఫర్ ప్రశ్నకు దిశ సంఖ్యతో ఎలాంటి సంబంధం లేదు. సెట్టింగ్ రెండవ ఎన్‌క్రిప్షన్ పొరను కూడా జోడించదు, పొడవైన కీ కోసం వెతకడానికి ప్రజలను పంపేది ఆ ఊహే.
ఇది tls-crypt కు వర్తించదు, దాని సొంత ఎంపికలు మరియు కీ నిర్వహణ ఉన్న మరో నియంత్రణ ఛానెల్ విధానం, మరియు ఏ పీర్ యొక్క సర్టిఫికెట్ గుర్తింపు గురించీ ఏమీ చెప్పదు. కాబట్టి పని చేసే దిశ సరిపోలిక రెండు చివరలు నియంత్రణ ఛానెల్‌ను ఎలా ప్రామాణీకరించాలనే దానిపై ఏకీభవిస్తున్నాయని మాత్రమే నిరూపిస్తుంది, విశ్వాస గొలుసు ధృవీకరించబడిందని కాదు.
జంటను సమలేఖనం చేసి మళ్లీ కనెక్ట్ అవ్వండి
ఏదైనా మార్చే ముందు రెండు కాన్ఫిగరేషన్లను పోల్చండి, ఎందుకంటే ఇప్పటికే సరైన వైపును సవరించడం పనిని రెట్టింపు చేస్తుంది. క్రింది grep ప్రతి ఫైల్ ఏ విధానాన్ని ఎంచుకుంటుందో చూపిస్తుంది; వివరమైన అమలు నియంత్రణ ఛానెల్ ప్రామాణీకరించబడిందో లేదో చూపిస్తుంది. రెండు అవుట్‌పుట్‌లను ఉంచండి, తదుపరి మార్పును తెలిసిన స్థితితో పోల్చవచ్చు.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
ఏ మార్పు తర్వాతైనా రెండు పీర్లను మళ్లీ ప్రారంభించండి, ఎందుకంటే ఈ ఎంపికలు ప్రారంభంలో ఒకసారి చదవబడతాయి, ఒక వైపును మళ్లీ లోడ్ చేయడం పాత సెషన్ పూర్తి జీవితకాలంలో జంటను అసంగతంగా వదిలిస్తుంది. అమలు ఇప్పుడు దిశ కాన్ఫిగర్ చేయకుండా పని చేస్తుంటే, ఒక పీర్‌పై సెట్టింగ్ జోడించడం మీరు ప్రారంభించిన వైఫల్యాన్ని పునరుత్పత్తి చేస్తుంది; రెండింటినీ వదిలేయండి లేదా రెండింటినీ కాన్ఫిగర్ చేయండి. ఒకసారి ఒక చివర మార్చి మునుపటి ఫైల్‌ను ఉంచండి, తిరోగమనం పునర్నిర్మాణం కాదు, రెండు నిమిషాల పునరుద్ధరణ అవుతుంది.
ప్రతి చివరకు విధానం, కీ ఫైల్ మరియు దిశను అమలు గమనికలలో నమోదు చేయండి, లేకపోతే తదుపరి వ్యక్తి సమానమైన రెండు ఫైళ్లను చదివి సంఖ్యలు ఒకదానితో ఒకటి సరిపోలాలని భావిస్తాడు. దిశ సమన్వయ వివరం, భద్రతా పెంపు కాదు: అది నియంత్రణ ఛానెల్ యొక్క రెండు దిశలను వేరు చేస్తుంది, మరేమీ చేయదు.