VPN ప్రైవేట్ కీ ఎక్కడ ఉండాలో రెండు ప్రశ్నలు నిర్ణయిస్తాయి: కీ పదార్థాన్ని హోస్ట్ నుండి కాపీ చేయగలమా, మరియు ఒక ప్రక్రియ కీబోర్డ్ వద్ద ఎవరూ లేకుండా దాన్ని ఉపయోగించగలదా. ఒక నిల్వ మార్కెటింగ్ లేబుల్ రెండింటికీ సమాధానం ఇవ్వదు. పునఃప్రారంభం తర్వాత తిరిగి రావాల్సిన టన్నెల్ డెమన్‌కు పర్యవేక్షణ లేని వాడకం కావాలి, ఇది మనిషి టైప్ చేసిన PINపై ఆధారపడిన ప్రతిదాన్ని మినహాయిస్తుంది.

కాపీ మరియు వాడకం మధ్య ఎంచుకోండి

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

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

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

నిల్వను టన్నెల్ డెమన్‌తో సరిపోల్చండి

డెమన్ దీన్ని భద్రతా విధానం కంటే ఎక్కువగా పరిమితం చేస్తుంది. WireGuard ఫైల్ లేదా wg set ఇన్‌పుట్ నుండి base64 ప్రైవేట్ కీని తీసుకుంటుంది మరియు సర్టిఫికేట్ నిల్వకు మార్గం లేదు, కాబట్టి TPM మద్దతు ఉన్న ఇంటర్‌ఫేస్ కీ ప్రశ్నలో లేదు. OpenSSL 3కి వ్యతిరేకంగా నిర్మించిన OpenVPN ప్రదాత URI ద్వారా కీని లోడ్ చేయగలదు, strongSwan PKCS#11 మద్దతుతో పాటు TPM ప్లగిన్‌ను అందిస్తుంది, కానీ రెండూ మీ ప్యాకేజీ ఎలా కంపైల్ అయిందనే దానిపై ఆధారపడి ఉంటాయి.

ఎంచుకున్న నిల్వను చేరుకోలేని డెమన్ హార్డ్‌వేర్ సరిహద్దును అలంకరణగా మారుస్తుంది. ఎవరో కీని ఒకసారి ఎగుమతి చేసి ఫైల్‌లో వదిలేస్తారు, మిగిలిన డిజైన్ ఆ కాపీపై నిశ్శబ్దంగా నడుస్తుంది.

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

కీని తరలించే ముందు జాబితా చేయండి

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

openssl x509 -in vpn.crt -noout -subject -ext subjectAltName
openssl pkey -in vpn.key -check -noout
openssl x509 -in vpn.crt -noout -pubkey | openssl sha256
openssl pkey -in vpn.key -pubout | openssl sha256

చివరి రెండు సారాంశాలు ఒకేలా ఉండాలి. అలా కాకపోతే డెమన్ సెటప్‌ను పూర్తి చేసి ఆపై ప్రతి ప్రయత్నంలో సర్టిఫికేట్ లేదా సంతకం లోపంతో విఫలమవుతుంది, అది అసలు కారణానికి దగ్గరగా ఎక్కడా సూచించదు. WireGuard సమానమైనది చిన్నది, ఎందుకంటే పబ్లిక్ కీ నేరుగా ప్రైవేట్ నుండి ఉత్పన్నమవుతుంది: wg pubkey < /etc/wireguard/wg0.key మీ సర్వర్ ఇప్పటికే నిల్వ చేసిన పీర్ కీని ముద్రించాలి.

అనుమతులు అదే జాబితాకు చెందుతాయి. stat -c '%a %U:%G' /etc/wireguard/wg0.key 600 root:root తిరిగి ఇవ్వాలి, మరియు సమూహం లేదా ప్రపంచానికి చదవగలిగేది ఏదైనా కీ ఇప్పటికే మీరు ఊహించని ప్రక్రియలకు అందుబాటులో ఉందని అర్థం.

నిల్వ మరియు వాడకం మార్గాన్ని పరిశీలించండి

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

certutil -store -user My
certutil -csp "Microsoft Platform Crypto Provider" -key -user
certutil -verifykeys -user My
ipsec listcerts

