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 प्रोफाइल ले यसको प्रमाणीकरण कसरी हुन्छ भन्ने समेट्छ; त्यो प्रमाणीकरणको कुनै भागले घुमाउनुअघि प्रतिलिपि गरिएको निजी कुञ्जीको रक्षा गर्दैन।

निर्णय एक ठाउँमा लेख्नुहोस्: कुन भण्डारले कुञ्जी राख्छ, कुन प्रक्रियाले प्रयोग गर्न सक्छ, कसले पुनः जारी गर्न सक्छ र फर्कने के हो। त्यही अनुच्छेद हो जो लेखापरीक्षक सोध्छन्, र त्यही हो जो कर्मचारी परिवर्तनमा टिक्छ।