’n Poort in die adresveld van Windows VPN werk net met SSTP

’n VPN-bediener antwoord op TCP 10443, die ingeboude Windows-kliënt het die regte geloofsbriewe, en die verbinding sterf steeds ná ’n pouse wat soos ’n DNS-tydverstryking lyk. Die oorsaak is gewoonlik die adresveld: as jy vpn.example.com:10443 in Servernaam of adres tik, lees Windows die hele string as ’n gasheernaam, want daardie blokkie is nie ’n algemene host:port-invoer nie. Of ’n poort daar hoegenaamd uitgedruk kan word, hang af van die tonneltipe wat die profiel gebruik, en net een van die vier tipes behandel die waarde as iets wat dit kan ontleed.

Waarom die adresveld nie ’n host:port-blokkie is nie

Die profieleienskap agter daardie veld is ServerAddress, en elke tonneltipe besluit wat dit met die string doen. Drie van hulle het geen poortparameter om in te vul nie, so ’n dubbelpunt en ’n getal is bloot karakters in ’n naam wat nooit sal resolveer nie. Die vierde loop oor HTTPS, waar ’n poort deel van die URL is, so die waarde moet in ’n vorm geskryf word wat as een ontleed.

Dis daarom dat die fout soos naamresolusie lyk eerder as ’n geweierde verbinding. Daar is geen slegte poort om te rapporteer nie, net ’n gasheernaam wat nie bestaan nie, en die fout kom nadat die resolveerder opgee. Voordat jy aan die bediener raak, kyk watter tonneltipe die profiel sê dit gebruik.

Die drie tipes met ’n vaste poort

PPTP verbind met TCP 1723 en dra dan die tonnel in GRE, IP-protokol 47. L2TP/IPsec gebruik UDP 1701 vir die tonnel en UDP 500 plus 4500 vir IPsec, met 4500 wat die NAT-deurgangspoort is. IKEv2 gebruik ook UDP 500 en 4500. Nie een van daardie profiele stel ’n poortveld enige plek in die koppelvlak bloot nie, en nie een sal oor ’n nie-standaard een onderhandel nie.

’n Bediener wat op ’n pasgemaakte poort luister, is dus onbereikbaar vir daardie profiele, maak nie saak hoe die adres geskryf is nie. Die praktiese antwoorde is smal: publiseer die standaardpoort op die bediener, of vertaal die standaardpoort na die pasgemaakte een op die router voor dit. Albei laat die kliëntprofiel onaangeraak, wat baie werd is wanneer die profiel per beleid ontplooi word eerder as met die hand getik.

SSTP het ’n URL nodig, nie ’n naam nie

SSTP is die uitsondering omdat dit binne ’n TLS-sessie loop. Die veld moet as ’n URL ontleed: eers die https://-skema, dan die gasheer, dan ’n dubbelpunt en die poort. Sonder die skema hou Windows aan om die waarde as ’n gewone naam te behandel, en die verbinding misluk voordat enige TLS-uitruiling plaasvind.

Die rede waarom dit mense verras, is dat die standaardpoort die kaal gasheernaam aanvaar. ’n Profiel wat nooit ’n pasgemaakte poort nodig gehad het nie, leer nooit die reël nie, en die eerste persoon wat een byvoeg, ontdek dit deur te faal. Nadat jy gestoor het, lees die gestoorde waarde terug eerder as om die dialoog te vertrou:

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

ServerAddress wys presies wat gestoor is. As dit as ’n kaal gasheernaam met ’n dubbelpunt daarin gelees word, het die profiel nooit ’n URL ontvang nie en geen hoeveelheid herprobeer sal dit regmaak nie.

Leveransiersintaksis wat in dieselfde blokkie geplak word

Sommige gateways dokumenteer ekstra konvensies vir daardie veld, soos ’n realm wat ná die poort aangeheg word of navraagparameters wat sertifikaathantering verander. Hulle word deur daardie leveransier se bediener verstaan en, in sommige boue, deur sy eie kliënt. Hulle is nie deel van die Windows-profielformaat nie, en om hulle in ’n ingeboude profiel te plak lewer gewoonlik dieselfde stil naamfout.

Behandel ’n parameter wat sertifikaatvalidering deaktiveer as ’n waarskuwing eerder as ’n regstelling. As ’n profiel net met daardie parameter verbind, pas die sertifikaat nie by die naam wat gebruik word nie, en die korrekte herstel is op die gateway, nie in die kliënt nie. ’n Realm ná die poort het dieselfde eienskap: dit doen iets net as die bediener aan die ander kant dit verwag.

Bewys die poort, lees dan die falende stadium

Bevestig dat iets TCP op daardie poort vanaf die kliënt se netwerk aanvaar voordat jy die profiel blameer:

Test-NetConnection vpn.example.com -Port 10443

Sukses bewys ’n luisteraar, nie SSTP nie. ’n Webbediener, ’n omgekeerde proxy of ’n lasbalanseerder kan die TCP-handdruk voltooi en steeds nie SSTP praat nie, so ’n groen toets met ’n rooi VPN is ’n werklike kombinasie. Vergelyk die sertifikaatonderwerp met die naam in die profiel, en kyk na die RasClient-log in boue wat dit verskaf, want dit teken die stadium aan wat gefaal het eerder as ’n generiese tydverstryking.

Oorweeg dan die opsie wat die probleem verwyder eerder as om dit te dokumenteer: stuur TCP 443 aan die buitekant deur na 10443 op die VPN-bediener. Die kliënt gebruik dan die verstekprofiel sonder enige poort, wat gewoonlik die skoonste reëling vir ’n bestuurde vloot is en die pasgemaakte poort as ’n interne besonderheid laat.