openssl rand ले tls-crypt लाई चाहिने कुञ्जी किन बनाउन सक्दैन

OpenSSL पहिले नै स्थापित छ, होस्टसँग इन्ट्रोपी छ, र यससँग कुञ्जी बनाउनु स्पष्ट छोटो बाटो जस्तो लाग्छ। आउटपुट अनियमित र गोप्य र पूर्ण रूपमा अनुपयोगी हुनेछ, र असफलता कुञ्जी ढाँचा उल्लेख गर्ने कुनै कुराको सट्टा नियन्त्रण-च्यानल त्रुटिको रूपमा आउनेछ। यही भ्रम महँगो भाग हो, किनकि यसले मानिसहरूलाई उनीहरूको साइफर जाँच्न पठाउँछ। VPN ले पढ्ने कुरा एक विशिष्ट फाइल संरचना हो, कुनै मनपरी बाइट ब्लक होइन, र यो सुविधाको एउटा प्रकार सर्भर बाहिर बिल्कुलै बनाउन सकिँदैन।

डिस्कमा रहेको फाइल वास्तवमा के हुनुपर्छ

OpenVPN को स्ट्याटिक कुञ्जी फाइल पाठ हो। यो के हो भनी घोषणा गर्ने टिप्पणी लाइनबाट सुरु हुन्छ, स्थिर चौडाइका पङ्क्तिहरूमा हेक्स डेटा बोक्छ, र कुल 256 बाइट कुञ्जी सामग्री हुन्छ। OpenVPN ले यसलाई नियन्त्रण च्यानलको साझा रहस्यको रूपमा पढ्छ, प्रमाणपत्रको रूपमा होइन, पासफ्रेजको रूपमा होइन र TLS पुस्तकालयले चिन्ने कुनै कुराको रूपमा होइन।

उही वस्तु प्रकारले नियन्त्रण च्यानलका दुवै सुविधाहरूको सेवा गर्छ। tls-auth सँग, प्रत्येक पीयरलाई दिशा पनि चाहिन्छ ताकि एक पक्षका प्याकेटहरू उसतर्फ फर्केर परावर्तन हुन नसकून्। tls-crypt सँग, एउटै साझा रहस्यले दुवै दिशामा नियन्त्रण च्यानललाई इन्क्रिप्ट र प्रमाणीकरण गर्छ, जसले ह्यान्डशेक लुकाउँछ र साथै सुरक्षा दिन्छ।

यीमध्ये केही पनि गोप्य ज्ञान होइन, र ढाँचा मुख्य कुरा होइन। मुख्य कुरा यो हो कि फाइल पाठकले अपेक्षा गरेकोसँग ठ्याक्कै मिल्नुपर्छ: हेडर, पङ्क्तिको चौडाइ, अन्तिम नयाँ लाइन र कुल लम्बाइ। एक पङ्क्तिले तलमाथि भएको फाइल फोहोरको रूपमा लोड हुन्छ वा पूर्ण रूपमा असफल हुन्छ। त्यसैले दुई पीयरलाई बाइट-बाइट तुलना गर्नु वैध पहिलो परीक्षण हो, र यो दुई कन्फिगरेसन फाइलमध्ये कुनै पनि पढ्नभन्दा छिटो हुन्छ।

एउटा बनाउने समर्थित तरिका

साधारण स्ट्याटिक कुञ्जी त्यसलाई उपभोग गर्ने उपकरणले बनाउनुहोस्, त्यसपछि दुवै छेउबाट यसको सन्दर्भ दिनुहोस्:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

विकल्पको हिज्जे समयसँगै परिवर्तन भयो: 2.4 युगका पुराना स्थापनाहरूले फाइलनाम अघि छुट्टै झन्डा भएको रूप प्रयोग गर्थे, जबकि हालका बिल्डहरू छोटो रूप स्वीकार गर्छन्। जे भए पनि परिणाम फाइल उही वस्तु प्रकार हो, त्यसैले जाँच दुवै पीयरसँग समान बाइट छन् कि भन्ने हो।

दोस्रो पुस्ताले बाह्य जेनेरेटरले आविष्कार गर्न नसक्ने संरचना थप्छ। सर्भर कुञ्जी एक पटक बनाइन्छ, र प्रत्येक क्लाइन्टले त्यसबाट व्युत्पन्न बेरिएको कुञ्जी प्राप्त गर्छ:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

