OpenVPN से जुड़े हैं पर कुछ लोड नहीं होता: क्लाइंट से बाहर की ओर एक रास्ता

क्लाइंट विंडो Connected कहती है, टनल का पता मौजूद है, और ब्राउज़र अब भी घूम रहा है। यह संयोजन सामान्य है, क्योंकि सफल हैंडशेक केवल यह सिद्ध करता है कि टनल बन गई; यह नहीं बताता कि सर्वर आपके पैकेट आगे भेजेगा, उनका स्रोत फिर से लिखेगा या आपकी DNS क्वेरी का उत्तर देगा। ज़्यादातर लोग जो गलती करते हैं वह पहले सर्वर कॉन्फ़िगरेशन खोलना है। इसके बजाय क्लाइंट से बाहर की ओर काम करें, क्योंकि नीचे का हर चरण बताता है कि अगला कदम जाँचने लायक है या नहीं।

क्लाइंट से शुरू करें और बाहर की ओर बढ़ें

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

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

दो कैप्चर दिखाते हैं कि पैकेट कहाँ रुकते हैं

क्लाइंट से किसी सार्वजनिक पते पर ping चलते समय टनल इंटरफ़ेस पर एक कैप्चर और उस अपलिंक पर दूसरा कैप्चर लें जिसे इंटरनेट तक पहुँचना चाहिए। दोनों एक ही समय चलाएँ ताकि टाइमस्टैम्प मेल खाएँ।

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

यदि अनुरोध टनल पर दिखते हैं और अपलिंक पर कभी नहीं, तो सर्वर ने उन्हें टनल और तार के बीच गिरा दिया, और कारण फ़ॉरवर्डिंग या फ़ॉरवर्ड फ़ायरवॉल नीति है, NAT नहीं। यदि वे दोनों पर दिखते हैं, तो सर्वर ने अपना हिस्सा किया और उत्तर आगे कहीं खो गया, जो अनुवाद, ऊपरी फ़िल्टर या प्रदाता की ओर से सीमा की ओर संकेत करता है।

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

ip -4 route get 9.9.9.9

उस आउटपुट का dev फ़ील्ड वह नाम है जो NAT नियम को बाद में चाहिए होगा, इसलिए इसे रखें।

फ़ॉरवर्डिंग एक कर्नेल स्विच और एक फ़ायरवॉल नीति है

कर्नेल को पहले ही फ़ॉरवर्ड करने पर सहमत होना होगा। मौजूदा मान पढ़ें, फिर सेटिंग को केवल चल रहे कर्नेल में लिखने के बजाय स्थायी बनाएँ:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

फ़ॉरवर्डिंग आधी बात है। UFW वाले होस्ट पर फ़ॉरवर्ड नीति /etc/default/ufw में सेट होती है और रीलोड लागू होने से पहले उसे ACCEPT होना चाहिए। फ़ॉरवर्ड पथ पर डिफ़ॉल्ट ड्रॉप हैंडशेक को पूरी तरह स्वस्थ रखता है और टनल से बाहर जाने की कोशिश करता हर पैकेट चुपचाप गिरा देता है, जो ठीक वही लक्षण है जिससे आपने शुरू किया था।

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

NAT नियम में असली एग्रेस इंटरफ़ेस का नाम दें

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

क्लासिक विफलता वह नियम है जो किसी गाइड से कॉपी किया गया और -o eth0 कहता है ऐसी मशीन पर जिसका एडाप्टर कुछ और कहलाता है। नियम बिना चेतावनी इंस्टॉल हो जाता है, किसी से मेल नहीं खाता, और क्लाइंट के पास इंटरनेट नहीं आता। पूल उसी गलती का दूसरा आधा है: अगर सर्वर 10.44.0.0/24 बाँटता है और नियम 10.8.0.0/24 को कवर करता है, तो कुछ भी कभी मेल नहीं खाएगा।

नियम के पाठ पर भरोसा करने के बजाय काउंटर देखें। सूची प्रति नियम पैकेट बताती है, और जो नियम कभी मेल नहीं खाता वह कितना भी सही दिखे, शून्य पर रहता है। उस संख्या से कुछ निकालने से पहले उसे एक मिनट का असली क्लाइंट ट्रैफ़िक दें:

iptables -t nat -L POSTROUTING -v -n

असली क्लाइंट परीक्षण के बाद शून्य पैकेट गणना का अर्थ है कि मिलान गलत है, टनल टूटी नहीं है। एक बार मेल खाने पर नियम-समूह सहेजें ताकि वह रीबूट के बाद टिके; जो सुधार केवल आपके शेल इतिहास में रहता है वह पहले रीस्टार्ट पर ही गायब हो जाता है।

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

DNS पहली के पीछे दूसरी विफलता है

पते से ping चलना जबकि नाम विफल हों, रिज़ॉल्वर की समस्या है, और इसका अपना कारण है। जो क्लाइंट अपना स्थानीय रिज़ॉल्वर रखता है वह वे क्वेरी पूरी टनल में भेजता है और ऐसे उत्तर की प्रतीक्षा करता है जो कभी नहीं आता, क्योंकि स्थानीय रिज़ॉल्वर अब मार्ग के गलत ओर है।

सर्वर से रिज़ॉल्वर भेजें ताकि क्लाइंट को पता चले कि कहाँ पूछना है। दो प्रविष्टियाँ क्लाइंट को विकल्प देती हैं यदि पहली तक न पहुँचे, और दोनों ऐसे रिज़ॉल्वर होने चाहिए जिन्हें टनल वास्तव में अनुमति देती है।

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows क्लाइंट फिर भी स्थानीय रिज़ॉल्वर पर लौट सकते हैं, और block-outside-dns ठीक यही रोकने के लिए है, पर उसकी कीमत उन नामों को खोना है जिन्हें केवल स्थानीय नेटवर्क हल कर सकता है। systemd-resolved वाले Linux क्लाइंट अक्सर भेजे गए रिज़ॉल्वर को अनदेखा करते हैं जब तक कोई स्क्रिप्ट उसे इंस्टॉल न करे, इसलिए यह मानने से पहले कि भेजना अनदेखा हुआ, टनल डिवाइस के लिए resolvectl status जाँचें।

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