OpenVPN నియంత్రణ ప్యాకెట్ల ట్రేసింగ్: TLS కి ముందు tls-auth

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

కవరు నిర్మించబడే క్రమంలోనే చదవండి

నియంత్రణ ప్యాకెట్ సెషన్ గుర్తింపు, ఐచ్ఛిక tls-auth HMAC, పునరావృత్తి మరియు ఒప్పుకోలు సమాచారం, మరియు నమ్మదగిన సందేశ గుర్తింపును మోసుకుంటుంది, ఆ తర్వాత సందేశ రకం పేలోడ్ వస్తుంది. సందేశం హ్యాండ్‌షేక్ సందేశం అయితే, పేలోడ్ TLS సైఫర్‌టెక్స్ట్ అవుతుంది. సంబంధం అంతే: TLS పదార్థం కవరు ఇప్పటికే రక్షించే సందేశం లోపల ప్రయాణిస్తుంది. చూడండి OpenVPN నెట్‌వర్క్ ప్రోటోకాల్ సూచన నియంత్రణ ఛానెల్ ఫీల్డ్‌లను అదే క్రమంలో జాబితా చేస్తుంది.

నమ్మకత్వ పొరను గూఢలిపి శాస్త్రంగా పొరపాటు పడటం సులభం. ఒప్పుకోలు, మళ్లీ పంపడం మరియు సందేశ గుర్తింపు నమ్మదగని రవాణాపై నియంత్రణ సందేశాలు ఒకసారి, క్రమంగా చేరుకోవడానికి ఉన్నాయి. అవి ప్రామాణీకరణ కాదు, సరైన సందేశ గుర్తింపు ప్యాకెట్‌ను ఎవరు పంపారనే దాని గురించి ఏమీ నిరూపించదు.

ఈ సమూహాన్ని భావనాత్మకంగా ఉంచండి. ఇది బైట్ క్రమ చిత్రం కాదు, ట్యాగ్ లెక్కించడానికి సరిపోదు, ఎందుకంటే HMAC లోకి ప్రవేశించే ఫీల్డ్‌లు అమలు, సంస్కరణ మరియు మోడ్‌పై ఆధారపడి ఉంటాయి.

తనిఖీ హ్యాండ్‌షేక్‌కు ముందే జరుగుతుందని చూపించండి

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

డీమన్ వాచాలత పెంచి, tun పరికరానికి బదులు నియంత్రణ ఛానెల్‌ను గమనించండి:

openvpn --config /etc/openvpn/server.conf --verb 6

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

దిశ నిర్వహణ కూడా ఇక్కడ ఉంది. స్థిర కీ ఫైల్ tls-auth తో ఉపయోగించినప్పుడు, రెండు చివరలు వ్యతిరేక కీ దిశలను తీసుకుంటాయి, పట్టుబడిన ప్యాకెట్ దాని పంపినవారి వైపు తిరిగి ప్రతిబింబించలేని విధంగా ప్రోటోకాల్ ఆ విభజనను ఉపయోగిస్తుంది. దిశను తిప్పితే కీ అలాగే ఉంటుంది, అయినా ప్రతి ప్యాకెట్ విఫలమవుతుంది. ఒకసారి ఒక చివర మార్చి, తర్వాత జోడీ కలిసి లోడ్ అవ్వడానికి రెండు డీమన్‌లను మళ్లీ ప్రారంభించండి.

రెండు చివరల్లో కీ, దిశ మరియు digest సరిపోల్చండి

మూడు విలువలు సరిపోలాలి మరియు వాటిలో ఒకటి మాత్రమే ఫైల్. స్థిర కీ విషయం రెండు చివరల్లో సమానంగా ఉండాలి, దిశ వ్యతిరేకంగా ఉండాలి, HMAC కోసం ఉపయోగించే digest సరిపోలాలి. కీ పదార్థాన్ని తాకే ముందు కాన్ఫిగరేషన్ తనిఖీ చేయండి, ఎందుకంటే ఒక తిరిగిన దిశ చెడిపోయిన ఫైల్ కంటే ఎక్కువ వైఫల్యాలను వివరిస్తుంది:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

పంచుకున్న రహస్యాన్ని ఎడిటర్‌తో కాకుండా సాధనంతో సృష్టించి, అనుమతులను గట్టిగా ఉంచండి:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

tls-auth ను tls-crypt తో గందరగోళపరచకండి. రెండూ నియంత్రణ ఛానెల్‌ను రక్షిస్తాయి, కానీ tls-crypt దాన్ని ఎన్‌క్రిప్ట్ కూడా చేస్తుంది మరియు హ్యాండ్‌షేక్‌ను పరిశీలకుల నుండి దాస్తుంది, మరియు దిశ విభజనను దాని స్వంత కీ నిర్వహణతో భర్తీ చేస్తుంది. ఒకదాన్ని ఉపయోగించే ప్రొఫైల్ మరొకదానికి కాన్ఫిగర్ చేసిన భాగస్వామితో పనిచేయదు, ఏ digest ట్యూనింగ్ ఆ అంతరాన్ని మూసివేయదు.

ట్యాగ్‌ను నిజమైన ఆకృతి నుండి మాత్రమే మళ్లీ సృష్టించండి

బైట్-ఖచ్చితమైన పునఃసృష్టి VPN నడపడం నుండి వేరు పని, అది నిజమైన ఇన్‌పుట్‌లతో మాత్రమే పనిచేస్తుంది: ప్యాకెట్ నిర్మించిన అమలు మరియు సంస్కరణ, ఎంచుకున్న digest, దిశ, మరియు సెషన్ గుర్తింపు, ఒప్పుకోలు శ్రేణి సహా నిజమైన బైట్‌లు. ఫీల్డ్ జాబితా యొక్క పాఠ్య ప్రదర్శన ఆ బైట్‌లు కావు.

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

ఈ అభ్యాసాన్ని ఉత్పత్తి ప్రొఫైల్‌లకు దూరంగా ఉంచండి. ట్యాగ్‌ను మళ్లీ సృష్టించడంలో ఏదీ ఒక అమలు రక్షణను ప్రారంభించాలా లేదా అని చెప్పదు.

రక్షణను తీసివేయకుండా సరిపోలకపోవడాన్ని వెనక్కి తీసుకోండి

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

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

చివరగా, ఉత్తీర్ణమైన తనిఖీ అర్థం ఏమిటో గుర్తుంచుకోండి. భాగస్వామి వద్ద పంచుకున్న కీ ఉందని నిరూపిస్తుంది, వారి సర్టిఫికెట్ లేదా ఖాతా అధికృతమైందని కాదు, మరియు చర్చించిన డేటా-ఛానెల్ సైఫర్ గురించి ఏమీ చెప్పదు. అధికారం మరియు డేటా రక్షణ తర్వాత స్థాపించబడతాయి, కాబట్టి స్వచ్ఛమైన కవరు తనిఖీ ప్రారంభ బిందువు, తీర్పు కాదు.