Jaringan lokal tidak dapat dijangkau saat VPN tersambung? Empat pemeriksaan

Terowongan menyala, intranet muncul, dan printer berhenti menjawab. Tidak ada yang gagal di LAN; klien mengubah jalur yang dipakainya untuk alamat yang tidak lagi dianggap lokal. Jalankan empat pemeriksaan di bawah ini secara berurutan dan berhenti ketika salah satunya menunjukkan ketidakcocokan yang konkret, karena gejala yang sama punya empat penyebab umum dan hanya satu di antaranya yang diperbaiki dengan menyunting VPN.

Pertama, lihat tabel rute yang dipasang klien

Buka tabel rute klien selagi VPN tersambung. Di Linux gunakan ip route, di Windows gunakan route print atau Get-NetRoute, dan di macOS gunakan netstat -rn. Anda mencari rute default melalui terowongan dan mencari apa yang terjadi pada rute default fisik.

Klien full-tunnel sering menambahkan dua rute setengah default, 0.0.0.0/1 dan 128.0.0.0/1, alih-alih mengganti 0.0.0.0/0. Rute default asli tetap terlihat tetapi kehilangan setiap pencarian, itulah sebabnya tabel bisa tampak utuh sementara semua lalu lintas di luar subnet berpindah. Jika klien VPN menawarkan opsi split tunnel dan kebijakan mengizinkannya, itu perbaikan yang paling bersih.

Jika terowongan harus tetap menjadi default, sematkan subnet lokal sebagai gantinya. Di Linux rute itu menyebut antarmuka fisik dan gateway; di Windows tambahkan -p agar persisten dan baca nomor antarmuka dari route print daripada menebaknya:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Rute yang disematkan hanya bertahan selama alamat yang disebutnya tetap sama. Laptop yang menomori ulang adaptor Wi-Fi-nya pada setiap koneksi akan melanggar aturan itu lagi, jadi periksa alamat antarmuka sebelum memutuskan bahwa perbaikannya gagal.

Kedua, pastikan alamat itu memang lokal sejak awal

Jika tujuan berada di dalam subnet yang tersambung, rute default terowongan tidak pernah berlaku dan VPN bukan penyebabnya. Printer di 192.168.1.40 pada klien dengan 192.168.1.0/24 memakai rute tersambung; jika alamat itu gagal, periksa perangkat, switch, atau firewall di klien alih-alih VPN.

Kasus yang menipu banyak orang adalah alamat publik untuk server lokal. Dari dalam LAN, mencapai alamat WAN router dan kembali lagi memerlukan hairpin NAT, dan banyak router memang tidak menerapkannya untuk port forward. Uji alamat privat di samping alamat publik. Jika alamat privat berfungsi dan yang publik tidak, VPN hanya menyingkap keterbatasan NAT yang sudah ada sebelumnya.

Nama host memperburuknya. Jika nama lokal sekarang mengarah ke alamat publik, klien akan terus mencoba jalur yang tidak bisa kembali. Gunakan alamat privat untuk pengujian, lalu perbaiki namanya alih-alih menambahkan port forward lain.

Ketiga, lihat siapa yang menjawab nama sekarang

Resolver korporat mengenal intranet dan biasanya tidak tahu apa-apa tentang nama host NAS, nama Bonjour printer, atau alias lokal router. Ketika VPN mendorong server DNS-nya, nama-nama itu berhenti terurai meskipun alamatnya masih dapat dijangkau. Kueri nama itu secara langsung dan bandingkan jawabannya dengan alamat yang Anda tahu dipegang perangkat.

Di Linux, resolvectl query nas.local menunjukkan resolver mana yang menjawab. Di Windows, nslookup nas.local menyebutkan servernya, dan ipconfig /all menunjukkan urutan resolver. Jika sufiks lokal sekarang ditangani resolver korporat, arahkan sufiks itu kembali ke resolver lokal atau gunakan alamat IP untuk perangkat.

Penemuan adalah lapisan terpisah. mDNS dan siaran tidak melewati terowongan yang dirutekan, jadi perangkat bisa dijangkau lewat alamat sementara namanya tetap tak terlihat. Reflektor atau entri DNS lokal menyelesaikannya; rute tidak.

Keempat, periksa apakah mesin lain juga memakai VPN

Ketika mesin yang ingin Anda capai juga menjalankan klien VPN, sesi Anda bisa tiba sementara balasannya keluar melalui terowongan lain. Itu menghasilkan koneksi yang terbentuk lalu macet, atau percobaan RDP dan SSH yang kehabisan waktu tanpa kesalahan di pihak Anda. Periksa tabel rute host lain itu dan jalur defaultnya sebelum menyalahkan klien Anda.

Periksa juga alamat tempat layanan mendengarkan. Pendengar yang terikat hanya ke alamat terowongan menerima koneksi dari VPN dan menolaknya dari LAN, bahkan ketika perutean sempurna. Itu konfigurasi layanan, bukan jalur jaringan, dan lazim pada antarmuka manajemen yang dikunci ke alamat VPN.

Pertahankan jalur manajemen yang tidak bergantung pada terowongan: rute statis yang menyebut jaringan sumber Anda, antarmuka lain yang terpasang ke LAN, atau konsol yang melewati terowongan sepenuhnya. Merancang jalur itu setelah sesi terputus jauh lebih sulit daripada menambahkannya sebelum koneksi berikutnya.

Terapkan perbaikan yang cocok dengan pemeriksaan yang gagal

Jika tabel rute menunjukkan perebutan setengah default, pilih split tunnel ketika kebijakan mengizinkan dan rute lokal yang disematkan ketika tidak. Jika alamatnya ternyata publik, alihkan pengujian dan namanya ke alamat privat. Jika resolver berganti tangan, batasi sufiks lokal atau gunakan alamatnya. Jika host lain diterowongkan, perbaiki jalur kembalinya atau pengikatan pendengarnya.

Ubah satu hal, lalu ulangi pemeriksaan yang sama. Rute yang ditambahkan untuk subnet yang salah, sufiks resolver yang salah ketik, dan rute tersemat pada antarmuka yang menomori ulang semuanya tampak seperti kegagalan semula. Pengulangan itulah yang membedakan perbaikan dari kebetulan.

Catat rute, alamat, dan resolver yang berfungsi selagi VPN tersambung. Sambungan ulang berikutnya akan mengubah setidaknya salah satunya, dan catatan itu mengubah pemadaman berikutnya menjadi perbandingan singkat alih-alih penyelidikan baru.