જે સેટેલાઇટ બેઝ રાઉટરનાજ Wi-Fi નામને જવાબ આપે છે, તે તેના ક્લાયન્ટના પેકેટ ક્યાં જાય છે તે વિશે લગભગ કંઈ જ કહેતું નથી. નોડ એક રેડિયો અને બ્રિજ છે, જ્યાં સુધી ઊલટું સાબિત ન થાય. બહાર નીકળવાનો રસ્તો દરેક ક્લાયન્ટને મળતો ડિફોલ્ટ ગેટવે અને તેની આગળના નોડનો ફોરવર્ડિંગ મોડ નક્કી કરે છે. આ પાંચ તપાસ ક્લાયન્ટથી બહારની તરફ કરો, પછી સ્પીડ ટેસ્ટની છાપને બદલે એવો જવાબ મળશે જેનો તમે બચાવ કરી શકો.

ક્લાયન્ટને ખરેખર મળેલો ગેટવે વાંચો

ક્લાયન્ટ પર રૂટ ટેબલ અને પડોશી ટેબલ છાપો. ડિફોલ્ટ રૂટ તે સરનામાનું નામ લે છે જે ટ્રાફિક આગળ મોકલે છે; પડોશી નોંધ તે MACનું નામ લે છે જે તે સરનામાનો માલિક છે. રાઉટરની ઉપકરણ યાદી નહીં, ક્લાયન્ટ વાપરો, કારણ કે ઉપકરણ યાદી જોડાણો દેખાડે છે, રસ્તા નહીં.

ip route show default
ip -6 route show default
ip neigh show

Windows એ જ તથ્યો બીજા સ્વરૂપમાં છાપે છે: ipconfig /all ડિફોલ્ટ ગેટવે આપે છે અને arp -a MAC આપે છે. macOS પર route -n get default અને arp -an એ જ કામ કરે છે.

તે ગેટવેની સરખામણી તમે પહેલેથી જાણો છો તેવા બે સરનામાં સાથે કરો: બેઝ રાઉટરનું LAN સરનામું અને સેટેલાઇટનું સંચાલન સરનામું. ગેટવે રાઉટરનું LAN સરનામું હોય તો ક્લાયન્ટ રાઉટર સાથે બ્રિજ થયેલો છે અને તે નેટવર્ક માટે રાઉટરની નીતિ બદલાવ વગર લાગુ પડે છે. ગેટવે સેટેલાઇટનું સરનામું હોય તો સેટેલાઇટ રૂટિંગ કરી રહ્યું છે અને રાઉટર ક્લાયન્ટના પેકેટને ક્યારેય LAN ટ્રાફિક તરીકે જોતું નથી; નિર્ણય નોડ પર જ લેવો પડશે, નહીં તો થશે જ નહીં.

નોડ ખરેખર કયા મોડમાં છે તેની ખાતરી કરો

Mesh ઉત્પાદનો અલગ વર્તન માટે ત્રણ શબ્દો ફરી વાપરે છે, તેથી એપના લેબલ કરતાં પેકેટના રસ્તા પર વધુ ભરોસો રાખો. બ્રિજ અથવા એક્સેસ પોઇન્ટ મોડ ફ્રેમ આગળ મોકલે છે. રાઉટર મોડ સબનેટ પૂરું કરે છે અને DHCP ચલાવે છે. ગેસ્ટ મોડ સામાન્ય રીતે ક્લાયન્ટને પોતાના નિયમોવાળા અલગ VLANમાં રાખે છે. બીજા રાઉટર પાછળ રાઉટર મોડમાં રહેલો નોડ ડબલ NAT છે, અને તેના ક્લાયન્ટ VPN રાઉટર સુધી પહેલેથી અનુવાદિત થઈને પહોંચે છે, જે સ્રોત સરનામા આધારિત નીતિને નબળી પાડે છે.

What you seeWhat it meansNext check
Gateway is the router's LAN address, one MAC for every nodeThe node bridges; the router owns the policyRouter policy for that LAN and VLAN
Gateway is the node's address and DHCP comes from the nodeThe node routes; double NATNode's own VPN client, or a static route plus policy on the router
Gateway is a different subnet on a guest SSIDGuest VLAN, often client-isolatedWhether that VLAN is inside the tunnel policy
Gateway changes when you walk into another roomRoaming across segmentsRepeat the check per node

MAC નક્કી કરવા નોડ પરનું લેબલ વાંચો અને આ કમાન્ડના પરિણામ સાથે સરખાવો: ip neigh. ઉત્પાદકો બેઝ MAC છાપે છે અને દરેક રેડિયોનું MAC એક બાઇટ વધારીને કાઢે છે, તેથી છેલ્લો હેક્સ અંક અલગ હોય છે; આખા સરનામાને બદલે પ્રીફિક્સ સરખાવો. ગેટવેનું MAC રાઉટરના LAN ઇન્ટરફેસનું હોય તો નોડ તે ક્લાયન્ટ માટે રૂટિંગ કરતું નથી.

બહાર નીકળવાનો પુરાવો રાઉટર પર લો, સ્પીડ ટેસ્ટથી નહીં

રાઉટરની બાજુનું સ્ટેટ જ એકમાત્ર જગ્યા છે જે અનુવાદ દેખાડે છે. OpenWrt પર નીતિ નિયમો અને રૂટિંગ ટેબલની યાદી કરો, પછી ખાતરી કરો કે ટનલમાં તાજું handshake છે:

ip rule show
ip route show table all | grep default
wg show

pfSense અથવા 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 ઢાંકેલું અને ટનલ બંધ હોય ત્યારેનું વર્તન. રોમિંગ એ જ જગ્યા છે જ્યાં જવાબ બદલાય છે, તેથી તમે ખરેખર વાપરો તે રૂમ તપાસો. એક લીટી બાકીની સાથે ન મળે તો તપાસ તે જ નોડની થવી જોઈએ, અને સુધારો તે ઉપકરણ પર થશે જેની પાસે તે લીટીનો ગેટવે છે.

સંબંધિત લેખો