फ़ुल-टनल 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 की अलग से सूची बनाएँ।