VPN क्लायंट जोडतात पण इंटरनेट नाही: तीन गहाळ भाग

क्लायंटला पत्ता मिळतो, सर्व्हर ping ला उत्तर देतो, आणि तरीही प्रत्येक पृष्ठ वेळमर्यादा ओलांडते। बहुतेक लोक या टप्प्यावर क्लायंट प्रोफाइल संपादित करू लागतात, जे सहसा वायफळ श्रम असते: टनेल वर आल्यावर सर्व्हरने राउटरप्रमाणे वागले पाहिजे। पॅकेट बाहेर जाऊन उत्तर परत येण्यापूर्वी तीन अटी एकाच वेळी पूर्ण झाल्या पाहिजेत, आणि कोणती गहाळ असली तरी लक्षण एकच असते।

कार्यरत टनेलला अजूनही बाहेर जाण्याचा मार्ग का नाही

कर्नेलने इंटरफेसदरम्यान पॅकेट फॉरवर्ड करावे लागतात, जे बहुतेक Linux वितरणांमध्ये डीफॉल्टनुसार बंद असते। रहदारीचे भाषांतर अशा पत्त्यावर केले पाहिजे ज्याला बाहेरील जग उत्तर देऊ शकेल, जोपर्यंत प्रत्येक वरच्या राउटरला टनेल सबनेटपर्यंतचा परतीचा मार्ग आधीच माहीत नाही। फायरवॉलच्या फॉरवर्ड मार्गाने रहदारी दोन्ही दिशांनी परवानगी दिली पाहिजे, उत्तरांसह।

यापैकी प्रत्येकजण स्वतंत्रपणे दुरुस्त केला जाऊ शकतो, आणि हाच सापळा आहे। भाषांतर नियमाशिवाय फॉरवर्डिंग सुरू केल्यास पॅकेट खाजगी स्रोतासह आणि परतीच्या मार्गाशिवाय बाहेर पडतात। फॉरवर्ड नियमाशिवाय भाषांतर जोडल्यास कर्नेल एक पाऊल नंतर पॅकेट टाकून देते।

म्हणून क्लायंटऐवजी तीन स्तरांची चाचणी करा, आणि निकालाला अर्थ असावा म्हणून एका वेळी एकच बदला।

फॉरवर्डिंग हा कर्नेल स्विच आहे जो टिकवून ठेवावा लागतो

बदलण्यापूर्वी सध्याचे मूल्य तपासा, नंतर ते सेट करा आणि बदल अंमलात आला याची खात्री करा।

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

पहिला आदेश सध्याचे मूल्य सांगतो, दुसरा तो रनटाइममध्ये सेट करतो, आणि तिसरा लेखन काम करून गेल्याचे सिद्ध करतो। रनटाइम मूल्य पुढील रीबूटमध्ये नाहीसे होते, म्हणून कार्यरत सत्र देखभालीनंतर कोणत्याही कॉन्फिगरेशन बदलाशिवाय तुटू शकते।

ते /etc/sysctl.d/ अंतर्गत फाइलमध्ये कायमचे करा, नंतर जाणून घेण्यासाठी रीबूट करण्याऐवजी ती फाइल लागू करा। FreeBSD मध्ये समतुल्य net.inet.ip.forwarding आहे, आणि टिकाऊपणासाठी rc.conf मध्ये gateway_enable=YES। फॉरवर्डिंग बंद असल्याचे सांगणारे उपकरण «पॅकेट येतात आणि काहीच परत येत नाही» अशा संपूर्ण वर्गाचे अहवाल स्पष्ट करते। प्रत्येक अपग्रेडनंतरही सेटिंग तपासा, कारण पुन्हा तयार केलेले कर्नेल किंवा बदललेल्या उपकरणाच्या प्रतिमेने कोणालाही न सांगता ती रीसेट करू शकते।

masquerade किंवा एक निश्चित भाषांतर पत्ता निवडा

गतिमान बाह्य पत्त्यासह masquerading हा सर्वात सोपा योग्य प्रकार आहे। टनेल सबनेटला स्रोत आणि बाह्य इंटरफेसला निर्गम म्हणून नाव द्या।

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

स्थिर सार्वजनिक पत्त्यासह स्रोताचे भाषांतर नेमक्या त्या पत्त्यावर अधिक अंदाजयोग्य आणि तपासणे सोपे आहे।

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

