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 ढाकिएको र सुरुङ बन्द हुँदाको व्यवहार। रोमिङ त्यही ठाउँ हो जहाँ जवाफ बदलिन्छ, त्यसैले तपाईंले साँच्चै प्रयोग गर्ने कोठा जाँच्नुहोस्। एउटा पङ्क्ति अरूसँग नमिले त्यही नोड खोजी गर्नुपर्ने हुन्छ, र सुधार त्यो यन्त्रमा गर्नुपर्छ जसको नाममा त्यो पङ्क्तिको गेटवे छ।