आपका क्लाउड VPN अब भी होस्टिंग प्रदाता पर निर्भर है

आपने ऑपरेटिंग सिस्टम स्थापित किया, सेवा को सख्त किया और कुंजियाँ आपके पास हैं, और लगने लगता है कि सर्वर आपका है। यह आपका उसी तरह है जैसे किराए का फ्लैट आपका होता है: दरवाज़े का ताला आपके नियंत्रण में है और इमारत नहीं। हाइपरवाइज़र, इंस्टेंस के सामने का नेटवर्क और वह खाता जो सब कुछ फिर से बना सकता है, किसी और का है। यही अंतर तय करता है कि रिकवरी योजना को क्या कवर करना है, और स्व-होस्टिंग इसी हिस्से को सबसे कम बदलती है।

खाता ही असली नियंत्रण तल है

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

उस खाते को अलग परिसंपत्ति की तरह सुरक्षित रखें: स्वतंत्र क्रेडेंशियल, हार्डवेयर-समर्थित दूसरे कारक और ऐसा ऑडिट ट्रेल जिसे कोई वास्तव में पढ़े। VPN सेवा के साथ उसी पासवर्ड प्रबंधक प्रविष्टि को साझा करना वह गलती है जो बाकी हर नियंत्रण को अर्थहीन बना देती है।

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

ऐसी अवसंरचना घटनाएँ जिनका प्रशासन आप नहीं कर सकते

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

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

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

जाँचें कि पुनर्निर्माण के बाद क्या बचता है

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

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

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

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

तय करें कि स्व-होस्टिंग वास्तव में क्या बदलती है

अपना VPN चलाना भरोसा VPN ऑपरेटर से होस्टिंग प्रदाता और आपके पास ले जाता है। यह वास्तविक परिवर्तन है, और यह तीसरे पक्ष को हटाने के बराबर नहीं है। यदि उद्देश्य किसी वाणिज्यिक VPN को ट्रैफ़िक देखने से रोकना था, तो प्रदाता अब भी इंस्टेंस का नेटवर्क, उसकी डिस्क और बिलिंग रिकॉर्ड देख सकता है।

आपके अपने लॉग आपके सॉफ़्टवेयर का वर्णन करते हैं, और प्रदाता जो हर अवसंरचना रिकॉर्ड रखता है उसका वर्णन नहीं करते। उलटा भी सच है: अवसंरचना की दृश्यता यह सिद्ध नहीं करती कि प्रदाता क्या रखता है। दोनों प्रश्नों के लिए प्रदाता की नीति और आपका कॉन्फ़िगरेशन चाहिए, और कोई एक दूसरे का उत्तर नहीं देता।

उत्तर को श्रम-विभाजन के रूप में लिखें: कौन-सी परत विफल हुई, कौन उसे ठीक कर सकता है और उस मरम्मत में कितना समय लगता है। स्व-होस्टिंग बदलती है कि आप किस पर भरोसा करते हैं, और अभ्यास का उपयोगी हिस्सा यह जानना है कि आप किस परत के लिए उन पर भरोसा करते हैं।