Profil læst við netþjón mistekst bak við TLS-milliþjón: hvaða kynslóð?

Einn notandi getur tengst og annar ekki, í gegnum sama gátt, sama dag. Báðir hafa profíl læst við netþjón, báðir eru á sama Access Server smíði, og eini munurinn er hvenær prófíllinn þeirra var búinn til. Það er mynstrið sem vert er að þekkja, því "læst við netþjón" nefnir stefnu en ekki tengingaröð. Access Server hefur sent út tvær kynslóðir af þeirri gerð, og TLS-öfugur milliþjónn stendur aðeins fyrir einni slóð þeirra. Þrjú skilyrði ráða því hvaða grein þið eruð á.

Tvær kynslóðir, tvær tengingaraðir

Í eldri hönnuninni, sem gildir til 2.8, er innflutta skráin gerviprofíll. OpenVPN Connect notar hann til að auðkenna sig gagnvart vef-API Access Server yfir HTTPS, fær tímabundinn notendalæstan profíl og setutákn, og stofnar fyrst þá VPN. Tveir flutningsmátar keyra í röð, og sá fyrri er venjuleg vefbeiðni.

Sniðið sem kom með 2.9 framkvæmir ekki þessa ræsingu fyrir hverja tengingu. Það er innfæddur prófíll sem hægt er að nota með samhæfum OpenVPN biðlurum, ekki aðeins OpenVPN Connect. Niðurhal eða innflutningur í gegnum vefslóð getur enn falið í sér HTTPS — það er útgáfuskref, ekki sókn tímabundins prófíls fyrir hverja tengingu.

Uppfærsla endurskrifar ekki endilega prófíla sem þegar hafa verið gefnir út, svo núverandi netþjónsútgáfa getur enn verið að dreifa gömlu gerðinni. Smíð netþjónsins segir þér hvað er mögulegt, ekki hvað þessi notandi flutti inn.

Þrjú skilyrði sem velja greinina ykkar

Fyrsta skilyrðið er kynslóð gerðarinnar. Biðjið um skrána, sjáið hvernig hún var framleidd og skráið útgáfu biðlarans sem flutti hana inn. Ef þið getið ekki ákvarðað kynslóðina úr skránni, mun nýr prófíll gefinn út fyrir prófunarreikning segja ykkur hvað netþjónninn framleiðir í dag, og það eru önnur upplýsingar en þær sem notandinn sem mistekst hefur.

Annað er hvað framendinn ykkar lýkur í raun. Öfugur HTTP-milliþjónn á sjöunda laginu sem affermir TLS er ekki sami hlutur og TCP-framleiðsla á fjórða laginu, og UDP-framleiðsla er það ekki heldur. Venjulegt fyrirkomulag Access Server á porti 443 lætur OpenVPN TCP-púkann þekkja vafraumferð og afhenda vefþjónustunum hana, svo að setja ótengdan HTTPS-endir framan við varðveitir ekki samskiptareglur púkans. Að deila tölunni 443 gerir tvær hannanir ekki jafngildar.

Þriðja er hvar mistökin lenda. Mistök fyrir VPN og mistök í stjórnrás líta svipað út í biðlara sem segir aðeins "tengist", en þau skilja eftir sig sönnun á mismunandi stöðum. Ef gamla sniðið er í notkun er ræsingin kandídat. Ef nýja sniðið er í notkun er tóm vefaaðgangsskrá væntanleg og sannar ekkert í hvora áttina sem er.

Þegar gerðin er gömul: ræsingin mistekst fyrst

Lesið raunverulega villu biðlarans frekar en lokastöðu hans. Áhugaverðu svæðin eru HTTPS-villan, auðkenni netþjónsins sem biðlarinn vænti, áfangastaðurinn sem beiðnin fór til, og hvort staðfesting skírteinis kláraðist. Berið þau svo saman við skrár vefþjónustunnar og milliþjónsins á netþjónshlið.

