Ang profile na naka-lock sa server ay nabigo sa likod ng TLS proxy: aling henerasyon?
Magkaiba ang pagbuo ng Access Server 2.8 at 2.9 sa mga profile na naka-lock sa server. Magpasya kung aling landas ang sinisira ng iyong proxy bago baguhin ang front end.
May isang user na nakakonekta at may isa na hindi, sa parehong portal, sa parehong araw. Pareho silang may mga profile na naka-lock sa server, pareho silang nasa parehong Access Server build, at ang tanging pagkakaiba ay kung kailan nabuo ang kanilang profile. Iyon ang pattern na dapat makilala, dahil ang "naka-lock sa server" ay tumutukoy sa patakaran at hindi sa pagkakasunod-sunod ng koneksyon. Naglabas ang Access Server ng dalawang henerasyon ng artifact na iyon, at ang isang TLS reverse proxy ay nakatayo sa harap ng isa lamang sa mga landas nito. Tatlong kondisyon ang nagpapasya kung aling sangay ka.
Dalawang henerasyon, dalawang pagkakasunod-sunod ng koneksyon
Sa lumang disenyo, na umiiral hanggang 2.8, ang na-import na file ay isang pseudo-profile. Ginagamit ito ng OpenVPN Connect para mag-authenticate sa web API ng Access Server sa pamamagitan ng HTTPS, tumatanggap ng pansamantalang profile na naka-lock sa user at session token, at pagkatapos lamang ay nagtatatag ng VPN. Dalawang transport ang tumatakbo nang sunud-sunod, at ang una ay isang ordinaryong web request.
Ang format na ipinakilala sa 2.9 ay hindi nagsasagawa ng bootstrap bawat koneksyon. Ito ay isang native na profile na magagamit ng mga compatible na OpenVPN client, hindi lamang ng OpenVPN Connect. Ang pag-download o pag-import nito sa URL ay maaari pa ring may HTTPS — iyon ay hakbang ng paglalathala, hindi pagkuha ng pansamantalang profile bawat koneksyon.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
Ang upgrade ay hindi kinakailangang magsulat muli ng mga na-isyung profile, kaya ang kasalukuyang bersyon ng server ay maaaring nagbibigay pa rin ng lumang artifact. Sinasabi ng server build kung ano ang posible, hindi kung ano ang na-import ng user na ito.
Tatlong kondisyon na pumipili ng iyong sangay
Ang unang kondisyon ay ang henerasyon ng artifact. Hilingin ang file, tingnan kung paano ito ginawa, at itala ang bersyon ng client na nag-import nito. Kung hindi mo matukoy ang henerasyon mula sa file, sasabihin sa iyo ng bagong profile na inisyu para sa test account kung ano ang ginagawa ng server ngayon, at iba ito sa impormasyong taglay ng nabigong user.
Ang pangalawa ay kung ano ang aktwal na tinatapos ng iyong front end. Ang HTTP reverse proxy sa ikapitong layer na nag-aalis ng TLS ay hindi kaparehong bagay sa TCP forwarder sa ikaapat na layer, at hindi rin sa UDP forwarder. Ang karaniwang kaayusan ng Access Server sa port 443 ay nagiging dahilan upang makilala ng OpenVPN TCP daemon ang trapiko ng browser at ibigay ito sa mga web service, kaya ang paglalagay ng walang kaugnayang HTTPS terminator sa harap ay hindi nagpapanatili ng paghawak ng protocol ng daemon na iyon. Ang pagbabahagi ng numerong 443 ay hindi gumagawa ng dalawang disenyo na magkatumbas.
Ang pangatlo ay kung saan lumalapag ang kabiguan. Ang kabiguan bago ang VPN at ang kabiguan ng control channel ay magkamukha sa client na nagsasabi lamang ng "kumokonekta", ngunit nag-iiwan sila ng ebidensya sa magkaibang lugar. Kung ang lumang format ang nasa laro, ang bootstrap ay kandidato. Kung ang bagong format ang nasa laro, ang walang laman na web access log ay inaasahan at wala itong pinapatunayan sa alinmang direksyon.
Kapag luma ang artifact: nauuna ang pagkabigo ng bootstrap
Basahin ang aktwal na error ng client at hindi ang huling estado nito. Ang mga kawili-wiling field ay ang HTTPS error, ang pagkakakilanlan ng server na inasahan ng client, ang patutunguhan ng kahilingan, at kung natapos ang pagpapatunay ng certificate. Pagkatapos ay itugma ang mga ito sa mga log ng web service at proxy sa panig ng server.
Ang pag-abot ng browser sa login page ay hindi ebidensya na nagtagumpay ang API authentication ng client na ito. Magkaibang kahilingan ang mga ito, may magkaibang inaasahan sa certificate at madalas magkaibang hostname. Kung tama ang paghahatid ng portal at nabigo pa rin ang client, ang pagkakaiba ay nasa landas ng bootstrap, hindi sa password ng user.
Huwag gawing matagumpay ang paghahambing sa pamamagitan ng pagpatay ng TLS verification o pagluluwag ng patakaran sa authentication. Ginagawa nitong landas na gumagana pero hindi beripikado ang isang madadayagnos na hindi pagkakatugma ng configuration, at iyon mismo ang pagbabagong gumagawa ng pansamantalang pagsubok na permanenteng butas. Ang dokumentasyon ng Access Server tungkol sa mga profile ng koneksyon ay naglalarawan ng parehong henerasyon at ng daloy ng pansamantalang profile, at iyon ang sangguniang dapat suriin bago ipagpalagay na ang proxy ang may kasalanan.
Kapag bago ang artifact: basahin ang control channel
Sa profile na istilong 2.9, dumiretso ang client sa native na endpoint ng VPN. Suriin ang mga endpoint sa profile, ang transport na ginagamit, at ang error ng control channel. Kung hindi kailanman naglalabas ng HTTP request ang client, tugma iyon sa disenyo at hindi sintomas.
Dito rin nagbabago ang hugis ng tanong tungkol sa proxy. Ang HTTPS offload ay hindi makakasira ng stream na TCP lamang na hindi nito nakikita, ngunit makakasira pa rin ito ng download na naglalathala ng profile, at ang forwarder na TCP lamang ay hindi magdadala ng UDP. Suriin kung aling transport ang hinihingi ng profile bago magpasya na walang kaugnayan ang front end.
Ang TLS passthrough para sa isang stream ay makitid na kaayusan. Hindi ito nagbibigay ng UDP forwarding, at hindi nito ginagaya ang sariling pag-uugali ng daemon sa pagpapasa ng serbisyo sa 443. Kung ginagawa ng iyong front end ang isa sa mga ito, sabihin kung alin, dahil magkaiba ang lunas.
Mga lunas na nananatiling makitid
Ang pinakamaliit na interbensyong pagsusuri ay gumawa ng bagong sinusuportahang profile para sa test account at kumonekta sa pamamagitan ng inilaan na native endpoint gamit ang parehong mga kinakailangan sa authentication. Kung gumagana iyon at hindi ang itinagong lumang profile, nahiwalay mo ang artifact mula sa server at sa proxy sa isang hakbang.
Ang distribusyon ng profile na naka-lock sa user ay tuluyang nag-aalis ng pagdepende sa lumang bootstrap, dahil walang palitan ng pansamantalang profile na maaaring mabigo. Dapat itong inisyu para sa inilaan na user, hinding-hindi kokopyahin mula sa administrator, at binabago nito kung ano ang awtorisadong gawin ng client, kaya ituring itong desisyon sa patakaran at hindi pansamantalang solusyon.
Pagkatapos ay ayusin ang layout ng paglalathala upang umiral ang bawat kinakailangang landas: ang web path para sa mga download at paggamit ng portal, at ang native VPN path sa transport na inaasahan ng mga profile. Panatilihin ang trabaho ng proxy sa isang layer. Ang gumaganang tunnel na naka-lock sa user ay nagpapatunay na gumagana ang landas na iyon; hindi nito pinapatunay na sinusuportahan ng bawat kaayusan ng proxy ang bawat henerasyon, at ang kabiguan ng lumang bootstrap ay hindi humahatol sa mas bagong format.
- Tukuyin ang henerasyon ng artifact bago hawakan ang proxy.
- Tukuyin kung nangyayari ang kabiguan bago ang tunnel o sa loob nito.
- Kumpirmahin kung ano ang tinatapos ng front end: HTTP, TCP stream, o UDP.
- Subukan ang bagong inisyung profile laban sa native endpoint nang walang pagbabago sa patakaran.