Mergeți la conținutul principal

Conectorul meu este offline

Un conector ar trebui să treacă normal la starea Online în decurs de 30 de secunde de la instalare. Dacă nu o face, sau dacă un conector anterior sănătos trece la Offline, Degraded sau Needs recovery, utilizați acest runbook.

Ce înseamnă starea

  • Offline: conectorul nu este conectat în acest moment, dar se poate recupera singur după o întrerupere de rețea tranzitorie sau o repornire a procesului.
  • Degraded: cel puțin o cale de rulare este nefuncțională, dar nu fiecare cale de conector este inactivă.
  • Needs recovery: conectorul nu se mai află pe o cale de reconectare normală. Tratați aceasta ca pierdere de identitate durabilă, fallback bootstrap nevalid sau alt caz de recuperare mărginit. Conectorul nu reîncearcă în tăcere token-ul bootstrap original în această stare; eșuează închis și așteaptă un flux de recuperare inițiat în mod explicit de către operator.

Modul autonom versus recuperare ghidată

Modul în care conectorul se recuperează după o repornire depinde de prezența stocării de identitate durabilă.

ModPoziția de stocareRezultat runtimeAcțiunea operatorului
Modul autonomDurable /data sau PAM_AGENT_DATA_DIR este montat și intactConectorul încarcă pachetul de identitate la pornire și efectuează reconectare mTLS fără intervenția operatoruluiNiciuna
Recuperare ghidatăNiciun /data persistent sau volumul de identitate a fost pierdut / recreat golConectorul nu poate reconecta normal și intră în needs_recovery în timp ce păstrează configurația conectului în planul de controlEmiți un token de înscrierenou și cu o singură utilizare și re-asociază conectorul

Conectorul încarcă pachetul de identitate la pornire și efectuează reconectare mTLS fără nicio acțiune a operatorului în modul autonom. Aceasta este configurația implicită pentru implementările VM, Docker și Kubernetes configurate corect. Repornirile, reaplanificările podurilor și recrearea containerelor reuşesc toate automat atâta timp cât stocarea durabilă supraviețuiește.

În recuperarea ghidată, conectorul nu are identitate locală și nu poate reconecta. Configurația conectului — atribuirea org, ID-ul punctului final și rețelele permise — este păstrată în planul de control, dar o nouă înscrierea este necesară. Aceasta este starea explicită needs_recovery.

Retragerea bootstrap apare după prima înscrierea reușită și primul heartbeat online confirmat. Odată ce pachetul de identitate al conectului este salvat în stocarea durabilă și planul de control înregistrează acel heartbeat, token-ul bootstrap este consumat și retras. Toate repornirile ulterioare trebuie să utilizeze identitatea persistă pentru reconectare mTLS. Nu există cale — în niciun mod — în care un conector anterior înscris să se întoarcă în tăcere la token-ul bootstrap ca acreditare de repornire normală.

Verificări rapide

  1. Gazdele este conectată? SSH sau RDP în mașina de conector; confirmați că Docker / serviciul nativ funcționează.
    • Docker: docker ps | grep vaultpam-connector — containerul ar trebui să fie Up.
    • systemd: systemctl status vaultpam-connector.
  2. Poate gazda să ajungă la planul de control? Din mașina de conector:
    curl -v https://<control-plane-host>/healthz
    Dacă acest lucru nu reușește, aveți o problemă de rețea/DNS/firewall. Porturile 443 (HTTPS plan de control) și opțional 51820/udp (tunel VPN invers) trebuie să fie deschise pentru ieșire.
  3. Token-ul de înscrierea este încă valid? Token-urile expiră după 4 ore în mod implicit. Dacă conectorul nu a venit niciodată online și token-ul a expirat, generați un nou din Connectors → selectează conector → Regenerate token.
  4. Conectorul și-a pierdut stocarea de identitate durabilă? Un conector anterior asociat ar trebui să repornească din identitatea persistă sub /data sau PAM_AGENT_DATA_DIR.
    • Docker: confirmați că containerul montează încă același volum numit sau bind mount la /data.
    • Native / VM: confirmați că serviciul încă indică către același cale durabilă gazdă și că utilizatorul conectect o poate citi.
    • Kubernetes: confirmați că pod încă montează PVC-ul așteptat și nu a fost implementat din nou pe emptyDir sau alt strat efemer.

Identificați clasa de eșec

1. Eșecul bootstrap la prima pornire

