साइट-टू-साइट VPN का जवाब टनल से नहीं गुज़रता
टनल को छोड़ देने वाला जवाब दूर की तरफ़ लिया गया रूटिंग फ़ैसला है। होस्ट टेबल, सिलेक्टर और rp_filter जाँचें, फिर रूट या NAT चुनें।
मैंने एक सुबह ऐसे टनल पर बिताई जो साफ़-सुथरा ऊपर आया और ट्रैफ़िक ठीक एक ही दिशा में ले जाता रहा: शाखा मुख्यालय के फ़ाइल सर्वर तक पहुँच जाती थी, और मुख्यालय से शाखा में खुलने वाला हर कनेक्शन पहले SYN पर मर जाता था। SA चालू थे, टनल के काउंटर बढ़ रहे थे, और हैंडशेक कभी समस्या नहीं था। जवाब कहीं ऐसी जगह रूट हो रहा था जिसे टनल कवर नहीं करता, और यह चुनाव दूर की तरफ़ का है। साइट-टू-साइट VPN सिर्फ़ वे पैकेट ले जाता है जो होस्ट गेटवे को सौंपता है, और हर होस्ट यह चुनाव अलग-अलग, हर दिशा में, अपनी रूटिंग टेबल से करता है।
दोनों दिशाएँ अलग-अलग रूट होती हैं
IP बातचीत की दिशा का कोई ज्ञान नहीं रखता। पैकेट भेजने वाला हर होस्ट अपनी सबसे लंबी प्रीफ़िक्स खोज चलाता है, एक अगला हॉप चुनता है और फ़ैसला भूल जाता है। अनुरोध और जवाब दो बेमेल पैकेट हैं जो संयोग से एक ही कनेक्शन के हैं, और टनल एक हॉप है जिसे इनमें से कोई भी इस्तेमाल कर सकता है या नहीं। IKE की अदला-बदली में कुछ भी दूर के सर्वर को यह नहीं सिखाता कि आपके सबनेट तक कैसे पहुँचना है; बातचीत सिर्फ़ इस पर सहमत होती है कि कौन-सी प्रीफ़िक्स एन्क्रिप्ट की जा सकती हैं।
वह सहमति दूसरा दरवाज़ा है। strongSwan पर ट्रैफ़िक सिलेक्टर leftsubnet और rightsubnet हैं, और जिस पैकेट का स्रोत या गंतव्य तय की गई जोड़ी से बाहर पड़े वह एन्क्रिप्ट नहीं होता, रूटिंग टेबल चाहे कुछ भी कहे। जो प्रीफ़िक्स टनल में रूट होती है पर सिलेक्टर में नहीं है, वह एक शांत एकतरफ़ा विफलता है: रूट सही दिखता है, पैकेट फिर भी खुला निकल जाता है या गिरा दिया जाता है, और सिर्फ़ charon का लॉग शिकायत करता है।
दूर का होस्ट आपके टनल के बारे में कुछ नहीं जानता
दूर के LAN के अंदर जवाब आपके क्लाइंट को भेजा गया एक साधारण पैकेट है। गंतव्य होस्ट को कोई IPsec हेडर नहीं दिखता और उसके पास VPN गेटवे को प्राथमिकता देने की कोई वजह नहीं है; वह आपकी प्रीफ़िक्स खोजता है, अपने डिफ़ॉल्ट रूट से ज़्यादा ख़ास कुछ नहीं पाता और उसी पर चल पड़ता है। अगर डिफ़ॉल्ट किसी कोर फ़ायरवॉल की ओर इशारा करता है, तो फ़ायरवॉल के पास टनल में वापस जाने का रूट है या नहीं। जब नहीं है, तो आपको शांत ड्रॉप, ऐसा जवाब जो इंटरनेट की ओर वाले इंटरफ़ेस से निकलकर मर जाता है, या ICMP unreachable मिलता है।
दूसरा इंटरफ़ेस ही इसे तोड़ने के लिए काफ़ी है, तब भी जब रूट मौजूद हो। दूसरे VLAN पर मैनेजमेंट लिंक वाला NAS, बैकअप uplink वाला सर्वर, एक स्रोत-श्रेणी को दूसरी टेबल में भेजने वाला पॉलिसी नियम: इनमें से कोई भी जवाब पकड़ सकता है। Linux पर, ip rule show और ip route show table all वे नियम और टेबल दिखाते हैं जिन्हें डिफ़ॉल्ट सूची छिपाती है।
जवाब भेजने वाली मशीन पर फ़ैसला पढ़ें
कुछ भी बदलने से पहले कर्नेल से पूछें, और उसे स्रोत पता दें, क्योंकि स्रोत पर निर्भर नियम जवाब बदल देते हैं।
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"आउटपुट बाहर जाने वाला इंटरफ़ेस और अगला हॉप बताता है। अगर इंटरफ़ेस वह नहीं है जो VPN गेटवे की ओर है, तो आपको ख़राबी मिल गई है, और बाक़ी काम यह तय करना है कि रूट कहाँ होना चाहिए। गेटवे से किया गया ping यहाँ कम साबित करता है: वह ऐसे पते से जवाब देता है जिसे दूर का होस्ट रख सके, आपके लैपटॉप के पते से नहीं।
Windows पर बराबर Find-NetRoute -RemoteIPAddress 10.10.5.10 फ़ैसले के लिए और Get-NetRoute टेबल के लिए हैं। डिफ़ॉल्ट से ज़्यादा मीट्रिक वाला New-NetRoute से जोड़ा गया रूट चुपचाप हार जाता है, इसलिए मीट्रिक कॉलम पढ़ें, प्रविष्टि नहीं। फिर पैकेट से पुष्टि करें: दूर के LAN इंटरफ़ेस पर tcpdump -ni any "host 10.10.5.10 and tcp port 445" अनुरोध दिखाता है, और टनल की ओर वही फ़िल्टर दिखाता है कि जवाब लौटा या नहीं। अनुरोध दिखे पर जवाब न हो इसका मतलब जवाब कहीं और रूट हुआ या गिरा दिया गया; ग़लत इंटरफ़ेस पर जवाब आपको रूट छूने से पहले दोषी दे देता है।
जब सर्वर का गेटवे VPN एंडपॉइंट न हो
बहुत साइटें सर्वर और कॉन्सेंट्रेटर के बीच फ़ायरवॉल रखती हैं। वह फ़ायरवॉल जवाब आगे भेजता है, इसलिए उसे आपके क्लाइंट प्रीफ़िक्स के लिए VPN गेटवे की ओर इशारा करने वाला रूट और दोनों दिशाओं में फ़ॉरवर्डिंग पॉलिसी चाहिए। स्टेटफ़ुल डिवाइस इसे और बिगाड़ते हैं: अनुरोध ने उसी LAN होस्ट से फ़ायरवॉल पार किया जिसे उसने अनुमति दी थी, जवाब अब दूसरी दिशा से आता है, और कनेक्शन-ट्रैकिंग प्रविष्टि अब मेल नहीं खाती, इसलिए पैकेट अस्वीकार होने के बजाय अमान्य मानकर गिरा दिया जाता है। इसीलिए ट्रैफ़िक ग़ायब होते समय पॉलिसी लॉग ख़ाली दिखता है।
गेटवे का अपना दूसरा फ़िल्टर है। Linux की रिवर्स-पाथ फ़िल्टरिंग ऐसे पैकेट गिराती है जिनका स्रोत उस इंटरफ़ेस से पहुँच योग्य नहीं है जिस पर वे आए, और यह ठीक वैसी ही शक्ल है जैसी किसी वैध असममित वापसी मार्ग की होती है। strongSwan की फ़ॉरवर्डिंग गाइड इसी वजह से net.ipv4.ip_forward और ढीला net.ipv4.conf.all.rp_filter माँगती है। किसी भी गेटवे पर सख़्त मान 1 सही रूट को चुपचाप तोड़ देता है, और अगर आपको देखना आता है तो nstat -az वे ड्रॉप दिखाता है।
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
रूट करें या अनुवाद करें, फिर दोनों दिशाओं में जाँचें
दोनों मरम्मतें बराबर नहीं हैं। रूट जोड़ने से क्लाइंट का पता सुरक्षित रहता है, इसलिए स्रोत-आधारित नियम, ऑडिट लॉग और कॉलर दर्ज करने वाले ऐप्स काम करते रहते हैं; क़ीमत यह है कि फ़ैसला लेने वाले हर हॉप को रूट चाहिए, यानी ग़लती के और भी ठिकाने। दूर के गेटवे पर मास्करेड वापसी मार्ग को एक हॉप में सिकोड़ देता है, क्योंकि जवाब अब गेटवे को ही भेजा जाता है, और छिपा देता है कि किस क्लाइंट ने क्या किया।
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEइसे जान-बूझकर चुनें: जैसे ही क्लाइंट गेटवे के पते के रूप में दिखने लगते हैं, स्रोत-आधारित ACL उन्हें अलग पहचानना बंद कर देते हैं, और जवाब को टनल में वापस लिखे जाने के लिए conntrack को मैपिंग थामे रखना पड़ता है। अगर सिलेक्टर अब भी क्लाइंट प्रीफ़िक्स को बाहर रखते हैं, तो NAT कुछ नहीं बदलता, क्योंकि अनुरोध कभी टनल में घुसा ही नहीं।
इसे ठीक कहने से पहले चार चीज़ें क्रम से पक्की करें: जवाब भेजने वाले होस्ट पर रूट, उसे फ़ॉरवर्ड करने वाले हर हॉप पर रूट, दोनों प्रीफ़िक्स ढकने वाले सिलेक्टर, और ऐसा कैप्चर जो दिखाए कि जवाब उसी स्रोत के साथ टनल में घुस रहा है जिसकी आप उम्मीद करते हैं। फिर दूसरी साइट से परीक्षण दोहराएँ। एक दिशा पार होना आधा-खुला डिज़ाइन है, और दूसरी दिशा आम तौर पर उससे अलग वजह से विफल होती है जिसे आपने अभी ठीक किया।