Profili i bllokuar te serveri dështon prapa një proxy TLS: cila gjeneratë?

Një përdorues mund të lidhet dhe një tjetër jo, përmes të njëjtit portal, në të njëjtën ditë. Të dy kanë profile të bllokuara te serveri, të dy janë në të njëjtin build të Access Server, dhe i vetmi ndryshim është kur u gjenerua profili i tyre. Ky është modeli që ia vlen të njihet, sepse "i bllokuar te serveri" emërton një politikë dhe jo një sekuencë lidhjeje. Access Server ka dorëzuar dy gjenerata të atij artefakti, dhe një proxy i kundërt TLS qëndron përpara vetëm njërës prej rrugëve të tyre. Tre kushte vendosin në cilën degë jeni.

Dy gjenerata, dy sekuenca lidhjeje

Në projektimin më të vjetër, në fuqi deri në 2.8, skedari i importuar është një pseudoprofil. OpenVPN Connect e përdor për t'u autentikuar te API-ja web e Access Server përmes HTTPS, merr një profil të përkohshëm të bllokuar te përdoruesi dhe një token sesioni, dhe vetëm pas kësaj vendos VPN-në. Dy transporte punojnë me radhë, dhe i pari është një kërkesë web e zakonshme.

Formati i prezantuar me 2.9 nuk e kryen atë fillim për çdo lidhje. Është një profil vendas që mund të përdoret nga OpenVPN klientë të pajtueshëm, jo vetëm nga OpenVPN Connect. Shkarkimi ose importimi i tij përmes URL-së mund të përfshijë ende HTTPS — ky është një hap publikimi, jo një marrje e një profili të përkohshëm për çdo lidhje.

Një përditësim nuk i rishkruan domosdoshmërisht profilet e lëshuara më parë, kështu që një version aktual i serverit mund të shpërndajë ende artefaktin e vjetër. Build-i i serverit ju tregon çfarë është e mundur, jo çfarë importoi ky përdorues.

Tre kushte që zgjedhin degën tuaj

Kushti i parë është gjenerata e artefaktit. Kërkoni skedarin, shikoni si u prodhua, dhe shënoni versionin e klientit që e importoi. Nëse nuk mund ta përcaktoni gjeneratën nga skedari, një profil i ri i lëshuar për një llogari testuese do t'ju tregojë çfarë prodhon serveri sot, dhe ky është informacion i ndryshëm nga ai që ka përdoruesi që dështon.

Kushti i dytë është çfarë përfundon realisht front-end-i juaj. Një proxy i kundërt HTTP i shtresës së shtatë që shkarkon TLS nuk është i njëjti objekt si një përcjellës TCP i shtresës së katërt, dhe as një përcjellës UDP nuk është. Rregullimi i zakonshëm i Access Server në portën 443 e bën daemon-in OpenVPN TCP të njohë trafikun e shfletuesit dhe t'ia dorëzojë shërbimeve web, prandaj futja e një përfunduesi HTTPS të palidhur përpara nuk e ruan trajtimin e protokollit të atij daemoni. Ndarja e numrit 443 nuk i bën dy projektime të barasvlershme.

Kushti i tretë është ku ateron dështimi. Një dështim para VPN-së dhe një dështim i kanalit të kontrollit duken njësoj në një klient që thotë vetëm "po lidhet", por lënë prova në vende të ndryshme. Nëse formati i vjetër është në lojë, fillimi është kandidat. Nëse formati i ri është në lojë, një regjistër bosh i aksesit web pritet dhe nuk provon asgjë në asnjë drejtim.

Kur artefakti është i vjetër: fillimi dështon i pari

Lexoni gabimin e vërtetë të klientit dhe jo gjendjen e tij përfundimtare. Fushat interesante janë gabimi HTTPS, identiteti i serverit që klienti priste, destinacioni ku shkoi kërkesa, dhe nëse përfundoi validimi i certifikatës. Më pas krahasoni ato me regjistrat e shërbimit web dhe të proxy-t në anën e serverit.

