VPN सर्वर की इमेज को क्लोन करना, उसकी पहचान क्लोन किए बिना

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

तीन शर्तें उत्तर तय करती हैं, और वे उस सामग्री की तीन टोकरियाँ हैं जो कोई इमेज उठा सकती है। इमेज बनने से पहले उन्हें छाँटें, दो बार परिनियोजित होने के बाद नहीं।

पहले तय करें कि आप दोनों में से कौन-सा काम कर रहे हैं

बहाली एक सेवा पहचान रखती है। पुराना इंस्टेंस चला गया, नाम और प्रमाणपत्र रहते हैं, और क्लाइंट उसी अंतिम बिंदु पर भरोसा करते रहते हैं। जोड़ना दूसरी पहचान बनाता है जिसे क्लाइंट, लॉग और निरसन सभी को अलग पहचानना पड़ता है।

यह अंतर केवल दिखावटी नहीं है। यदि दो जीवित होस्ट एक ही गेटवे प्रमाणपत्र प्रस्तुत करते हैं, तो कोई क्लाइंट उन्हें अलग नहीं कर सकता, कोई ऑडिट ट्रेल भी नहीं, और उस प्रमाणपत्र को निरस्त करना दोनों को एक साथ हटा देता है। यह शायद ठीक वही हो जो जानबूझकर बनाए गए उच्च उपलब्धता डिज़ाइन को चाहिए, और जल्दबाज़ी में बनाई गई इमेज प्रतिलिपि का इरादा शायद ही यह होता है।

इसलिए पहला निर्णय एक वाक्य है, जो इमेज के बिल्ड होस्ट छोड़ने से पहले लिखा जाता है: यह प्रतिलिपि गेटवे A को बहाल करती है, या यह प्रतिलिपि गेटवे B बनती है। उसके बाद सब कुछ उस वाक्य के मुकाबले हिसाब है। अगर कोई उसे लिख नहीं सकता, तो प्रतिलिपि बनाने के लिए तैयार नहीं है।

पुन: प्रयोज्य इनपुट, पहचान और अधिकार, परिनियोजन स्थिति

पुन: प्रयोज्य टोकरी आसान है: पैकेज, बिना गोपनीय जानकारी वाला समीक्षित कॉन्फ़िगरेशन, सेवा टेम्पलेट, सख़्ती सेटिंग। इमेज वास्तव में इसमें अच्छी होती है, और इसे बिना सीमा के दोहराया जा सकता है।

पहचान और अधिकार की टोकरी वह जगह है जहाँ प्रतिलिपियाँ गड़बड़ाती हैं। गेटवे की निजी कुंजी और प्रमाणपत्र उस गेटवे को हर क्लाइंट के सामने पहचानते हैं। प्रमाणपत्र प्राधिकरण की हस्ताक्षर कुंजी अलग शक्ति वाली अलग वस्तु है: वह पहचान जारी करती है। किसी जारीकर्ता पर भरोसा करने का अर्थ यह नहीं कि हर नए गेटवे को जारी करने की क्षमता चाहिए, और हस्ताक्षर कुंजी को इमेज के भीतर भेजना वह क्षमता हर उस चीज़ को दे देता है जो इमेज पढ़ सकती है।

परिनियोजन स्थिति की टोकरी वह है जिसे लोग भूल जाते हैं क्योंकि वह कॉन्फ़िगरेशन जैसी दिखती है। सुनने के पते, पता पूल, धकेले गए रूट, रिज़ॉल्वर सेटिंग और स्थानीय एकीकरण सभी पहले होस्ट के बारे में मान्यताएँ कूटबद्ध करते हैं। इन्हें कॉपी करने वाला दूसरा नोड ऐसे पूल से आवंटित कर सकता है जो पहले से किसी दूसरे गेटवे का है, या क्लाइंट को ऐसे संसाधन की ओर भेज सकता है जो केवल मूल के पास ही मौजूद है।

नए नोड को क्या मिलना चाहिए, और किससे

स्वतंत्र रूप से प्रबंधित नोड को अपने क्रेडेंशियल स्वीकृत नामांकन प्रक्रिया से मिलने चाहिए, और हस्ताक्षर कार्य वहाँ होना चाहिए जहाँ हस्ताक्षर कुंजी रहती है, नए होस्ट पर नहीं। दर्ज करें कि कौन-सी पहचान अन्य नोड को परेशान किए बिना वापस ली जा सकती है; यदि उत्तर "सभी" है, तो डिज़ाइन में एक ही पहचान है जो दो होने का नाटक करती है।

