چگونه بررسی کنیم که یک گره Mesh Wi-Fi از روتر VPN استفاده می‌کند
دروازه پیش‌فرض، حالت ارسال گره و جدول وضعیت روتر را دنبال کنید تا ثابت کنید کلاینت‌های گره Mesh از VPN عبور می‌کنند یا نه.
گره‌ای که به همان نام Wi-Fi روتر پایه پاسخ می‌دهد تقریباً هیچ چیز درباره مقصد بسته‌های کلاینت‌هایش نمی‌گوید. گره یک رادیو و یک پل است تا وقتی خلافش ثابت شود. آنچه خروجی را تعیین می‌کند دروازه پیش‌فرضی است که هر کلاینت می‌گیرد و حالت ارسال گره‌ای که پیش روی اوست. این پنج بررسی را از کلاینت به سمت بیرون انجام دهید تا پاسخی داشته باشید که بتوانید از آن دفاع کنید، نه برداشتی از یک آزمون سرعت.
دروازه‌ای را بخوانید که کلاینت واقعاً گرفته است
روی کلاینت جدول مسیرها و جدول همسایه‌ها را چاپ کنید. مسیر پیش‌فرض آدرسی را نام می‌برد که ترافیک را ارسال می‌کند؛ ورودی همسایه MACای را نام می‌برد که صاحب آن آدرس است. از کلاینت استفاده کنید نه فهرست دستگاه‌های روتر، چون فهرست دستگاه‌ها پیوندها را نشان می‌دهد، نه مسیرها.
ip route show default
ip -6 route show default
ip neigh showویندوز همان واقعیت‌ها را به شکل دیگری چاپ می‌کند: 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 قواعد سیاست و جدول‌های مسیریابی را فهرست کنید، سپس تأیید کنید که تونل یک دست‌دهی تازه دارد:
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، و آزمون را کوتاه نگه دارید.
اگر کلاینت همچنان کار کند، گره یا روتر برای آن قطعه به‌صورت باز شکست می‌خورد و مش بی‌صدا کلید قطع را لغو کرده است. تونل را برگردانید، تأیید کنید که شمارنده دست‌دهی جابه‌جا شده و بررسی جدول وضعیت از گام سوم را تکرار کنید.
برای هر گره یک ردیف ثبت کنید: برچسب، SSID، آدرس دروازه، پیشوند MAC، خروج تأییدشده بله یا نه، پوشش IPv6 و رفتار با تونل قطع. رومینگ جایی است که پاسخ تغییر می‌کند، پس اتاق‌هایی را آزمایش کنید که واقعاً استفاده می‌کنید. وقتی یک ردیف با بقیه نمی‌خواند، همان گره باید بررسی شود و اصلاح به دستگاهی تعلق دارد که دروازه آن ردیف را دارد.