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ă.
| Mod | Poziția de stocare | Rezultat runtime | Acțiunea operatorului |
|---|---|---|---|
| Modul autonom | Durable /data sau PAM_AGENT_DATA_DIR este montat și intact | Conectorul încarcă pachetul de identitate la pornire și efectuează reconectare mTLS fără intervenția operatorului | Niciuna |
| Recuperare ghidată | Niciun /data persistent sau volumul de identitate a fost pierdut / recreat gol | Conectorul nu poate reconecta normal și intră în needs_recovery în timp ce păstrează configurația conectului în planul de control | Emiț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
- 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ă fieUp. - systemd:
systemctl status vaultpam-connector.
- Docker:
- Poate gazda să ajungă la planul de control? Din mașina de conector:
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.curl -v https://<control-plane-host>/healthz
- 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.
- Conectorul și-a pierdut stocarea de identitate durabilă? Un conector anterior asociat ar trebui să repornească din identitatea persistă sub
/datasauPAM_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
emptyDirsau alt strat efemer.
- Docker: confirmați că containerul montează încă același volum numit sau bind mount la
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:
- Remediați problema de încredere, rețea sau token.
- Generați un token de înscrierea proaspăt dacă cel original a expirat sau a fost revocat.
- 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:
Offlinetemporar 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:
- Restabiliți accesibilitatea HTTPS ieșire la planul de control.
- Confirmați că conectorul are încă pachetul de identitate local pe stocarea durabilă.
- Reporniți procesul conectect sau pod o singură dată.
- Validați că conectorul revine la
Onlinefă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_INVALIDdupă o asociere anterior reușită - alertele punctului final 401 cresc după repornire
- montarea stocării durabile a fost înlocuită, eliminată sau recreată goală
Recuperare:
- Opriți conectorul sau redimensionați pod-ul la zero înainte de a schimba acreditările.
- Încercați mai întâi să reataşați stocarea durabilă originală.
- 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
- Validați că repornirile ulterioare refolosesc identitatea persistă în loc să ceară un alt token.
- 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 jurnal | Semnificație | Remediere |
|---|---|---|
x509: certificate signed by unknown authority | Gazda nu are încredere în CA | Importați pachetul de certificat CA (/etc/vaultpam/ca.crt) — consultați runbook-ul imprimat în timpul instalării |
connection refused | Rețea blocată | Verificați lista albă de ieșire firewall-ul corporativ |
enrolment token revoked | Cineva a făcut clic pe Revoke în interfața de utilizator | Generaț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 bootstrap | Reataş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:
- Confirmați că conectorul ajunge la
Online. - Reporniți conectorul o dată din nou.
- Confirmați că se reconectează fără un token de înscrierea proaspăt.
- Confirmați că calea stocării durabile conține încă starea conectect după repornire.
- 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_renewedsaugateway.enrollment_failedlegate 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.