In poarte yn it adresfjild fan Windows VPN wurket allinnich foar SSTP

In VPN-tsjinner antwurdet op TCP 10443, de ynboude Windows-klient hat de goede oanmeldgegevens, en de ferbining falt dochs fuort nei in pauze dy’t op in DNS-timeout liket. De oarsaak is meastentiids it adresfjild: vpn.example.com:10443 yn Servernamme of adres typen lit Windows de hiele tekenrige as hostnamme lêze, omdat dat fak gjin algemiene host:port-ynfier is. Oft in poarte dêr hielendal útdrukt wurde kin, hinget ôf fan it tunneltype dat it profyl brûkt, en mar ien fan ’e fjouwer types behannelet de wearde as eat dat it analysearje kin.

Wêrom it adresfjild gjin host:port-fak is

It profylskaaim efter dat fjild is ServerAddress, en elk tunneltype beslút wat it mei de tekenrige docht. Trije fan harren hawwe gjin poarteparameter om yn te foljen, dat in dûbele punt en in getal binne gewoan tekens yn in namme dy’t nea oplost wurde sil. It fjirde rint oer HTTPS, wêr’t in poarte diel is fan ’e URL, dat de wearde moat skreaun wurde yn in foarm dy’t as URL analysearre wurdt.

Dêrom liket de flater op namme-oplossing ynstee fan in wegere ferbining. Der is gjin minne poarte om te melden, allinnich in hostnamme dy’t net bestiet, en de flater komt neidat de resolver it opjout. Foardat jo de tsjinner oanreitsje, kontrolearje hokker tunneltype it profyl seit te brûken.

De trije types mei in fêste poarte

PPTP ferbynt mei TCP 1723 en draacht dan de tunnel yn GRE, IP-protokol 47. L2TP/IPsec brûkt UDP 1701 foar de tunnel en UDP 500 plus 4500 foar IPsec, wêrby’t 4500 de NAT-trochgongspoarte is. IKEv2 brûkt ek UDP 500 en 4500. Gjin fan dy profilen lit earne yn ’e interface in poartefjild sjen, en gjinien sil oer in net-standert poarte ûnderhannelje.

In tsjinner dy’t op in oanpaste poarte harket is dêrom ûnberikber foar dy profilen, hoe’t it adres ek skreaun is. De praktyske antwurden binne smel: publisearje de standertpoarte op ’e tsjinner, of fertaal de standertpoarte nei de oanpaste op ’e router derfoar. Beide litte it klantprofyl ûnoantaaste, wat in soad wurdich is as it profyl fia belied útrolearre wurdt ynstee fan mei de hân yntypen.

SSTP hat in URL nedich, gjin namme

SSTP is de útsûndering omdat it yn in TLS-sesje rint. It fjild moat as URL analysearre wurde: earst it https://-skema, dan de host, dan in dûbele punt en de poarte. Sûnder it skema bliuwt Windows de wearde as in gewoane namme behanneljen en de ferbining mislearret foardat der in TLS-útwikseling bart.

De reden dat dit minsken oerraske is dat de standertpoarte de bleate hostnamme akseptearret. In profyl dat nea in oanpaste poarte nedich hie, leart de regel nea, en de earste persoan dy’t ien tafoeget, ûntdekt it troch te mislearjen. Lês nei it bewarjen de bewarre wearde werom ynstee fan de dialooch te fertrouwen:

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

ServerAddress lit krekt sjen wat bewarre is. As it lêzen wurdt as in bleate hostnamme mei in dûbele punt deryn, hat it profyl nea in URL krigen en gjin hoemannichte opnij besykjen sil dat reparearje.

Vendor-syntaksis dy’t yn itselde fak plakt wurdt

Guon gateways dokumintearje ekstra konvinsjes foar dat fjild, lykas in realm dy’t nei de poarte taheakke wurdt of query-parameters dy’t de sertifikaatbehanneling feroarje. Se wurde begrepen troch de tsjinner fan dy vendor en, yn guon builds, troch syn eigen klant. Se binne gjin part fan it Windows-profylformaat, en se yn in ynboud profyl plakke jout meastentiids deselde stille namme-flater.

Behannelje in parameter dy’t sertifikaatfalidaasje útskeakelt as in warskôging ynstee fan in reparaasje. As in profyl allinnich mei dy parameter ferbynt, komt it sertifikaat net oerien mei de brûkte namme, en de juste reparaasje is op ’e gateway, net yn ’e klant. In realm nei de poarte hat deselde eigenskip: it docht eat allinnich as de tsjinner oan ’e oare kant it ferwachtet.

Bewiis de poarte, lês dan de mislearjende faze

Befêstigje dat eat TCP op dy poarte fan it netwurk fan ’e klant akseptearret foardat jo it profyl de skuld jouwe:

Test-NetConnection vpn.example.com -Port 10443

Súkses bewiist in harker, net SSTP. In webserver, in omkearde proxy of in load balancer kin de TCP-handshake foltôgje en dochs gjin SSTP prate, dat in griene test mei in reade VPN is in echte kombinaasje. Fergelykje it sertifikaatûnderwerp mei de namme yn it profyl, en kontrolearje it RasClient-log yn builds dy’t it leverje, omdat it de faze fêstleit dy’t mislearre ynstee fan in generike timeout.

Tink dan oan de opsje dy’t it probleem fuorthellet ynstee fan it te dokumintearjen: stjoer TCP 443 fan bûten troch nei 10443 op ’e VPN-tsjinner. De klant brûkt dan it standertprofyl sûnder hokker poarte dan ek, wat meastentiids de skjinste regeling is foar in behearder fleat en lit de oanpaste poarte as yntern detail.