नेटवर्क मानों को भी वही व्यवहार मिलना चाहिए। ऐसा पूल, सुनने का पता और धकेले गए रूट का समूह चुनें जो मौजूदा गेटवे से टकराए नहीं, और उन्हें इमेज में नहीं बल्कि प्रावधान इनपुट में लिखें। इनपुट समीक्षा योग्य है; इमेज नहीं।

एक वैध मध्यवर्ती स्थिति है। समर्थित रिकवरी या प्रतिकृति डिज़ाइन जानबूझकर एक तार्किक सेवा पहचान को होस्टों के पार रख सकता है, पुरानी प्रतिलिपि तक नियंत्रित पहुँच और रोटेशन योजना के साथ। यह मालिक वाला निर्णय है, इमेज सुविधाजनक थी इसलिए होने वाला कोई डिफ़ॉल्ट नहीं।

openssl x509 -in /etc/openvpn/server/server.crt -noout -subject -issuer -dates
find /etc/openvpn -name '*.key' -o -name '*.pem' | head -20

पहला कमांड बताता है कि नोड वास्तव में कौन-सी पहचान प्रस्तुत करता है और किसने उस पर हस्ताक्षर किए। दूसरा प्रारंभिक सूची है, सबूत नहीं: निजी सामग्री उस निर्देशिका के बाहर, किसी एप्लिकेशन डेटाबेस के भीतर, या ऐसी स्नैपशॉट परत में रह सकती है जिसे चल रहा फ़ाइल सिस्टम अब नहीं दिखाता।

इमेज की एक प्रतिलिपि चुपचाप क्या उठा ले जाती है

किसी इमेज के सबसे नए संशोधन से फ़ाइल हटाना उसे पुराने संशोधनों, परत कैश या उसके रहते समय लिए गए स्नैपशॉट से नहीं हटाता। इसलिए क्रेडेंशियल वाली इमेजों को उनके पूरे जीवनकाल में संवेदनशील वस्तु मानना पड़ता है, केवल निर्माण के क्षण में नहीं।

इमेज की सामग्री और प्रावधान इनपुट को अलग-अलग प्रश्न मानकर जाँचें। इमेज उत्तर देती है "इस कलाकृति के अंदर क्या है", जबकि इनपुट उत्तर देते हैं "पहले बूट पर यह इंस्टेंस क्या बनेगा"। साझा कुंजी लाने वाली बूटस्ट्रैप स्क्रिप्ट वाली साफ़ इमेज पहले प्रश्न का अच्छा और दूसरे का बुरा उत्तर देती है।

वैध रूप से गोपनीय जानकारी रखने वाली रिकवरी इमेजों को उन्हीं लोगों तक सीमित रखें जिन्हें उनकी आवश्यकता है, और दर्ज करें कि वे कहाँ संग्रहीत हैं। विकल्प, यानी बिना किसी प्रावधान के काम करने के कारण सुविधाजनक इमेज, वही इमेज है जो उसे खोजने वाले किसी भी व्यक्ति को गेटवे की पहचान दे देती है। उन दो कार्यों में से केवल एक ही बिल्ड लॉग में दिखता है।

उत्पादन से पहले प्रवेश जाँच

नोड के ट्रैफ़िक लेने से पहले चार बातें पुष्ट करें: वह जो पहचान प्रस्तुत करता है, जो क्लाइंट स्वीकार करेगा, जिन संसाधनों तक पहुँचने की उसे अनुमति है, और जिन पतों को वह बाँटता है उनके लिए वापसी मार्ग।

systemctl status openvpn-server@lab --no-pager
ss -lunp 'sport = :1194'
ip -4 route show table all | grep -F '10.90.'

फिर नकारात्मक स्थिति जाँचें, जो दुर्घटनाएँ पकड़ती है: क्या नए नोड के पास मूल के लिए सोचा गया प्रशासक या क्लाइंट प्रवेश है? कॉपी किया गया कॉन्फ़िगरेशन एक अतिरिक्त क्लाइंट प्रविष्टि, उत्तराधिकार में मिला प्रबंधन मार्ग, या ऐसा पुश निर्देश उठा सकता है जो पहले होस्ट पर अर्थपूर्ण था।

यदि जीवित गोपनीय जानकारी वाली इमेज पहले ही अपनी स्वीकृत सीमा से आगे बढ़ चुकी है, तो क्रेडेंशियल बदलें और प्रतिलिपियों को सीमित करें। नवीनतम बिल्ड से फ़ाइल हटाना उस क्रेडेंशियल को सेवानिवृत्त करने के बराबर नहीं है जो पुरानी प्रतिलिपियाँ अभी भी रखती हैं, और उन दो तथ्यों के बीच का अंतराल ठीक वही खिड़की है जिसकी हमलावर को आवश्यकता होती है।