Saya menyambungkan klien VPN pada komputer riba Windows 11, jubin bertukar kepada Connected, perkongsian fail dalaman terbuka, dan tapak awam masih dimuatkan terus dari Wi-Fi pejabat. Campuran itu kelihatan seperti terowong yang rosak. Ia adalah output biasa profil yang menghantar sebahagian trafik melalui VPN dan membiarkan selebihnya pada penyesuai fizikal. Terowong paksa mengubah laluan lalai mana yang Windows utamakan; ia tidak memadam laluan yang lebih khusus dan tidak menjanjikan trafik berhenti apabila sambungan terputus. Berikut ialah urutan yang saya lalui apabila klien mendakwa liputan: keadaan klien, profil tersimpan, laluan digunakan, penyelesai, kemudian aliran sebenar.

Mulakan pada klien, kemudian berhenti mempercayainya

Klien ialah tempat permulaan yang betul hanya kerana ia memberitahu profil mana yang aktif. Buka sifat sambungan dan catat nama profil yang tepat, sama ada ia dicipta untuk pengguna semasa atau untuk semua orang pada mesin, dan penyesuai mana yang muncul dalam ncpa.cpl selepas bersambung. Pada komputer riba ujian saya penyesuai membawa nama profil, yang memudahkan output laluan dibaca. Pada mesin lain ia muncul sebagai entri WAN Miniport dan namanya tidak memberitahu anda apa-apa.

Apa yang klien tidak boleh beritahu anda ialah liputan. Jubin bersambung menerangkan keadaan terowong, bukan inventori destinasi. Klien pihak ketiga juga menyimpan konfigurasi mereka sendiri, jadi profil Windows asli, dan setiap sifat yang anda akan baca daripadanya, mungkin tiada kaitan dengan apa yang klien itu pasang. Jika VPN datang melalui AnyConnect, OpenVPN GUI, WireGuard atau ejen vendor, semakan PowerShell di bawah kebanyakannya tidak terpakai dan anda patut membaca tetapan split-tunnel dan penghalaan klien itu sendiri.

Baca profil tersimpan, bukan jubin

Bagi profil Windows asli (IKEv2, L2TP, SSTP atau yang ditolak oleh MDM), keputusan split-tunnel tersimpan ialah satu sifat:

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Tambahkan -AllUserConnection apabila profil dicipta untuk semua orang pada peranti. Tanpanya anda membaca senarai pengguna semasa, yang mungkin kosong atau mengandungi entri lain dengan nama serupa. Nilai False dalam SplitTunneling bermaksud profil disimpan sebagai terowong penuh: Windows memasang laluan lalai melalui penyesuai VPN. True bermaksud split tunnel, dan liputan kemudian bergantung sepenuhnya pada laluan dan peraturan penyelesaian nama yang ditolak oleh profil itu.

Anggap nilai itu sebagai konfigurasi, bukan pemerhatian. Ia merekodkan apa yang profil minta semasa bersambung. Windows boleh berakhir dengan laluan digunakan yang berbeza, kerana laluan lebih khusus daripada antara muka lain, tetapan dasar atau entri sisa daripada sambungan sebelumnya, jadi Boolean itu tidak pernah menyelesaikan soalan itu sendiri.

Bandingkan nilai tersimpan dengan jadual laluan yang digunakan

Selepas bersambung, senaraikan laluan pada penyesuai terowong dan bukannya menatal seluruh jadual:

$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 1

Find-NetRoute ialah separuh yang berguna. Ia menjawab soalan yang klien tidak pernah jawab: untuk destinasi ini, antara muka mana dan alamat sumber mana yang akan Windows benar-benar gunakan? Jalankannya untuk hos dalaman, hos awam dan apa sahaja yang anda anggap pengecualian yang disengajakan. Profil terowong penuh sepatutnya menunjukkan antara muka terowong untuk alamat awam. Profil split tunnel biasanya menunjukkan penyesuai fizikal di situ manakala awalan dalaman masih diselesaikan ke VPN.

Dua perangkap menjelaskan kebanyakan laporan «ia menghala ke arah yang salah». Awalan paling khusus sentiasa menang, jadi /24 pada penyesuai fizikal mengalahkan laluan lalai pada VPN tidak kira betapa rendah metrik terowong itu. Metrik hanya memutuskan seri antara laluan untuk awalan yang sama. Dan IPv4 dan IPv6 diputuskan secara berasingan: profil yang meliputi 0.0.0.0/0 boleh membiarkan IPv6 pada pautan setempat, yang membuat tapak dwi-timbunan kelihatan separuh terowong. Semak Get-NetRoute -AddressFamily IPv6 sebelum membuat kesimpulan terowong itu baik.

