तपाईंको 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

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