Windowsలో మొదటి ఆదేశం వ్యక్తిగత నిల్వను జాబితా చేసి ప్రతి నమోదు పక్కన కీ ప్రదాతను ముద్రిస్తుంది, అక్కడే హార్డ్‌వేర్ మద్దతు ఉన్నట్టు కనిపించే కానీ సాఫ్ట్‌వేర్ ప్రదాతలో కూర్చున్న సర్టిఫికేట్ కనిపిస్తుంది. రెండోది ప్లాట్‌ఫారమ్ క్రిప్టో ప్రదాత కలిగి ఉన్న కీలను జాబితా చేస్తుంది, కాబట్టి అక్కడ లేని VPN గుర్తింపు దాని సర్టిఫికేట్ ఉన్నప్పుడు, ప్రైవేట్ సగం మరెక్కడో నివసిస్తుందని అర్థం. Linux గేట్‌వేలో ipsec listcerts strongSwan ఏమి లోడ్ చేసిందో, TPM ప్లగిన్ నుండి వచ్చిన కీలతో సహా నివేదిస్తుంది. నమోదుల సంఖ్యను నమ్మడం కంటే వేలిముద్రలు లేదా పబ్లిక్ కీ హాష్‌లను జాబితాతో పోల్చండి.

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

పునరుద్ధరణ మరియు తిరిగి రావడం రాయండి

తిరిగి వచ్చేది రెండు కుటుంబాల మధ్య తీవ్రంగా భిన్నం, ఆ భేదం డిజైన్ నోట్‌కు చెందుతుంది, సంఘటన కాల్‌కు కాదు. ఫైల్ కీని ఎన్‌క్రిప్ట్ చేసి బ్యాకప్ చేసి పునరుద్ధరించవచ్చు, కాబట్టి విఫలమైన మార్పిడి తిరగదిస్తారు. ఎగుమతి చేయలేని కీని బ్యాకప్ చేయడమే కుదరదు, ఇది పరికరం చనిపోయినప్పుడు పునఃజారీ మరియు పునఃనమోదును ఏకైక కోలుకోవడం మార్గంగా చేస్తుంది.

గడువు ముగింపును అంతరాయంగా మారకముందే పరిశీలించండి: openssl x509 -in vpn.crt -noout -checkend 2592000 సర్టిఫికేట్ ముప్పై రోజుల్లో ముగిసినప్పుడు సున్నా కాని కోడ్‌తో ముగుస్తుంది, కాబట్టి అది నేరుగా పర్యవేక్షణ తనిఖీలోకి వస్తుంది. ఆ పంక్తి యొక్క వారపు అమలు ఎవరూ ప్రణాళిక వేయని పునరుద్ధరణను పట్టుకుంటుంది.

తొలగింపు సర్వర్‌లో జరుగుతుంది: పీర్‌ను తొలగించండి లేదా క్రమ సంఖ్యను రద్దు చేయండి, తర్వాత టన్నెల్ విఫలమవుతుందని నిర్ధారించండి, ఎందుకంటే కాష్ చేసిన సెషన్ ఉన్న క్లయింట్ సగం పూర్తయిన రద్దును కొంతసేపు దాచగలడు. రద్దు CA డేటాబేస్‌కు మాత్రమే కాదు, కేంద్రీకరణ CRL లేదా OCSP మార్గానికి కూడా చేరాలి. సర్టిఫికేట్ పబ్లిక్ పత్రం, మరియు RFC 5280 ప్రొఫైల్ అది ఎలా ధృవీకరించబడుతుందో కవర్ చేస్తుంది; ఆ ధృవీకరణలో ఏదీ భ్రమణానికి ముందు కాపీ చేసిన ప్రైవేట్ కీని రక్షించదు.

నిర్ణయాన్ని ఒకే చోట రాయండి: ఏ నిల్వ కీని ఉంచుతుంది, ఏ ప్రక్రియ దాన్ని ఉపయోగించగలదు, ఎవరు పునఃజారీ చేయగలరు మరియు తిరిగి వచ్చేది ఏమిటి. ఆ పేరానే ఆడిటర్లు అడిగేది, మరియు సిబ్బంది మార్పు నుండి తప్పించుకునేది.

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