SSTP Linuxissa epäonnistuu ennen kirjautumista? Tarkista ajonaikaiset osat

Asennat SSTP-liitännäisen, valintanappi ilmestyy verkkoeditoriin, täytät yhdyskäytävän ja käyttäjänimen, ja profiili epäonnistuu yleisellä virheellä ennen kuin se edes kysyy salasanaa. Mikään tuossa järjestyksessä ei ole epätavallista, eikä mikään siinä todista, että tunneliohjelmisto on asennettu. SSTP-yhteys kootaan osista, jotka toimitetaan erikseen: VPN-liitännäinen, jonka NetworkManager voi käynnistää, SSTP-asiakasohjelma, joka omistaa TLS- ja PPP-istunnon, sen alla oleva PPP-taustaohjelma ja salaisuuksien säilö, jota yhteys saa lukea.

Mitä valikkokohta lisää ja mitä ei

Liitännäinen tarjoaa palvelukuvauksen, joka kertoo NetworkManagerille, miten se käynnistetään, ja useimmissa jakeluissa pienen editorin, joka piirtää lomakkeen. Se on koko valikkokohdan laajuus. Asiakasohjelma tulee toisesta lähdepaketista, ja liitännäisen oma README sanoo jaon suoraan: se on liitännäinen, ei asiakasohjelma.

Asiakasohjelma tarvitsee sitten PPP:n, koska SSTP kuljettaa PPP-istuntoa TLS-yhteyden sisällä. Ilman pppd tunneli voi suorittaa TLS-kättelyn loppuun ja silti kuolla ensimmäisessä ohjauskehyksessä, mikä näyttää tunnistetietojen ongelmalta eikä ole sitä. Debianissa ja Ubuntussa osat tulevat niminä network-manager-sstp, sstp-client ja ppp, ja vain ensimmäisen asentaminen on yleisin syy siihen, että lomake hyväksyy jokaisen kentän, mutta yhteys ei koskaan valmistu.

Työpöydän valinta lisää yhden jaon. Plasma muokkaa profiileja plasma-nm:n kautta, joka tarvitsee oman SSTP-komponenttinsa ja lukee saman palvelukuvauksen, joten editori ilman SSTP-kohtaa ja CLI, joka luo profiileja hyvin, on puuttuva editorin puolikas, ei rikkinäinen ajonaikainen ympäristö.

Lue ensimmäinen epäonnistuva vaihe ennen kuin asennat mitään uudelleen

Epäonnistunut SSTP-yritys kulkee vaiheiden läpi kiinteässä järjestyksessä, ja epäonnistunut vaihe kertoo, mitä komponenttia pitää katsoa.

Liitännäisen käynnistys on ensimmäinen, ja sen epäonnistuminen tuottaa viestin VPN-palvelusta, ei palvelimesta. Seuraavaksi tulee TCP-yhteys porttiin 443; hylkäys tai aikakatkaisu tässä on tavoitettavuusongelma, ei TLS-ongelma. Sitten TLS-kättely ja palvelimen identiteetin tarkistus, sitten PPP-neuvottelu ja tilin todennus, ja lopuksi osoitteen jako ja reitit. Tarkkaile journalctl -f -u NetworkManager, kun aktivoit profiilin kerran, ja lue ensimmäinen täsmällinen rivi viimeisen yleisen sijaan.

Tuo järjestys selittää yleisen väärinluennan. Varustevirhe raportoidaan ennen kuin mitään tunnistetietoja lähetetään, joten salasanan vaihtaminen ei voi auttaa; PPP-todennuksen hylkäys saapuu onnistuneen kättelyn jälkeen, joten varmenteen vaihtaminenkaan ei auta. Pidä ensimmäinen virhe ja sen vaihe, niin sinulla on diagnoosi eikä oire.

Varmenteen luottamus ja tilille kirjautuminen ovat erilliset portit

Kättely vahvistaa, että palvelin on se, johon halusit päästä, käyttäen määrittämääsi myöntäjää ja nimeä. Vasta sen jälkeen PPP-kerros tarjoaa käyttäjänimesi ja salasanasi yhdyskäytävän todennusmenetelmälle. Kaksi itsenäistä tarkistusta siis, arvioidaan kiinteässä järjestyksessä, kummallekin omat asetukset. Mikään salasanakenttään kirjoitettu ei voi vaikuttaa ensimmäiseen.

Profiili, joka luottaa väärään myöntäjään, epäonnistuu ensimmäisellä portilla identiteettivirheeseen. Profiili, joka luottaa siihen oikein mutta tallentaa vanhentuneen salasanan, epäonnistuu toisella portilla todennuksen hylkäykseen. Molemmat näyttävät VPN:ltä, joka ei yhdistä, eikä kumpaakaan korjata toisen lääkkeellä.

Hanki odotettu myöntäjä ja palvelimen nimi siltä, joka ylläpitää yhdyskäytävää, sen sijaan että arvaisit editorin oletuksia, ja kirjaa vaadittu todennusmenetelmä. Jos organisaatio tarvitsee menetelmän, jota liitännäinen ei voi ilmaista, rehellinen vastaus on hyväksytty asiakasohjelma, joka voi, ei profiili, josta vahvistus on kytketty pois virheen häivyttämiseksi.

Anna yhden omistajan pitää profiili ja salaisuudet

Kun profiili on olemassa, aktivoi se NetworkManagerin kautta ja anna sen hallinnan omistaa syntyvät reitit ja resolverin muutokset. Toisen erillisen SSTP-asiakasohjelman käynnistäminen, kun NetworkManager jo hoitaa yhteyttä, antaa kaksi reittijoukkoa, kaksi DNS-määritystä ja virheenetsintäistunnon ilman yhtä totuuden lähdettä.

Salaisuuksillakin on omistaja. Järjestelmänlaajuiseen käyttöön merkitty yhteys tallentaa tunnistetiedot eri tavalla kuin käyttäjäistuntoosi rajattu, ja käsin avaintiedostoon luotu profiili ei ehkä ole salaisuusagentin luettavissa, joka odottaa antavansa salasanan vuorovaikutteisesti. Tarkista, mitä kontekstia profiili odottaa, ennen kuin kirjoitat uudelleen salasanan, joka ei koskaan ollut ongelma. Saman profiilin aktivoiminen päätteeltä nmcli:llä on nopein testi, koska kehote, joka ei koskaan ilmesty, kertoo, ettei agentilla ollut enää mitään tarjottavaa.

Tarkista tunneli, reitit ja resolveri erikseen

Yhdistetty-ilmaisin väittää vain, että linkki nousi. Tarkista kohde, jota todella tarvitset, sen kuljettava reitti ja käytössä oleva resolveri, yksi kerrallaan; kukin voi olla väärin, kun kaksi muuta ovat kunnossa.

Epäonnistuneesta yrityksestä tallenna kunkin komponentin versio ja puhdistettu virheteksti. Jaa ne, älä koko profiilia, koska profiili voi sisältää ennalta jaetun salaisuuden ja tallennetut tunnistetietosi.

Lopuksi katkaise ja yhdistä uudelleen ja käynnistä sitten kerran uudelleen. Jos profiili toimii vain ensimmäisellä yrityksellä, ongelma on salaisuuksien käsittelyssä tai reittien omistajuudessa, ja molemmat on halvempi korjata nyt kuin kesken työpäivän.