रिमोट वापरकर्ते VPN हबमधून दुसऱ्या साइटपर्यंत पोहोचत नाहीत

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

जाण्यासाठी तीन लुकअप लागतात, एक टनेल नाही

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

म्हणूनच प्रत्येक टनेल स्वतंत्रपणे तपासणे इतके कमी सिद्ध करते। हबच्या LAN पत्त्याला पिंग करणे पहिला निर्णय तपासते, आणि मुख्यालयातून हबला पिंग करणे तिसरा तपासते। जे पॅकेट अयशस्वी होते त्याचा स्रोत वापरकर्ता पूल आणि गंतव्य दुसरी साइट असते, म्हणून आधी ते प्रीफिक्स लिहून घ्या। येथे पूल 10.80.0.0/24 आहे, हबचे LAN 10.10.0.0/24 आहे आणि मुख्यालय 10.20.0.0/24 आहे।

दूरचे प्रीफिक्स रिमोट क्लायंटकडे ढकला

एका OpenVPN रिमोट-अॅक्सेस सर्व्हरवर क्लायंट जोडणीच्या वेळी रूट शिकतो। push नसल्यास, स्प्लिट-टनेल क्लायंट 10.20.0.50 स्वतःच्या गेटवेवर पाठवतो आणि पॅकेट कधीही टनेलमध्ये जात नाही।

push "route 10.20.0.0 255.255.255.0"

ढकललेला रूट क्लायंट जोडला जातो तेव्हा लागू होतो, त्यामुळे ऑनलाइन राहणारा वापरकर्ता पुन्हा जोडेपर्यंत काहीही पाहत नाही। क्लायंटवर तपासा: Linux वर ip route get 10.20.0.50, Windows वर route print। आउटपुटने टनेल इंटरफेसचे नाव सांगितले पाहिजे।

push हबला मदत करत नाही। हा क्लायंटला दिलेला संदेश आहे, सर्व्हरवरील रूट नाही आणि पुढे पाठवण्याची परवानगीही नाही, त्यामुळे परिपूर्ण push ओळ असलेले हबही एका हॉपनंतर प्रवाह सोडते। लोक push अयशस्वी झाले असा निष्कर्ष काढण्याचे हेच नेहमीचे कारण आहे।

हबला खरा इग्रेस रूट द्या

हबला मुख्यालयाच्या प्रीफिक्ससाठी स्वतःचा पुढील हॉप हवा। राउटेड टनेलवर तो साइट-टू-साइट इंटरफेसवरून जाणारा सामान्य रूट असतो, आणि एक कमांड निवडलेला रूट व निवडलेला स्रोत दोन्ही दाखवते:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

जिथे साइट-टू-साइट पाया स्वतः OpenVPN आहे, तिथे रूट त्या कॉन्फिगरेशनमध्येच पीअरच्या टनेल पत्त्याला गेटवे म्हणून ठेवून राहू शकतो: route 10.20.0.0 255.255.255.0 172.30.0.2। गेटवे ऐच्छिक नाही। तो वगळला तर पुढील हॉप अंमलबजावणीच्या डीफॉल्टवर पडतो, जो एकल-रिमोट क्लायंट आणि बहु-पीअर हबमध्ये वेगळा असतो।

धोरण-आधारित IPsec वेगळे आहे: हबचे कर्नेल पॅकेट त्याच्या नेहमीच्या LAN गेटवेवर पाठवते आणि धोरण ते बाहेर जाताना पकडते, त्यामुळे टनेल रूट एकतर काहीही करत नाही किंवा धोरणाच्या बाजूने ट्राफिक नेते। वरील कमांडमधील स्रोत पहा, कारण पूलच्या पत्त्याऐवजी 10.10.0.1 म्हणजे कर्नेलने असे पत्ते निवडले जे दूरची बाजू नाकारेल। iroute हेही उत्तर नाही; ते सर्व्हरला सांगते की कोणता क्लायंट स्वतःच्या टनेलमागील सबनेटचा मालक आहे, तिसऱ्या साइटसाठी ट्राफिक कुठे पाठवायचे हे नाही।

दूरची बाजू वापरकर्ता पूलपर्यंत वाढवा

मुख्यालय आधीच हबचे LAN, 10.10.0.0/24 व्यापते। वापरकर्ता पूल हा दुसरा प्रीफिक्स आहे आणि तो सिलेक्टरमध्येही असला पाहिजे, नाहीतर 10.80.0.25 ला पाठवलेल्या उत्तराला कोणतेही धोरण व्यापत नाही। प्रत्येक पीअर स्वतःच्या बाजूने प्रीफिक्स संचांची तीच जोडी नाव देते:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

