कैसे जाँचें कि 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 globalअगर resolver नोड ही है और नोड राउटर को आगे भेजता है, तो DNS सुरंग के साथ चलता है। अगर नोड स्थानीय रूप से हल करता है या प्रदाता के resolver की ओर इशारा करता है, तो क्वेरी सुरंग से बाहर जाती हैं, तब भी जब HTTP ऐसा नहीं करता। IPv6 भी वही जाँच माँगता है: ग्लोबल पता और सुरंग को बायपास करने वाला डिफ़ॉल्ट रूट यानी लीक, और Mesh फ़र्मवेयर अकसर IPv6 को चालू छोड़ देता है जबकि VPN नीति सिर्फ़ IPv4 ढकती है।
सुरंग को जान-बूझकर तोड़ें, फिर नतीजा लिखें
सुरंग नीचे करें और उस नोड से जुड़े क्लाइंट को देखें, राउटर के पास बैठे क्लाइंट को नहीं। ping और curl कम टाइमआउट के साथ काफ़ी हैं; सवाल यह है कि ट्रैफ़िक रुकता है या WAN पर लौट जाता है। सुरंग को ख़ुद राउटर की सेवा कमांड से रोकें, जैसे wg-quick down wg0 या OpenVPN सेवा बंद करके, और जाँच छोटी रखें।
अगर क्लाइंट काम करता रहे, तो नोड या राउटर उस सेगमेंट के लिए खुलकर फ़ेल हो रहा है, और mesh ने चुपचाप kill switch रद्द कर दिया है। सुरंग वापस लाएँ, पक्का करें कि handshake काउंटर हिला है, और तीसरे चरण की स्टेट टेबल जाँच दोहराएँ।
हर नोड के लिए एक पंक्ति लिखें: लेबल, SSID, गेटवे का पता, MAC प्रीफ़िक्स, बाहर निकलना पुष्ट हाँ या नहीं, IPv6 ढका है या नहीं, और सुरंग बंद होने पर व्यवहार। रोमिंग वह जगह है जहाँ जवाब बदलता है, इसलिए वे कमरे जाँचें जो आप सचमुच इस्तेमाल करते हैं। जब एक पंक्ति बाक़ी से मेल न खाए, तो जाँच उसी नोड की होनी चाहिए, और सुधार उस डिवाइस पर होगा जिसके पास उस पंक्ति का गेटवे है।