Cara memeriksa apakah satelit Mesh Wi-Fi memakai router VPN
Lacak gateway bawaan, mode penerusan node, dan tabel status router untuk membuktikan apakah klien satelit Mesh lewat VPN.
Satelit yang menjawab nama Wi-Fi yang sama dengan router induk hampir tidak memberi tahu apa pun tentang ke mana paket kliennya pergi. Node itu hanyalah radio dan jembatan sampai terbukti sebaliknya. Yang menentukan pintu keluar adalah gateway bawaan yang diterima setiap klien dan mode penerusan node di depannya. Lakukan lima pemeriksaan ini dari klien ke luar, dan Anda akan mendapat jawaban yang bisa dipertahankan, bukan kesan dari uji kecepatan.
Baca gateway yang benar-benar diterima klien
Di klien, cetak tabel rute dan tabel tetangga. Rute bawaan menyebut alamat yang meneruskan lalu lintas; entri tetangga menyebut MAC pemilik alamat itu. Pakai klien, bukan daftar perangkat router, karena daftar perangkat menunjukkan asosiasi, bukan jalur.
ip route show default
ip -6 route show default
ip neigh showWindows mencetak fakta yang sama dalam bentuk lain: ipconfig /all memberi gateway bawaan dan arp -a memberi MAC. Di macOS, route -n get default dan arp -an mencakup hal yang sama.
Bandingkan gateway itu dengan dua alamat yang sudah Anda kenal: alamat LAN router induk dan alamat manajemen satelit. Jika gateway adalah alamat LAN router, klien dijembatani ke router dan kebijakan router untuk jaringan itu berlaku tanpa perubahan. Jika gateway adalah alamat satelit, satelit sedang merutekan dan router tidak pernah melihat paket klien sebagai lalu lintas LAN; keputusan harus diambil di node, kalau tidak, tidak akan terjadi.
Pastikan node benar-benar berada di mode mana
Produk Mesh memakai ulang tiga kata untuk perilaku berbeda, jadi percayai jalur paket lebih dari label di aplikasi. Mode jembatan atau titik akses meneruskan frame. Mode router mengakhiri subnet dan menjalankan DHCP. Mode tamu biasanya menempatkan klien di VLAN terpisah dengan aturannya sendiri. Node dalam mode router di belakang router lain adalah NAT ganda, dan kliennya tiba di router VPN dalam keadaan sudah diterjemahkan, yang melemahkan kebijakan berbasis alamat sumber.
| 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 |
Untuk memastikan MAC, baca label pada node dan bandingkan dengan ip neigh. Pabrikan mencetak MAC dasar dan menurunkan MAC tiap radio dengan menaikkan satu byte, jadi digit heksadesimal terakhir berbeda; bandingkan prefiksnya, bukan seluruh alamat. Jika MAC gateway milik antarmuka LAN router, node tidak merutekan untuk klien itu.
Buktikan pintu keluar di router, bukan dengan uji kecepatan
Status di sisi router adalah satu-satunya tempat yang menunjukkan penerjemahan. Di OpenWrt, daftar aturan kebijakan dan tabel rute, lalu pastikan terowongan punya handshake terbaru:
ip rule show
ip route show table all | grep default
wg showDi pfSense atau OPNsense bukti yang sama ada di pfctl -sr untuk aturan, pfctl -ss untuk status aktif, dan halaman status WireGuard untuk penghitung peer, mengikuti dokumentasi klien WireGuard. Saring tabel status dengan alamat klien. Jika status menunjukkan klien diterjemahkan ke alamat terowongan, lalu lintas ada di dalam terowongan; jika menunjukkan alamat WAN, tidak, apa pun kata lencana di dasbor.
Traceroute dari klien menambah satu fakta yang tidak bisa diberikan tabel status: lompatan pertama. Jika lompatan pertama adalah alamat LAN router, klien mencapai router secara langsung. Jika itu alamat node dan diikuti lompatan privat lain, Anda berada di segmen yang dirutekan, dan lompatan kedua itulah perangkat yang harus memegang kebijakan.
Periksa apa lagi yang dibagikan node selain alamat
Opsi DHCP ikut bersama sewa, jadi node yang melayani DHCP sendiri juga bisa melayani DNS sendiri dan pengumuman router IPv6 sendiri. Karena itu klien bisa keluar lewat terowongan dan tetap mengirim kueri ke resolver di node, atau mendapat alamat IPv6 global yang tidak pernah dicakup kebijakan terowongan. Cetak keduanya di klien:
cat /etc/resolv.conf
ip -6 addr show scope globalJika resolver adalah node dan node meneruskan ke router, DNS mengikuti terowongan. Jika node menyelesaikan secara lokal atau menunjuk resolver penyedia, kueri keluar dari terowongan meski HTTP tidak. IPv6 juga layak diuji sama: alamat global ditambah rute bawaan yang memutari terowongan berarti kebocoran, dan firmware Mesh sering membiarkan IPv6 menyala sementara kebijakan VPN hanya mencakup IPv4.
Putuskan terowongan dengan sengaja, lalu catat hasilnya
Turunkan terowongan dan amati klien yang terhubung ke node itu, bukan klien di samping router. ping dan curl dengan batas waktu singkat sudah cukup; pertanyaannya apakah lalu lintas berhenti atau jatuh kembali ke WAN. Hentikan terowongan dengan perintah layanan router itu sendiri, misalnya wg-quick down wg0 atau penghentian layanan OpenVPN, dan jaga pengujian tetap singkat.
Jika klien tetap bekerja, node atau router gagal terbuka untuk segmen itu, dan mesh diam-diam membatalkan kill switch. Kembalikan terowongan, pastikan penghitung handshake bergerak, dan ulangi pemeriksaan tabel status dari langkah ketiga.
Catat satu baris per node: label, SSID, alamat gateway, prefiks MAC, pintu keluar terkonfirmasi ya atau tidak, IPv6 tercakup, dan perilaku saat terowongan turun. Roaming adalah tempat jawabannya berubah, jadi uji ruangan yang benar-benar Anda pakai. Bila satu baris tidak cocok dengan yang lain, node itulah yang perlu diselidiki, dan perbaikannya ada pada perangkat yang memiliki gateway baris tersebut.