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 यशस्वी असतानाही क्लायंट टाकून देतो। सर्व तपासण्या पास झाल्यावरही अनुप्रयोग अपयशी ठरल्यास दोष टनेलच्या वर आहे: एका इंटरफेसला बांधलेली सेवा, किंवा क्लायंटवर सेट केलेला प्रॉक्सी।