VPN ची खाजगी किल्ली कुठे राहावी: फाइल, CNG की TPM?

दोन प्रश्न ठरवतात की 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 प्रोफाइल त्याची पडताळणी कशी होते ते समाविष्ट करते; त्या पडताळणीचा कोणताही भाग फिरण्यापूर्वी कॉपी केलेल्या खाजगी किल्लीचे संरक्षण करत नाही.

निर्णय एका ठिकाणी लिहा: कोणता साठा किल्ली ठेवतो, कोणती प्रक्रिया ती वापरू शकते, कोण ती पुन्हा जारी करू शकते आणि परती काय आहे. तोच परिच्छेद ऑडिटर विचारतात, आणि तोच कर्मचारी बदलात टिकतो.