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 सफल हुँदा पनि क्लाइन्टलाई गिराउँछ। सबै जाँच पास भए पनि एप असफल भएमा त्रुटि टनेलमाथि हुन्छ: एउटा इन्टरफेसमा बाँधिएको सेवा, वा क्लाइन्टमा सेट गरिएको प्रोक्सी।