OpenVPN द्वारे सार्वजनिक प्रीफिक्स: परतीचा मार्ग दुरुस्त करा

टनेल वर येताना आणि क्लायंट पलीकडे पिंग करताना पहा, आणि नंतर VPN मागे असलेला सार्वजनिक पत्ता दुसऱ्या ठिकाणाहून प्रतिसाद देतो, किंवा अजिबात देत नाही। या लक्षणाचा सामान्यतः सायफर किंवा प्रमाणपत्रांशी काही संबंध नसतो। प्रदात्याने राउट केलेला प्रीफिक्स IP मार्ग म्हणून पोहोचवला जातो, आणि तो OpenVPN द्वारे वाहून नेणे म्हणजे तो मार्ग दोन स्तरांवर पुन्हा तयार करणे आणि परतीच्या मार्गावर स्रोत पत्ता टिकवणे। WAN ब्रिज करण्याची गरज नाही, आणि पत्ता इंटरफेसवर जोडल्याने वरचा मार्ग तयार होत नाही।

प्रीफिक्स आधी तुमच्याकडे राउट व्हायला हवा

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

जर प्रदाता 198.51.100.64/28 तुमच्या प्रवेश सर्व्हरवर राउट करत असेल, तर त्या श्रेणीचे पॅकेट सर्व्हरवर येऊन तुम्ही ते फॉरवर्ड केले नाही तर तिथेच थांबतात। जर प्रदाता त्याऐवजी श्रेणी तुमच्या अपलिंकवर ब्रिज करत असेल, तर सर्व्हरला त्यासाठी ARP चे उत्तर द्यावे लागते, जी वेगळी समस्या आहे।

OpenVPN ला स्पर्श करण्यापूर्वी डिलिव्हरी मॉडेल तपासा: बाहेरून ब्लॉकमधील पत्त्याला पिंग करा आणि कोणता इंटरफेस तो स्वीकारतो ते पहा। काहीही आले नाही तर कोणतेही टनेल कॉन्फिगरेशन मदत करणार नाही। जर पत्ता WAN वर थेट प्रतिसाद देत असेल, तर प्रदाता राउट करण्याऐवजी ब्रिज करत आहे, आणि खालील डिझाइन लागू होत नाही।

दोन राउटिंग स्तर: कर्नेल मार्ग आणि iroute

OpenVPN ला प्रीफिक्स दोन ठिकाणी लागतो। कर्नेलला माहीत असले पाहिजे की प्रीफिक्स टनेल उपकरणाचा आहे, जेणेकरून फॉरवर्ड केलेले पॅकेट डीफॉल्ट मार्गाऐवजी OpenVPN मध्ये जातील। OpenVPN ला हे देखील माहीत असले पाहिजे की कोणता प्रमाणित क्लायंट प्रीफिक्सचा मालक आहे, आणि ती क्लायंट-विशिष्ट डिरेक्टरीमधील iroute नोंद आहे।

सर्व्हर-बाजूचा मार्ग असा दिसतो, ज्यात प्रीफिक्स आणि मास्क वाटपाशी जुळले पाहिजेत:

ip route add 198.51.100.64/28 dev tun0

क्लायंट-विशिष्ट कॉन्फिगरेशन मालकी नेमते। ते क्लायंट प्रमाणपत्राच्या सामान्य नावावर नाव असलेल्या CCD फाइलमध्ये ठेवा, आणि सर्व्हर प्रत्यक्षात तीच डिरेक्टरी वाचतो याची खात्री करा:

iroute 198.51.100.64 255.255.255.240

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

सेवा पत्ता कुठे राहतो

डेलिगेट केलेला प्रीफिक्स टनेलच्या स्वतःच्या पत्त्यांसारखा नसतो। हवे असल्यास लिंक खाजगी जागेतून क्रमांकित करा, आणि सार्वजनिक सेवा पत्ता सेवा प्रत्यक्षात चालते तिथे ठेवा।

सेवा स्थानिक पातळीवर संपवणाऱ्या Linux क्लायंटवर एकच होस्ट पत्ता पुरतो:

ip address add 198.51.100.70/32 dev lo

जर प्रीफिक्स पुढे VM होस्ट किंवा दुसऱ्या LAN कडे राउट होत असेल, तर त्याऐवजी तो डाउनस्ट्रीम मार्ग आणि त्याचा परत मार्ग कॉन्फिगर करा। ब्लॉकमधील प्रत्येक पत्ता VPN क्लायंटला देण्याची गरज नाही आणि त्यामुळे नंतर संघर्ष होतात।

परतीच्या मार्गावर सार्वजनिक स्रोत ठेवा

डेलिगेट केलेल्या प्रीफिक्समधून प्रतिसाद टनेलमधून बाहेर पडून प्रदात्याच्या मार्गापर्यंत पोहोचला पाहिजे। जर दूरचा होस्ट तो स्वतःच्या ISP द्वारे पाठवत असेल, तर स्रोत पत्ता बनावट वाटतो, आणि प्रदाता किंवा गंतव्य तो टाकून देतात। उपाय आहे स्रोत-आधारित नियम किंवा समर्पित राउटिंग तक्ता, अधिक रुंद NAT नाही। त्याशिवाय सेवा टनेल भागीदाराकडून काम करते आणि इतर सर्व ठिकाणांहून अपयशी ठरते।

प्रवेश सर्व्हरवर रुंद masquerade नियम हा नेहमीचा दोषी असतो। तो सार्वजनिक स्रोत सर्व्हरच्या मुख्य पत्त्यावर पुन्हा लिहितो, आणि क्लायंटला खरा कधीच दिसत नाही:

iptables -t nat -S POSTROUTING

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

त्यावर विश्वास ठेवण्यापूर्वी दोन्ही दिशा तपासा

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

कर्नेलला विचारा की डेलिगेट केलेला पत्ता कोणता मार्ग घेतो, आणि विनंती चालू असताना टनेल पहा:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

रिव्हर्स-पाथ फिल्टरिंग योग्य मार्ग रद्द करू शकते। टनेलवर आणि अपलिंकवर प्रभावी सेटिंग तपासा, आणि लक्षात ठेवा की कठोर मोड तो रहदारी नाकारतो ज्याचा स्रोत ज्या इंटरफेसवरून आला त्याला जुळत नाही:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

शेवटी, अपयशाची स्थिती तपासा। टनेल थांबवा आणि सार्वजनिक प्रीफिक्स सामान्य अपलिंकमधून गळत नाही याची खात्री करा। VPN पुनर्संचयित केल्यावर होस्ट जे पोर्ट उघडतो ते न वाढवता सेवा परत आली पाहिजे।