Ang port sa field ng address ng Windows VPN ay gumagana lamang sa SSTP

Sumasagot ang isang VPN server sa TCP 10443, tama ang mga kredensyal ng built-in na client ng Windows, at namamatay pa rin ang koneksyon pagkatapos ng paghinto na mukhang timeout ng DNS. Ang sanhi ay karaniwang ang field ng address: kapag nag-type ng vpn.example.com:10443 sa Pangalan ng server o address, binabasa ng Windows ang buong string bilang hostname, dahil ang kahon na iyon ay hindi pangkalahatang host:port input. Kung maipapahayag man ang isang port doon ay nakasalalay sa uri ng tunnel na ginagamit ng profile, at isa lamang sa apat na uri ang itinuturing ang halaga na isang bagay na kaya nitong suriin.

Bakit hindi host:port na kahon ang field ng address

Ang property ng profile sa likod ng field na iyon ay ServerAddress, at bawat uri ng tunnel ang nagpapasya kung ano ang gagawin sa string. Tatlo sa kanila ay walang parameter ng port na pupunan, kaya ang tutuldok at numero ay mga karakter lamang sa isang pangalan na hindi kailanman malulutas. Ang ikaapat ay tumatakbo sa HTTPS, kung saan bahagi ng URL ang port, kaya dapat isulat ang halaga sa anyong sinusuri bilang URL.

Kaya mukhang resolusyon ng pangalan ang pagpalya at hindi tinanggihang koneksyon. Walang masamang port na iuulat, may hostname lamang na wala, at dumarating ang error pagkatapos sumuko ng resolver. Bago hawakan ang server, tingnan kung anong uri ng tunnel ang sinasabi ng profile na ginagamit nito.

Ang tatlong uri na may fixed na port

Kumokonekta ang PPTP sa TCP 1723 at pagkatapos ay dinadala ang tunnel sa GRE, IP protocol 47. Gumagamit ang L2TP/IPsec ng UDP 1701 para sa tunnel at UDP 500 kasama ng 4500 para sa IPsec, kung saan ang 4500 ang port ng pagdaan sa NAT. Gumagamit din ang IKEv2 ng UDP 500 at 4500. Wala sa mga profile na iyon ang naglalantad ng field ng port kahit saan sa interface, at wala ring makikipag-ayos ng hindi karaniwang port.

Ang server na nakikinig sa custom na port ay hindi maabot ng mga profile na iyon, gaano man isulat ang address. Makitid ang mga praktikal na sagot: i-publish ang standard na port sa server, o isalin ang standard na port sa custom sa router sa harap nito. Pinapanatili ng dalawa ang profile ng client na hindi ginalaw, na malaking halaga kapag ipinapamahagi ang profile sa pamamagitan ng patakaran at hindi tinatype sa kamay.

Kailangan ng SSTP ng URL, hindi pangalan

Ang SSTP ang eksepsyon dahil tumatakbo ito sa loob ng TLS session. Dapat suriin ang field bilang URL: una ang https:// scheme, pagkatapos ang host, pagkatapos ang tutuldok at port. Kung walang scheme, patuloy na itinuturing ng Windows ang halaga bilang ordinaryong pangalan at nabigo ang koneksyon bago pa man maganap ang anumang palitan ng TLS.

Ang dahilan kung bakit ito nakakagulat ay tinatanggap ng default na port ang hubad na hostname. Ang profile na hindi kailanman nangailangan ng custom na port ay hindi kailanman nagtuturo ng tuntunin, at ang unang taong magdadagdag ng isa ay natutuklasan ito sa pamamagitan ng pagpalya. Pagkatapos i-save, basahin muli ang naka-save na halaga sa halip na magtiwala sa dialog:

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

Ipinapakita ng ServerAddress ang eksaktong naka-save. Kung binabasa ito bilang hubad na hostname na may tutuldok, hindi kailanman nakatanggap ng URL ang profile at walang dami ng muling pagsubok ang makakapag-ayos nito.

Syntax ng vendor na idinidikit sa parehong kahon

May mga gateway na nagdodokumento ng karagdagang kombensyon para sa field na iyon, tulad ng realm na idinagdag pagkatapos ng port o mga parameter ng query na nagbabago ng paghawak sa sertipiko. Nauunawaan ang mga ito ng server ng vendor na iyon at, sa ilang build, ng sarili nitong client. Hindi sila bahagi ng format ng profile ng Windows, at ang pagdikit sa kanila sa built-in na profile ay karaniwang gumagawa ng parehong tahimik na pagpalya ng pangalan.

Ituring ang parameter na nagpapawalang-bisa ng pagpapatunay ng sertipiko bilang babala at hindi bilang pag-aayos. Kung ang isang profile ay kumokonekta lamang sa parameter na iyon, hindi tumutugma ang sertipiko sa ginagamit na pangalan, at ang tamang pag-aayos ay nasa gateway, hindi sa client. Ang realm pagkatapos ng port ay may parehong katangian: may ginagawa lamang ito kung inaasahan ito ng server sa kabilang panig.

Patunayan ang port, pagkatapos basahin ang yugtong nabigo

Kumpirmahin na may tumatanggap ng TCP sa port na iyon mula sa network ng client bago sisihin ang profile:

Test-NetConnection vpn.example.com -Port 10443

Ang tagumpay ay nagpapatunay ng listener, hindi SSTP. Maaaring tapusin ng web server, reverse proxy o load balancer ang TCP handshake at hindi pa rin magsalita ng SSTP, kaya ang berdeng test na may pulang VPN ay totoong kombinasyon. Ihambing ang subject ng sertipiko sa pangalan sa profile, at tingnan ang log ng RasClient sa mga build na may kasama nito, dahil itinatala nito ang yugtong nabigo sa halip na pangkalahatang timeout.

Pagkatapos, isaalang-alang ang opsyon na nag-aalis ng problema sa halip na idokumento ito: i-forward ang TCP 443 mula sa labas patungo sa 10443 sa VPN server. Ginagamit noon ng client ang default na profile na walang port, na karaniwang pinakamalinis na kaayusan para sa pinamamahalaang fleet at iniiwan ang custom na port bilang panloob na detalye.