Установление соединения · аутентификация
Соединение между пирами (Raft-порт = клиентский порт + 1000) устанавливается в точности в том же порядке, что и на клиентском порту. В самом протоколе нет процедуры различения клиента и пира — роль определяется только портом.
- TCP-подключение — инициатором всегда является вызывающая (dial) сторона
- Если на сервере включён TLS — TLS-хендшейк
- Аутентификационный хендшейк — один раз; спецификация (challenge · digest · ответ) байт в байт совпадает с клиентским портом
- Далее — обмен RPC с префиксом длины
Поток
Вызывающий узел (dial)
Принимающий узел
TCP-подключение (Raft-порт = клиентский + 1000)
если на сервере включён TLS — TLS-хендшейк
challenge (SHA-256 ␣ nonce)
digest — вычислен по первому токену из cluster_tokens
проверка идёт по всему списку cluster_tokens
далее — обмен RPC Raft с префиксом длины
запросответRPC консенсуса (Raft)
Отличия от клиентского порта
| Параметр | Клиентский порт | Raft-порт |
|---|---|---|
| Набор токенов для проверки | client_tokens | cluster_tokens |
| Токен отправляющей стороны | токен, заданный клиентом | первый токен из cluster_tokens |
| После аутентификации | кадры, завершаемые \n | RPC с префиксом длины |
- При приёме проверка идёт по всему списку
cluster_tokens, поэтому, перечислив старый и новый токен вместе и выполнив последовательный перезапуск узлов, токен можно заменить без простоя (Конфигурация (переменные окружения)). - Если включён TLS, Raft-порт использует тот же сертификат. Вызывающая сторона проверяет сертификат собеседника через
tls_ca(или системное хранилище доверия, если он не задан), аtls_skip_verifyпредназначен только для тестов. - При ошибке аутентификации соединение закрывается после
E auth_failed— так же, как и на клиентском порту.