Cara menyemak sama ada satelit Mesh Wi-Fi menggunakan penghala VPN

Satelit yang menjawab nama Wi-Fi yang sama dengan penghala asas hampir tidak memberitahu apa-apa tentang ke mana paket kliennya pergi. Nod itu hanyalah radio dan jambatan sehingga terbukti sebaliknya. Yang menentukan pintu keluar ialah get laluan lalai yang diterima setiap klien dan mod penghantaran nod di hadapannya. Lakukan lima semakan ini dari klien ke luar, dan anda akan mendapat jawapan yang boleh dipertahankan, bukan tanggapan daripada ujian kelajuan.

Baca get laluan yang benar-benar diterima klien

Pada klien, cetak jadual laluan dan jadual jiran. Laluan lalai menamakan alamat yang menghantar trafik; entri jiran menamakan MAC pemilik alamat itu. Gunakan klien, bukan senarai peranti penghala, kerana senarai peranti menunjukkan perkaitan, bukan laluan.

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

Windows mencetak fakta yang sama dalam bentuk lain: ipconfig /all memberikan get laluan lalai dan arp -a memberikan MAC. Pada macOS, route -n get default dan arp -an merangkumi perkara yang sama.

Bandingkan get laluan itu dengan dua alamat yang anda sudah tahu: alamat LAN penghala asas dan alamat pengurusan satelit. Jika get laluan ialah alamat LAN penghala, klien dijambatkan ke penghala dan dasar penghala untuk rangkaian itu terpakai tanpa perubahan. Jika get laluan ialah alamat satelit, satelit sedang menghala dan penghala tidak pernah melihat paket klien sebagai trafik LAN; keputusan mesti dibuat pada nod, jika tidak ia tidak berlaku.

Pastikan nod benar-benar berada dalam mod yang mana

Produk Mesh menggunakan semula tiga perkataan untuk tingkah laku berbeza, jadi percayai laluan paket lebih daripada label dalam aplikasi. Mod jambatan atau titik akses menghantar bingkai. Mod penghala menamatkan subnet dan menjalankan DHCP. Mod tetamu biasanya meletakkan klien dalam VLAN berasingan dengan peraturannya sendiri. Nod dalam mod penghala di belakang penghala lain ialah NAT berganda, dan kliennya tiba di penghala VPN dalam keadaan sudah diterjemah, yang melemahkan dasar berasaskan alamat sumber.

Untuk memastikan MAC, baca label pada nod dan bandingkan dengan ip neigh. Pengeluar mencetak MAC asas dan memperoleh MAC setiap radio dengan menaikkan satu bait, jadi digit perenambelasan terakhir berbeza; bandingkan awalan dan bukan seluruh alamat. Jika MAC get laluan milik antara muka LAN penghala, nod tidak menghala untuk klien itu.

Buktikan pintu keluar pada penghala, bukan dengan ujian kelajuan

Keadaan di sebelah penghala ialah satu-satunya tempat yang menunjukkan terjemahan. Pada OpenWrt, senaraikan peraturan dasar dan jadual laluan, kemudian pastikan terowong mempunyai handshake terkini:

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

Pada pfSense atau OPNsense bukti yang sama ada dalam pfctl -sr untuk peraturan, pfctl -ss untuk keadaan aktif dan halaman status WireGuard untuk pembilang rakan, mengikut dokumentasi klien WireGuard. Tapis jadual keadaan dengan alamat klien. Jika keadaan menunjukkan klien diterjemah ke alamat terowong, trafik berada dalam terowong; jika menunjukkan alamat WAN, ia tidak, apa pun kata lencana pada papan pemuka.

Traceroute dari klien menambah satu fakta yang tidak dapat diberikan jadual keadaan: lompatan pertama. Jika lompatan pertama ialah alamat LAN penghala, klien mencapai penghala secara terus. Jika ia alamat nod diikuti lompatan persendirian lain, anda berada pada segmen yang dihalakan, dan lompatan kedua itulah peranti yang mesti memegang dasar.

Periksa apa lagi yang dikongsi nod selain alamat

Pilihan DHCP bergerak bersama pajakan, jadi nod yang menyediakan DHCP sendiri juga boleh menyediakan DNS sendiri dan pengumuman penghala IPv6 sendiri. Oleh itu klien boleh keluar melalui terowong dan masih menghantar pertanyaan kepada resolver pada nod, atau menerima alamat IPv6 global yang tidak pernah diliputi dasar terowong. Cetak kedua-duanya pada klien:

cat /etc/resolv.conf
ip -6 addr show scope global

Jika resolver ialah nod dan nod menghantar ke penghala, DNS mengikut terowong. Jika nod menyelesaikan secara tempatan atau menunjuk ke resolver pembekal, pertanyaan keluar dari terowong walaupun HTTP tidak. IPv6 juga wajar diuji sama: alamat global ditambah laluan lalai yang memintas terowong bermakna kebocoran, dan perisian tegar Mesh sering membiarkan IPv6 hidup sementara dasar VPN hanya meliputi IPv4.

Putuskan terowong dengan sengaja, kemudian catat hasilnya

Turunkan terowong dan perhatikan klien yang bersambung dengan nod itu, bukan klien di sebelah penghala. ping dan curl dengan had masa pendek sudah cukup; persoalannya sama ada trafik berhenti atau jatuh kembali ke WAN. Hentikan terowong dengan arahan perkhidmatan penghala itu sendiri, contohnya wg-quick down wg0 atau penghentian perkhidmatan OpenVPN, dan pastikan ujian kekal singkat.

Jika klien masih berfungsi, nod atau penghala gagal terbuka untuk segmen itu, dan mesh telah membatalkan kill switch secara senyap. Kembalikan terowong, pastikan pembilang handshake bergerak, dan ulangi semakan jadual keadaan dari langkah ketiga.

Catat satu baris bagi setiap nod: label, SSID, alamat get laluan, awalan MAC, pintu keluar disahkan ya atau tidak, IPv6 diliputi, dan tingkah laku apabila terowong diturunkan. Perayauan ialah tempat jawapannya berubah, jadi uji bilik yang benar-benar anda gunakan. Apabila satu baris tidak sepadan dengan yang lain, nod itulah yang perlu disiasat, dan pembetulan terletak pada peranti yang memiliki get laluan baris itu.