Windows VPN-aren helbide-eremuko portu batek SSTP-n bakarrik funtzionatzen du

VPN zerbitzari batek TCP 10443-n erantzuten du, Windowsen barneko bezeroak kredentzial zuzenak ditu, eta konexioa oraindik hiltzen da DNS itxaronaldia dirudien pausa baten ondoren. Arrazoia helbide-eremua izan ohi da: vpn.example.com:10443 Zerbitzariaren izena edo helbidea eremuan idaztean, Windowsek kate osoa ostalari-izen gisa irakurtzen du, kaxa hori ez baita host:port sarrera orokorra. Portu bat han adieraz daitekeen ala ez profilean erabilitako tunel motaren araberakoa da, eta lau motetatik batek soilik tratatzen du balioa analiza dezakeen zerbait gisa.

Zergatik helbide-eremua ez den host:port kaxa bat

Eremu horren atzeko profile-propietatea ServerAddress da, eta tunel mota bakoitzak erabakitzen du zer egiten duen katearekin. Hiruk ez dute betetzeko portu-parametrorik, beraz bi puntu eta zenbaki bat inoiz ebatzi ez den izen bateko karaktereak besterik ez dira. Laugarrenak HTTPS bidez funtzionatzen du, non portua URLaren parte den, beraz balioa URL gisa analizatzen den forman idatzi behar da.

Horregatik hutsegiteak izen-ebazpena dirudi, eta ez ukatutako konexio bat. Ez dago salatzeko portu txarrik, existitzen ez den ostalari-izen bat baino ez, eta errorea ebazlea amore ematen duenean iristen da. Zerbitzaria ukitu aurretik, egiaztatu profilean zein tunel mota erabiltzen duen.

Portu finkoa duten hiru motak

PPTP TCP 1723-ra konektatzen da eta gero tunela GRE-n eramaten du, IP protokolo 47. L2TP/IPsec-ek UDP 1701 erabiltzen du tunelerako eta UDP 500 gehi 4500 IPsec-erako, 4500 NAT zeharkako portua delarik. IKEv2-k UDP 500 eta 4500 ere erabiltzen ditu. Profil horietako batek ere ez du portu-eremurik erakusten interfazean, eta batek ere ez du portu ez-estandarrik negoziatuko.

Beraz, portu berezi batean entzuten duen zerbitzari bat ezin da iritsi profil horietara, helbidea nola idatzita ere. Erantzun praktikoak estu dira: argitaratu portu estandarra zerbitzarian, edo itzuli portu estandarra portu berezira haren aurrean dagoen bideratzailean. Biek bezeroaren profila ukitu gabe uzten dute, eta hori asko balio du profila politika bidez banatzen denean, eskuz idatzi beharrean.

SSTP-k URL bat behar du, ez izen bat

SSTP da salbuespena, TLS saio baten barruan exekutatzen delako. Eremuak URL gisa analizatu behar du: lehenengo https:// eskema, gero ostalaria, gero bi puntu eta portua. Eskemarik gabe, Windowsek balioa izen arrunt gisa tratatzen jarraitzen du eta konexioak huts egiten du TLS trukaketarik gertatu aurretik.

Hori jendeari harridura sortzearen arrazoia da portu lehenetsiak ostalari-izen biluzia onartzen duela. Inoiz portu berezirik behar izan ez duen profilek ez du araua sekula irakasten, eta bat gehitzen duen lehen pertsonak huts eginez deskubritzen du. Gorde ondoren, irakurri gordetako balioa elkarrizketan fidatu beharrean:

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

ServerAddress-ek gorde zen zehazki erakusten du. Bi puntua duen ostalari-izen biluzi gisa irakurtzen bada, profilek ez zuen inoiz URLrik jaso eta berriro saiatzeak ez du konponduko.

Kaxa berberean itsasten den hornitzaile-sintaxia

Gateway batzuek eremu horretarako konbentzio osagarriak dokumentatzen dituzte, adibidez portuaren ondoren gehitutako erreinua edo ziurtagirien tratamendua aldatzen duten kontsulta-parametroak. Hornitzaile horren zerbitzariak ulertzen ditu eta, eraikuntza batzuetan, bere bezeroak ere bai. Ez dira Windows profileko formatuaren parte, eta profil integratu batean itsasteak normalean isil-isiliko izen-hutsegite bera eragiten du.

Ziurtagirien baliozkotzea desgaitzen duen parametroa abisu gisa tratatu, ez konponbide gisa. Profilak parametro horrekin soilik konektatzen badu, ziurtagiria ez dator bat erabiltzen ari den izenarekin, eta konponketa zuzena gatewayan dago, ez bezeroan. Portuaren ondorengo erreinuak propietate bera du: zerbait egiten du beste aldeko zerbitzariak espero badu soilik.

Froga ezazu portua, gero irakurri huts egiten duen fasea

Egiaztatu zerbait TCP onartzen ari dela portu horretan bezeroaren sarean, profila erruduntzat jo aurretik:

Test-NetConnection vpn.example.com -Port 10443

Arrakastak entzule bat frogatzen du, ez SSTP. Web zerbitzari batek, alderantzizko proxy batek edo karga-balantzatzaile batek TCP esku-ukitua osa dezake eta oraindik SSTP ez hitz egin, beraz proba berdea VPN gorriarekin konbinazio erreala da. Konparatu ziurtagirien gaia profileko izenarekin, eta begiratu RasClient erregistroa bera daramaten eraikuntzetan, huts egin zuen fasea erregistratzen baitu itxaronaldi orokor baten ordez.

Gero aztertu arazoa dokumentatu beharrean ezabatzen duen aukera: birbidali kanpotik TCP 443 VPN zerbitzariko 10443-ra. Bezeroak porturik gabeko profil lehenetsia erabiltzen du orduan, eta hori izaten da erabilera-flota kudeatu baterako antolamendu garbiena, portu berezia xehetasun interno gisa utziz.