Port di kolom alamat VPN Windows hanya berfungsi untuk SSTP

Server VPN menjawab di TCP 10443, klien bawaan Windows punya kredensial yang benar, tetapi koneksi tetap mati setelah jeda yang tampak seperti timeout DNS. Penyebabnya biasanya kolom alamat: mengetik vpn.example.com:10443 di Nama server atau alamat membuat Windows membaca seluruh string sebagai nama host, karena kotak itu bukan input host:port umum. Apakah port bisa dinyatakan di sana sama sekali bergantung pada jenis tunnel yang dipakai profil, dan hanya satu dari empat jenis yang memperlakukan nilai itu sebagai sesuatu yang bisa diuraikannya.

Mengapa kolom alamat bukan kotak host:port

Properti profil di balik kolom itu adalah ServerAddress, dan setiap jenis tunnel memutuskan apa yang dilakukannya dengan string tersebut. Tiga di antaranya tidak punya parameter port untuk diisi, jadi titik dua dan angka hanyalah karakter dalam nama yang tidak akan pernah diresolusi. Yang keempat berjalan di atas HTTPS, tempat port adalah bagian dari URL, jadi nilainya harus ditulis dalam bentuk yang terurai sebagai URL.

Itulah sebabnya kegagalannya tampak seperti resolusi nama, bukan koneksi yang ditolak. Tidak ada port buruk untuk dilaporkan, hanya nama host yang tidak ada, dan galatnya datang setelah resolver menyerah. Sebelum menyentuh server, periksa jenis tunnel apa yang diklaim profil.

Tiga jenis dengan port tetap

PPTP terhubung ke TCP 1723 lalu membawa tunnel di GRE, protokol IP 47. L2TP/IPsec memakai UDP 1701 untuk tunnel dan UDP 500 plus 4500 untuk IPsec, dengan 4500 sebagai port penembusan NAT. IKEv2 juga memakai UDP 500 dan 4500. Tidak satu pun profil itu menampilkan kolom port di mana pun dalam antarmuka, dan tidak satu pun akan menegosiasikan port non-standar.

Server yang mendengarkan di port khusus karena itu tidak terjangkau oleh profil tersebut, tidak peduli bagaimana alamatnya ditulis. Jawaban praktisnya sempit: publikasikan port standar di server, atau terjemahkan port standar ke port khusus di router di depannya. Keduanya membiarkan profil klien tidak tersentuh, yang sangat berharga ketika profil disebarkan lewat kebijakan, bukan diketik dengan tangan.

SSTP butuh URL, bukan nama

SSTP adalah pengecualian karena berjalan di dalam sesi TLS. Kolom itu harus terurai sebagai URL: skema https:// lebih dulu, lalu host, lalu titik dua dan port. Tanpa skema, Windows terus memperlakukan nilai itu sebagai nama biasa dan koneksi gagal sebelum pertukaran TLS apa pun terjadi.

Alasan hal ini mengejutkan orang adalah bahwa port default menerima nama host telanjang. Profil yang tidak pernah membutuhkan port khusus tidak pernah mengajarkan aturannya, dan orang pertama yang menambahkan satu menemukannya dengan gagal. Setelah menyimpan, baca kembali nilai yang tersimpan alih-alih memercayai dialognya:

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress menunjukkan persis apa yang tersimpan. Jika terbaca sebagai nama host telanjang dengan titik dua di dalamnya, profil tidak pernah menerima URL dan berapa kali pun diulang tidak akan memperbaikinya.

Sintaks vendor yang ditempelkan ke kotak yang sama

Sebagian gateway mendokumentasikan konvensi tambahan untuk kolom itu, seperti realm yang ditambahkan setelah port atau parameter kueri yang mengubah penanganan sertifikat. Konvensi itu dipahami oleh server vendor tersebut dan, pada sebagian build, oleh kliennya sendiri. Itu bukan bagian dari format profil Windows, dan menempelkannya ke profil bawaan biasanya menghasilkan kegagalan nama senyap yang sama.

Perlakukan parameter yang menonaktifkan validasi sertifikat sebagai peringatan, bukan perbaikan. Jika sebuah profil hanya terhubung dengan parameter itu, sertifikatnya tidak cocok dengan nama yang dipakai, dan perbaikan yang benar ada di gateway, bukan di klien. Realm setelah port punya sifat yang sama: ia hanya melakukan sesuatu jika server di sisi lain mengharapkannya.

Buktikan portnya, lalu baca tahap yang gagal

Pastikan ada sesuatu yang menerima TCP di port itu dari jaringan klien sebelum menyalahkan profil:

Test-NetConnection vpn.example.com -Port 10443

Keberhasilan membuktikan adanya pendengar, bukan SSTP. Server web, proxy terbalik, atau penyeimbang beban dapat menyelesaikan jabat tangan TCP dan tetap tidak berbicara SSTP, jadi uji hijau dengan VPN merah adalah kombinasi yang nyata. Bandingkan subjek sertifikat dengan nama di profil, dan periksa log RasClient pada build yang menyertakannya, karena log itu mencatat tahap yang gagal alih-alih timeout generik.

Lalu pertimbangkan opsi yang menghapus masalah alih-alih mendokumentasikannya: teruskan TCP 443 dari luar ke 10443 di server VPN. Klien kemudian memakai profil default tanpa port sama sekali, yang biasanya merupakan susunan paling bersih untuk armada terkelola dan membiarkan port khusus menjadi detail internal.