एक ही होस्ट पर बिना टकराव के VPN और वेबसाइट चलाना

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

तय करें कि कौन से पते और परिवहन पर क्या सुनता है

तीन स्तंभों वाली एक तालिका लिखें, पता, परिवहन और पोर्ट, और प्रत्येक सेवा के लिए एक पंक्ति, प्रशासनिक इंटरफ़ेस सहित। साइट के लिए TCP 443 और VPN के लिए UDP 443 टकराव नहीं हैं, भले ही संख्याएँ मेल खाएँ, क्योंकि परिवहन अलग है। एक ही पते, परिवहन और पोर्ट पर दो सेवाओं को ऐसी व्यवस्था चाहिए जिसे कार्यान्वयन प्रलेखित करे, वह नहीं जो आप किसी रुकावट के दौरान गढ़ें। वह तालिका ही वह कलाकृति है जो अगले परिवर्तन को समीक्षा-योग्य बनाती है।

अलग पते या दूसरा पोर्ट पैकेट कैप्चर में स्वामित्व को दृश्यमान बनाते हैं, और यह चालाकी से अधिक मूल्यवान है। कुछ VPN कार्यान्वयन वेब सर्वर के साथ पोर्ट साझा करने का समर्थन करते हैं, लेकिन तंत्र विशिष्ट है: डेमॉन पहले बाइट की जाँच करता है और वह ट्रैफ़िक आगे भेजता है जो उसका अपना प्रोटोकॉल नहीं है। सामान्य HTTP रिवर्स प्रॉक्सी ऐसा नहीं करता, और हेडर फिर से लिखने से वह एन्क्रिप्टेड टनल के हैंडशेक को नहीं समझ पाएगा। प्रोटोकॉल के तैनाती नोट्स पढ़ें, जैसे OpenVPN श्रोता प्रलेखन, और जिस व्यवस्था का वह वर्णन करता है उसका पालन करें।

तय करें कि कौन सी पहचान किस सेवा की है

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

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

तय करें कि प्रशासन कहाँ रहता है

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

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

जब भी कोई सेवा जोड़ी जाए, उन नियमों की श्रोता तालिका के विरुद्ध समीक्षा करें। समीक्षा सस्ती है और यह उस नियम को पकड़ लेती है जो किसी ने रात दो बजे जोड़ा था।

तय करें कि जब दोनों का टकराव हो तो क्या करें

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

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

बाहर से सत्यापित करें, फिर पुनः आरंभ के बाद दोबारा

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

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