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