Palvelimeen lukittu profiili epäonnistuu TLS-välityspalvelimen takana: mikä sukupolvi?

Yksi käyttäjä voi yhdistää ja toinen ei, saman portaalin kautta, samana päivänä. Molemmilla on palvelimeen lukittu profiili, molemmat ovat samassa Access Server -koonnissa, ja ainoa ero on se, milloin heidän profiilinsa luotiin. Se on kuvio, joka kannattaa tunnistaa, koska "palvelimeen lukittu" nimeää käytännön eikä yhteysjaksoa. Access Server on toimittanut kaksi sukupolvea tuosta artefaktista, ja TLS-käänteinen välityspalvelin on vain toisen niiden polun edessä. Kolme ehtoa ratkaisee, missä haarassa olette.

Kaksi sukupolvea, kaksi yhteysjaksoa

Vanhemmassa mallissa, joka on voimassa 2.8 asti, tuotu tiedosto on pseudoprofiili. OpenVPN Connect käyttää sitä todentautuakseen Access Serverin verkko-APIa vastaan HTTPS:n yli, saa väliaikaisen käyttäjään lukitun profiilin ja istuntotunnisteen, ja vasta sitten muodostaa VPN:n. Kaksi siirtotietä toimii peräkkäin, ja ensimmäinen on tavallinen verkkopyyntö.

Version 2.9 mukana tullut muoto ei tee tuota käynnistystä yhteyttä kohden. Se on natiiviprofiili, jota voivat käyttää yhteensopivat OpenVPN asiakkaat, ei vain OpenVPN Connect. Sen lataaminen tai tuominen URL:n kautta voi yhä sisältää HTTPS:n — se on julkaisuvaihe, ei väliaikaisen profiilin nouto yhteyttä kohden.

Päivitys ei välttämättä kirjoita uudelleen jo myönnettyjä profiileja, joten nykyinen palvelinversio voi yhä jakaa vanhaa artefaktia. Palvelimen koonti kertoo, mikä on mahdollista, ei sitä, mitä tämä käyttäjä toi.

Kolme ehtoa, jotka valitsevat haarasi

Ensimmäinen ehto on artefaktin sukupolvi. Pyytäkää tiedosto, katsokaa miten se on tuotettu ja merkitkää muistiin sen tuoneen asiakkaan versio. Jos ette voi päätellä sukupolvea tiedostosta, testitilille myönnetty tuore profiili kertoo, mitä palvelin tuottaa tänään, ja se on eri tieto kuin se, joka epäonnistuvalla käyttäjällä on.

Toinen on se, mitä etuostanne todella päättää. TLS:n pois siirtävä seitsemännen kerroksen HTTP-käänteinen välityspalvelin ei ole sama objekti kuin neljännen kerroksen TCP-edelleenlähettäjä, eikä UDP-edelleenlähettäjä ole sitä myöskään. Access Serverin tavallinen järjestely portissa 443 saa OpenVPN TCP -taustapalvelun tunnistamaan selaimen liikenteen ja antamaan sen verkkopalveluille, joten asiaankuulumattoman HTTPS-päättäjän lisääminen eteen ei säilytä kyseisen taustapalvelun protokollankäsittelyä. Saman numeron 443 jakaminen ei tee kahdesta mallista samanarvoisia.

Kolmas on se, mihin epäonnistuminen laskeutuu. Ennen VPN:ää tapahtuva epäonnistuminen ja ohjauskanavan epäonnistuminen näyttävät samankaltaisilta asiakkaassa, joka sanoo vain "yhdistää", mutta jättävät todisteita eri paikkoihin. Jos vanha muoto on pelissä, käynnistys on ehdokas. Jos uusi muoto on pelissä, tyhjä verkkokäyttöloki on odotettavissa eikä todista mitään kumpaankaan suuntaan.

Kun artefakti on vanha: käynnistys epäonnistuu ensin

Lukekaa asiakkaan todellinen virhe sen lopputilan sijaan. Kiinnostavat kentät ovat HTTPS-virhe, palvelimen identiteetti, jota asiakas odotti, kohde, johon pyyntö meni, ja se, valmistuiko varmennevahvistus. Verratkaa niitä sitten palvelinpuolen verkkopalvelun ja välityspalvelimen lokeihin.

