Ticketing Conexión y autenticación
Una conexión de igual a igual (puerto Raft = puerto de cliente + 1000) se establece en exactamente el mismo orden que el puerto de cliente. No hay ningún paso en el protocolo para distinguir cliente de par — los roles se diferencian únicamente por el puerto.
- Conexión TCP — el lado que llama (dial) es siempre el solicitante
- Handshake TLS, si el servidor tiene TLS activado
- Un protocolo de autenticación — la especificación (challenge, digest, respuesta) es idéntica byte a byte a la del puerto de cliente
- Intercambio de RPC con prefijo de longitud a partir de entonces
Flujo
Nodo que llama (dial)
Nodo receptor
conexión TCP (puerto Raft = puerto de cliente + 1000)
handshake TLS, si el servidor tiene TLS activado
challenge (SHA-256 ␣ nonce)
digest — calculado con el primer token de cluster_tokens
se verifica contra toda la lista de cluster_tokens
a partir de aquí, RPC Raft con prefijo de longitud
solicitudrespuestaRPC de consenso (Raft)
En qué se diferencia del puerto de cliente
| Elemento | Puerto de cliente | Puerto Raft |
|---|---|---|
| Conjunto de tokens usado para verificar | client_tokens | cluster_tokens |
| Token enviado | el token que configuró el cliente | el primer token de cluster_tokens |
| Tras la autenticación | tramas terminadas en \n | RPC con prefijo de longitud |
- En el lado receptor, la verificación comprueba contra toda la lista de
cluster_tokens, así que puedes listar tokens antiguos y nuevos juntos y reiniciar los nodos uno a uno para rotar tokens sin tiempo de inactividad (Configuración (variables de entorno)). - Con TLS activado, el puerto Raft usa el mismo certificado. El lado que llama verifica el certificado del par contra
tls_ca(o el almacén de confianza del sistema si no está definido);tls_skip_verifyes solo para pruebas. - Si falla la autenticación, la conexión se cierra tras
E auth_failed— igual que en el puerto de cliente.