OpenVPN డైజెస్ట్‌ల గురించిన చాలా చర్చలు తప్పు ప్యాకెట్ నుండే మొదలవుతాయి. auth SHA256 ను “SHA256 అందించే పీర్‌లను మాత్రమే అంగీకరించు” అని చదవడం మొదట మరచాల్సిన విషయం. ఎంపిక నిర్దిష్ట ప్యాకెట్‌లకు డైజెస్ట్‌ను పేర్కొంటుంది, ఆ ప్యాకెట్‌లు ఏవి అనేది ఛానెల్‌పై మరియు ఆ ఛానెల్ AEAD అవునా కాదా అనే దానిపై ఆధారపడి ఉంటుంది. క్రింది నాలుగు ప్రశ్నలను క్రమంగా పరిశీలించండి; ప్రతి ఒక్కటి మీ డిప్లాయ్‌మెంట్‌లో ఈ సెట్టింగ్‌కు ఏ అర్థం ఉండవచ్చో కుదిస్తుంది.

సెట్టింగ్ రక్షించాల్సిన ఛానెల్‌ను పేర్కొనండి

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

క్రింది పట్టిక అదే ఎంపిక ప్రతి సందర్భంలో ఎలా దిగుతుందనే దాని చిన్న రూపం.

ContextWhat the auth digest does
Data channel without AEADSelects the HMAC digest that authenticates each data packet
Data channel with AEAD, such as GCMUnused for the data channel; the cipher authenticates its own packets
Control channel protected by tls-authSelects the HMAC digest for that protection, even when data is AEAD

దానిపై ఆధారపడే ముందు డేటా ఛానెల్ AEAD అవునా కాదా తనిఖీ చేయండి

సమన్వయం చేసుకున్న డేటా సైఫర్ AES-GCM లేదా CHACHA20-POLY1305 అయితే, డేటా ఛానెల్ తనను తాను ప్రామాణీకరిస్తుంది మరియు ప్రత్యేక డైజెస్ట్ మీరు ఊహించే పనిని చేయదు. రెండూ AEAD నిర్మాణాలు, కాబట్టి పేలోడ్‌ను ఎన్‌క్రిప్ట్ చేసే అదే కార్యకలాపం ద్వారా సమగ్రత ఏర్పడుతుంది. ఇది స్థాయి తగ్గింపు కాదు, కానీ “ప్రతి డేటా ప్యాకెట్ HMAC-SHA256” అని సమర్థించబడే విధానం ఆ టన్నెల్‌లో వాస్తవికంగా తప్పు అని అర్థం. విధానాన్ని తిరిగి రాసే ముందు సర్వర్ లాగ్ లేదా క్లయింట్ స్థితి అవుట్‌పుట్‌లో సమన్వయ మూల్యాన్ని నిర్ధారించండి.

ప్రొఫైల్‌లోని జాబితాకు బదులుగా నిజంగా సమన్వయం చేసుకున్న సైఫర్‌ను పరిశీలించండి, ఎందుకంటే సమన్వయం సమితిలోని మరో సభ్యుడి వద్దకు చేరవచ్చు. data-ciphers AES-256-GCM:AES-128-GCM ఒక సమన్వయ జాబితా, మరియు రెండు నమోదులు AEAD, కాబట్టి వాటిలో ఏదీ పేలోడ్ రక్షణ కోసం auth డైజెస్ట్‌ను వినియోగించదు.

నియంత్రణ-ఛానెల్ రక్షణను ప్రత్యేక నిర్ణయంగా పరిగణించండి

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

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

auth ను సైఫర్ సమన్వయం మరియు ధృవపత్రాల నుండి వేరుగా ఉంచండి

మూడు సెట్టింగ్‌లు నిరంతరం కలిపివేయబడతాయి: auth డైజెస్ట్, డేటా-సైఫర్ జాబితా మరియు ధృవపత్రం యొక్క సంతకం అల్గోరిథం. మొదటిది మార్చడం ధృవపత్రాన్ని తిరిగి జారీ చేయదు, దాని సంతకం డైజెస్ట్‌ను ఎంచుకోదు, వినియోగదారు-పాస్‌వర్డ్ పద్ధతిని సృష్టించదు. ప్రోటోకాల్ ఎంపికల నిర్వచనాలు OpenVPN 2.6 మూలాలలో ప్రతి ఒక్కటి దాని స్వంత విభాగంలో వివరిస్తాయి, ఇవి స్వతంత్ర నాబ్‌లు అని గుర్తు చేసుకోవడానికి ఇది ఉపయోగకరం.

డైజెస్ట్ మార్పు తర్వాత పీర్ కనెక్ట్ కావడానికి నిరాకరిస్తే, కారణం సాధారణంగా మిగిలిన రెండు సెట్టింగ్‌లలో ఒకదానిలో అసమతుల్యత. ఏదైనా మార్చే ముందు రెండు చివరలను చదవండి.

విధానాన్ని రాయండి మరియు నడుస్తున్న కాన్ఫిగ్‌లతో పోల్చండి

ఫ్లీట్-స్థాయి ప్రకటన అనుమతించిన డేటా-ఛానెల్ రీతులను మరియు ఎంచుకున్న నియంత్రణ-ఛానెల్ రక్షణను ఒకే వాక్యంలో స్పష్టంగా పేర్కొనాలి. ఆ వాక్యం పరీక్షించదగినది; “మేము SHA256 ఉపయోగిస్తాము” కాదు. తర్వాత దాన్ని రిపాజిటరీలోని టెంప్లేట్‌తో కాకుండా ప్రభావవంతమైన సర్వర్ మరియు క్లయింట్ ప్రొఫైల్‌లతో పోల్చండి.

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

సంబంధిత వ్యాసాలు