दूरस्थ उपयोगकर्ता 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 का दस्तावेज़ीकरण करता है।