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 کا احاطہ اور سرنگ بند ہونے پر رویہ۔ رومنگ وہ جگہ ہے جہاں جواب بدلتا ہے، اس لیے وہ کمرے جانچیں جو آپ واقعی استعمال کرتے ہیں۔ جب ایک قطار باقیوں سے نہ ملے تو تحقیقات اُسی نوڈ کی ہونی چاہیے، اور اصلاح اُس ڈیوائس کی ذمہ داری ہے جس کے پاس اُس قطار کا گیٹ وے ہے۔