Cara memeriksa apa yang sebenarnya dirutekan VPN di Windows dengan PowerShell
Ubin VPN yang terhubung tidak membuktikan cakupan. Baca flag profil tersimpan, tabel rute langsung, dan aturan NRPT dalam urutan ini.
Saya menghubungkan klien VPN di laptop Windows 11, ubinnya berubah ke Connected, sebuah berbagi file internal terbuka, dan situs publik masih dimuat langsung dari Wi-Fi kantor. Campuran itu terlihat seperti terowongan rusak. Itu adalah keluaran normal dari profil yang mengirim sebagian lalu lintas melalui VPN dan membiarkan sisanya di adaptor fisik. Tunneling paksa mengubah rute default mana yang disukai Windows; ia tidak menghapus rute yang lebih spesifik dan tidak menjanjikan lalu lintas berhenti saat koneksi putus. Berikut ini urutan yang saya lalui ketika klien mengklaim cakupan: status klien, profil tersimpan, rute terpasang, resolver, lalu aliran nyata.
Mulai dari klien, lalu berhenti memercayainya
Klien adalah tempat awal yang tepat hanya karena ia memberi tahu profil mana yang aktif. Buka properti koneksi dan catat nama profil yang tepat, apakah dibuat untuk pengguna saat ini atau untuk semua orang di mesin, dan adaptor mana yang muncul di ncpa.cpl setelah terhubung. Di laptop uji saya, adaptor membawa nama profil, yang membuat keluaran rute mudah dibaca. Di mesin lain, ia muncul sebagai entri WAN Miniport dan namanya tidak memberi tahu Anda apa pun.
Yang tidak bisa dikatakan klien adalah cakupan. Ubin yang terhubung menggambarkan keadaan terowongan, bukan inventaris tujuan. Klien pihak ketiga juga menyimpan konfigurasinya sendiri, jadi profil Windows asli, dan setiap properti yang akan Anda baca darinya, mungkin tidak ada hubungannya dengan apa yang dipasang klien itu. Jika VPN datang melalui AnyConnect, OpenVPN GUI, WireGuard, atau agen vendor, pemeriksaan PowerShell di bawah umumnya tidak berlaku dan Anda sebaiknya membaca pengaturan split-tunnel dan perutean klien itu sendiri.
Baca profil tersimpan, bukan ubinnya
Untuk profil Windows asli (IKEv2, L2TP, SSTP, atau yang didorong MDM), keputusan split-tunnel tersimpan adalah satu properti:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixTambahkan -AllUserConnection ketika profil dibuat untuk semua orang di perangkat. Tanpa itu Anda membaca daftar pengguna saat ini, yang mungkin kosong atau berisi entri lain dengan nama serupa. Nilai False di SplitTunneling berarti profil disimpan sebagai terowongan penuh: Windows memasang rute default melalui adaptor VPN. True berarti split tunnel, dan cakupan lalu bergantung sepenuhnya pada rute dan aturan resolusi nama yang didorong profil itu.
Perlakukan nilai itu sebagai konfigurasi, bukan pengamatan. Ia mencatat apa yang diminta profil saat terhubung. Windows bisa berakhir dengan rute terpasang yang berbeda, karena rute lain yang lebih spesifik dari antarmuka lain, pengaturan kebijakan, atau entri sisa dari koneksi sebelumnya, sehingga nilai Boolean tidak pernah menyelesaikan pertanyaan itu sendiri.
Bandingkan nilai tersimpan dengan tabel rute terpasang
Setelah terhubung, daftarkan rute pada adaptor terowongan alih-alih menggulir seluruh tabel:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute adalah separuh yang berguna. Ia menjawab pertanyaan yang tidak pernah dijawab klien: untuk tujuan ini, antarmuka mana dan alamat sumber mana yang benar-benar akan dipakai Windows? Jalankan untuk host internal, host publik, dan apa pun yang Anda anggap pengecualian yang disengaja. Profil terowongan penuh seharusnya menunjukkan antarmuka terowongan untuk alamat publik. Profil split tunnel biasanya menunjukkan adaptor fisik di sana sementara prefiks internal tetap diselesaikan ke VPN.
Dua jebakan menjelaskan sebagian besar laporan «ia merutekan ke arah yang salah». Prefiks paling spesifik selalu menang, jadi /24 pada adaptor fisik mengalahkan rute default pada VPN seberapa rendah pun metrik terowongannya. Metrik hanya memecah seri antar rute untuk prefiks yang sama. Dan IPv4 dan IPv6 diputuskan terpisah: profil yang mencakup 0.0.0.0/0 dapat membiarkan IPv6 di tautan lokal, yang membuat situs dual-stack tampak setengah terowongan. Periksa Get-NetRoute -AddressFamily IPv6 sebelum menyimpulkan terowongannya baik-baik saja.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Periksa resolusi nama secara terpisah dengan NRPT
Nama internal yang gagal sementara alamat IP internal berfungsi menunjuk ke kebijakan resolver, bukan perutean. Windows memutuskan DNS per namespace melalui tabel kebijakan resolusi nama, yang independen dari tabel rute:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexKetika aturan cocok dengan *.corp.example, kueri untuk namespace itu pergi ke server DNS terowongan bahkan jika jalur data ke server tersebut tetap di adaptor fisik dalam mode split tunnel. Itulah desainnya, dan itulah sebabnya uji peramban yang membuka situs publik tidak memberi tahu Anda apa pun tentang nama internal. Jika adaptor mencantumkan server yang diharapkan tetapi pencarian tetap pergi ke tempat lain, bandingkan urutan aturan NRPT dan periksa apakah namespace yang lebih spesifik cocok lebih dulu.
Verifikasi alirannya, lalu putuskan apa yang sebenarnya Anda minta
Telusuri tujuan dalam urutan tetap agar hasilnya dapat dibandingkan antar mesin: alamat publik, alamat internal, nama internal, dan satu pengecualian yang disengaja seperti printer lokal atau panggilan video. Catat antarmuka dan alamat sumber yang dikembalikan Find-NetRoute untuk masing-masing. Setelah perubahan kebijakan apa pun, sambungkan ulang dan ulangi empat pemeriksaan yang sama; tabel rute setelah penyambungan ulang adalah satu-satunya bukti bahwa profil baru berlaku.
Lalu pisahkan perutean dari penegakan. Tunneling paksa lebih memilih terowongan untuk lalu lintas tercakup selama terowongan hidup. Itu bukan kill switch. Jika persyaratannya adalah tidak ada yang keluar dari mesin saat terowongan putus, itu harus datang dari desain pemblokiran: profil firewall yang terikat pada status terowongan, profil selalu aktif dengan filter lalu lintas, atau opsi tutup-saat-gagal milik klien vendor. Tunneling paksa juga harus membiarkan alamat server VPN itu sendiri tetap terjangkau di luar terowongan, dan memblokirnya atas nama «memaksa semuanya» adalah cara andal untuk mengunci diri Anda keluar dari koneksi yang Anda coba tegakkan.
Sebelum mengubah apa pun, telusuri daftar ini. Setiap butir yang gagal mempersempit di mana masalah sebenarnya.
- Nama dan cakupan profil dikonfirmasi, dengan
-AllUserConnectionuntuk profil seluruh mesin. SplitTunnelingdibaca dan diperlakukan sebagai konfigurasi, bukan bukti cakupan.- Rute adaptor terowongan didaftarkan terpisah untuk IPv4 dan IPv6.
Find-NetRoutedijalankan untuk satu tujuan publik, satu internal, dan satu pengecualian.- Aturan NRPT diperiksa sebelum menyalahkan rute atas kegagalan nama.
- Persyaratan pemblokiran dibaca ulang: perutean yang disukai bukan sama dengan pemblokiran yang ditegakkan.
Keputusan terowongan penuh atau split adalah milik pemilik profil, dan catatan perutean Microsoft menjelaskan perilaku yang diterapkan Windows ketika profil menetapkannya. Microsoft: tunneling paksa dan split adalah referensi yang saya biarkan terbuka saat membaca keluaran.