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.'
त्यसपछि दुर्घटना समात्ने नकारात्मक अवस्था जाँच्नुहोस्: नयाँ नोडसँग मूलका लागि सोचिएको प्रशासक वा ग्राहक पहुँच छ? प्रतिलिपि गरिएको कन्फिगरेसनले थप ग्राहक प्रविष्टि, वंशानुगत व्यवस्थापन रुट, वा पहिलो होस्टमा अर्थपूर्ण भएको पुश निर्देश बोक्न सक्छ।
यदि जीवित गोप्य कुरा भएको इमेज पहिले नै आफ्नो स्वीकृत सीमा नाघिसकेको छ भने, प्रमाणहरू बदल्नुहोस् र प्रतिहरू सीमित गर्नुहोस्। नयाँ बिल्डबाट फाइल हटाउनु पुराना प्रतिले अझै राखेको प्रमाणलाई अवकाश दिनुसरह होइन, र ती दुई तथ्यबीचको खाडल नै आक्रमणकारीलाई चाहिने ठ्याक्कै त्यो झ्याल हो।