PiVPN का हैंडशेक काम करता है, पेज अटकते हैं: MASQUERADE जाँचें

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

इससे शुरू करें कि क्लाइंट क्या पा सकता है और क्या नहीं

जुड़े हुए क्लाइंट से, सार्वजनिक इंटरनेट पर रहने वाला पेज लोड करें और देखें कि यह तुरंत विफल होता है या बीच में अटक जाता है। फिर VPN सर्वर के अपने निजी पते पर कोई संसाधन खोलें और दोनों नतीजों की तुलना करें।

जो टनल पता ping का जवाब देता है जबकि सार्वजनिक साइटें समय-सीमा पार कर जाती हैं, वह फ़ॉरवर्डिंग या अनुवाद की समस्या का संकेत है, टूटे हैंडशेक का नहीं। क्लाइंट का अपना स्टेटस पैनल इन दोनों में फ़र्क़ नहीं कर सकता, क्योंकि उसे केवल इतना पता है कि नियंत्रण चैनल ऊपर है। सर्वर पर टनल इंटरफ़ेस इससे जाँचें ip -br addr show tun0 और पुष्टि करें कि क्लाइंट को दिया गया पता आपके द्वारा सेट किए गए पूल के भीतर पड़ता है। अगर पूल और क्लाइंट पता मेल न खाएँ, तो पहले उसे ठीक करें, क्योंकि नीचे का हर नियम पूल से मेल खाता है।

इसके बाद सर्वर से पूछें कि किसी सार्वजनिक पते तक पहुँचने के लिए वह कौन-सा इंटरफ़ेस इस्तेमाल करेगा। ip route get 203.0.113.9 अपनी पहली पंक्ति में चुना गया डिवाइस और स्रोत छापता है। उस डिवाइस का नाम लिख लें, क्योंकि NAT नियम में यही मान होना चाहिए।

वह नियम पढ़ें जो तय करता है कि पैकेट बाहर जाएँगे या नहीं

MASQUERADE पैकेट को केवल तब फिर से लिखता है जब पैकेट नियम में बताए गए इंटरफ़ेस से बाहर निकलता है। तार वाले डिवाइस तक सीमित नियम Wi-Fi से बाहर जाने वाले ट्रैफ़िक के लिए कुछ नहीं करता, और पैकेट ऊपरी राउटर तक अपना निजी स्रोत पता बनाए रखता है। उस राउटर के पास आपके टनल पूल तक वापस जाने का कोई रास्ता नहीं है, इसलिए वह जवाब गिरा देता है, और क्लाइंट एक ऐसा कनेक्शन देखता है जो खुलता है और फिर मर जाता है। लक्षण इस बात के साथ बढ़ता है कि पहला जवाब ज़रूरी होने से पहले पेज का कितना हिस्सा आ जाता है।

जीवित तालिका सूचीबद्ध करें और सिर्फ़ MASQUERADE शब्द खोजने के बजाय आउट-इंटरफ़ेस कॉलम पढ़ें। फ़ॉर्मैट की गई सूची से जोड़ने के रूप का आउटपुट तुलना करने में आसान है:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

एक Raspberry Pi पर जो पहले Ethernet और अब Wi-Fi इस्तेमाल करता है, पुराना नाम लगभग हमेशा पूरी कहानी होता है। इंस्टॉलर ने दर्ज किया था कि सेटअप के समय कौन-सा डिवाइस मौजूद था, और सहेजा गया नियम-समूह हर बूट पर उसे फिर चलाता है। कुछ और बदलने से पहले रूट खोज से मिले डिवाइस की तुलना नियम वाले डिवाइस से करें। अगर दोनों मेल खाते हैं, तो इंटरफ़ेस आपकी समस्या नहीं है और आपको अंतिम भाग के काउंटरों पर जाना चाहिए। अगर अलग हैं, तो सुधार स्थायित्व फ़ाइल में एक शब्द का संपादन है।

सहेजा गया नियम-समूह ठीक करें, सिर्फ़ चल रहा नहीं

सिर्फ़ जीवित तालिका संपादित करना अगले रीबूट तक टिकता है, जो आपको यह विश्वास दिलाने के लिए बिल्कुल पर्याप्त है कि समस्या हल हो गई है। बूट पर लौटने वाले नियम एक फ़ाइल में रहते हैं जिसे फ़ायरवॉल स्थायित्व पैकेज फिर से लोड करता है। Debian आधारित Pi इमेजों में वह फ़ाइल आम तौर पर /etc/iptables/rules.v4।

उसे छूने से पहले नकल लें, फिर MASQUERADE पंक्ति का आउट-इंटरफ़ेस उस डिवाइस से बदलें जो आपने लिखा था, उदाहरण के लिए -o wlan0 के बजाय -o eth0। स्रोत श्रेणी को वैसा ही रखें, जब तक आपका क्लाइंट पूल न बदला हो। फिर से लोड करें और पुष्टि करें कि नियम अब सही डिवाइस बताता है:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

दो पास-पास की सेटिंग भूलना आसान है। sysctl net.ipv4.ip_forward को 1 बताना चाहिए, और ऊपरी राउटर को निजी स्रोत पते खुद फ़िल्टर नहीं करने चाहिए।

साबित करें कि नियम सक्रिय होता है, फिर अलग करें कि अब भी क्या धीमा है

काउंटर ही इस बात का एकमात्र ईमानदार सबूत हैं कि कोई नियम मेल खाया। विस्तृत सूची चलाएँ, क्लाइंट पर डाउनलोड शुरू करें और उसे फिर चलाएँ। आपके नियम के बगल के पैकेट और बाइट कॉलम बढ़ने चाहिए, और शून्य पर रहने वाला नियम अब भी मेल नहीं खाता। अगर काउंटर हिलते हैं पर पेज अब भी विफल होते हैं, तो स्रोत श्रेणी की असली पूल से इससे तुलना करें grep -n "^server " /etc/openvpn/server.conf। अगर वे हिलते हैं और पेज लोड होते हैं पर थ्रूपुट खराब है, तो अनुवाद हो चुका है और बाकी समस्या कहीं और है।

एक ही क्लाइंट से दो स्थानांतरणों की तुलना करें, एक स्थानीय नेटवर्क के होस्ट पर और एक टनल से उसी होस्ट पर। दोनों में धीमा होना Pi के अपलिंक या Wi-Fi लिंक की ओर इशारा करता है, VPN की ओर नहीं। सिर्फ़ टनल से धीमा होना MTU और पुनःप्रेषणों की ओर इशारा करता है, जिन्हें आप किसी भी क्रिप्टो सेटिंग को बदलने से पहले इससे देख सकते हैं ip -s link show tun0 कोई भी क्रिप्टो सेटिंग बदलने से पहले।

प्रयोग को पूर्ववत करने के लिए नकल बहाल करें और उसे फिर से लोड करें, फिर पुष्टि करें कि मूल नियम और उसके काउंटर लौट आए हैं। सर्वर नोट्स में एग्रेस डिवाइस और फिर से लोड करने का कमांड लिखें, क्योंकि अगला अपलिंक परिवर्तन वही असंगति फिर खोज निकालेगा। गलत डिवाइस बताने वाला नियम तब तक अदृश्य रहता है जब तक ट्रैफ़िक को उसकी ज़रूरत न पड़े।