Port dalam medan alamat VPN Windows hanya berfungsi untuk SSTP

Pelayan VPN menjawab pada TCP 10443, klien terbina dalam Windows mempunyai kelayakan yang betul, tetapi sambungan masih mati selepas jeda yang kelihatan seperti tamat masa DNS. Puncanya biasanya medan alamat: menaip vpn.example.com:10443 dalam Nama pelayan atau alamat membuat Windows membaca seluruh rentetan sebagai nama hos, kerana kotak itu bukan input host:port umum. Sama ada port boleh dinyatakan di situ bergantung pada jenis terowong yang digunakan oleh profil, dan hanya satu daripada empat jenis menganggap nilai itu sebagai sesuatu yang boleh dihuraikannya.

Mengapa medan alamat bukan kotak host:port

Sifat profil di sebalik medan itu ialah ServerAddress, dan setiap jenis terowong menentukan apa yang dilakukannya dengan rentetan itu. Tiga daripadanya tidak mempunyai parameter port untuk diisi, jadi titik bertindih dan nombor hanyalah aksara dalam nama yang tidak akan pernah diselesaikan. Yang keempat berjalan melalui HTTPS, di mana port ialah sebahagian daripada URL, jadi nilainya mesti ditulis dalam bentuk yang dihuraikan sebagai URL.

Itulah sebabnya kegagalan kelihatan seperti penyelesaian nama dan bukan sambungan yang ditolak. Tiada port buruk untuk dilaporkan, hanya nama hos yang tidak wujud, dan ralat itu tiba selepas penyelesai berputus asa. Sebelum menyentuh pelayan, semak jenis terowong yang didakwa digunakan oleh profil.

Tiga jenis dengan port tetap

PPTP bersambung ke TCP 1723 dan kemudian membawa terowong dalam GRE, protokol IP 47. L2TP/IPsec menggunakan UDP 1701 untuk terowong dan UDP 500 serta 4500 untuk IPsec, dengan 4500 sebagai port penembusan NAT. IKEv2 juga menggunakan UDP 500 dan 4500. Tiada satu pun profil itu mendedahkan medan port di mana-mana dalam antara muka, dan tiada satu pun akan merundingkan port bukan standard.

Pelayan yang mendengar pada port tersuai oleh itu tidak dapat dicapai oleh profil tersebut, tidak kira bagaimana alamat ditulis. Jawapan praktikalnya sempit: terbitkan port standard pada pelayan, atau terjemahkan port standard kepada port tersuai pada penghala di hadapannya. Kedua-duanya membiarkan profil klien tidak tersentuh, yang amat berharga apabila profil digerakkan melalui dasar dan bukan ditaip dengan tangan.

SSTP memerlukan URL, bukan nama

SSTP ialah pengecualian kerana ia berjalan di dalam sesi TLS. Medan itu mesti dihuraikan sebagai URL: skema https:// dahulu, kemudian hos, kemudian titik bertindih dan port. Tanpa skema, Windows terus menganggap nilai itu sebagai nama biasa dan sambungan gagal sebelum sebarang pertukaran TLS berlaku.

Sebab perkara ini mengejutkan orang ialah port lalai menerima nama hos kosong. Profil yang tidak pernah memerlukan port tersuai tidak pernah mengajar peraturan itu, dan orang pertama yang menambah satu menemuinya dengan gagal. Selepas menyimpan, baca semula nilai yang disimpan dan bukan mempercayai dialog itu:

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

ServerAddress menunjukkan dengan tepat apa yang disimpan. Jika ia dibaca sebagai nama hos kosong dengan titik bertindih di dalamnya, profil itu tidak pernah menerima URL dan berapa kali pun cuba semula tidak akan membetulkannya.

Sintaks vendor yang ditampal ke dalam kotak yang sama

Sesetengah gateway mendokumenkan konvensyen tambahan untuk medan itu, seperti realm yang dilampirkan selepas port atau parameter pertanyaan yang mengubah pengendalian sijil. Ia difahami oleh pelayan vendor tersebut dan, dalam sesetengah binaan, oleh kliennya sendiri. Ia bukan sebahagian daripada format profil Windows, dan menampalnya ke dalam profil terbina dalam biasanya menghasilkan kegagalan nama senyap yang sama.

Anggap parameter yang melumpuhkan pengesahan sijil sebagai amaran dan bukan pembaikan. Jika sesuatu profil hanya bersambung dengan parameter itu, sijil tidak sepadan dengan nama yang digunakan, dan pembaikan yang betul adalah pada gateway, bukan dalam klien. Realm selepas port mempunyai sifat yang sama: ia melakukan sesuatu hanya jika pelayan di sebelah sana menjangkakannya.

Buktikan port itu, kemudian baca peringkat yang gagal

Sahkan bahawa sesuatu menerima TCP pada port itu dari rangkaian klien sebelum menyalahkan profil:

Test-NetConnection vpn.example.com -Port 10443

Kejayaan membuktikan pendengar, bukan SSTP. Pelayan web, proksi songsang atau pengimbang beban boleh menyelesaikan jabat tangan TCP dan masih tidak bertutur SSTP, jadi ujian hijau dengan VPN merah ialah gabungan sebenar. Bandingkan subjek sijil dengan nama dalam profil, dan semak log RasClient dalam binaan yang menyertakannya, kerana ia merekodkan peringkat yang gagal dan bukan tamat masa generik.

Kemudian pertimbangkan pilihan yang menghapuskan masalah dan bukan mendokumenkannya: majukan TCP 443 dari luar ke 10443 pada pelayan VPN. Klien kemudian menggunakan profil lalai tanpa sebarang port, yang biasanya merupakan susunan paling bersih untuk armada terurus dan membiarkan port tersuai sebagai butiran dalaman.