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 तपासा.

वापरकर्त्याला जसा अनुभव येतो त्याप्रमाणे हा प्रवास पूर्ण करा. क्लायंटवरून खरे पृष्ठ लोड करा, ते कोणत्या पत्त्यावरून बाहेर पडते ते तपासा, सर्व्हर रीबूट करा, पुन्हा जोडा आणि तीनही चाचण्या पुन्हा करा. फक्त ती दुसरी फेरीच जतन केलेले नियम, फायरवॉल धोरण आणि पाठवलेला रिझोल्व्हर सर्व एकत्र टिकले हे सिद्ध करते.