LAN सर्वर पर VPN क्लाइंट: जवाब गलत रास्ते से क्यों निकलते हैं

लक्षण एक ही आकार का अनुसरण करते हैं: होस्ट काम करता है, फिर वह क्लाइंट के रूप में VPN से जुड़ता है, और अब LAN क्लाइंट उस तक पहुँचते हैं जबकि उसके जवाब गायब हो जाते हैं। होस्ट पर किया गया कैप्चर दिखाता है कि जवाब LAN इंटरफ़ेस के बजाय टनल डिवाइस से बाहर जाते हैं। टनल में कुछ टूटा नहीं है, और सुधार एक रूट है, दोबारा कनेक्ट नहीं। नीचे दिए चार जाँच क्रम में करें और पहली विफल जाँच पर रुकें।

जवाब एक नया पैकेट है, रास्ते का उल्टा नहीं

यह विचार छोड़ना मदद करता है कि जवाब उसी रास्ते लौटता है जिससे कोई अनुरोध गया। राउटिंग हर पैकेट के लिए, हर दिशा के लिए, भेजने वाले होस्ट पर तय होती है। टनल के भीतर 10.64.0.23 से आया अनुरोध कोई वापसी रास्ता नहीं बनाता; जब होस्ट जवाब देता है, वह जवाब नए पैकेट के रूप में तालिका से मिलाया जाता है और जो रूट जीतता है उससे बाहर जाता है।

इसीलिए LAN भी सेवा देने वाली मशीन पर फुल-टनल क्लाइंट इतनी उलझाने वाली विफलता पैदा करता है। क्लाइंट डिफ़ॉल्ट रूट, या वे दो आधे-डिफ़ॉल्ट रूट इंस्टॉल करता है जिन्हें कुछ क्लाइंट पसंद करते हैं, और LAN क्लाइंट को जवाब अब टनल से मेल खाता है। वह प्रदाता के पास जाता है, जिसके पास उसे आगे भेजने का कोई कारण नहीं है, और LAN क्लाइंट समय-समाप्ति देखता है जबकि होस्ट चालू है और स्थानीय रूप से जवाब दे रहा है। कैप्चर इसे स्पष्ट कर देता है, और राउटिंग तालिका इसे समझाती है।

बाकी पढ़ते समय दो सबनेट ध्यान में रखें। एक VPN पता पूल है जहाँ से दूरस्थ क्लाइंट आते हैं, इस उदाहरण में 10.64.0.0/24। दूसरा वह LAN है जो चलता रहना चाहिए, 172.16.24.0/24 अपने राउटर के साथ 172.16.24.1 पर। गड़बड़ यह है कि उनके बीच का ट्रैफ़िक डिफ़ॉल्ट रूट से तय होता है।

इसे कैप्चर और लुकअप से साबित करें

कुछ भी बदलने से पहले पुष्टि करें कि जवाब कौन-सा डिवाइस इस्तेमाल करेगा। लुकअप कैप्चर से तेज़ है और पैकेट बनते समय कर्नेल जिस प्रश्न का उत्तर देगा, ठीक उसी प्रश्न का उत्तर देता है।

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

जवाब को दो भागों में पढ़ें। अगर वह dev tun0 बताता है, तो होस्ट जवाब को एनकैप्सुलेट करके प्रदाता को देगा, और LAN क्लाइंट उसे कभी नहीं देखेगा। अगर वह dev eth0 बताता है पर क्लाइंट फिर भी समय-समाप्ति पाता है, तो रूट पहले से सही है और पैकेट बाद में गिराया जा रहा है, जो दूसरी समस्या और दूसरा सुधार है।

उसी चरण का कैप्चर वह संदेह दूर करता है जो ping नहीं कर सकता। LAN क्लाइंट तक पहुँचता इको जवाब साबित करता है कि कोई रास्ता काम करता है, यह नहीं कि कौन-सा इंटरफ़ेस उसे ले गया, इसलिए कैप्चर होस्ट पर ही चलाएँ और देखें कि फ़्रेम कहाँ से निकलते हैं। उसी सबनेट का प्रिंटर जवाब देता रहता है, क्योंकि उसका सीधा रूट टनल के डिफ़ॉल्ट से अधिक विशिष्ट है। फ़ॉरवर्ड किया गया पोर्ट किसी भी अन्य फ़्लो की तरह ही विफल होता है, क्योंकि इंटरफ़ेस तालिका चुनती है, कनेक्शन नहीं।

