VPN bawaan Windows tidak bisa menjangkau gateway SSL vendor: mengapa

Windows membawa empat jenis tunnel, dan gateway SSL vendor bukan salah satunya. Arahkan profil bawaan ke salah satunya juga, dan koneksi gagal sebelum permintaan kredensial, biasanya dengan pesan bahwa sistem lokal mengakhiri koneksi. Teks itu adalah sinyal ketidakcocokan, bukan diagnosis. Jenis profil dan klien yang memiliki protokol harus cocok, dan salah satunya hilang.

Empat jenis dan satu dialog

Setiap profil tersimpan membawa jenis tunnel. Klien bawaan menerima PPTP, L2TP, IKEv2, dan SSTP, ditambah mode otomatis yang mencobanya berurutan. Tidak ada entri SSL VPN umum, dan tidak ada cara menambahkannya lewat dialog. Gateway vendor berbicara protokol aplikasinya sendiri di atas TLS, yang hanya diimplementasikan oleh klien vendor itu.

Daftarnya hanya berjarak satu perintah, dan layak dijalankan sebelum pemecahan masalah lain karena hanya butuh satu detik dan menghapus satu kelas asumsi yang salah:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType, SplitTunneling
Get-VpnConnection -Name "Office" | Format-List

Jika profil menyebut SSTP dan gateway bukan server RRAS, ketidakcocokan sudah terbukti. Tidak ada pekerjaan sertifikat atau firewall yang mengubahnya.

SSTP dan TLS vendor terlihat sama di port 443

SSTP membungkus sesi PPP di dalam TLS dan berjalan di TCP 443. Di tumpukan Microsoft, sesi itu diakhiri RRAS, yang menyajikan sertifikat server yang divalidasi klien. Perangkat Fortinet, Citrix, atau Pulse juga mengakhiri TLS di 443, dan portalnya terbuka di browser mana pun tanpa keluhan.

Uji browser itu membuktikan keterjangkauan, bukan kompatibilitas. Protokol sesi di balik portal milik vendor, dan klien bawaan tidak memiliki implementasinya. Apakah vendor menyediakan kliennya sendiri memberi tahu Anda separuh mana dari ketidakcocokan yang sedang dihadapi.

Kebingungan sebaliknya juga terjadi. Profil yang dikonfigurasi sebagai SSTP terhadap server RRAS sungguhan bisa gagal pada validasi sertifikat sementara portalnya baik-baik saja, dan itu masalah sertifikat, bukan masalah protokol.

Kesalahan yang muncul sebelum tunnel ada

Kode seri 800 dilaporkan sebelum tunnel apa pun terbentuk, itulah sebabnya aturan firewall jarang mengubahnya. Kesalahan 812 adalah kebijakan sisi server yang menolak metode autentikasi yang ditawarkan klien. Yang lain dalam rentang itu datang dari pengelola koneksi lokal, bukan dari jaringan.

Aktifkan pelacakan sebelum membangun ulang apa pun. Pelacakan menyebutkan tahap yang gagal, dan nama tahap lebih berharga daripada teks dialog:

netsh ras set tracing * enable
Get-ChildItem "$env:windir\tracing" | Sort-Object LastWriteTime -Descending | Select-Object -First 5

Jejak mendarat di direktori pelacakan dan tetap di sana sampai Anda membersihkannya, jadi matikan pelacakan setelahnya alih-alih membiarkannya berjalan berminggu-minggu.

Profil yang tersambung tetap bisa merusak segalanya

Profil yang tersambung lalu merusak penjelajahan, berbagi lokal, atau mesin kontainer punya masalah perutean, bukan masalah tunnel. Gateway default berpindah ke tunnel, jadi setiap tujuan kini melewati rekan yang mungkin tidak merutekannya.

Dua kontrol menentukan ini. Satu adalah properti split tunneling pada profil. Yang lain adalah opsi per adaptor untuk memakai gateway default di jaringan jarak jauh, yang berada di pengaturan lanjutan IPv4.

Set-VpnConnection -Name "Office" -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName "Office" -DestinationPrefix 10.20.0.0/16

Mengaktifkan split tunneling tanpa menambahkan rute menghasilkan tunnel yang tersambung dan tidak menjangkau apa pun. Mematikannya tanpa memeriksa DNS menghasilkan nama internal yang terurai ke jawaban publik, karena sufiks dan server milik adaptor tidak dipakai.

Verifikasi saluran pipanya, lalu jenisnya

Bekerjalah dalam urutan ini, dan berhenti saat satu langkah gagal alih-alih menyesuaikan semuanya sekaligus:

Test-NetConnection vpn.example.net -Port 443
Get-VpnConnection -Name "Office" | Format-List TunnelType, ServerAddress, DnsSuffix
netsh interface ipv4 show route
rasdial Office

Perintah pertama memisahkan keterjangkauan dari protokol. Yang kedua menegaskan apa yang diklaim profil. Tabel rute menunjukkan apakah tunnel menangkap rute default. Perintah dial melaporkan kesalahan pengelola koneksi itu sendiri, yang sering lebih jelas daripada dialog.

Catat jenis tunnel, produk gateway, dan kesalahan persisnya di tiket. Orang berikutnya lalu tahu dalam satu menit apakah ini ketidakcocokan protokol, kegagalan sertifikat, atau keputusan perutean, alih-alih mulai dari “VPN tidak berfungsi”.