वेब होस्टिंग या VPS: क्या आपका प्लान VPN सर्वर चला सकता है?
साझा होस्टिंग, प्रबंधित ऐप और स्व-प्रबंधित सर्वर अलग नेटवर्क नियंत्रण देते हैं। कुछ भी खरीदने या माइग्रेट करने से पहले चार क्षमताओं की तुलना करें।
चलती हुई वेबसाइट इस बात का सबूत है कि प्रदाता HTTP परोस सकता है, यह नहीं कि आप एक मशीन नियंत्रित करते हैं। साझा प्लान, प्रबंधित एप्लिकेशन और स्व-प्रबंधित सर्वर के बीच इस बात में बड़ा अंतर है कि खाता नेटवर्क के साथ क्या कर सकता है। एक और साल का भुगतान करने से पहले तय करें कि आपके VPN डिज़ाइन को उस अंतर का कौन-सा पक्ष चाहिए। चार क्षमताएँ दोनों को अलग करती हैं, और उनमें से कोई भी मूल्य सूची में नहीं दिखती।
हर प्लान वास्तव में क्या देता है
उपयोगी तुलना कीमत या डिस्क आकार नहीं, अधिकार है। पूछें कि खाता क्या शुरू कर सकता है, किन कर्नेल सुविधाओं तक पहुँचता है, कौन-से पोर्ट आने वाला ट्रैफ़िक स्वीकार करते हैं और क्या स्वीकृत ट्रैफ़िक फिर कहीं और जा सकता है।
अधिकांश होस्टिंग उत्पाद तीन रूपों में आते हैं, और केवल अंतिम ही सामान्य-उद्देश्य वाला सर्वर है:
| Capability | Website plan | Self-managed server |
|---|---|---|
| Long-running custom process | Usually not permitted | Yours to run under a service manager |
| Virtual network interface | Almost never available | Present when the kernel module and privilege allow it |
| Arbitrary inbound port | Restricted to the web stack | Provider filtering still applies |
| Forwarding for clients | Not offered | Possible once routing and policy are configured |
शेल खाता आम भ्रम का स्रोत है। फ़ाइल स्थानांतरण या निर्धारित कार्यों तक पहुँच प्रशासन जैसी लग सकती है, जबकि प्रक्रिया एक निर्देशिका और कुछ अनुमत क्रियाओं तक सीमित रहती है।
वह चार क्षमताएँ जो उत्तर तय करती हैं
इन्हें क्रम से लें, क्योंकि पहले चरण में विफलता बाकी को अप्रासंगिक बना देती है।
पहला, सॉफ़्टवेयर को दीर्घकालिक प्रक्रिया के रूप में चलना चाहिए जो रखरखाव के बाद भी बना रहे। दूसरा, कार्यान्वयन को अपना आभासी इंटरफ़ेस बनाने में सक्षम होना चाहिए; Linux पर इसका अर्थ आमतौर पर संबंधित प्रशासनिक अनुमति के साथ /dev/net/tun खोलना है, जैसा कि कर्नेल का TUN/TAP दस्तावेज़ बताता है, हालाँकि हर VPN डिज़ाइन उस उपकरण का उपयोग नहीं करता। तीसरा, क्लाइंट को सार्वजनिक पते पर श्रोता तक पहुँचना चाहिए, उस ट्रांसपोर्ट और पोर्ट पर जिसका आप इरादा रखते हैं, और HTTPS स्वीकार करने वाला कोई वेब रिवर्स प्रॉक्सी उसी नंबर पर किसी असंबंधित प्रोटोकॉल के बारे में कुछ नहीं कहता। चौथा, स्वीकृत ट्रैफ़िक को आगे बढ़ सकना चाहिए, मार्गों, अग्रेषण और वास्तव में समर्थित किसी भी अनुवाद के साथ।
सेवा की शर्तें उन चार के बगल में बैठती हैं और बिलकुल तकनीकी नहीं हैं। असीमित ट्रैफ़िक की सीमाएँ आमतौर पर वेब अनुरोधों का वर्णन करती हैं, दूसरों के डाउनलोड ढोने वाली किसी सुरंग का नहीं। उसके इर्द-गिर्द डिज़ाइन करने से पहले स्वीकार्य उपयोग वाला खंड पढ़ें, और जिस दिन सेवा शुरू न हो उस दिन के लिए रिकवरी पहुँच याद रखें।
वेबसाइट खाता कहाँ रुक जाता है
वेबसाइट प्लान आमतौर पर आपके कोड को एक निश्चित प्रवेश-बिंदु वाले प्रबंधित रनटाइम में चलाता है। सुरंग की बाइनरी मौजूद होने पर भी प्रक्रिया के पास डिवाइस नोड खोलने, विशेषाधिकार प्राप्त पोर्ट बाँधने या रूटिंग तालिका बदलने की अनुमति नहीं हो सकती। ये प्रतिबंध ही उत्पाद हैं, चूक नहीं।
इसीलिए VPN का वादा करने वाला प्लगइन आमतौर पर कहीं और जाने वाला प्रॉक्सी निकलता है। अगर मौजूदा खाता केवल वेबसाइट नियंत्रण देता है, तो ईमानदार कदम अलग सर्वर है, गायब अधिकार खोलने वाले मॉड्यूल की खोज नहीं।
जब एक ही होस्ट को दोनों चलाने पड़ें
साझा करना संभव है और कभी-कभी समझदारी भरा, पर इसे सुविधा नहीं, सुरक्षा-निर्णय मानें। अपलोड फ़ॉर्म वाला वेब एप्लिकेशन सुरंग के क्रेडेंशियल और नियंत्रण सॉकेट के बगल में बैठता है, और एक में की गई छेड़छाड़ दूसरे तक पहुँचती है। अलग खाते, अलग सेवा इकाइयाँ और अलग फ़ाइलसिस्टम दूसरी मशीन खरीदे बिना उस जोखिम को घटाते हैं।
संसाधनों की होड़ भी उतनी ही मायने रखती है। सुरंग के ज़रिए बैकअप और व्यस्त वेब प्रक्रिया एक ही अपलिंक और एक ही डिस्क के लिए होड़ करते हैं, और विफलता भरी हुई सुरंग के बजाय धीमी साइट जैसी दिखती है। घटना से पहले तय करें कौन-सा कार्यभार जीतेगा, और सुरंग को सीमित करें ताकि वेबसाइट उत्तर देती रहे।
दोनों सेवाएँ चलने भर से कोई भी व्यवस्था पृथक नहीं है। दोनों को साथ होस्ट करने की क्षमता डिज़ाइन की शुरुआत है, और अलगाव का काम ही इसे बचाव योग्य बनाता है।
चार आदेशों से परीक्षण होस्ट पर इसे तय करें
माइग्रेट करने से पहले लक्ष्य उत्पाद का सबसे छोटा इंस्टेंस एक घंटे के लिए किराए पर लें और चारों क्षमताएँ सीधे जाँचें। फ़ीचर तालिका से अनुमान लगाना गलत प्लान के एक साल से कम पैसा बर्बाद करता है, पर बहुत अधिक समय।
इन्हें परीक्षण होस्ट पर चलाएँ और विफलताओं को बाधा नहीं, उत्तर की तरह पढ़ें:
ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | headपहली दो पंक्तियाँ बताती हैं कि सुरंग उपकरण आख़िर बन ही सकता है या नहीं। तीसरी बताती है कि होस्ट पैकेट आगे भेज सकता है या नहीं, और चौथी दिखाती है कि पहले से क्या सुन रहा है ताकि पोर्ट का टकराव जल्दी पकड़ा जाए। जो प्रदाता दूसरी पंक्ति में विफल होता है वह फिर भी उपयोगकर्ता-स्थान वाला कार्यान्वयन समर्थित कर सकता है, इसलिए उनके सहायता डेस्क से पूछते समय उत्पाद श्रेणी नहीं, अपनी ज़रूरत का तंत्र बताएँ।