Näin tarkistat, tukeeko VPN-asiakas todella SSTP-protokollaa

Tuotteen kutsuminen VPN-asiakkaaksi ei kerro mitään siitä, puhuuko se SSTP-protokollaa, ja portti 443 osoitteessa todistaa vielä vähemmän. SSTP ajaa TLS:ää TCP 443:n päällä, sitten SSTP-ohjausvaihdon, sitten PPP:n itse linkille, ja päällä on varmenteen vahvistus ja PPP-todennusmenetelmä. Asiakas tukee protokollaa vain, kun nimetty toteutus asennetussa versiossa suorittaa jokaisen näistä kerroksista palvelimesi vaatimusten mukaisesti. Tee alla olevat tarkistukset järjestyksessä ja pysähdy ensimmäiseen epäonnistuneeseen, koska juuri se kannattaa ratkaista.

Sovita toteutus, versio ja alusta yhteen

Aloita alustasta, sovelluksesta ja asennetusta koontiversiosta, koska yksi valmistajan nimi voi peittää kaksi täysin erilaista toteutusta. Sisäänrakennetut VPN-tyypit ja kolmannen osapuolen asiakkaat eivät ole sama asia, ja laajennus voi näyttää sovitinsarakkeen, joka ei kuvaa sen alla olevaa protokollaa. Nykyisen julkaisun dokumentaatio ei kuvaa sitä koontiversiota, joka pyörii edessäsi olevalla koneella. Lue versionkohtainen sivu ja vertaa sitä siihen, mitä asiakas kertoo itsestään.

Windowsissa tunnelityyppi tulee alustalta eikä käyttöliittymästä, joten kysy alustalta. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress näyttää Sstp, kun natiivi asiakas yrittää protokollaa, ja yhteystyypin viite luettelee sen sisäänrakennettujen tunnelityyppien joukossa. Linuxissa natiivia SSTP-asiakasta ei ole lainkaan, joten kysymys on, onko erillinen toteutus, kuten sstp-client-paketin sstpc, asennettu ja ajan tasalla.

Lue profiilin muoto ennen merkintää

Profiilit eivät ole vaihdettavissa, ja saamasi tiedosto ratkaisee kysymyksen yleensä nopeammin kuin mikään ominaisuusluettelo. OpenVPN:n direktiivit, WireGuardin avaimet ja SSTP-yhteyden asetukset kuvaavat kolmea toisistaan riippumatonta protokollaa, eikä mikään tuontivalinta muunna yhtä toiseksi. Jaettu TCP-portti 443 ei käännä mitään, koska SSTP, OpenVPN TLS:n päällä ja tavallinen HTTPS-palvelu voivat varata saman portin ilman mitään yhteistä sen yläpuolella.

Jos tiedosto on .ovpn tai WireGuard-määritys, vastaus on jo selvillä: tältä asiakkaalta ei pyydetä SSTP:tä. Sen tuonti vain SSTP:tä tekevään asiakkaaseen epäonnistuu jo profiilivaiheessa, kauan ennen kuin protokollaneuvottelu alkaa.

Mitä TLS ei todista käyttöönotosta

Valmis TLS-kättely todistaa, että palvelimella on varmenne, eikä se todista mitään siitä, luottaako asiakkaasi myöntäjäketjuun tai täsmääkö siinä oleva nimi. Vahvistuksen on onnistuttava aiottua palvelinta vastaan, mukaan lukien organisaation ylläpitämä yksityinen CA, ja asiakas, joka tarjoaa varmennevirheiden ohittamista, on poistanut tarkistuksen sen sijaan että olisi saanut protokollatuen. Ketjun vahvistus ja nimen täsmäytys ovat kaksi erillistä testiä, ja pinon, joka läpäisee toisen, voi epäonnistua toisessa. Molemmat kuuluvat hyväksymiskriteereihin, eivät vianetsintäliitteeseen.

Vahvista sitten PPP-todennusmenetelmä, koska EAP-TLS:ää käyttävä käyttöönotto tarvitsee asiakkaan, joka voi esittää varmenteen PPP:n sisällä, kun taas salasanaan perustuva menetelmä tarvitsee tukea kyseiselle vaihdolle. Palvelimen osoite ja salasana eivät kuvaa organisaation todellista vaatimusta, varsinkaan kun sen edessä on toinen tekijä tai laitetarkistus. Kysy, mitä menetelmää palvelin vaatii, ennen kuin oletat asiakkaan pystyvän siihen.

Seuraa istuntoa neljässä vaiheessa

Katso, miten yhteys ylittää neljä rajaa: TCP ja TLS palvelimelle, SSTP-ohjausvaihto, PPP-neuvottelu ja sitten se resurssi, jota todella tarvitset. Loki, joka pysähtyy TLS:n jälkeen, kuvaa eri vikaa kuin se, joka pysähtyy PPP:n sisällä, ja ne johtavat eri vastuutahoihin. Selaimen lataama isännän verkkosivu todistaa vain, että jokin vastasi portissa 443, mikä on tämän alueen yleisin väärä positiivinen tulos. Jos sivu latautuu, mutta asiakas epäonnistuu edelleen, ongelma on TLS:n yläpuolella eikä verkkopalvelin ole epäilty.

Päätä todelliseen yksityiseen resurssiin ja nimikyselyyn, koska istunto, joka muodostuu eikä kanna mitään, näyttää useimmissa tilanneikkunoissa samalta kuin toimiva. Yksi onnistunut pyyntö tarvitsemaasi resurssiin ratkaisee kysymyksen, johon kuvake ei pysty.

Kun tuki puuttuu, vaihda suunnitelmaa

Jos asiakas ei voi puhua SSTP:tä, hanki hyväksytty vaihtoehto tai pyydä palvelimen omistajalta protokolla, jota molemmat päät tukevat. Tuntemattomien valintojen poistaminen, kunnes tuonti onnistuu, tuottaa profiilin, joka ei yhdistä mihinkään, mikä on hitaampi reitti samaan umpikujaan. Tuntemattomasta lähteestä tuleva asentaja, joka mainostaa yleistä yhteensopivuutta, lisää koneeseen hyväksymättömän luottamuspolun ja korvaa usein alusta-asiakkaan jollakin, jota organisaatio ei voi päivittää. Kumpikaan liike ei ole korjaus, ja molempia on vaikeampi peruuttaa kuin alkuperäistä ongelmaa.

Käsittele yhteensopivuuskysymys erillään suorituskyvystä ja päätepisteen valinnasta, koska lähellä oleva palvelin on hyödytön, kun asiakas ei voi puhua sen protokollaa. Viiveen viritys ei korjaa vaihetta, joka ei koskaan valmistu.