Keyakinan bahwa mode klien itu sendiri mematikan akses LAN membawa orang ke menu pengaturan yang salah, dan penyebab sebenarnya biasanya dua. Tunnel tidak menghapus jembatan LAN dan tidak menghentikan klien kabel serta nirkabel saling menjangkau. Yang merusak akses lokal adalah fitur inspeksi di jalur penerusan router atau rentang alamat LAN yang bergeser saat firmware melakukannya. Keduanya menghasilkan keluhan yang sama, dan tidak satu pun diperbaiki dengan memasang ulang profil VPN.

Mitos, dan apa yang sebenarnya diubah mode klien

Mode klien menambahkan antarmuka tunnel dan rute default yang melewatinya, lalu meneruskan lalu lintas LAN ke tunnel itu. Jembatan antara port kabel dan radio nirkabel tetap utuh, begitu juga switching lokal. Yang berubah adalah kebijakan: lalu lintas mana yang diteruskan, di mana diterjemahkan, dan resolver mana yang diterima klien.

Perbedaan itu penting karena LAN yang rusak biasanya berarti salah satu dari tiga kebijakan berubah, bukan bahwa router berhenti menjadi switch. Router yang masih menjawab halaman administrasinya sendiri adalah bukti antarmuka LAN hidup. Router yang tidak menjawab apa pun punya masalah lain, seperti alamat LAN yang berubah atau klien di subnet yang salah.

Jadi langkah pertama yang berguna adalah menemukan lapisan mana yang rusak, bukan mengubah lapisan yang Anda curigai.

Uji tiga target sebelum menyentuh pengaturan

Dari klien kabel, uji tiga target secara terpisah dan catat setiap hasil: alamat LAN router itu sendiri, perangkat lain di switch yang sama berdasarkan IP, dan sesuatu yang hanya dapat dijangkau melalui tunnel. Lakukan dalam urutan itu, karena setiap hasil menyingkirkan lapisan yang berbeda. Gunakan alamat alih-alih nama pada putaran pertama, karena kegagalan nama mencampur DNS ke dalam pertanyaan konektivitas.

Pola jawabannya adalah diagnosis. Router yang menjawab sementara perangkat lokal tidak menunjuk ke switching lokal atau fitur penyaringan, bukan routing. Perangkat lokal yang menjawab sementara sisi tunnel tidak menunjuk ke rute tunnel atau firewall jarak jauh. Jika semuanya menjawab lewat alamat tetapi nama gagal, itu pertanyaan resolver, dan tidak ada penyuntingan rute yang akan memperbaikinya.

What answersWhat it points at
Router onlyLAN-side filtering or a broken bridge
Router and local hosts, not remoteTunnel route, NAT or remote firewall
Addresses yes, names noDNS handed to clients by the router
Nothing at allClient subnet or router LAN address changed

Simpan tabel di samping hasil pengujian. Tabel itu mengubah keluhan kabur menjadi satu baris yang bisa Anda tindak lanjuti.

Lapisan keamanan di dalam jalur penerusan

Router konsumen makin sering menyertakan fitur inspeksi yang mengawasi lalu lintas yang diteruskan, dan fitur itu berjalan di jalur yang sama dengan paket dari LAN ke tunnel. Ketika inspeksi itu tidak dapat mengklasifikasikan lalu lintas tunnel, penerusan dapat macet sementara tunnel tetap aktif dan router melaporkan koneksi sehat. Tidak ada yang menunjukkannya di log VPN, karena VPN memang terhubung.

Diagnosisnya adalah eksperimen terkendali, bukan perubahan permanen. Catat pengaturan saat ini, matikan fitur selama satu pengujian, nyalakan kembali tunnel, dan uji satu host lokal berdasarkan alamat. Penerusan yang kembali adalah bukti yang Anda butuhkan, dan komprominya lalu menjadi keputusan alih-alih dugaan. Jika tidak ada yang berubah, aktifkan lagi segera dan beralih ke penyebab pengalamatan.

Membiarkan fitur keamanan berbayar nonaktif agar tunnel tetap berfungsi adalah kompromi yang harus dibuat dengan sengaja dan dicatat. Ada baiknya juga bertanya apakah tunnel seharusnya ada di perangkat lain, karena router yang harus memeriksa semuanya dan router yang harus meneruskan semuanya adalah dua pekerjaan berbeda.

Penyebab kedua: rentang LAN bergeser

Pembaruan firmware rutin mengembalikan alamat LAN ke nilai default pabrikan, dan sebagian router memiliki sakelar mode eksplisit yang memutuskan apakah LAN mempertahankan rentang privat atau mewarisi satu dari perangkat di atasnya. Klien yang mengharapkan 192.168.8.x bisa berakhir di 10.64.0.x, lalu sesi SSH ke host habis waktunya padahal tunnel sepenuhnya sehat.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Baca prefiks dan gateway dari sewa sebelum membuka halaman router. Dua perintah pertama menunjukkan apa yang benar-benar diterima klien, dan yang ketiga menunjukkan antarmuka mana yang akan dipakai klien untuk alamat lokal, dan begitulah rute sisa atau subnet lama memperlihatkan diri. Lalu bandingkan dengan halaman LAN dan mode router.

Jika rentang tidak dapat kembali, perbarui setiap objek yang menyebutnya: reservasi DHCP, rute statis apa pun ke subnet lama, dan setiap aturan firewall yang membawa prefiks sebelumnya. Rentang yang bertabrakan dengan subnet jarak jauh tunnel adalah varian yang lebih buruk, karena perangkat lokal tetap terjangkau sementara tujuan jarak jauh diam-diam salah dirutekan ke LAN.

Sambungkan ulang dan uji ulang dalam urutan paket

Setelah salah satu perubahan, sambungkan ulang tunnel dan ulangi pengujian dalam urutan paket: router, host lokal, host jarak jauh, lalu nama, lalu aplikasi. Menguji aplikasi lebih dulu menyembunyikan lapisan mana yang masih rusak, dan percobaan ulang peramban terhadap nama yang di-cache bisa tampak seperti kegagalan routing.

Catat versi firmware, prefiks LAN, dan status fitur inspeksi di samping profil VPN. Ketiganya adalah konfigurasi yang mungkin ditimpa pembaruan berikutnya, dan dua baris catatan menghemat satu jam yang baru saja Anda habiskan.

Artikel terkait