आपका VPN होस्ट करने से पहले VPS को क्या अनुमति देनी चाहिए

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

प्रोटोकॉल को जरूरी इंटरफ़ेस की पुष्टि करें

OpenVPN TUN पर चलने के लिए कैरेक्टर डिवाइस और उसके पीछे का कर्नेल मॉड्यूल चाहिए; WireGuard को अपना कर्नेल समर्थन या मेल खाती अपेक्षाओं वाला यूज़रस्पेस कार्यान्वयन चाहिए। प्रबंधित कंटेनर ऐसा होस्ट कर्नेल साझा कर सकते हैं जो डिवाइस को कभी उजागर नहीं करता, और कुछ प्लेटफ़ॉर्म चाहे कुछ भी इंस्टॉल हो, सुरंग इंटरफ़ेस बनाने को पूरी तरह मना करते हैं।

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

पहली जोड़ी पर इंकार का मतलब है कि TUN उपलब्ध नहीं है और OpenVPN का डिफ़ॉल्ट मोड शुरू नहीं हो सकता; अंतिम पंक्ति पर इंकार का मतलब है कि WireGuard का कर्नेल इंटरफ़ेस गायब है। कर्नेल का TUN/TAP दस्तावेज़ पहली जाँच जिस डिवाइस को आज़माती है उसका वर्णन करता है। दोनों में से कोई भी विफलता VPN पैकेज दोबारा इंस्टॉल करने से ठीक नहीं होती।

याद रखें कि आने वाले मार्ग के दो मालिक हैं

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

UDP आम शिकार है: कई प्लेटफ़ॉर्म डिफ़ॉल्ट रूप से TCP की अनुमति देते हैं और UDP नियमों को अलग प्रविष्टि मानते हैं। अगर इंस्टेंस सार्वजनिक पता रखने के बजाय प्रदाता के NAT के पीछे है, तो प्रदाता की ओर पोर्ट फ़ॉरवर्डिंग सामंजस्य बिठाने वाला तीसरा कॉन्फ़िगरेशन बन जाता है।

वापसी मार्ग की योजना बनाएँ, केवल निकास की नहीं

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

योजना को तीन ठोस निर्णयों के रूप में लिखें: क्लाइंट कौन-सी स्रोत श्रेणी पाते हैं, उनका ट्रैफ़िक इंटरनेट की ओर कैसे निकलता है, और जवाब वापसी का रास्ता कैसे पाते हैं। फिर क्लाइंट परखने से पहले पुष्टि करें कि कर्नेल योजना से सहमत है, ताकि शांत असंगति को क्लाइंट-पक्ष की खराबी न समझा जाए।

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

IPv6 के मामले पर स्पष्ट निर्णय लें

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

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

इसे बाहरी क्लाइंट से साबित करें

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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