Pordo en la adreskampo de Windows VPN funkcias nur por SSTP

VPN-servilo respondas sur TCP 10443, la enkonstruita Windows-kliento havas la ĝustajn identigilojn, kaj la konekto tamen mortas post paŭzo, kiu aspektas kiel DNS-tempoŝlimo. La kaŭzo kutime estas la adreskampo: tajpi vpn.example.com:10443 en Servila nomo aŭ adreso igas Windows legi la tutan ĉenon kiel gastigantan nomon, ĉar tiu kampo ne estas ĝenerala host:port-enigo. Ĉu pordo entute povas esti esprimita tie, dependas de la tunela tipo, kiun la profilo uzas, kaj nur unu el la kvar tipoj traktas la valoron kiel ion, kion ĝi povas analizi.

Kial la adreskampo ne estas host:port-kampo

La profila atributo malantaŭ tiu kampo estas ServerAddress, kaj ĉiu tunela tipo decidas, kion ĝi faras kun la ĉeno. Tri el ili ne havas pordan parametron por plenigi, do dupunkto kaj nombro estas simple signoj en nomo, kiu neniam solviĝos. La kvara funkcias per HTTPS, kie pordo estas parto de la URL, do la valoro devas esti skribita en formo, kiu analiziĝas kiel URL.

Tial la fiasko aspektas kiel nom-solvado anstataŭ kiel rifuzita konekto. Ne estas malbona pordo por raporti, nur gastiganta nomo, kiu ne ekzistas, kaj la eraro alvenas post kiam la solvilo rezignas. Antaŭ ol tuŝi la servilon, kontrolu, kiun tunelan tipon la profilo asertas uzi.

La tri tipoj kun fiksa pordo

PPTP konektiĝas al TCP 1723 kaj poste portas la tunelon en GRE, IP-protokolo 47. L2TP/IPsec uzas UDP 1701 por la tunelo kaj UDP 500 plus 4500 por IPsec, kie 4500 estas la NAT-traira pordo. IKEv2 ankaŭ uzas UDP 500 kaj 4500. Neniu el tiuj profilo montras pordan kampon ie ajn en la interfaco, kaj neniu interkonsentos pri ne-norma pordo.

Servilo aŭskultanta sur propra pordo do estas neatingebla por tiuj profilo, sendepende de tio, kiel la adreso estas skribita. La praktikaj respondoj estas mallarĝaj: publikigu la norman pordon sur la servilo, aŭ traduku la norman pordon al la propra sur la enkursigilo antaŭ ĝi. Ambaŭ lasas la klientan profilon netuŝita, kio multe valoras, kiam la profilo estas disdonata per politiko anstataŭ tajpita permane.

SSTP bezonas URL-on, ne nomon

SSTP estas la escepto, ĉar ĝi funkcias ene de TLS-sesio. La kampo devas analiziĝi kiel URL: unue la skemo https://, poste la gastiganto, poste dupunkto kaj la pordo. Sen la skemo, Windows daŭre traktas la valoron kiel simplan nomon, kaj la konekto fiaskas antaŭ ol iu ajn TLS-interŝanĝo okazas.

La kialo, kial tio surprizas homojn, estas ke la norma pordo akceptas la nudan gastigantan nomon. Profilo, kiu neniam bezonis propran pordon, neniam lernas la regulon, kaj la unua persono, kiu aldonas unu, malkovras ĝin per fiasko. Post konservado, relegu la konservitan valoron anstataŭ fidi la dialogon:

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

ServerAddress montras precize tion, kio estis konservita. Se ĝi legeblas kiel nuda gastiganta nomo kun dupunkto en ĝi, la profilo neniam ricevis URL-on kaj neniu kvanto da reprovado riparos ĝin.

Provizanta sintakso, kiu estas gluata en la saman kampon

Kelkaj enirejoj dokumentas kromajn konvenciojn por tiu kampo, ekzemple regnon aldonitan post la pordo aŭ petparametrojn, kiuj ŝanĝas la traktadon de atestiloj. Ili estas komprenataj de la servilo de tiu provizanto kaj, en kelkaj konstruoj, de ĝia propra kliento. Ili ne estas parto de la Windows-profila formato, kaj glui ilin en enkonstruitan profilon kutime produktas la saman silentan nomfiaskon.

Traktu parametron, kiu malŝaltas atestilan validigon, kiel averton anstataŭ kiel riparon. Se profilo konektiĝas nur kun tiu parametro, la atestilo ne kongruas kun la uzata nomo, kaj la ĝusta riparo estas sur la enirejo, ne en la kliento. Regno post la pordo havas la saman econ: ĝi faras ion nur se la servilo aliflanke atendas ĝin.

Pruvu la pordon, poste legu la fiaskantan etapon

Konfirmu, ke io akceptas TCP sur tiu pordo el la reto de la kliento, antaŭ ol kulpigi la profilon:

Test-NetConnection vpn.example.com -Port 10443

Sukceso pruvas aŭskultanton, ne SSTP. Reta servilo, inversa prokuro aŭ ŝarĝbalancilo povas fini la TCP-manpremon kaj tamen ne paroli SSTP, do verda testo kun ruĝa VPN estas reala kombinaĵo. Komparu la atestilan subjekton kun la nomo en la profilo, kaj kontrolu la protokolon RasClient en konstruoj, kiuj liveras ĝin, ĉar ĝi registras la fiaskintan etapon anstataŭ ĝenerala tempoŝlimo.

Poste konsideru la opcion, kiu forigas la problemon anstataŭ dokumenti ĝin: plusendu TCP 443 de ekstere al 10443 sur la VPN-servilo. La kliento tiam uzas la norman profilon tute sen pordo, kio kutime estas la plej pura aranĝo por administrata aro kaj lasas la propran pordon kiel internan detalon.