पूर्ण सुरुङ OpenVPN: सर्भर पक्षमा इन्टरनेट निकास थप्नुहोस्
पूर्वनिर्धारित मार्ग पुश गर्नु पूर्ण सुरुङ सेवाको आधा मात्र हो। सर्भरलाई अगाडि पठाउने, सीमित अगाडि-पठाउने नियम र पूलका लागि फर्कने मार्ग पनि चाहिन्छ।
एक क्लाइन्ट प्रमाणीकरण गर्छ, पूलबाट ठेगाना पाउँछ र VPN होस्टमा भएका सेवाहरूसम्म पुग्छ, तर हरेक सार्वजनिक गन्तव्य समय सकिएर रोकिन्छ। निकास नभएको सुरुङ यस्तै देखिन्छ, र चार अलग कुरा सत्य नहुँदासम्म यही अवस्था रहन्छ। क्लाइन्टले पूर्वनिर्धारित मार्ग स्वीकार्नुपर्छ, सर्भरले अगाडि पठाउनुपर्छ, फायरवालले ट्रान्जिट अनुमति दिनुपर्छ, र जवाफलाई पूलतर्फ फर्कने बाटो चाहिन्छ। चारै असफलताको एउटै लक्षण छ, त्यसैले प्रत्येक प्रयासमा एउटा कुरा मात्र बदल्नुहोस् र नतिजा लेख्नुहोस्।
पूर्वनिर्धारित मार्ग पुश गर्नुहोस् र क्लाइन्टले के स्थापना गर्यो जाँच्नुहोस्
सर्भर पक्षको लाइन छोटो छ, र यसले पुश गरिएका विकल्प स्वीकार्ने क्लाइन्टलाई मात्र असर गर्छ. def1 ढाँचाले विद्यमान पूर्वनिर्धारित हटाउनुको सट्टा दुई आधा-पूर्वनिर्धारित मार्ग स्थापना गर्छ, जसले हालको जडान जीवित राख्छ र साथै हरेक गन्तव्य समात्छ।
push "redirect-gateway def1"
पुनः जोडिएपछि प्रोफाइलमा भरोसा गर्नुको सट्टा क्लाइन्टको राउटिङ तालिका पढ्नुहोस्। Linux मा दुई /1 प्रविष्टि मूल पूर्वनिर्धारितको छेउमा देखिन्छन्, र Windows ले त्यही जोडीलाई 0.0.0.0/1 र 128.0.0.0/1 का रूपमा देखाउँछ। पुश गरिएका विकल्प बेवास्ता गर्ने क्लाइन्ट, वा तिनलाई अस्वीकार गर्न कन्फिगर गरिएको क्लाइन्ट, आफ्नो पुरानो पूर्वनिर्धारित राख्छ र इन्टरनेट ट्राफिक कहिल्यै सुरुङमा पठाउँदैन। सर्भरमा केही परिवर्तन गर्नुअघि यो प्रश्न टुंग्याउनुहोस्, किनकि सर्भर पक्षको कुनै पनि नियमले यसको भरपाई गर्न सक्दैन।
अगाडि पठाउने काम सर्भरको सेटिङ हो, VPN को होइन
राउटिङ छुनुअघि अगाडि पठाउने झन्डा पढ्नुहोस्। त्यहाँ शून्य भन्नाले कर्नेलले क्लाइन्टको प्याकेट लिन्छ र अगाडि पठाउन अस्वीकार गर्छ, जुन टाढाको छेउबाट फायरवाल अवरोधजस्तै देखिन्छ। मान प्रणालीको कन्फिगरेसन डाइरेक्टरीमार्फत सेट गर्नुहोस् ताकि पुनः सुरु गरेपछि पनि रहिरहोस्।
sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system
अर्को, होस्ट आफैंसँग इन्टरनेट निकाससम्म काम गर्ने मार्ग छ भनी पुष्टि गर्नुहोस्। सर्भरको शेलबाट गरिएको अनुरोधले माथिल्लो बाटो प्रयोगयोग्य छ भनी प्रमाणित गर्छ र क्लाइन्टको प्याकेट अगाडि पठाउनेबारे केही पनि भन्दैन, त्यसैले तिनलाई दुई अलग परीक्षण मान्नुहोस्। सर्भर गन्तव्यसम्म पुग्न सक्दैन भने जति पनि अगाडि-पठाउने कन्फिगरेसनले सहयोग गर्दैन।
तपाईंले चाहेको ट्रान्जिटलाई मात्र अनुमति दिनुहोस्, अरूलाई होइन
अगाडि पठाइएका प्याकेट forward मार्ग पार गर्छन्; VPN होस्टलाई नै सम्बोधन गरिएको ट्राफिक input मार्ग पार गर्छ। यी अलग निर्णय हुन्, र input मार्ग खोल्दा मेसिनबाट ट्रान्जिटको अनुमति दिँदैन। यी दुईलाई गल्लौट गर्नु भनेको फायरवाल सबै कुरा अनुमति दिँदै छ जस्तो देखिँदा पनि क्लाइन्ट अझै समय सकिएर रोकिनुको सबैभन्दा सामान्य कारण।
न्यूनतम नीतिले पूलबाट निकास इन्टरफेसतर्फ नयाँ जडान स्वीकार्छ र स्थापित प्रवाहसँग सम्बन्धित जवाफ स्वीकार्छ। प्रत्येक बुटमा नक्कली नियम थप्नुको सट्टा तपाईंको वितरणले प्रयोग गर्ने नियमसमूहको मालिकमा राख्नुहोस्; नक्कली नियम थुप्रिन्छन् र गणकको अर्थ सकिन्छ।
sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
हरेक चेनलाई स्वीकारमा बदल्दा परीक्षण उत्तीर्ण हुन्छ र फायरवाल रहनुको कारण हट्छ। दायरा पूल र निकास इन्टरफेसमा सीमित राख्नुहोस्, र असम्बन्धित अगाडि-पठाउने कामलाई यथावत् राख्नुहोस्।
जवाफलाई जाने ठाउँ दिनुहोस्
पूलका ठेगाना निजी हुन्, त्यसैले सार्वजनिक सर्भरले तिनलाई सिधै जवाफ पुर्याउन सक्दैन। या त VPN होस्टले बाहिर जाँदा स्रोत ठेगाना अनुवाद गर्छ, वा माथिल्लो उपकरणले पूलतर्फ फर्कने मार्ग राख्छ।
sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE
ठ्याक्कै एउटा अनुवाद तह थप्नुहोस्। अझ माथिको दोस्रो NAT ले पहिलो लुकाउँछ र पछि केही बिग्रिएपछि दुवै लगलाई लगभग निरर्थक बनाउँछ। माथिल्लो राउटरले पूल पहिल्यै फर्काइरहेको छ भने होस्टमा अनुवाद थप्नु अनावश्यक हुन्छ, र फर्कने मार्ग त्यतिबेला तपाईंको होइन, त्यो राउटरको कन्फिगरेसनमा निर्भर हुन्छ।
क्लाउड इन्स्टेन्सले अर्को एउटा ढोका थप्छ, किनकि केही प्लेटफर्मले स्रोत ठेगाना इन्स्टेन्सकै नभएका प्याकेट ती जाँच खुकुलो नपारिएसम्म फालिदिन्छन्। त्यो सेटिङ अतिथिबाहिर छ र स्थानीय परीक्षण मेसिन चलिरहेको बेला बिर्सन सजिलो छ।
यो सर्भरको शेलबाट होइन, क्लाइन्टबाट प्रमाणित गर्नुहोस्
सङ्ख्यात्मक IPv4 अनुरोधबाट सुरु गर्नुहोस्, त्यसपछि नाम खोज, त्यसपछि अनुप्रयोग। ping ले अगाडि पठाउने र अनुवाद प्रमाणित गर्छ;यसले नाम समाधानबारे केही पनि प्रमाणित गर्दैन, किनकि DNS विकल्प क्लाइन्ट एकीकरणले तिनलाई स्थापना गरेपछि मात्र लागू हुन्छन्।
curl -4 -m 5 http://198.51.100.10/
dig +short example.com
परिवर्तन र फर्काउने चरण चल्दै गर्दा लेख्नुहोस्, ताकि परीक्षण असफल हुँदा निकास नीति एउटै कार्यले फर्काउन सकियोस्। यो विधिले IPv4 मात्र समेट्छ; परिनियोजनले सबै ट्राफिक बोक्छ भनी दाबी गर्नुअघि IPv6 अलगै सूचीबद्ध गर्नुहोस्।