Gateway Juniper sau Pulse: ce protocol OpenConnect să folosești
Indicatorul de protocol decide schimbul de autentificare. Comparați suportul pentru Network Connect și Pulse, apoi potriviți clientul cu ceea ce gateway-ul servește efectiv.
Alegerea unui protocol pentru OpenConnect este un exercițiu de potrivire, nu o căutare de marcă. Un gateway care scrie Juniper pe pagina de autentificare poate expune Network Connect, Pulse sau ambele, iar valoarea implicită a clientului nu este niciuna dintre ele. Ghicitul costă o autentificare eșuată și, mai rău, un fir de suport care dă vina pe credențiale pentru o nepotrivire de protocol. Confirmați serviciul înainte de a tasta un nume de gazdă într-un profil.
OpenConnect numește protocolul mai vechi nc și pe cel mai nou pulse, iar ambele trăiesc în același binar. Indicatorul ales schimbă schimbul de autentificare, nu rutarea după o conexiune reușită.
Cele două nume de protocol împart o istorie de produs
Network Connect de la Juniper și clientul Pulse Secure ulterior sunt protocoale diferite pe care o familie de aparate le-a expus de-a lungul timpului. OpenConnect a dezvoltat un handler nc pentru primul și un handler pulse pentru al doilea. Sunt căi de cod separate cu formate de cerere separate, așa că suportul într-unul nu spune nimic despre celălalt.
Diferența apare imediat în conversația de autentificare: punctele finale, câmpurile formularului și modul în care clientul raportează un al doilea factor respins variază între cei doi handleri.
Alegerea în linia de comandă este o schimbare de un cuvânt: openconnect --protocol=nc vpn.example.com pentru Network Connect sau openconnect --protocol=pulse vpn.example.com pentru Pulse. Ambele încercări sunt încercări reale de conectare care pot reconfigura rutele și DNS-ul, așa că executați-le deliberat. Nu puneți niciodată o parolă pe linia de comandă și nu dezactivați verificările certificatelor pentru a ocoli o eroare de protocol, deoarece asta ascunde nepotrivirea în loc să o remedieze. Dacă trebuie să vedeți ce trimite clientul, --dump-http-traffic tipărește schimbul, care de obicei identifică handlerul așteptat de gateway.
Potriviți protocolul cu ceea ce expune gateway-ul
Aparatul răspunde doar la protocolul pentru care este configurat. Un serviciu doar cu Pulse respinge o autentificare nc chiar și cu credențiale valide, iar un serviciu Network Connect vechi nu are niciun punct final pulse la care să răspundă. Întrebați administratorul care este activat și ce client acceptă. Un aparat redenumit, o pagină wiki învechită și un portal web familiar sunt toate dovezi slabe.
După ce știți protocolul, confirmați cerințele din jur: autentificare cu certificat sau token, o selecție de grup de autentificare și orice verificare de conformitate a punctului final. Acestea decid dacă un client din linia de comandă poate finaliza autentificarea.
Autentificarea poate rezolva întrebarea înaintea protocolului
Un implementare poate cere un certificat de client, o rundă SAML prin browser sau un verificator de gazdă care inspectează mașina înainte de a acorda acces. Handlerul pulse al OpenConnect documentează limite de compatibilitate pentru unele dintre aceste fluxuri, iar handlerul nc are propriile lacune. O parolă care funcționează în browser dovedește că contul este valid; nu dovedește că un CLI sau un plugin de desktop arbitrar poate finaliza aceeași secvență. Când este implicat un verificator de gazdă, clientul are nevoie de un script de împachetare furnizat de administrator. Fără el, autentificarea se blochează după primul răspuns și pare o defecțiune de protocol când de fapt este un pas de conformitate lipsă.
Selecția grupului de autentificare este celălalt punct frecvent de împiedicare, deoarece un gateway cu mai multe grupuri așteaptă ca clientul să numească unul.
În linia de comandă, --authgroup="Employees" oferă acea alegere, iar omiterea ei poate lăsa sesiunea într-un grup implicit care respinge contul. Cu certificate, --certificate indică certificatul și cheia clientului, iar gateway-ul poate cere în continuare un token după aceea. Testați întreaga secvență o dată cu ieșire detaliată înainte de a automatiza ceva în jurul ei.
Când interfața desktop nu poate exprima alegerea
Interfețele grafice vin cu propriile seturi de funcții, iar un plugin mai vechi poate precede protocolul de care aveți nevoie. Integrarea OpenConnect a NetworkManager stochează alegerea în datele sale de conexiune, așa că nmcli connection modify "Office VPN" vpn.data "protocol=pulse" poate seta ce nu arată editorul. Verificați dacă versiunea instalată a pluginului acceptă cheia înainte de a presupune că modificarea a intrat în vigoare.
Dacă un meniu oferă doar PPTP sau L2TP, alegerea unuia nu transformă un serviciu Pulse în acel protocol. Instalați integrarea aprobată în loc să treceți la ce listează meniul din întâmplare.
Ce să înregistrați când autentificarea tot eșuează
Înregistrați patru lucruri: protocolul ales, versiunile clientului și ale pluginului, fluxul de autentificare așteptat și prima eroare care a revenit cu un cod de stare, nu cu un timeout. Acel set separă un handler greșit de un certificat lipsă, un grup de autentificare respins sau o verificare de conformitate blocată. Ieșirea detaliată merită păstrată din același motiv, pentru că arată cererea care a eșuat, nu doar simptomul.
Păstrați comanda sau profilul care funcționează lângă numele gateway-ului când reușește. Altfel, următoarea persoană care se conectează va repeta aceeași presupunere marcă versus protocol.