Mesh Wi-Fi उपग्रह VPN राउटर वापरतो का हे कसे तपासायचे
Mesh उपग्रहाचे क्लायंट VPN मधून जातात का हे सिद्ध करण्यासाठी डीफॉल्ट गेटवे, नोडचा फॉरवर्डिंग मोड आणि राउटरची स्टेट टेबल पाहा.
जो उपग्रह बेस राउटरच्याच Wi-Fi नावाला उत्तर देतो, तो त्याच्या क्लायंटचे पॅकेट कुठे जातात याबद्दल जवळपास काहीच सांगत नाही. नोड एक रेडिओ आणि ब्रिज आहे, जोपर्यंत उलटे सिद्ध होत नाही. बाहेर पडणे कोणत्या मार्गाने होते हे प्रत्येक क्लायंटला मिळणारा डीफॉल्ट गेटवे आणि त्याच्यापुढील नोडचा फॉरवर्डिंग मोड ठरवतो. या पाच तपासण्या क्लायंटपासून बाहेरच्या दिशेने करा, मग स्पीड टेस्टच्या ठसक्याऐवजी तुमच्याकडे सिद्ध करता येईल असे उत्तर असेल.
क्लायंटला प्रत्यक्षात मिळालेला गेटवे वाचा
क्लायंटवर रूट टेबल आणि शेजारी टेबल छापा. डीफॉल्ट रूट त्या पत्त्याचे नाव घेते जो रहदारी पुढे पाठवते; शेजारी नोंद त्या MAC चे नाव घेते ज्याच्या मालकीचा तो पत्ता आहे. राउटरची उपकरणांची यादी नाही, क्लायंट वापरा, कारण उपकरणांची यादी जोडण्या दाखवते, मार्ग नाही.
ip route show default
ip -6 route show default
ip neigh showWindows तीच तथ्ये वेगळ्या स्वरूपात छापते: ipconfig /all डीफॉल्ट गेटवे देते आणि arp -a MAC देते. macOS वर route -n get default आणि arp -an तेच करतात.
त्या गेटवेची तुलना तुम्हाला आधीच माहीत असलेल्या दोन पत्त्यांशी करा: बेस राउटरचा LAN पत्ता आणि उपग्रहाचा व्यवस्थापन पत्ता. गेटवे राउटरचा LAN पत्ता असेल, तर क्लायंट राउटरशी ब्रिजने जोडलेला आहे आणि त्या नेटवर्कसाठी राउटरचे धोरण बदलाशिवाय लागू होते. गेटवे उपग्रहाचा पत्ता असेल, तर उपग्रह राउटिंग करत आहे आणि राउटर क्लायंटचे पॅकेट कधीच LAN रहदारी म्हणून पाहत नाही; निर्णय नोडवरच घ्यायला हवा, नाहीतर तो होणारच नाही.
नोड प्रत्यक्षात कोणत्या मोडमध्ये आहे याची खात्री करा
Mesh उत्पादने वेगळ्या वर्तनासाठी तीन शब्द पुन्हा वापरतात, म्हणून ॲपमधील लेबलापेक्षा पॅकेटच्या मार्गावर जास्त विश्वास ठेवा. ब्रिज किंवा ॲक्सेस पॉइंट मोड फ्रेम पुढे पाठवतो. राउटर मोड सबनेट संपवतो आणि DHCP चालवतो. गेस्ट मोड सामान्यतः क्लायंटला स्वतःच्या नियमांसह वेगळ्या VLAN मध्ये ठेवतो. दुसऱ्या राउटरच्या मागे राउटर मोडमधील नोड डबल NAT आहे, आणि त्याचे क्लायंट VPN राउटरपर्यंत आधीच अनुवादित होऊन पोहोचतात, ज्यामुळे स्रोत पत्त्यावर आधारित धोरण कमकुवत होते.
| What you see | What it means | Next check |
|---|---|---|
| Gateway is the router's LAN address, one MAC for every node | The node bridges; the router owns the policy | Router policy for that LAN and VLAN |
| Gateway is the node's address and DHCP comes from the node | The node routes; double NAT | Node's own VPN client, or a static route plus policy on the router |
| Gateway is a different subnet on a guest SSID | Guest VLAN, often client-isolated | Whether that VLAN is inside the tunnel policy |
| Gateway changes when you walk into another room | Roaming across segments | Repeat the check per node |
MAC ठरवण्यासाठी नोडवरील लेबल वाचा आणि खालील कमांडच्या निकालाशी तुलना करा: ip neigh. निर्माते बेस MAC छापतात आणि प्रत्येक रेडिओचा MAC एक बाइट वाढवून काढतात, म्हणून शेवटचा हेक्स अंक वेगळा असतो; संपूर्ण पत्त्याऐवजी प्रीफिक्सची तुलना करा. गेटवेचा MAC राउटरच्या LAN इंटरफेसचा असेल, तर नोड त्या क्लायंटसाठी राउटिंग करत नाही.
बाहेर पडण्याचा पुरावा राउटरवर घ्या, स्पीड टेस्टने नाही
राउटरच्या बाजूची स्टेट ही एकमेव जागा आहे जी अनुवाद दाखवते. OpenWrt वर धोरण नियम आणि राउटिंग टेबलची यादी करा, मग बोगद्याला ताजे handshake आहे याची खात्री करा:
ip rule show
ip route show table all | grep default
wg showpfSense किंवा OPNsense वर तेच पुरावे pfctl -sr मध्ये नियमांसाठी, pfctl -ss मध्ये सक्रिय स्टेटसाठी आणि WireGuard च्या स्टेटस पेजवर पीअर काउंटरसाठी सापडतात, यानुसार: WireGuard क्लायंट दस्तऐवज. स्टेट टेबल क्लायंटच्या पत्त्याने फिल्टर करा. स्टेट क्लायंटला बोगद्याच्या पत्त्यावर अनुवादित दाखवत असेल, तर रहदारी बोगद्याच्या आत आहे; WAN पत्ता दाखवत असेल, तर नाही, डॅशबोर्डचा बॅज काहीही म्हणो.
क्लायंटवरून traceroute एक तथ्य जोडते जे स्टेट टेबल देऊ शकत नाही: पहिला हॉप. पहिला हॉप राउटरचा LAN पत्ता असेल, तर क्लायंट थेट राउटरपर्यंत पोहोचला. तो नोडचा पत्ता असेल आणि त्यानंतर अजून एक खाजगी हॉप असेल, तर तुम्ही राउटेड सेगमेंटवर आहात, आणि तो दुसरा हॉप हेच असे उपकरण आहे ज्याने धोरण धरायचे आहे.
नोड पत्त्याशिवाय आणखी काय वाटतो ते पाहा
DHCP पर्याय लीजसोबत प्रवास करतात, म्हणून स्वतःचे DHCP देणारा नोड स्वतःचे DNS आणि स्वतःच्या IPv6 राउटर घोषणाही देऊ शकतो. त्यामुळे क्लायंट बोगद्यातून बाहेर जाऊनही नोडवरील resolver ला क्वेरी पाठवू शकतो, किंवा बोगद्याचे धोरण कधीच न झाकणारा जागतिक IPv6 पत्ता घेऊ शकतो. दोन्ही क्लायंटवर छापा:
cat /etc/resolv.conf
ip -6 addr show scope globalresolver नोडच असेल आणि नोड राउटरकडे पुढे पाठवत असेल, तर DNS बोगद्याच्या मागे जाते. नोड स्थानिक पातळीवर सोडवत असेल किंवा पुरवठादाराच्या resolver कडे निर्देश करत असेल, तर क्वेरी बोगद्याबाहेर जातात, अगदी HTTP जरी तसे करत नसले तरी. IPv6 ही तीच चाचणी मागतो: जागतिक पत्ता आणि बोगद्याला बायपास करणारा डीफॉल्ट रूट म्हणजे गळती, आणि Mesh फर्मवेअर बऱ्याचदा IPv6 सुरू ठेवते जेव्हा VPN धोरण फक्त IPv4 झाकते.
बोगदा मुद्दाम तोडा, मग निकाल लिहून ठेवा
बोगदा खाली करा आणि त्या नोडशी जोडलेला क्लायंट पाहा, राउटरच्या शेजारी बसलेला क्लायंट नाही. ping आणि curl कमी टाइमआउटसह पुरेसे आहेत; प्रश्न हा आहे की रहदारी थांबते की WAN वर परत जाते. बोगदा राउटरच्याच सेवा कमांडने थांबवा, उदाहरणार्थ wg-quick down wg0 किंवा OpenVPN सेवा बंद करून, आणि तपासणी छोटी ठेवा.
क्लायंट काम करत राहिला, तर नोड किंवा राउटर त्या सेगमेंटसाठी खुलेपणाने अपयशी होत आहे, आणि mesh ने गपचूप kill switch रद्द केला आहे. बोगदा परत आणा, handshake काउंटर हलला याची खात्री करा, आणि तिसऱ्या पायरीतील स्टेट टेबल तपासणी पुन्हा करा.
प्रत्येक नोडसाठी एक ओळ लिहा: लेबल, SSID, गेटवेचा पत्ता, MAC प्रीफिक्स, बाहेर पडणे पुष्टी होय किंवा नाही, IPv6 झाकले आहे का, आणि बोगदा बंद असतानाचे वर्तन. रोमिंग हीच ती जागा आहे जिथे उत्तर बदलते, म्हणून तुम्ही खरोखर वापरता त्या खोल्या तपासा. एक ओळ बाकीच्यांशी जुळली नाही, तर तपासणी त्याच नोडची झाली पाहिजे, आणि दुरुस्ती त्या उपकरणावर होईल ज्याच्याकडे त्या ओळीचा गेटवे आहे.