Fakti që një shfletues arrin faqen e hyrjes nuk është provë që autentikimi API i këtij klienti pati sukses. Janë kërkesa të ndryshme, me pritshmëri të ndryshme certifikate dhe shpesh me emra hostesh të ndryshëm. Nëse portali shërbehet saktë dhe klienti vazhdon të dështojë, mospërputhja është në rrugën e fillimit, jo në fjalëkalimin e përdoruesit.

Mos e bëni krahasimin të kalojë duke çaktivizuar verifikimin TLS ose duke zbutur politikën e autentikimit. Kjo e shndërron një mospërputhje konfigurimi të diagnostikueshme në një rrugë që funksionon, por nuk është e verifikuar, dhe pikërisht ky ndryshim e shndërron një test të përkohshëm në një vrimë të përhershme. Dokumentacioni i Access Server për profilet e lidhjes përshkruan të dyja gjeneratat dhe rrjedhën e profilit të përkohshëm, dhe është referenca që duhet kontrolluar përpara se të supozohet se faji është i proxy-t.

Kur artefakti është i ri: lexoni kanalin e kontrollit

Me një profil në stilin 2.9, klienti shkon drejt e në pikën fundore vendase të VPN-së. Hetoni pikat fundore në profil, transportin e përdorur dhe gabimin e kanalit të kontrollit. Nëse klienti nuk lëshon kurrë një kërkesë HTTP, kjo përputhet me projektimin dhe nuk është simptomë.

Këtu edhe pyetja e proxy-t ndryshon formë. Një shkarkim HTTPS nuk mund të thyejë një rrjedhë vetëm TCP që nuk e sheh kurrë, por ende mund të thyejë shkarkimin që publikon profilin, dhe një përcjellës vetëm TCP nuk do të mbajë fare UDP. Kontrolloni çfarë transporti kërkon profili përpara se të përfundoni se front-end-i është i parëndësishëm.

Kalimi TLS për një rrjedhë të vetme është një rregullim i ngushtë. Nuk ofron përcjellje UDP dhe nuk riprodhon sjelljen e përcjelljes së shërbimeve të vetë daemon-it në 443. Nëse front-end-i juaj bën një nga këto, thoni cilën, sepse mjekimi është i ndryshëm.

Mjekime që mbeten të ngushta

Kontrolli më pak invaziv është të gjeneroni një profil të ri të mbështetur për një llogari testuese dhe të lidheni përmes pikës fundore vendase të synuar me të njëjtat kërkesa autentikimi. Nëse kjo funksionon dhe profili i vjetër i ruajtur jo, ju e keni ndarë artefaktin nga serveri dhe nga proxy-i në një hap.

Shpërndarja e një profili të bllokuar te përdoruesi heq plotësisht varësinë nga fillimi i trashëguar, sepse nuk ka shkëmbim profili të përkohshëm që mund të dështojë. Duhet të lëshohet për përdoruesin e synuar, të mos kopjohet kurrë nga një administrator, dhe ndryshon atë për të cilën klienti është i autorizuar, prandaj trajtojeni si një vendim politike dhe jo si një zgjidhje anashkaluese.

Më pas rregulloni strukturën e publikimit që të ekzistojë çdo rrugë e nevojshme: rruga web për shkarkimet dhe përdorimin e portalit, dhe rruga vendase VPN në transportin që presin profilet. Mbani punën e proxy-t në një shtresë të vetme. Një tunel i bllokuar te përdoruesi që funksionon provon se ajo rrugë funksionon; nuk provon se çdo rregullim proxy-i mbështet çdo gjeneratë, dhe një dështim i vjetër fillimi nuk e dënon formatin më të ri.

• Përcaktoni gjeneratën e artefaktit përpara se të prekni proxy-n.
• Përcaktoni nëse dështimi ndodh para tunelit apo brenda tij.
• Konfirmoni çfarë përfundon front-end-i: HTTP, rrjedhë TCP apo UDP.
• Testoni një profil të sapo lëshuar kundrejt pikës fundore vendase me politikën e pandryshuar.