VPN-palvelin vastaa TCP 10443:ssa, Windowsin sisäänrakennetulla asiakasohjelmalla on oikeat tunnistetiedot, ja yhteys katkeaa silti DNS-aikakatkaisua muistuttavan tauon jälkeen. Syy on yleensä osoitekenttä: kun Palvelimen nimi tai osoite -kenttään kirjoitetaan vpn.example.com:10443, Windows lukee koko merkkijonon isäntänimenä, koska kyseinen kenttä ei ole yleinen host:port-syöte. Voiko portin ilmaista siinä lainkaan, riippuu profiilin käyttämästä tunnelityypistä, ja vain yksi neljästä tyypistä käsittelee arvoa sellaisena, jonka se osaa jäsentää.

Miksi osoitekenttä ei ole host:port-kenttä

Kentän taustalla oleva profiiliominaisuus on ServerAddress, ja jokainen tunnelityyppi päättää, mitä se tekee merkkijonolla. Kolmella niistä ei ole täytettävää porttiparametria, joten kaksoispiste ja numero ovat vain merkkejä nimessä, jota ei koskaan ratkaista. Neljäs toimii HTTPS:n yli, jossa portti on osa URL-osoitetta, joten arvo on kirjoitettava muotoon, joka jäsennetään URL-osoitteena.

Siksi vika näyttää nimien ratkaisulta eikä hylätyltä yhteydeltä. Ei ole väärää porttia raportoitavaksi, vain isäntänimi, jota ei ole olemassa, ja virhe saapuu sen jälkeen, kun ratkaisija luovuttaa. Ennen kuin kosket palvelimeen, tarkista, mitä tunnelityyppiä profiili väittää käyttävänsä.

Kolme tyyppiä, joilla on kiinteä portti

PPTP yhdistää TCP 1723:een ja kuljettaa sitten tunnelin GRE:ssä, IP-protokollassa 47. L2TP/IPsec käyttää UDP 1701:tä tunneliin ja UDP 500 plus 4500 IPsec:iin, jolloin 4500 on NAT-läpäisyn portti. IKEv2 käyttää myös UDP 500 ja 4500. Mikään näistä profiileista ei paljasta porttikenttää missään käyttöliittymässä, eikä mikään neuvottele epätyypillistä porttia.

Mukautetulla portilla kuunteleva palvelin on siksi näille profiileille tavoittamaton riippumatta siitä, miten osoite kirjoitetaan. Käytännön vastaukset ovat kapeat: julkaise vakioportti palvelimessa tai käännä vakioportti mukautetuksi portiksi sen edessä olevassa reitittimessä. Molemmat pitävät asiakasprofiilin koskemattomana, mikä on arvokasta, kun profiili otetaan käyttöön käytännöllä eikä käsin kirjoittamalla.

SSTP tarvitsee URL-osoitteen, ei nimeä

SSTP on poikkeus, koska se toimii TLS-istunnon sisällä. Kenttä on jäsennettävä URL-osoitteena: ensin https://-skeema, sitten isäntä, sitten kaksoispiste ja portti. Ilman skeemaa Windows käsittelee arvoa edelleen tavallisena nimenä ja yhteys epäonnistuu ennen kuin mitään TLS-vaihtoa tapahtuu.

Syy siihen, miksi tämä yllättää, on se, että oletusportti hyväksyy paljaan isäntänimen. Profiili, joka ei koskaan tarvinnut mukautettua porttia, ei koskaan opeta sääntöä, ja ensimmäinen sen lisäävä henkilö löytää sen epäonnistumalla. Kun olet tallentanut, lue tallennettu arvo takaisin sen sijaan, että luottaisit valintaikkunaan:

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

ServerAddress näyttää täsmälleen sen, mitä tallennettiin. Jos se luetaan paljaana isäntänimenä, jossa on kaksoispiste, profiili ei koskaan saanut URL-osoitetta, eikä mikään määrä uudelleenyrityksiä korjaa sitä.

Toimittajan syntaksi, joka liitetään samaan kenttään

Jotkin yhdyskäytävät dokumentoivat kyseiselle kentälle lisäkäytäntöjä, kuten portin perään liitetyn realmin tai kyselyparametrit, jotka muuttavat varmennekäsittelyä. Ne ymmärtää kyseisen toimittajan palvelin ja joissakin buildeissa sen oma asiakasohjelma. Ne eivät ole osa Windowsin profiilimuotoa, ja niiden liittäminen sisäänrakennettuun profiiliin tuottaa yleensä saman hiljaisen nimivirheen.

Käsittele parametria, joka poistaa varmenteen validoinnin käytöstä, varoituksena äläkä korjauksena. Jos profiili yhdistää vain kyseisellä parametrilla, varmenne ei vastaa käytettävää nimeä, ja oikea korjaus on yhdyskäytävässä, ei asiakasohjelmassa. Portin jälkeisellä realmilla on sama ominaisuus: se tekee jotain vain, jos toisella puolella oleva palvelin odottaa sitä.

Todista portti ja lue sitten epäonnistuva vaihe

Vahvista, että jokin ottaa TCP:n vastaan kyseisellä portilla asiakkaan verkosta ennen kuin syytät profiilia:

Test-NetConnection vpn.example.com -Port 10443

Menestys todistaa kuuntelijan, ei SSTP:tä. Verkkopalvelin, käänteinen välityspalvelin tai kuormantasaaja voi viimeistellä TCP-kättelyn ja silti olla puhumatta SSTP:tä, joten vihreä testi ja punainen VPN on todellinen yhdistelmä. Vertaa varmenteen subjektia profiilin nimeen ja tarkista RasClient-loki niissä buildeissa, jotka sen sisältävät, koska se kirjaa epäonnistuneen vaiheen yleisen aikakatkaisun sijaan.

Harkitse sitten vaihtoehtoa, joka poistaa ongelman sen dokumentoimisen sijaan: ohjaa TCP 443 ulkopuolelta VPN-palvelimen porttiin 10443. Asiakas käyttää silloin oletusprofiilia ilman porttia, mikä on yleensä siistein järjestely hallitulle laivueelle ja jättää mukautetun portin sisäiseksi yksityiskohdaksi.

Aiheeseen liittyvät artikkelit