Utilizați această ramură dacă conectorul nu s-a asociat niciodată cu succes.

Semnale obișnuite:

  • conectorul nu a devenit niciodată Online
  • jurnalele arată expirarea token-ului, revocare token, eșec validare CSR sau eșec încredere CA
  • interfața de utilizator arată încă o stare de onboarding sau activare mai degrabă decât ready

Recuperare:

  1. Remediați problema de încredere, rețea sau token.
  2. Generați un token de înscrierea proaspăt dacă cel original a expirat sau a fost revocat.
  3. Reîncercați asocierea.

2. Eșecul reconectării normale

Utilizați această ramură dacă conectorul s-a asociat anterior și are încă identitatea durabilă.

Semnale obișnuite:

  • Offline temporar după reboot, implementare sau fluctuație de rețea
  • activitate de alertă cp_tunnel_heartbeat_timeouts_total
  • directorul de date local este încă prezent și citibil

Recuperare:

  1. Restabiliți accesibilitatea HTTPS ieșire la planul de control.
  2. Confirmați că conectorul are încă pachetul de identitate local pe stocarea durabilă.
  3. Reporniți procesul conectect sau pod o singură dată.
  4. Validați că conectorul revine la Online fără a utiliza un nou token de înscrierea.

3. Pierderea identității durabile sau fallback bootstrap nevalid

Utilizați această ramură dacă conectorul s-a asociat anterior, dar acum se comportă ca un conector complet nou.

Semnale obișnuite:

  • interfața de utilizator sau API arată Needs recovery
  • jurnalele arată 401 ENROLLMENT_TOKEN_INVALID după o asociere anterior reușită
  • alertele punctului final 401 cresc după repornire
  • montarea stocării durabile a fost înlocuită, eliminată sau recreată goală

Recuperare:

  1. Opriți conectorul sau redimensionați pod-ul la zero înainte de a schimba acreditările.
  2. Încercați mai întâi să reataşați stocarea durabilă originală.
  3. Dacă identitatea originală nu mai există, tratați aceasta ca aprovizionare controlată:
    • revocați token-ul bootstrap vechi dacă încă există
    • emiți un token de înscrierea nou și cu o singură utilizare din planul de control
    • asigurați-vă că stocarea durabilă este montată corect înainte de a porni din nou
    • asociați exact o dată cu noul token
  4. Validați că repornirile ulterioare refolosesc identitatea persistă în loc să ceară un alt token.
  5. Confirmați că configurația conectult păstrată este încă prezentă; dacă configurația lipsește, escaladați ca o problemă de implementare separată.

Nu tratați reîncercările bootstrap repetate ca o cale de repornire normală.

Jurnale de inspectat

  • Docker: docker logs -n 200 vaultpam-connector.
  • Native: /var/log/vaultpam/connector.log (Linux) sau %PROGRAMDATA%\VaultPAM\connector.log (Windows).

Erori comune:

Fragment jurnalSemnificațieRemediere
x509: certificate signed by unknown authorityGazda nu are încredere în CAImportați pachetul de certificat CA (/etc/vaultpam/ca.crt) — consultați runbook-ul imprimat în timpul instalării
connection refusedRețea blocatăVerificați lista albă de ieșire firewall-ul corporativ
enrolment token revokedCineva a făcut clic pe Revoke în interfața de utilizatorGenerați un token nou
401 ENROLLMENT_TOKEN_INVALID după ce conectorul a fost deja asociat o datăConectorul și-a pierdut identitatea persistă și s-a întors la bootstrapReataşați directorul de date durabil original dacă disponibil. Dacă identitatea nu mai există, generați un token proaspăt și asociați din nou pe stocarea durabilă

Validare post-recuperare

După orice remediere:

  1. Confirmați că conectorul ajunge la Online.
  2. Reporniți conectorul o dată din nou.
  3. Confirmați că se reconectează fără un token de înscrierea proaspăt.
  4. Confirmați că calea stocării durabile conține încă starea conectect după repornire.
  5. Capturați dovezile pentru audit:
    • starea conectect înainte și după
    • linia jurnalului care dovedește succesul reconectării sau reînnoirii
    • toate intrările audit endpoint.cert_renewed sau gateway.enrollment_failed legate de incident
    • numele alertei și fereastra de timp dacă monitorizarea s-a declanşat

Încă blocat

Contactați suportul și includeți: versiunea conectect, cozul jurnalelor, rezultatul din curl -v https://<control-plane-host>/healthz.

Articole conexe