DH ఫైలా tls-auth కీనా? రెండు OpenVPN ఫైళ్లను వేరు చేయడం

రెండు ఫైళ్లు, రెండు సూచనలు, మరియు అవి కాన్ఫిగర్ చేసే వస్తువు పేరుతో రెండింటినీ పిలవడం అలవాటు. అలా dh.pem tls-auth పంక్తిలో చేరుతుంది, క్లయింట్ ఊహించని కీ ఫార్మాట్ గురించి సందేశంతో విఫలమవుతుంది. మీ ముందున్న నిర్ణయం ఏ ఫైల్ బలంగా ఉంది అనేది కాదు. అమలుకు నిజంగా ఏ పాత్ర కావాలి అనేది, మూడు షరతులు దాన్ని నిర్ణయిస్తాయి: మీ TLS స్టాక్ ఏ కీ మార్పిడిని చర్చిస్తుంది, నియంత్రణ-ఛానెల్ ప్రామాణీకరణ మీకు కావాలా, మరియు పదార్థం రహస్యంగా ఉండాలా.

వాటికి క్రమంగా సమాధానం ఇవ్వండి, ఫైల్ ప్రశ్న తనకు తానే సమాధానమవుతుంది. వాటిని దాటవేస్తే సూచనల పేర్లు పరస్పరం మార్చుకోగలిగినట్లు కనిపిస్తాయి, పొరపాటు సరిగ్గా ఆ స్థితి నుండే వస్తుంది.

ఫైల్ పేరుకు ముందు లేబుల్ చదవండి

ఫైల్ మొదటి పంక్తి దాని పేరు కంటే ఎక్కువ సమాచారం ఇస్తుంది, ఎందుకంటే పేరు మానవ సంప్రదాయం, లేబుల్ను సాధనం తయారు చేస్తుంది. Diffie-Hellman పారామితులు BEGIN DH PARAMETERS అనే PEM లేబుల్ కలిగి ఉంటాయి. OpenVPN స్థిర కీ పూర్తిగా భిన్న నిర్మాణం, దాని స్వంత శీర్షిక మరియు హెక్స్ పేలోడ్ ఉన్నాయి.

పేరు మార్చడం ఏదీ మార్చదు. ta.key పేరుతో ఉన్న పారామితి ఫైల్ ఇప్పటికీ పారామితులే, dh.pem పేరుతో ఉన్న స్థిర కీ ఇప్పటికీ స్థిర కీయే; పార్సర్ విషయాన్ని చదివి అసంగతిని తిరస్కరిస్తుంది. ప్రొఫైల్ సవరించే ముందు తనిఖీ చేయండి:

head -n 1 dh.pem
head -n 1 ta.key

ఏ ఫైల్ కావాలో నిర్ణయించే మూడు షరతులు

మొదటి షరతు మార్పిడి. పరిమిత క్షేత్రపు Diffie-Hellman చేయి కలపడానికి గ్రూప్ కావాలి, dh సూచన సర్వర్ దానికి పారామితులను పేర్కొనే స్థలం. దీర్ఘవృత్తాకార వక్రం చేయి కలపడానికి ఆ ఫైల్ అసలు కావాల్సిన అవసరం లేదు, ఎందుకంటే వక్రమే పారామితుల సముదాయం. మీ సర్వర్ ECDHE సూట్లతో మాత్రమే చర్చిస్తే, DH ఫైల్ అదనపు శక్తి కాదు, చచ్చిన భారం.

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

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

ప్రతి పాత్రకు సరైన పదార్థాన్ని సృష్టించండి

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

openvpn --genkey tls-auth ta.key

ఆ ఆదేశం కొత్త రహస్య పదార్థాన్ని సృష్టిస్తుంది; ఉన్న కీని మరమ్మతు చేయదు లేదా తనిఖీ చేయదు, మళ్లీ అమలు చేస్తే ఇతర పక్షాల వద్ద లేని వేరే కీ లభిస్తుంది. వచ్చిన ఫైల్ను అవసరమైన పక్షాలకు ఏదైనా పంచుకున్న రహస్యానికి వాడే మార్గం ద్వారా కాపీ చేయండి, దిశ సంప్రదాయాన్ని స్థిరంగా ఉంచండి: tls-auth తో ఒక వైపు key-direction 0, మరో వైపు key-direction 1 ఉపయోగిస్తుంది.

DH పారామితులు అవసరమైనప్పుడు పారామితి ఉత్పత్తి నుండి వస్తాయి, కీ జనరేటర్ నుండి కాదు, ఫలితం పబ్లిక్ అయినా వాటి మూలం ముఖ్యం. తెలియని మూలం నుండి తీసుకున్న గ్రూప్ పబ్లిక్ అవడం వల్ల నమ్మదగినది కాదు; అది ఇప్పటికీ మీ పక్షాలు అంగీకరించే గ్రూప్ గానూ, దాని పరిమాణం లేదా నిర్మాణం బలహీనపరచని దానిగానూ ఉండాలి.

dh none అంటే ఏమిటి, ఏమి కాదు

dh none సంకుచిత అర్థం ఉన్న నిజమైన సూచన: పరిమిత-క్షేత్ర పారామితి ఫైల్ ఏదీ లోడ్ కాదు, ఎందుకంటే చేయి కలపడం దీర్ఘవృత్తాకార వక్రం Diffie-Hellman ఉపయోగిస్తుంది. ఇది ఏదో బలహీనపరచడం అనే అర్థంలో “DH దశను దాటవేయి” అనే సంక్షిప్తం కాదు, OpenVPNకు మరో ఫైల్ను ప్రత్యామ్నాయంగా అంగీకరించమని ఖచ్చితంగా చెప్పదు.

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

తప్పు ఫైల్ ఇప్పటికే అమలు చేయబడి ఉంటే

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

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

ఐదు నిమిషాల తనిఖీ మీరు ఏ సందర్భంలో ఉన్నారో నిర్ణయిస్తుంది: ప్రతి ఫైల్ మొదటి పంక్తి చదవండి, దాన్ని సూచించే సూచనను నిర్ధారించండి, ఫైల్ పంపిణీ పదార్థ అవసరానికి సరిపోతుందా నిర్ధారించండి. ఇది నడిచే PKIని మళ్లీ సృష్టించడం కంటే చిన్న పని, మూడు షరతులు ఎప్పుడూ చూపించిందీ ఇదే.