दुसऱ्या प्रकारात देखभालीचा सापळा आहे: नंतर बदलणारा हार्डकोड केलेला पत्ता टनेल चालू ठेवतो तर इंटरनेट प्रवेश शांतपणे थांबतो। एकतर masquerade वापरा किंवा प्रदात्याने तुम्हाला हलवल्यावर नियम अद्ययावत करा। इंटरफेसही महत्त्वाचा आहे, कारण स्वतःचा वरचा टनेल सामायिक करणाऱ्या राउटरला भौतिक WAN मधून नव्हे, त्या टनेलमधून भाषांतर करावे लागते।

फिल्टर तक्ता हे तिसरे प्रवेशद्वार आहे

फॉरवर्डिंग आणि भाषांतर दोन्ही बरोबर असू शकतात तरी पॅकेट फिल्टर तक्त्यात मरते। ufw वारंवार दोषी असतो: त्याचे फॉरवर्ड धोरण DROP म्हणून येते, आणि उर्वरित सेटअप पूर्णपणे बरोबर दिसू शकतो तर ती एकच सेटिंग रहदारी मारते। ती वर करणे हे चेकबॉक्स नव्हे, जाणीवपूर्वक सुरक्षा निर्णय आहे।

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

पहिला नियम टनेलमधून बाहेरच्या दिशेने नवीन रहदारीला परवानगी देतो, आणि दुसरा फक्त उत्तरांना परत येऊ देतो। दोन्ही टनेल सबनेट आणि इच्छित गंतव्यापर्यंत मर्यादित करा, कारण टनेल इंटरफेसवरील सर्वसमावेशक परवानगी VPN ला प्रमाणित करू शकणाऱ्या कोणासाठीही खुले निर्गम बिंदू बनवते।

ब्रिज केलेल्या टनेलला वेगळे उत्तर हवे। पत्ता भौतिक पोर्टचा नाही, ब्रिजचा आहे, त्यामुळे इंटरफेसला गुलाम करणे त्याचा आधीचा पत्ता काढून टाकते आणि ब्रिजला स्वतःला पत्ता मिळेपर्यंत होस्ट अगम्य दिसतो, जो dhclient br0 देऊ शकतो। ती अयशस्वीता VPN समस्या वाटते आणि दुसऱ्या स्तराची समस्या आहे। फायरवॉलला हात लावण्यापूर्वी ब्रिजचा स्वतःचा पत्ता तपासा, कारण फिल्टर बदल पाठवण्यासाठी पत्ता नसलेला होस्ट दुरुस्त करू शकत नाही।

पृष्ठ कधीही लोड न झाल्यास कुठे पाहावे

टनेल अस्तित्वात आहे हे सिद्ध करण्यासाठी सर्व्हरच्या टनेल पत्त्यावर ping करा। नंतर क्लायंटपासून सार्वजनिक पत्त्यापर्यंत traceroute चालवा आणि कुठे थांबते ते वाचा: सर्व्हरवर पॅकेट पोहोचते पण फॉरवर्ड किंवा भाषांतर होत नाही; सर्व्हरच्या पलीकडे समस्या वरच्या स्तरावर आहे आणि तुमच्या हातात नाही।

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

पहिला आदेश सिद्ध करतो की टनेल रहदारी सर्व्हरपर्यंतच नेतो, आणि दुसरा दाखवतो की पॅकेट बाहेर किती दूर जाते। टनेल पत्त्यावर संपणारा ठसा सर्व्हरवरील फॉरवर्डिंग किंवा भाषांतराकडे निर्देश करतो, तर एक हॉप नंतर थांबणारा ठसा प्रदात्याकडे किंवा वरच्या राउटरच्या परतीच्या मार्गाकडे।

सर्व्हरवर, क्लायंट पृष्ठ लोड करत असताना बाह्य इंटरफेस पाहा। खाजगी स्रोत पत्त्यासह बाहेर पडणारी रहदारी म्हणजे भाषांतर गहाळ आहे, आणि उत्तर अजिबात न येणे म्हणजे फॉरवर्ड मार्ग किंवा वरचा परतीचा मार्ग ते टाकून देत आहे।

जर दूरच्या क्लायंटना सर्व्हरच्या LAN वरील होस्टपर्यंतही पोहोचायचे असेल, तर LAN ला टनेल सबनेटपर्यंत परतीचा मार्ग लागतो हे लक्षात ठेवा। हे भाषांतर नव्हे, राउटिंग आहे, आणि इंटरनेट मार्ग शेवटी काम करू लागल्यानंतर सर्वात जास्त विसरला जाणारा टप्पा हाच आहे।