टनल को पछाड़ने वाला सबसे संकरा रूट इंस्टॉल करें

प्रीफ़िक्स लंबाई तय करती है, मीट्रिक नहीं, इसलिए LAN राउटर से क्लाइंट पूल का रूट VPN क्लाइंट के किसी भी डिफ़ॉल्ट पर भारी पड़ता है। मीट्रिक सर्जरी की ज़रूरत नहीं है, और डिफ़ॉल्ट ठीक वहीं रह सकता है जहाँ क्लाइंट ने रखा है।

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

दूसरे add के बजाय replace इस्तेमाल करें, क्योंकि दोबारा जुड़ने वाला क्लाइंट अपनी प्रविष्टि इंस्टॉल कर चुका होगा और दूसरा add मौजूदा रूट की त्रुटि से विफल होता है जो अनुमति की समस्या जैसी लगती है। Windows होस्ट पर समतुल्य route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p है, जहाँ -p रीबूट के पार प्रविष्टि रखता है, क्योंकि टनल फिर ऊपर आने पर क्लाइंट तालिका फिर बना सकता है। आधुनिक Windows होस्ट पर समर्थित समतुल्य New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore है, और पुराना route आदेश लीगेसी रूप में रखा गया है।

एक ब्योरा तय करता है कि यह सही है या केवल विश्वसनीय: अगली हॉप वही राउटर होनी चाहिए जो वास्तव में क्लाइंटों तक वापसी रास्ते का मालिक है। रूट को ऐसे पते की ओर इंगित करना जिस तक खुद टनल से पहुँचा जाता है, एक लूप बनाता है जो साफ़ विफलता की बजाय रुक-रुक कर नुकसान के रूप में दिखता है। पंक्ति लागू करने से पहले पुष्टि करें कि अगली हॉप LAN सबनेट पर है।

दोबारा कनेक्ट के बाद जवाब बनाए रखें

हाथ से जोड़ा गया रूट अधिकतम अगले दोबारा कनेक्ट तक टिकता है। अगर क्लाइंट पूल गतिशील है, तो उसे सर्वर कॉन्फ़िगरेशन में पिन करें ताकि आपने जो प्रीफ़िक्स रूट किया वही प्रीफ़िक्स क्लाइंटों को मिलता रहे; वरना प्रविष्टि खाली श्रेणी की ओर इशारा करती है और लक्षण हफ़्तों बाद बिना स्पष्ट कारण के लौट आता है। रूट को क्लाइंट की अपनी up-स्क्रिप्ट में लिखना दूसरा भरोसेमंद विकल्प है, क्योंकि वह क्लाइंट द्वारा तालिका फिर लिखे जाने के बाद चलता है।

स्टेटफुल फ़ायरवॉल सही रूट को फिर भी हरा सकता है। अगर कैप्चर अब दिखाता है कि जवाब eth0 से बाहर जाता है और क्लाइंट फिर भी समय-समाप्ति पाता है, तो जाँचें कि होस्ट भेजने से पहले पैकेट गिरा रहा है या नहीं। सख़्त रिवर्स-पाथ फ़िल्टरिंग और net.ipv4.conf.all.rp_filter को 1 पर सेट करना, ऐसे पैकेट गिराते हैं जिनका स्रोत जिस इंटरफ़ेस से आया उसी से वापस रूट न होता, और यह ठीक वही असममित स्थिति है जो आपने अभी बनाई और फिर ठीक की, और conntrack स्थिति फ़ॉरवर्ड किए गए पोर्ट के लिए वही कहानी कहती है।

आख़िरी जाँच वही है जिसे लोग छोड़ देते हैं: टनल के नीचे जाने और फिर ऊपर आने के बाद लुकअप दोहराएँ। चार मान आपने जो लिखा उससे मेल खाने चाहिए: गंतव्य, अगली हॉप, डिवाइस और चुना गया स्रोत। अगर इनमें से कोई खिसका, तो क्लाइंट ने तालिका फिर लिखी है और सुधार उसके हुक्स में है, shell इतिहास में नहीं।