Að vafri nái innskráningarsíðunni er ekki sönnun þess að API-auðkenning þessa biðlara hafi tekist. Þetta eru mismunandi beiðnir, með mismunandi skírteinisvæntingum og oft mismunandi hýsilnöfnum. Ef gáttin er þjónuð rétt og biðlarinn mistekst samt, er ágreiningurinn í ræsingarslóðinni, ekki í lykilorði notandans.

Ekki láta samanburðinn standast með því að slökkva á TLS-staðfestingu eða milda auðkenningarstefnuna. Það breytir greinanlegu stillingarósamræmi í slóð sem virkar en er óstaðfest, og það er einmitt sú breyting sem gerir tímabundið próf að varanlegu gati. Skjöl Access Server um tengingarprófíla lýsa báðum kynslóðum og ferli tímabundins prófíls, og það er viðmiðið sem á að skoða áður en gert er ráð fyrir að milliþjónn sé sekur.

Þegar gerðin er ný: lesið stjórnrásina í staðinn

Með prófíl í 2.9-stíl fer biðlarinn beint á innfædda VPN-endapunktinn. Rannsakið endapunkta prófílsins, flutningsmátann sem er notaður og villu stjórnrásarinnar. Ef biðlarinn sendir aldrei HTTP-beiðni er það í samræmi við hönnunina og ekki einkenni.

Hér breytist spurningin um milliþjóninn líka í laginu. HTTPS-afferming getur ekki brotið straum sem er aðeins TCP og hún sér aldrei, en hún getur enn brotið niðurhal sem birtir prófílinn, og framleiðsla sem er aðeins TCP flytur UDP alls ekki. Athugið hvaða flutningsmáta prófíllinn biður um áður en ályktað er að framendinn skipti ekki máli.

TLS-gegnumstreymi fyrir einn straum er þröngt fyrirkomulag. Það veitir ekki UDP-framleiðslu og endurgerir ekki eigið þjónustuframleiðsluhegðun púkans á 443. Ef framendinn ykkar gerir eitt af þessu, segið hvað, því lækningin er mismunandi.

Lækningar sem halda sér þröngar

Óáreitnasta prófið er að búa til nýjan studdan prófíl fyrir prófunarreikning og tengjast í gegnum fyrirhugaða innfædda endapunktinn með sömu auðkenningarkröfum. Ef það virkar og geymdur gamall prófíll ekki, hafið þið aðgreint gerðina frá netþjóninum og frá milliþjóninum í einu skrefi.

Dreifing notendalæsts prófíls fjarlægir arfleifðarræsingarháðina að fullu, því það er engin skipti á tímabundnum prófíl sem geta mistekist. Hann verður að vera gefinn út fyrir fyrirhugaðan notanda, aldrei afritaður frá stjórnanda, og hann breytir því hvað biðlarinn hefur heimild til, svo meðhöndlið hann sem stefnuákvörðun en ekki tilhlaup.

Lagið svo útgáfufyrirkomulagið þannig að hver nauðsynleg slóð sé til: vefslóðin fyrir niðurhal og gáttarnotkun, og innfædda VPN-slóðin á þeim flutningsmáta sem prófílarnir vænta. Haldið starfi milliþjónsins á einu lagi. Virkt notendalæst göng sanna að sú slóð virki; þau sanna ekki að hvert milliþjónsfyrirkomulag styðji hverja kynslóð, og gömul ræsingarvilla fordæmir ekki nýrra sniðið.

• Ákvarðið kynslóð gerðarinnar áður en þið snertið milliþjóninn.
• Ákvarðið hvort mistökin verða fyrir göngin eða inni í þeim.
• Staðfestið hvað framendinn lýkur: HTTP, TCP-straum eða UDP.
• Prófið nýútgefinn prófíl gagnvart innfædda endapunktinum með óbreyttri stefnu.