Profilul blocat pe server eșuează în spatele unui proxy TLS: care generație?

Un utilizator se poate conecta, iar altul nu, prin același portal, în aceeași zi. Ambii au profile blocate pe server, ambii sunt pe aceeași versiune Access Server, iar singura diferență este când le-a fost generat profilul. Acesta este tiparul care merită recunoscut, pentru că "blocat pe server" numește o politică, nu o secvență de conectare. Access Server a livrat două generații ale acelui artefact, iar un proxy invers TLS stă în fața unei singure dintre căile lor. Trei condiții decid în ce ramură vă aflați.

Două generații, două secvențe de conectare

În proiectarea mai veche, valabilă până la 2.8, fișierul importat este un pseudoprofil. OpenVPN Connect îl folosește pentru a se autentifica la API-ul web al Access Server prin HTTPS, primește un profil temporar blocat pe utilizator și un token de sesiune, și abia apoi stabilește VPN-ul. Două transporturi rulează succesiv, iar primul este o cerere web obișnuită.

Formatul introdus cu 2.9 nu face acea inițializare la fiecare conexiune. Este un profil nativ utilizabil de OpenVPN clienți compatibili, nu doar de OpenVPN Connect. Descărcarea sau importarea lui prin URL poate implica încă HTTPS — acesta este un pas de publicare, nu o obținere de profil temporar la fiecare conexiune.

O actualizare nu rescrie neapărat profilele deja emise, așa că o versiune curentă a serverului poate distribui încă artefactul vechi. Versiunea serverului vă spune ce este posibil, nu ce a importat acest utilizator.

Trei condiții care vă aleg ramura

Prima condiție este generația artefactului. Cereți fișierul, vedeți cum a fost produs și notați versiunea clientului care l-a importat. Dacă nu puteți stabili generația din fișier, un profil nou emis pentru un cont de test vă va spune ce produce serverul astăzi, iar aceasta este o informație diferită de cea pe care o are utilizatorul care eșuează.

A doua este ce termină de fapt front end-ul dumneavoastră. Un proxy invers HTTP de nivel șapte care descarcă TLS nu este același obiect ca un redirecționator TCP de nivel patru, și nici un redirecționator UDP nu este. Amplasarea obișnuită a Access Server pe portul 443 face ca demonul OpenVPN TCP să recunoască traficul browserului și să îl predea serviciilor web, așa că introducerea unui terminator HTTPS nelegat în față nu păstrează tratarea protocolului de către acel demon. Partajarea numărului 443 nu face două proiecte echivalente.

A treia este unde aterizează eșecul. Un eșec înainte de VPN și un eșec al canalului de control arată similar într-un client care spune doar "se conectează", dar lasă dovezi în locuri diferite. Dacă formatul vechi este în joc, inițializarea este candidată. Dacă formatul nou este în joc, un jurnal de acces web gol este de așteptat și nu dovedește nimic în nicio direcție.

Când artefactul este vechi: inițializarea eșuează prima

Citiți eroarea reală a clientului în loc de starea lui finală. Câmpurile interesante sunt eroarea HTTPS, identitatea serverului pe care clientul o aștepta, destinația către care a mers cererea și dacă validarea certificatului s-a încheiat. Apoi comparați-le cu jurnalele serviciului web și ale proxy-ului din partea serverului.

Faptul că un browser ajunge la pagina de autentificare nu este dovada că autentificarea API a acestui client a reușit. Sunt cereri diferite, cu așteptări diferite privind certificatul și adesea cu nume de gazdă diferite. Dacă portalul este servit corect și clientul tot eșuează, dezacordul este pe calea de inițializare, nu în parola utilizatorului.

Nu faceți comparația să treacă dezactivând verificarea TLS sau relaxând politica de autentificare. Asta transformă o nepotrivire de configurare diagnosticabilă într-o cale care funcționează, dar nu este verificată, și exact această schimbare transformă un test temporar într-o gaură permanentă. Documentația Access Server despre profilele de conectare descrie ambele generații și fluxul profilului temporar, și este referința de verificat înainte de a presupune că un proxy este vinovat.

Când artefactul este nou: citiți canalul de control

Cu un profil în stil 2.9, clientul merge direct la punctul final nativ al VPN-ului. Investigați punctele finale din profil, transportul folosit și eroarea canalului de control. Dacă clientul nu emite niciodată o cerere HTTP, asta este consecvent cu proiectarea și nu este un simptom.

Aici și întrebarea despre proxy își schimbă forma. O descărcare HTTPS nu poate rupe un flux doar TCP pe care nu îl vede niciodată, dar poate rupe în continuare descărcarea care publică profilul, iar un redirecționator doar TCP nu va transporta deloc UDP. Verificați ce transport cere profilul înainte de a concluziona că front end-ul este irelevant.

Trecerea TLS pentru un singur flux este o aranjare îngustă. Nu oferă redirecționare UDP și nu reproduce comportamentul propriu de redirecționare a serviciilor al demonului pe 443. Dacă front end-ul dumneavoastră face unul dintre aceste lucruri, spuneți care, pentru că remediul diferă.

Remedii care rămân înguste

Cea mai puțin invazivă verificare este să generați un profil nou acceptat pentru un cont de test și să vă conectați prin punctul final nativ prevăzut, cu aceleași cerințe de autentificare. Dacă asta funcționează și profilul vechi păstrat nu, ați separat artefactul de server și de proxy într-un singur pas.

Distribuirea unui profil blocat pe utilizator elimină complet dependența de inițializarea moștenită, pentru că nu există niciun schimb de profil temporar care să poată eșua. Trebuie emis pentru utilizatorul prevăzut, niciodată copiat de la un administrator, și schimbă ceea ce clientul este autorizat să facă, așa că tratați-l ca o decizie de politică și nu ca o soluție ocolitoare.

Apoi corectați aranjarea publicării astfel încât fiecare cale necesară să existe: calea web pentru descărcări și utilizarea portalului, și calea nativă VPN pe transportul pe care profilele îl așteaptă. Păstrați activitatea proxy-ului pe un singur nivel. Un tunel blocat pe utilizator care funcționează dovedește că acea cale funcționează; nu dovedește că orice aranjare de proxy acceptă orice generație, iar un eșec vechi de inițializare nu condamnă formatul mai nou.

• Identificați generația artefactului înainte de a atinge proxy-ul.
• Stabiliți dacă eșecul are loc înainte de tunel sau în interiorul lui.
• Confirmați ce termină front end-ul: HTTP, flux TCP sau UDP.
• Testați un profil proaspăt emis împotriva punctului final nativ cu politica neschimbată.