Profil uzamknutý na server zlyháva za proxy TLS: ktorá generácia?

Jeden používateľ sa dokáže pripojiť a druhý nie, cez ten istý portál, v ten istý deň. Obaja majú profily uzamknuté na server, obaja sú na rovnakom zostavení Access Serveru a jediný rozdiel je, kedy bol ich profil vygenerovaný. To je vzor, ktorý stojí za to rozpoznať, pretože "uzamknutý na server" pomenúva politiku, nie sled pripojenia. Access Server vydal dve generácie tohto artefaktu a reverzná proxy TLS stojí len pred jednou z ich ciest. O vetve, v ktorej ste, rozhodujú tri podmienky.

Dve generácie, dva sledy pripojenia

V staršom návrhu, platnom do verzie 2.8, je importovaný súbor pseudoprofil. OpenVPN Connect ho používa na overenie voči webovému API Access Serveru cez HTTPS, dostane dočasný profil uzamknutý na používateľa a token relácie, a až potom nadviaže VPN. Dva prenosy bežia za sebou a prvý z nich je bežná webová požiadavka.

Formát zavedený s verziou 2.9 nevykonáva toto zavádzanie pri každom pripojení. Je to natívny profil, ktorý môžu používať kompatibilní OpenVPN klienti, nielen OpenVPN Connect. Jeho stiahnutie alebo import cez URL môže stále zahŕňať HTTPS — to je krok publikovania, nie získanie dočasného profilu pri každom pripojení.

Aktualizácia nemusí prepísať profily, ktoré už boli vydané, takže aktuálna verzia serveru môže stále vydávať starý artefakt. Zostavenie serveru vám hovorí, čo je možné, nie čo tento používateľ importoval.

Tri podmienky, ktoré vyberajú vašu vetvu

Prvou podmienkou je generácia artefaktu. Vyžiadajte súbor, pozrite sa, ako vznikol, a poznamenajte si verziu klienta, ktorý ho importoval. Ak generáciu zo súboru nedokážete určiť, čerstvý profil vydaný pre testovací účet vám povie, čo server dnes produkuje, a to je iná informácia než tá, ktorú má zlyhávajúci používateľ.

Druhou je, čo váš front end skutočne ukončuje. Reverzná HTTP proxy siedmej vrstvy, ktorá odkladá TLS, nie je rovnaký objekt ako TCP preposielač štvrtej vrstvy, a UDP preposielač tiež nie. Zvyčajné usporiadanie Access Serveru na porte 443 núti démona OpenVPN TCP rozpoznať prevádzku prehliadača a odovzdať ju webovým službám, takže vloženie nesúvisiaceho HTTPS terminátora dopredu nezachováva spracovanie protokolu týmto démonom. Zdieľanie čísla 443 nerobí dva návrhy rovnocennými.

Treťou je, kam zlyhanie dopadá. Zlyhanie pred VPN a zlyhanie riadiaceho kanála vyzerajú v klientovi, ktorý hlási len "pripájanie", podobne, ale zanechávajú dôkazy na rôznych miestach. Ak je v hre starý formát, zavádzanie je kandidát. Ak je v hre nový formát, prázdny webový prístupový log je očakávaný a nič nedokazuje ani jedným smerom.

Keď je artefakt starý: zavádzanie zlyhá prvé

Čítajte skutočnú chybu klienta, nie jeho konečný stav. Zaujímavé polia sú chyba HTTPS, identita serveru, ktorú klient očakával, cieľ, kam požiadavka išla, a či sa dokončilo overenie certifikátu. Potom ich porovnajte s logmi webovej služby a proxy na strane serveru.

To, že prehliadač dosiahne prihlasovaciu stránku, nie je dôkaz, že overenie tohto klienta cez API uspelo. Sú to rôzne požiadavky, s rôznymi očakávaniami certifikátu a často rôznymi názvami hostiteľov. Ak je portál obsluhovaný správne a klient stále zlyháva, nesúlad je v ceste zavádzania, nie v používateľskom hesle.

Nedosahujte úspešného porovnania vypnutím overovania TLS alebo zmiernením politiky overovania. To mení diagnostikovateľný nesúlad konfigurácie na cestu, ktorá funguje, ale nie je overená, a práve táto zmena mení dočasný test na trvalú dieru. Dokumentácia Access Serveru k profilom pripojenia opisuje obe generácie a tok dočasného profilu a je referenciou, ktorú treba skontrolovať, než predpokladáte, že je na vine proxy.

Keď je artefakt nový: čítajte riadiaci kanál

S profilom v štýle 2.9 ide klient priamo na natívny koncový bod VPN. Preskúmajte koncové body v profile, používaný prenos a chybu riadiaceho kanála. Ak klient nikdy nevydá HTTP požiadavku, je to v súlade s návrhom, nie symptóm.

Aj tu otázka proxy mení tvar. Odkladanie HTTPS nemôže zlomiť prúd len cez TCP, ktorý nikdy nevidí, ale stále môže zlomiť stiahnutie, ktoré profil publikuje, a preposielač len cez TCP neprenesie UDP vôbec. Skontrolujte, aký prenos profil vyžaduje, než usúdite, že front end je irelevantný.

Priechod TLS pre jediný prúd je úzke usporiadanie. Neposkytuje preposielanie UDP a nereprodukuje vlastné správanie démona pri preposielaní služieb na 443. Ak váš front end robí jednu z týchto vecí, povedzte ktorú, pretože náprava sa líši.

Nápravy, ktoré zostávajú úzke

Najmenej invazívnou kontrolou je vygenerovať čerstvý podporovaný profil pre testovací účet a pripojiť sa cez zamýšľaný natívny koncový bod s rovnakými požiadavkami na overenie. Ak to funguje a zachovaný starý profil nie, oddelili ste artefakt od serveru a od proxy jedným krokom.

Distribúcia profilu uzamknutého na používateľa úplne odstraňuje závislosť od zdedeného zavádzania, pretože neexistuje výmena dočasného profilu, ktorá by mohla zlyhať. Musí byť vydaný zamýšľanému používateľovi, nikdy skopírovaný od správcu, a mení, na čo je klient oprávnený, takže ho berte ako rozhodnutie o politike, nie ako obchádzku.

Potom opravte usporiadanie publikovania tak, aby existovala každá potrebná cesta: webová cesta na stiahnutia a používanie portálu a natívna cesta VPN na prenose, ktorý profily očakávajú. Držte prácu proxy na jednej vrstve. Fungujúci tunel uzamknutý na používateľa dokazuje, že tá cesta funguje; nedokazuje, že každé usporiadanie proxy podporuje každú generáciu, a zlyhanie starého zavádzania neodsudzuje novší formát.

• Určte generáciu artefaktu, než sa dotknete proxy.
• Zistite, či zlyhanie nastáva pred tunelom alebo v ňom.
• Potvrďte, čo front end ukončuje: HTTP, prúd TCP alebo UDP.
• Otestujte čerstvo vydaný profil proti natívnemu koncovému bodu s nezmenenou politikou.