एका उपकरणाचा local_ts दुसऱ्याचा remote_ts असतो। हबचा ब्लॉक मुख्यालयावर कॉपी करा आणि जोडी उलटते, त्यामुळे चाइल्ड SA कधीही वर येत नाही।

जुना ipsec.conf सिंटॅक्स स्वल्पविरामाने वेगळे केलेले leftsubnet वापरतो। चालू सुरक्षा संस्था ज्या सिलेक्टरवर वाटाघाटी केली ते ठेवते, त्यामुळे संपादनानंतर टनेल पुन्हा स्थापित करा। 10:00 वाजता बदललेला सिलेक्टर 09:40 वाजता वर आलेल्या SA विरुद्ध तपासला तरी अयशस्वी होतो, तर कॉन्फिग फाइल संपूर्ण वेळ बरोबर दिसते।

मग शेवटचा हॉप तपासा। दूरच्या एंडपॉइंटवर ip route get 10.80.0.25 टनेलकडे निर्देश करेल। जर सेवा LAN राउटरला तिचा डीफॉल्ट गेटवे म्हणून वापरत असेल, तर त्या राउटरलाही रिटर्न रूट हवा, नाहीतर उत्तर तिथेच मरते। त्या सेगमेंटवर tcpdump -ni eth1 host 10.80.0.25 चालवल्यास उत्तर एंडपॉइंटमधून बाहेर पडले आहे का हे दिसते।

हबवर प्रवाहास परवानगी द्या

फॉर्वर्डिंग सक्षम आणि मार्ग परवानगीत असावा। इंटरफेसांमधील सर्व काही स्वीकारण्याऐवजी नियम दोन प्रीफिक्सपर्यंत मर्यादित करा।

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

रिव्हर्स-पाथ फिल्टरिंग ही त्याच्या बाजूची शांत अयशस्वीता आहे: दोन पाय वेगवेगळ्या इंटरफेसवर असतील तर rp_filter=1 उत्तर टाकू शकते, तर स्वीकृती नियमाचा काउंटर कधीही हलत नाही। एका प्रयत्नापूर्वी आणि नंतर iptables -vnL FORWARD ची तुलना करा। जो नियम कधीही वाढत नाही तिथे पोहोचले जात नाही, त्यामुळे तो पुन्हा लिहिण्याऐवजी एक थर खाली पहा।

जर फक्त एका गटाला जाण्याची गरज असेल, तर जागतिक push रुंदावण्याऐवजी client-config-dir अंतर्गत प्रति-क्लायंट फाइलमध्ये रूट ठेवा। हबवरील सोर्स NAT देखील दूरच्या बाजूच्या रिटर्न रूटची गरज दूर करते, पण ते वापरकर्त्याचा पत्ता लपवते, त्यामुळे दूरच्या साइटचे लॉग आणि पत्ता-आधारित नियम वापरकर्त्यांमध्ये फरक करणे थांबवतात।

क्लायंटवरून तपासा, मग उलट क्रमाने रोलबॅक करा

फक्त ICMP नाही तर TCP पोर्ट तपासा, कारण सेवा अवरोधित असतानाही पिंग जाऊ शकते। क्लायंटवरून nc -vz 10.20.0.50 445 आणि traceroute -n 10.20.0.50 दाखवतात की दुसरा हॉप हबचा टनेल पत्ता आहे का। हबवर, tcpdump -ni tun0 host 10.20.0.50 आणि साइट-टू-साइट इंटरफेसवर तोच फिल्टर: दोन्हीवर विनंती पण कोणत्याहीवर उत्तर नाही, समस्या दूरच्या बाजूकडे सरकते।

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

रोलबॅक यादी ठेवा, कारण चार वस्तू बदलल्या आहेत आणि तीन विसरणे सोपे आहे: ढकललेला रूट, हबचा रूट, सिलेक्टर आणि फायरवॉल नियम। त्या उलट क्रमाने मागे घ्या, SA पुन्हा स्थापित करा, आणि एका वापरकर्त्याला पुन्हा जोडू द्या। अर्धवट रोलबॅक अशा टनेलकडे निर्देश करणारा रूट सोडतो जो आता जुळत नाही, आणि ते मूळ शांततेपेक्षा वाचणे कठीण आहे। OpenVPN 2.6 मॅन्युअल तुमच्या आवृत्तीसाठी push, route आणि iroute चे दस्तऐवजीकरण करते।