Profil uzamčený na server selhává za TLS proxy: která generace?

Jeden uživatel se připojí a druhý ne, přes stejný portál, ve stejný den. Oba mají profily uzamčené na server, oba jsou na stejném sestavení Access Serveru a jediný rozdíl je, kdy byl jejich profil vygenerován. To je vzor, který stojí za to rozpoznat, protože "uzamčeno na server" pojmenovává politiku, nikoli sled připojení. Access Server vydal dvě generace tohoto artefaktu a reverzní TLS proxy stojí jen před jednou z jejich cest. O větvi, ve které jste, rozhodují tři podmínky.

Dvě generace, dva sledy připojení

Ve starším návrhu, platném do verze 2.8, je importovaný soubor pseudo-profil. OpenVPN Connect jej používá k ověření vůči webovému API Access Serveru přes HTTPS, obdrží dočasný profil uzamčený na uživatele a token relace, a teprve potom naváže VPN. Dva přenosy běží za sebou a první z nich je běžný webový požadavek.

Formát zavedený s verzí 2.9 toto zavádění při každém připojení neprovádí. Je to nativní profil, který mohou používat kompatibilní OpenVPN klienti, nejen OpenVPN Connect. Jeho stažení nebo import přes URL může stále zahrnovat HTTPS — to je krok publikace, nikoli získání dočasného profilu při každém připojení.

Aktualizace nemusí přepsat profily, které už byly vydány, takže aktuální verze serveru může stále vydávat starý artefakt. Sestavení serveru vám říká, co je možné, ne co tento uživatel importoval.

Tři podmínky, které vybírají vaši větev

První podmínkou je generace artefaktu. Vyžádejte soubor, podívejte se, jak vznikl, a poznamenejte si verzi klienta, který jej importoval. Pokud generaci ze souboru nezjistíte, čerstvý profil vydaný pro testovací účet vám řekne, co server dnes produkuje, což je jiná informace než ta, kterou má selhávající uživatel.

Druhou je, co váš frontend skutečně ukončuje. Reverzní HTTP proxy sedmé vrstvy, která odkládá TLS, není stejný objekt jako TCP přeposílač čtvrté vrstvy a UDP přeposílač také ne. Obvyklé uspořádání Access Serveru na portu 443 nutí démona OpenVPN TCP rozpoznat provoz prohlížeče a předat jej webovým službám, takže vložení nesouvisejícího HTTPS terminátoru dopředu nezachová zpracování protokolu tímto démonem. Sdílení čísla 443 nečiní dva návrhy rovnocennými.

Třetí je, kam selhání dopadá. Selhání před VPN a selhání řídicího kanálu vypadají v klientovi, který hlásí jen "připojování", podobně, ale zanechávají důkazy na různých místech. Pokud je ve hře starý formát, je zavádění kandidátem. Pokud je ve hře nový formát, prázdný webový přístupový log je očekávaný a nic nedokazuje ani jedním směrem.

Když je artefakt starý: zavádění selže první

Čtěte skutečnou chybu klienta, ne jeho konečný stav. Zajímavá pole jsou chyba HTTPS, identita serveru, kterou klient očekával, cíl, kam požadavek šel, a zda se dokončilo ověření certifikátu. Poté je porovnejte s logy webové služby a proxy na straně serveru.

To, že prohlížeč dosáhne přihlašovací stránky, není důkaz, že ověření tohoto klienta přes API uspělo. Jsou to různé požadavky s různými očekáváními certifikátu a často různými názvy hostitelů. Pokud je portál obsluhován správně a klient stále selhává, nesoulad je v cestě zavádění, ne v uživatelském heslu.

Nedosahujte úspěšného srovnání vypnutím ověřování TLS nebo zmírněním politiky ověřování. To mění diagnostikovatelný nesoulad konfigurace v cestu, která funguje, ale není ověřená, a právě tato změna mění dočasný test v trvalou díru. Dokumentace Access Serveru k profilům připojení popisuje obě generace a tok dočasného profilu a je referencí, kterou je třeba zkontrolovat, než předpokládáte, že je na vině proxy.

Když je artefakt nový: čtěte řídicí kanál

S profilem ve stylu 2.9 jde klient přímo na nativní koncový bod VPN. Prozkoumejte koncové body v profilu, používaný přenos a chybu řídicího kanálu. Pokud klient nikdy nevydá HTTP požadavek, je to v souladu s návrhem, nikoli symptomatické.

I zde otázka proxy mění tvar. Odkládání HTTPS nemůže zlomit proud pouze přes TCP, který nikdy nevidí, ale stále může zlomit stahování, které profil publikuje, a přeposílač pouze přes TCP nepřenese UDP vůbec. Zkontrolujte, jaký přenos profil vyžaduje, než usoudíte, že je frontend nevýznamný.

Průchod TLS pro jediný proud je úzké uspořádání. Neposkytuje přeposílání UDP a nereprodukuje vlastní chování démona při přeposílání služeb na 443. Pokud váš frontend dělá jednu z těchto věcí, řekněte kterou, protože náprava se liší.

Nápravy, které zůstávají úzké

Nejméně invazivní kontrolou je vygenerovat čerstvý podporovaný profil pro testovací účet a připojit se přes zamýšlený nativní koncový bod se stejnými požadavky na ověření. Pokud to funguje a zachovaný starý profil ne, oddělili jste artefakt od serveru a od proxy jedním krokem.

Distribuce profilu uzamčeného na uživatele zcela odstraňuje závislost na zděděném zavádění, protože neexistuje výměna dočasného profilu, která by mohla selhat. Musí být vydán zamýšlenému uživateli, nikdy zkopírován od správce, a mění, k čemu je klient oprávněn, takže jej berte jako rozhodnutí o politice, ne jako provizorní řešení.

Poté opravte uspořádání publikace tak, aby existovala každá potřebná cesta: webová cesta pro stahování a používání portálu a nativní cesta VPN na přenosu, který profily očekávají. Držte práci proxy na jedné vrstvě. Fungující tunel uzamčený na uživatele dokazuje, že tato cesta funguje; nedokazuje, že každé uspořádání proxy podporuje každou generaci, a selhání starého zavádění neodsuzuje novější formát.

• Určete generaci artefaktu, než se dotknete proxy.
• Zjistěte, zda k selhání dochází před tunelem, nebo v něm.
• Potvrďte, co frontend ukončuje: HTTP, TCP proud, nebo UDP.
• Otestujte čerstvě vydaný profil proti nativnímu koncovému bodu s nezměněnou politikou.