क्लाइन्टले पाउने कुरा सर्भरको आफ्नै कुञ्जीको प्रतिलिपि होइन। यो सर्भरले मात्र खोल्न सक्ने मेटाडेटा बोक्ने बेरिएको वस्तु हो, र यही बेर्ने कारणले एउटा यन्त्रको फाइल अरू कुनै यन्त्रलाई छुँदै नरद्द गर्न सकिन्छ। सर्भर कुञ्जी सर्भरमै राख्नुहोस् र यसलाई त्यो यन्त्र-आधारित विश्वासको जरा मान्नुहोस्।

हातले बनाएका बाइट कहाँ टुट्छन्

सही हेडरमुनि 256 अनियमित बाइटलाई हेक्सको रूपमा छाप्दा सैद्धान्तिक रूपमा लोड हुने स्ट्याटिक कुञ्जी फाइल प्राप्त हुन्छ। यो तैपनि खराब विचार हो। प्रत्येक ढाँचा विवरण लोडको समयमा असफल हुने वा, अझ नराम्रो, प्रमाणीकरण असफलताको रूपमा मात्र देखिने फरक मानहरूसँग दुई पीयर छोड्ने सामग्री बनाउने अवसर बन्छ।

v2 प्रकारसँग समतुल्य केही पनि सम्भव छैन। बेरिएको क्लाइन्ट कुञ्जी सर्भर कुञ्जी प्रक्रियाको आउटपुटको रूपमा मात्र अवस्थित हुन्छ, र सर्भरले यसलाई खोल्न आवश्यक सामग्री राख्छ। अनियमित ब्लक अस्वीकार हुनेछ वा डिक्रिप्ट हुनै सक्दैन, र दुई सन्देशमध्ये कुनैले पनि अनियमितताको उल्लेख गर्नेछैन।

संस्करण अनुकूलता यी सबैमाथि बस्छ। पहिलो पुस्तालाई दुवै छेउमा यसलाई समर्थन गर्ने रिलिज चाहिन्छ, र दोस्रोलाई फेरि नयाँ रिलिज चाहिन्छ। सुविधा अस्तित्वमा आउनुअघि बनाइएको क्लाइन्टले बेरिएको सामग्री मात्र स्वीकार गर्ने सर्भरसँग ह्यान्डशेक पूरा गर्न सक्दैन, र यसले रिपोर्ट गर्ने असफलताले संस्करणतर्फ होइन, नियन्त्रण च्यानलतर्फ सङ्केत गर्छ।

सबैलाई बाहिर थुन्नुबिना घुमाउने

एउटा साझा रहस्य घुमाउनु समन्वयको अभ्यास हो, प्राविधिक होइन। सर्भरले अघिल्लो फिर्ता नलिनुअघि प्रत्येक क्लाइन्टको हातमा प्रतिस्थापन फाइल हुनुपर्छ, र पुरानो मान अझै राखेको कुनै पनि मेसिन त्यही क्षण असफल हुन्छ। कार्यदिनको बीचमा यो घुमाउने सुरु नगर्नुहोस्।

v2 मिलाइसँग, घुमाउने प्रति यन्त्र हो: एउटा मेसिनका लागि नयाँ बेरिएको कुञ्जी जारी गर्नुहोस् र पुरानोलाई त्यही मेसिनका लागि मात्र अवकाश दिनुहोस्। प्रत्येक क्लाइन्ट यसलाई समर्थन गर्ने रिलिजमा पुगेपछि सर्ने मुख्य तर्क यही हो।

फाइल अनुमतिहरू उही कुराकानीमा पर्छन्। कुञ्जी सेवा चलाउने खातालाई मात्र पढ्न योग्य हुनुपर्छ, र यसले सुरक्षित राख्ने प्रोफाइलहरूसँगै एउटै रिपोजिटरीमा बस्नु हुँदैन। OpenVPN 2.6 सन्दर्भ ले बनाउने रूपहरू र कुञ्जी-सामग्री खण्डहरूको दस्तावेजीकरण गर्छ, जो फोरम पोस्टबाट प्रतिलिपि गरिएको आदेशभन्दा राम्रो स्रोत हो।