रूटेड VPN क्लाइंट सर्वर तक पहुँचता है, पर LAN होस्ट तक नहीं

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

जवाब का पीछा करें, अनुरोध का नहीं

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

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

रिटर्न रूट वहाँ रखें जहाँ होस्ट देखते हैं

हर LAN होस्ट अपने डिफ़ॉल्ट गेटवे से परामर्श करता है, इसलिए गेटवे ही वह अकेला डिवाइस है जिसे जानना है कि टनल पूल कहाँ है। वहाँ स्थिर रूट जोड़ें और हर होस्ट बिना छुए सही रास्ता पा लेता है।

अगर गेटवे अपना पता DHCP विकल्प के रूप में बाँटता है, तो रूट उसी तरह बाँटें ताकि नई मशीनें उसे अपने आप ले लें। वरना रूट एक कॉन्फ़िगरेशन फ़ाइल में रहता है और अगली पुनर्निर्माण में गायब हो जाता है।

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

स्रोत NAT इसे ठीक करता क्यों दिखता है

क्लाइंट पूल को VPN सर्वर के पते के पीछे छिपाना पैकेट से क्लाइंट का पता हटाकर समस्या हटा देता है। तब जवाब सर्वर पर लौटते हैं, जिसे पहले से पता है कि टनल तक कैसे पहुँचना है, और सब काम करता है। कीमत यह है कि आंतरिक होस्ट अब नहीं देख सकते कि क्लाइंट कौन है, और हर कनेक्शन एक ही मशीन से आता दिखता है।

यह अदला-बदली कभी-कभी सही होती है, जैसे जब विक्रेता के उपकरण को स्थिर रूट नहीं दिया जा सकता। नियम को मौजूदा पूल से चौड़ा न बनाएँ, क्योंकि /24 के लिए लिखा नियम उस दिन मेल खाना बंद कर देता है जब पूल को /16 पर फिर से क्रमांकित किया जाता है, और पहला संकेत नए क्लाइंट का समूह होता है जो जुड़ते हैं और कहीं नहीं पहुँचते।

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

क्लाउड रास्ते को तीन सेटिंग चाहिए

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

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

जाँचें इसी क्रम में करें

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

क्लाइंट के LAN होस्ट को पिंग करते समय वहाँ लिया गया कैप्चर लेकर समाप्त करें। जो अनुरोध मिलते जवाब के बिना आता है वह वापसी का रास्ता सिद्ध करता है, और जो अनुरोध कभी नहीं आता वह दोष को सर्वर या टनल पर लौटा देता है।

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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