OpenVPN से LAN एक्सेस टूटा? ज़ोन, रूट और वापसी पथ जाँचें

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

कौन-सा फ़िल्टर LAN की ओर जाता पैकेट देखता है

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

OpenWrt इस विभाजन को जाँचने योग्य बनाता है, और यह अंतर एक बार पढ़ने लायक है। जो ज़ोन टनल समाप्त करता है उसे LAN ज़ोन की ओर इंगित फ़ॉरवर्ड नियम चाहिए, जबकि इनपुट नियम केवल राउटर पर चलने वाली सेवाओं को नियंत्रित करता है। चालू प्रशासन पेज के साथ मृत LAN उसी अनुपस्थित फ़ॉरवर्ड नियम का सामान्य परिणाम है।

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

विभाजित टनल को पुश किया गया प्रीफ़िक्स क्यों चाहिए

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

साइट-से-साइट पीयर पुश से अधिक माँगता है। सर्वर को सीखना पड़ता है कि उस पीयर के पीछे कौन-से प्रीफ़िक्स हैं, जो उसकी client-config-dir फ़ाइल में iroute पंक्ति करती है, और उसकी अपनी तालिका को टनल में जाने वाला मेल खाता रूट चाहिए।

जवाब को ऐसा पता चाहिए जहाँ वह पहुँच सके

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

tcpdump -ni tun0 host 192.168.50.20

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

सही जगह पर समाप्त होने वाली सीढ़ी

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

नाम सीढ़ी के अंत में आते हैं, कभी शुरुआत में नहीं। जो शेयर 192.168.50.20 के रूप में जवाब देता है पर nas.local के रूप में नहीं, वह नाम-समाधान या खोज प्रत्यय की ओर इशारा करता है, और फ़ायरवॉल संपादन इनमें से किसी को नहीं बदल सकते।

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