तुमचा 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

चाचणीसोबत कार्यात्मक पाया ठेवा: अपडेटसाठी जागा, मर्यादित लॉग, टनेलवर अवलंबून नसलेला प्रशासकीय प्रवेश, पुनर्प्राप्ती कन्सोल, आणि इन्स्टन्स पुन्हा बांधला गेल्यावर व त्याचा सार्वजनिक पत्ता बदलल्यावर क्लायंट प्रोफाइलचे काय होते याबद्दल टीप। आवश्यक इंटरफेस किंवा फॉरवर्डिंग मॉडेल उपलब्धच नसेल, तर कोणताही क्लायंट-बाजू बदल ते देणार नाही, आणि प्रामाणिक पुढचे पाऊल अधिक कॉन्फिगरेशन नाही तर वेगळ्या प्रकारचा इन्स्टन्स आहे।