What you seeMost likely causeCheck next
Public traffic leaves the physical adapter while SplitTunneling reads FalseA more specific route on that adapter wins over the tunnel defaultFind-NetRoute for the exact destination, then look for a /24 or host route on the physical interface
Internal name fails, internal IP worksNo NRPT rule for that namespace, or a broader rule matches firstGet-DnsClientNrptPolicy and the namespace order
A dual-stack site opens directly while IPv4 uses the tunnelThe profile covers only the IPv4 default routeThe IPv6 route table on both interfaces
Routes look right but one app still goes directThe app uses its own proxy, or the client keeps a per-app listThe app's proxy settings and the client's application list

Semak penyelesaian nama secara berasingan dengan NRPT

Nama dalaman yang gagal sementara alamat IP dalaman berfungsi menunjukkan dasar penyelesai, bukan penghalaan. Windows memutuskan DNS setiap ruang nama melalui jadual dasar penyelesaian nama, yang bebas daripada jadual laluan:

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Apabila peraturan sepadan dengan *.corp.example, pertanyaan untuk ruang nama itu pergi ke pelayan DNS terowong walaupun laluan data ke pelayan tersebut kekal pada penyesuai fizikal dalam mod split tunnel. Itulah reka bentuknya, dan sebab itulah ujian pelayar yang membuka tapak awam tidak memberitahu anda apa-apa tentang nama dalaman. Jika penyesuai menyenaraikan pelayan yang dijangka tetapi carian masih pergi ke tempat lain, bandingkan susunan peraturan NRPT dan semak sama ada ruang nama yang lebih khusus sepadan dahulu.

Sahkan aliran, kemudian putuskan apa yang sebenarnya anda minta

Lalui destinasi dalam urutan tetap supaya hasil boleh dibandingkan antara mesin: alamat awam, alamat dalaman, nama dalaman dan satu pengecualian yang disengajakan seperti pencetak setempat atau panggilan video. Catat antara muka dan alamat sumber yang Find-NetRoute kembalikan untuk setiap satu. Selepas sebarang perubahan dasar, sambung semula dan ulang empat semakan yang sama; jadual laluan selepas sambung semula ialah satu-satunya bukti bahawa profil baharu berkuat kuasa.

Kemudian pisahkan penghalaan daripada penguatkuasaan. Terowong paksa mengutamakan terowong untuk trafik diliputi selagi ia hidup. Ia bukan kill switch. Jika keperluan ialah tiada apa yang keluar dari mesin apabila terowong jatuh, itu mesti datang daripada reka bentuk penyekatan: profil firewall terikat pada keadaan terowong, profil sentiasa hidup dengan penapis trafik atau pilihan tutup-semasa-gagal klien vendor sendiri. Terowong paksa juga mesti membiarkan alamat pelayan VPN itu sendiri boleh dicapai di luar terowong, dan menyekatnya atas nama «memaksa semuanya» ialah cara yang boleh dipercayai untuk mengunci diri anda keluar daripada sambungan yang anda cuba kuatkuasakan.

Sebelum mengubah apa-apa, lalui senarai ini. Setiap item yang gagal menyempitkan di mana masalah sebenar.

  • Nama dan skop profil disahkan, dengan -AllUserConnection untuk profil seluruh mesin.
  • SplitTunneling dibaca dan dianggap sebagai konfigurasi, bukan bukti liputan.
  • Laluan penyesuai terowong disenaraikan secara berasingan untuk IPv4 dan IPv6.
  • Find-NetRoute dijalankan untuk satu destinasi awam, satu dalaman dan satu pengecualian.
  • Peraturan NRPT disemak sebelum menyalahkan laluan atas kegagalan nama.
  • Keperluan penyekatan dibaca semula: penghalaan pilihan bukan sama dengan penyekatan dikuatkuasakan.

Keputusan terowong penuh atau split adalah milik pemilik profil, dan nota penghalaan Microsoft menerangkan tingkah laku yang Windows laksanakan apabila profil menetapkannya. Microsoft: terowong paksa dan split ialah rujukan yang saya biarkan terbuka semasa membaca output.

Artikel berkaitan