Se, että selain saavuttaa kirjautumissivun, ei todista, että tämän asiakkaan API-todennus onnistui. Ne ovat eri pyyntöjä, joilla on eri varmenteen odotukset ja usein eri isäntänimet. Jos portaali tarjoillaan oikein ja asiakas silti epäonnistuu, erimielisyys on käynnistyspolulla, ei käyttäjän salasanassa.

Älkää saako vertailua onnistumaan kytkemällä TLS-vahvistus pois päältä tai löysentämällä todennuskäytäntöä. Se muuttaa diagnosoitavan kokoonpanopoikkeaman toimivaksi mutta vahvistamattomaksi poluksi, ja juuri se muutos tekee tilapäisestä testistä pysyvän reiän. Access Serverin yhteysprofiilien dokumentaatio kuvaa molemmat sukupolvet ja väliaikaisen profiilin kulun, ja se on viite, joka kannattaa tarkistaa ennen kuin olettaa välityspalvelimen olevan syyllinen.

Kun artefakti on uusi: lukekaa sen sijaan ohjauskanavaa

2.9-tyylisellä profiililla asiakas menee suoraan natiiville VPN-päätepisteelle. Tutkikaa profiilin päätepisteet, käytetty siirtotie ja ohjauskanavan virhe. Jos asiakas ei koskaan lähetä HTTP-pyyntöä, se on mallin mukaista eikä oire.

Tässä myös välityspalvelinkysymys muuttaa muotoaan. HTTPS-purku ei voi rikkoa pelkkää TCP-virtaa, jota se ei koskaan näe, mutta se voi yhä rikkoa latauksen, joka julkaisee profiilin, eikä pelkkä TCP-edelleenlähettäjä kuljeta UDP:tä lainkaan. Tarkistakaa, mitä siirtotietä profiili pyytää, ennen kuin päättelette, että etuosa on merkityksetön.

TLS:n läpivienti yhdelle virralle on kapea järjestely. Se ei tarjoa UDP-edelleenlähetystä eikä toista taustapalvelun omaa palvelujen edelleenlähetystä portissa 443. Jos etuostanne tekee jotakin näistä, sanokaa mitä, koska korjauskeino on erilainen.

Korjauskeinot, jotka pysyvät kapeina

Vähiten häiritsevä tarkistus on luoda testitilille tuore tuettu profiili ja yhdistää aiottuun natiiviin päätepisteeseen samoilla todennusvaatimuksilla. Jos se toimii eikä säilytetty vanha profiili toimi, olette erottaneet artefaktin palvelimesta ja välityspalvelimesta yhdellä askeleella.

Käyttäjään lukitun profiilin jakaminen poistaa perityn käynnistysriippuvuuden kokonaan, koska väliaikaisen profiilin vaihtoa, joka voisi epäonnistua, ei ole. Se on myönnettävä aiotulle käyttäjälle, ei koskaan kopioitava ylläpitäjältä, ja se muuttaa sitä, mihin asiakas on valtuutettu, joten kohdelkaa sitä käytäntöpäätöksenä, älkääkä kiertotienä.

Korjatkaa sitten julkaisun asettelu niin, että jokainen tarvittava polku on olemassa: verkkopolku latauksille ja portaalin käytölle sekä natiivi VPN-polku siirtotiellä, jota profiilit odottavat. Pitäkää välityspalvelimen työ yhdessä kerroksessa. Toimiva käyttäjään lukittu tunneli todistaa, että tämä polku toimii; se ei todista, että jokainen välityspalvelinjärjestely tukee jokaista sukupolvea, eikä vanha käynnistysvirhe tuomitse uudempaa muotoa.

• Selvittäkää artefaktin sukupolvi ennen kuin koskette välityspalvelimeen.
• Selvittäkää, tapahtuuko epäonnistuminen ennen tunnelia vai sen sisällä.
• Vahvistakaa, mitä etuosa päättää: HTTP, TCP-virta vai UDP.
• Testatkaa äskettäin myönnetty profiili natiivia päätepistettä vastaan käytäntöä muuttamatta.