VPN memblokir LAN lokal di Windows: rute atau kebijakan klien?

Printer, NAS, atau mesin pengembangan di meja Anda sendiri berhenti menjawab saat VPN kerja tersambung. Kadang satu perintah rute memperbaikinya dalam hitungan detik; kadang rute yang sama sudah benar dan paket tetap menghilang, yang berarti Anda menghadapi masalah lain dengan gejala serupa. Keputusannya bermuara pada tiga pertanyaan, dan mengajukannya dalam urutan yang salah adalah alasan orang menghabiskan sepanjang malam menghapus dan menambahkan rute lagi.

Tiga pertanyaan sebelum perintah apa pun

Pertama: apakah ada entri untuk prefiks lokal, dan apakah entri itu menunjuk ke adaptor fisik? Kedua: apakah klien menerima izin atau penolakan jaringan lokal dari gateway saat tersambung? Ketiga: apakah Anda hanya perlu akses keluar ke LAN, atau ada sesuatu di internet yang juga harus menjangkau layanan yang berjalan di mesin Anda?

Pertanyaan pertama memisahkan gangguan perutean dari gangguan penyaringan. Yang kedua memberi tahu apakah perbaikan rute diizinkan bekerja. Yang ketiga mengubah perbaikan: rute memperbaiki lalu lintas keluar, sedangkan layanan masuk yang tak terjangkau biasanya merupakan masalah pengikatan listener dan jalur balik yang justru diperburuk oleh rute.

Pertanyaan satu: rute, filter, atau nama

Baca tabel sebelum menambahkan apa pun. Indeks antarmuka penting, karena setiap perintah rute di bawah ini berjangkar padanya:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Subnet yang terhubung langsung biasanya mempertahankan rute on-link bahkan saat tunnel aktif, jadi entri bisa ada dan lalu lintas tetap gagal. Kombinasi itu adalah tanda filter yang berjalan setelah perutean, dan itulah kasus ketika rute kedua yang lebih spesifik tidak mengubah apa pun.

Uji terpisah berdasarkan alamat dan berdasarkan nama. Jika ping 192.168.1.50 menjawab dan net view 192.168.1.50 tidak, tabel perutean tidak pernah menjadi masalah: tunnel mengubah resolver dan nama lokal tidak lagi terurai. Menambahkan rute untuk itu adalah pekerjaan sia-sia.

Pertanyaan dua: apakah gateway mengizinkan akses LAN lokal?

Klien komersial memasang lebih dari sekadar rute. Ia menerima kebijakan saat tersambung, dan kebijakan itu dapat memuat izin jaringan lokal yang eksplisit. Dalam penerapan Cisco IPsec, kebijakan grup membawa setelan split-tunneling dan bendera terpisah untuk akses LAN lokal; kotak centang di klien adalah permintaan yang dapat ditolak gateway. Di AnyConnect, profil mengendalikan daftar sertakan dan kecualikan split serta izin yang sama. Pada Windows RRAS, padanannya adalah opsi gateway default di profil ditambah rute statis yang diberikan server.

Saat bendera mati, perilaku yang didokumentasikan adalah klien memblokir lalu lintas ke subnet yang terhubung langsung meskipun ada rute valid yang lebih spesifik. Itu juga sebabnya rute yang bukan milik klien bisa hilang beberapa detik setelah Anda menambahkannya: klien sedang membangun ulang keadaan yang diperintahkan kepadanya, bukan melawan Anda.

Log klien mencatat keputusan saat tersambung, dan membacanya lebih cepat daripada eksperimen apa pun di mesin. Jika log mengatakan akses lokal diblokir, berhentilah: tidak ada perbaikan baris perintah yang bertahan dari itu, dan satu-satunya jalan yang tersisa adalah perubahan kebijakan, menjangkau sumber daya melalui tunnel, atau mengurung klien di mesin virtual dan membiarkan host di jaringan lokal.

Pertanyaan tiga: arah mana yang Anda butuhkan?

Lalu lintas keluar ke perangkat terdekat adalah pertanyaan perutean. Arahkan prefiks LAN ke gateway lokal dengan metrik cukup rendah untuk mengalahkan rute default tunnel:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Bentuk kedua mematok satu perangkat, dan itulah yang Anda inginkan ketika satu alamat adalah seluruh kebutuhannya. Padanan netsh mencatat keputusan yang sama berdasarkan nama antarmuka, bukan indeks:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Perintah rute gagal dengan Parameternya salah ketika alamat dan mask tidak cocok, misalnya alamat host dengan mask /24. Gunakan alamat jaringan untuk rute subnet dan mask host untuk satu host.

Yang masuk berbeda. Server VNC atau SSH di mesin yang sama menjadi tak terjangkau ketika balasan atas koneksi masuk keluar melalui gateway VPN dan tidak pernah kembali. Periksa pada apa layanan mendengarkan sebelum menyentuh rute:

netstat -ano | findstr :5900

Listener yang terikat ke satu alamat tertentu tidak akan menjawab di antarmuka lain. Mengikatnya ke semua antarmuka adalah keputusan sadar, diambil bersama aturan firewall yang dibatasi pada jaringan yang Anda percayai. Hanya setelah itu perbaikan rute memulihkan jalur balik.

Terapkan perubahan terkecil yang cocok

Langkah umum lainnya adalah menghapus centang “Gunakan gateway default pada jaringan jarak jauh” di properti lanjutan IPv4. Ini menjaga lalu lintas internet tetap lokal, tetapi melakukan dua hal sekaligus: VPN berhenti menjadi jalur default, dan klien berhenti menerima rute untuk jaringan jarak jauh, termasuk multicast. Hapus centangnya dan LAN jarak jauh menghilang kecuali server mendorong prefiks jarak jauh spesifik yang dibutuhkan setiap klien.

Asimetri itu menentukan urutan kerja. Jika sisi jarak jauh harus tetap sepenuhnya terjangkau, dorong subnet jarak jauh dari server dan biarkan default lokal apa adanya. Jika Anda tidak dapat mengubah server, tambahkan rute persisten ke prefiks jarak jauh melalui alamat yang diberikan tunnel, dan periksa dengan route print bahwa prefiks menunjuk ke antarmuka VPN sementara default masih menunjuk ke gateway fisik.

Lalu pastikan perbaikan bertahan setelah penyambungan ulang, karena rute tidak persisten mati bersama adaptor dan skrip yang berjalan setelah setiap sambungan adalah tempat yang jujur untuknya. Uji satu perangkat lokal dan satu sumber daya jarak jauh dalam sesi yang sama, putuskan, sambungkan lagi, dan uji lagi. Jika perangkat lokal masih gagal sementara rute tampak benar, kembali ke pertanyaan dua: klien sedang menyaring, dan jawabannya adalah perubahan kebijakan, bukan rute kedua yang bersaing.