De ce VPN-ul tău de pe Mac cere acces la Keychain de fiecare dată
Identifică ce componentă declanșează fiecare mesaj al VPN-ului pe Mac, oprește încercările de conectare duplicate și repară accesul la Keychain fără a reseta întregul portchei.
Un clic pe Connect ar trebui să producă o singură fereastră de autentificare. Pe un Mac produce adesea trei, iar ele împart rar același proprietar: portcheile deține solicitările locale de credențiale, gateway-ul VPN deține autentificarea, iar clientul le deține pe ale sale. În loc să căutați un comutator care reduce totul la tăcere, tratați fiecare fereastră ca un defect separat, cu reparația ei. Ghidul de mai jos parcurge o singură încercare deliberată de conectare și se încheie cu o verificare pe care o puteți repeta.
Numiți proprietarul fiecărui dialog înainte de a schimba o setare
Primul pas este evidența, nu configurarea. Faceți o încercare de conectare și, pentru fiecare fereastră care apare, notați patru câmpuri: numele aplicației din dialog, textul exact fără nimic secret, faza în care a apărut și ce s-a întâmplat când ați anulat-o. Trei astfel de rânduri acoperă aproape fiecare raport pe care l-am analizat.
Proprietatea decide reparația corectă, iar reparația greșită este de obicei cea care transformă o solicitare în trei:
| Window | Who owns it | Correct fix | What not to do |
|---|---|---|---|
| “wants to use your confidential information stored in…” | The item's access control list in your login keychain | Approve the specific client helper, once, after checking the name | Resetting the login keychain, or granting Always Allow to every application |
| “Sign in to <organization>” or an MFA push | The gateway's identity provider | Use the client's supported session renewal, or re-authenticate | Scripting a fixed password or code into the client |
| “Connection failed”, “Update required”, a policy banner | The client or your organization | Read the first error and fix its cause | Hiding notices by editing a preference file the client rewrites |
O solicitare care revine în aceeași încercare este un semnal diferit de una care revine la încercarea următoare. Prima înseamnă de obicei că conexiunea a fost repornită sub tine; a doua înseamnă de obicei că se cere din nou o credențială salvată. Notați care este cazul înainte de a atinge portcheile, pentru că cele două aproape nu au nimic în comun.
Aflați câte lucruri pornesc tunelul
Patru mecanisme pot porni același VPN pe un Mac: o acțiune din bara de meniu, un element de autentificare, o regulă On Demand și un script sau un agent. Când două dintre ele se declanșează, a doua pornire poate sosi în timp ce prima așteaptă încă autentificarea, ceea ce produce o fereastră duplicată și niciun progres. Enumerați mai întâi ce este configurat: scutil --nc list afișează serviciile VPN cunoscute de Setările Sistemului, cu starea lor actuală. Clienții care livrează propria extensie de rețea păstrează profilurile în aplicație și pot să nu apară acolo, așa că verificați și lista de conexiuni a clientului.
Apoi căutați startere concurente. scutil --nc show "Work VPN" afișează dicționarul de configurare al unui serviciu încorporat, inclusiv regulile On Demand; o regulă care se reconectează la orice schimbare de interfață va reporni tunelul — și va redeschide solicitarea de autentificare — de fiecare dată când Wi-Fi se deplasează sau un ecran trezește stiva de rețea. Verificați elementele de autentificare din Setările Sistemului > General > Elemente de autentificare și listați agenții pe utilizator cu ls ~/Library/LaunchAgents. Lăsați în pace tot ce aparține unei stive de securitate administrată de MDM; eliminarea este de obicei împinsă înapoi la următoarea verificare.
Pentru a vedea ce rulează efectiv în timpul unei încercări: ps -Ao pid,comm | grep -iE 'vpn|tunnel|extension'. Doi asistenți de client acolo unde așteptați unul explică „de ce am primit două solicitări” mult mai des decât orice problemă de credențiale.
Reparați accesul la portchei fără a reseta portcheile
Solicitarea vine din lista de control al accesului a elementului salvat, nu din protocolul VPN. Fiecare element înregistrează ce aplicații îl pot citi fără să întrebe. După o actualizare a clientului, asistentul care întreabă poate purta alt nume sau altă semnătură în timp ce elementul îl listează încă pe cel vechi, așa că macOS întreabă din nou la fiecare conexiune. Aprobarea noului asistent pentru acel singur element este întreaga reparație; aprobarea fiecărei aplicații nu este.
Puteți confirma că ACL-ul este cauza fără să atingeți VPN-ul: security find-generic-password -s "service-name" -g citește același element dintr-un terminal. Dacă acea comandă declanșează și ea solicitarea, dialogul aparține portcheii, iar tunelul este doar declanșatorul. Îndrumările Apple despre cele trei butoane — Permite o dată, Permite întotdeauna, Refuză — merită o lectură, pentru că Refuză este cea care face solicitarea să reapară imediat, nu la încercarea următoare.
Dacă ați aprobat asistentul greșit, deschideți elementul în Acces la portchei, treceți la Control acces și eliminați acea intrare; aceasta este revenirea. Ștergerea portcheii de autentificare sau rularea unui instrument de reparare care o reconstruiește aruncă și parole nelegate și este o schimbare mult mai mare decât problema.
Păstrați pașii de autentificare și de politică în fluxurile care le dețin
O autentificare în browser sau o provocare MFA aparțin gateway-ului. Dacă organizația voastră oferă persistența sesiunii sau autentificare bazată pe certificate, folosiți-o, pentru că este modalitatea acceptată de a vă autentifica mai rar. Tastarea unui cod fix într-un client sau stocarea unei parole într-un script ca solicitarea să nu apară niciodată înlocuiește un factor interactiv cu un secret static și eșuează la următoarea rotație a politicii.
Notificările organizației sunt singura categorie pe care nu ar trebui să o suprimați. De obicei impun o verificare a posturii sau o confirmare a utilizării acceptabile, iar ascunderea lor poate scoate dispozitivul din conformitate chiar și când tunelul funcționează. Dialogurile de eroare sunt cealaltă categorie: păstrați textul primei erori, pentru că un al doilea dialog este adesea doar aceeași defecțiune raportată după o reîncercare.
Verificați cu o încercare, apoi după o repornire
După ce starterele duplicate au fost eliminate și intrarea din portchei reparată, faceți o singură încercare: închideți fiecare instanță a clientului, inclusiv asistentul din bara de meniu, conectați-vă o dată și numărați ferestrele. Doriți aprobarea portcheii, dacă elementul a fost reconstruit, și un singur pas de autentificare. Nimic mai mult. scutil --nc status "Work VPN" ar trebui să raporteze Connected pentru un serviciu încorporat.
Apoi reporniți o dată și repetați. O solicitare care revine doar după o repornire indică un element de autentificare sau o regulă On Demand, nu credențiale; una care revine în sesiune indică ACL-ul sau un al doilea starter. Dacă se repetă încă după ambele treceri, lucrul util de înmânat administratorului este tabelul cu trei rânduri din prima încercare — proprietar, text exact, fază — nu o captură de ecran a dialogului.
Mai puține solicitări este scopul, nu solicitări silențioase. O conexiune care își ascunde pașii de autorizare este o conexiune pe care nu o mai puteți audita, iar următoarea rotație de certificate vă va găsi fără să știți care componentă eșuează.