Serveriga seotud profiil ebaõnnestub TLS-puhverserveri taga: milline põlvkond?

Üks kasutaja saab ühenduse ja teine mitte, sama portaali kaudu, samal päeval. Mõlemal on serveriga seotud profiil, mõlemad on samal Access Serveri versioonil, ja ainus erinevus on see, millal nende profiil loodi. See on muster, mida tasub ära tunda, sest "serveriga seotud" nimetab poliitikat, mitte ühenduste jada. Access Server on välja andnud selle artefakti kaks põlvkonda, ja TLS-i vastupuhverserver seisab ainult ühe nende tee ees. Kolm tingimust otsustavad, millises harus te olete.

Kaks põlvkonda, kaks ühenduste jada

Vanemas disainis, mis kehtib kuni 2.8, on imporditud fail pseudoprofiil. OpenVPN Connect kasutab seda autentimiseks Access Serveri veebi-API vastu üle HTTPS-i, saab ajutise kasutajaga seotud profiili ja sessioonitõendi, ja alles seejärel loob VPN-i. Kaks transporti töötavad järjest, ja esimene neist on tavaline veebipäring.

Versiooniga 2.9 kasutusele võetud vorming ei tee seda alglaadimist ühenduse kohta. See on natiivne profiil, mida saavad kasutada ühilduvad OpenVPN kliendid, mitte ainult OpenVPN Connect. Selle allalaadimine või URL-i kaudu importimine võib endiselt hõlmata HTTPS-i — see on avaldamise samm, mitte ajutise profiili hankimine ühenduse kohta.

Uuendamine ei kirjuta tingimata üle juba välja antud profiile, seega võib praegune serveri versioon endiselt vana artefakti jagada. Serveri versioon ütleb teile, mis on võimalik, mitte seda, mida see kasutaja importis.

Kolm tingimust, mis valivad teie haru

Esimene tingimus on artefakti põlvkond. Küsige fail, vaadake, kuidas see loodi, ja märkige üles kliendi versioon, mis selle importis. Kui te ei suuda põlvkonda failist kindlaks teha, ütleb testkontole välja antud värske profiil teile, mida server täna toodab, ja see on erinev teave sellest, mis on tõrkuval kasutajal.

Teine on see, mida teie esiosa tegelikult lõpetab. Seitsmenda kihi HTTP-vastupuhverserver, mis TLS-i maha laadib, ei ole sama objekt kui neljanda kihi TCP-edastaja, ja ka UDP-edastaja ei ole. Access Serveri tavaline paigutus pordil 443 paneb OpenVPN TCP-deemon brauseri liiklust ära tundma ja selle veebiteenustele üle andma, nii et mitteseotud HTTPS-lõpetaja ette panemine ei säilita selle deemon protokollikäsitlust. Sama numbri 443 jagamine ei tee kahte disaini samaväärseks.

Kolmas on see, kuhu tõrge maandub. Tõrge enne VPN-i ja juhtkanali tõrge näevad kliendis, mis ütleb ainult "ühendan", sarnased välja, kuid jätavad jälgi erinevatesse kohtadesse. Kui mängus on vana vorming, on alglaadimine kandidaat. Kui mängus on uus vorming, on tühi veebipääsulogi ootuspärane ega tõesta midagi kummaski suunas.

Kui artefakt on vana: alglaadimine ebaõnnestub esimesena

Lugege kliendi tegelikku viga, mitte selle lõppolekut. Huvitavad väljad on HTTPS-i viga, serveri identiteet, mida klient ootas, sihtkoht, kuhu päring läks, ja see, kas sertifikaadi valideerimine lõppes. Seejärel võrrelge neid serveripoolsete veebiteenuse ja puhverserveri logidega.

See, et brauser jõuab sisselogimislehele, ei ole tõestus, et selle kliendi API-autentimine õnnestus. Need on erinevad päringud, erinevate sertifikaadiootustega ja sageli erinevate hostinimedega. Kui portaal teenindatakse korrektselt ja klient ikka ebaõnnestub, on lahknevus alglaadimise teel, mitte kasutaja paroolis.

Ärge tehke võrdlust läbituks TLS-i kontrolli väljalülitamise või autentimispoliitika lõdvendamisega. See muudab diagnoositava konfiguratsioonierinevuse töötavaks, kuid kontrollimata teeks, ja just see muudatus muudab ajutise testi püsivaks auguks. Access Serveri ühendusprofiilide dokumentatsioon kirjeldab mõlemat põlvkonda ja ajutise profiili voogu, ja see on viide, mida tuleks kontrollida enne, kui eeldada, et puhverserver on süüdi.

Kui artefakt on uus: lugege hoopis juhtkanalit

2.9-stiilis profiiliga läheb klient otse natiivsesse VPN-i lõpp-punkti. Uurige profiili lõpp-punkte, kasutatavat transporti ja juhtkanali viga. Kui klient ei esita kunagi HTTP-päringut, on see kooskõlas disainiga ega ole sümptom.

Just siin muudab puhverserveri küsimus kuju. HTTPS-i mahalaadimine ei saa katki teha ainult TCP-põhist voogu, mida see kunagi ei näe, kuid see võib ikkagi katki teha allalaadimise, mis profiili avaldab, ja ainult TCP-edastaja ei kanna UDP-d üldse. Kontrollige, millist transporti profiil nõuab, enne kui järeldate, et esiosa on ebaoluline.

TLS-i läbilaskmine ühe voo jaoks on kitsas lahendus. See ei paku UDP-edastust ega taasta deemon enda teenuseedastuse käitumist pordil 443. Kui teie esiosa teeb ühte neist, öelge millist, sest raviviis erineb.

Raviviisid, mis jäävad kitsaks

Kõige vähem sekkuv kontroll on luua testkontole värske toetatud profiil ja ühenduda kavandatud natiivse lõpp-punkti kaudu samade autentimisnõuetega. Kui see töötab ja säilitatud vana profiil mitte, olete ühe sammuga eraldanud artefakti serverist ja puhverserverist.

Kasutajaga seotud profiili levitamine eemaldab pärandalglaadimise sõltuvuse täielikult, sest ajutise profiili vahetust, mis võiks ebaõnnestuda, ei ole. See tuleb välja anda kavandatud kasutajale, mitte kunagi administraatorilt kopeerida, ja see muudab seda, milleks klient on volitatud, seega käsitlege seda poliitikaotsusena, mitte mööregoodu.

Seejärel parandage avaldamise paigutus nii, et iga nõutav tee oleks olemas: veebitee allalaadimiste ja portaali kasutamise jaoks ning natiivne VPN-i tee transportil, mida profiilid eeldavad. Hoidke puhverserveri töö ühel kihil. Töötav kasutajaga seotud tunnel tõestab, et see tee töötab; see ei tõesta, et iga puhverserveri paigutus toetab iga põlvkonda, ja vana alglaadimise tõrge ei hukka uuemat vormingut.

• Tehke artefakti põlvkond kindlaks enne, kui puhverserverit puudutate.
• Tehke kindlaks, kas tõrge esineb enne tunnelit või selle sees.
• Kinnitage, mida esiosa lõpetab: HTTP, TCP-voog või UDP.
• Testige värskelt välja antud profiili natiivse lõpp-punkti vastu muutmata poliitikaga.