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 जाँच्नुहोस्।

प्रयोगकर्ताले अनुभव गरेझैं यो यात्रा पूरा गर्नुहोस्। क्लाइन्टबाट वास्तविक पृष्ठ लोड गर्नुहोस्, कुन ठेगानाबाट बाहिर निस्कन्छ पुष्टि गर्नुहोस्, सर्भर रिबुट गर्नुहोस्, फेरि जोडिनुहोस् र तीन परीक्षण दोहोर्याउनुहोस्। त्यो दोस्रो चरणले मात्र सुरक्षित नियम, फायरवाल नीति र पठाइएको रिजोल्भर सबै सँगै टिकेको प्रमाणित गर्छ।