Когда Vault перестаёт отвечать, первое, что стоит проверить, — статус самого сервера командой vault status: если она возвращает ошибку соединения или показывает Sealed: true, причина уже наполовину локализована. Именно запечатанное состояние хранилища и сбой подключения к API — две самые частые причины, по которым администраторы считают, что Vault «не работает», хотя сам процесс при этом может быть жив.
Проблема с запуском или доступом к HashiCorp Vault почти всегда оставляет следы в логах сервиса и в выводе диагностических команд. Ниже разобраны типичные сценарии: сервер не стартует, хранилище запечатано после перезагрузки, клиент не может подключиться, TLS-сертификат отклонён, токен просрочен. Для каждого случая приведены безопасные проверки, которые не требуют вмешательства в данные.
Проверка состояния сервера Vault
Начните с базовой диагностики. Выполните на машине, где развёрнут сервер:
vault statusКоманда покажет, инициализировано ли хранилище, запечатано ли оно и какая версия запущена. Если в ответ приходит ошибка вида Error checking seal status или отказ в соединении, значит, либо процесс Vault не запущен, либо клиент обращается не по тому адресу.
Проверьте, слушает ли сервер нужный порт и переменную окружения VAULT_ADDR. Частая ситуация: сервер работает на https://, а клиент настроен на http:// (или наоборот), из-за чего любая команда завершается ошибкой. Сверьте адрес с секцией listener в конфигурационном файле сервера.
- 🔍 Убедитесь, что процесс Vault запущен:
systemctl status vaultили аналог для вашей системы. - 🌐 Сверьте
VAULT_ADDRс параметромaddressв блокеlistenerконфигурации. - 📄 Посмотрите журнал сервиса — в нём почти всегда есть строка с конкретной причиной остановки.
- 🔁 Попробуйте выполнить
vault statusс флагом-address, явно указав адрес сервера.
Хранилище запечатано: почему это происходит
Vault при каждом старте находится в состоянии sealed — это штатное поведение, а не поломка. Данные хранилища зашифрованы, и пока не выполнена процедура unseal, сервер не обслуживает запросы к секретам. Если после перезагрузки сервера Vault «не работает», скорее всего, его просто никто не распечатал.
Для распечатывания нужны ключи unseal, которые были выданы при инициализации. Команда выглядит так:
vault operator unsealПри стандартной схеме Shamir команду потребуется выполнить несколько раз с разными ключами — количество зависит от порога, заданного при инициализации. Если используется auto-unseal через облачный KMS или HSM, а распечатывание не происходит автоматически, проверьте доступность внешнего сервиса ключей и права доступа к нему — сбой именно там блокирует весь запуск.
⚠️ Внимание: ключи unseal и root-токен нельзя хранить на том же сервере, где работает Vault. Если ключи утеряны, восстановить доступ к данным без них невозможно — это принципиальное свойство архитектуры, а не ограничение конкретной версии.
Сервер не стартует: типичные причины
Если процесс Vault падает сразу после запуска, причина обычно записана в журнале службы. Откройте его командой journalctl -u vault (для systemd) или в файле лога, если он задан в конфигурации.
Наиболее распространённые источники проблемы:
- ⚙️ Ошибка синтаксиса в конфигурационном файле — лишняя скобка, неверный отступ или опечатка в имени параметра. Проверить файл заранее можно командой
vault server -config=...в тестовом режиме либо валидацией HCL. - 📁 Недоступность бэкенда хранения: если используется файловое хранилище, проверьте права на каталог; если Consul или база данных — доступность соответствующего сервиса.
- 🔐 Проблемы с TLS: сервер не стартует, если пути к сертификату или ключу в блоке
listenerуказаны неверно или файлы недоступны для чтения. - 🚪 Порт уже занят другим процессом — проверьте, не слушает ли адрес другое приложение.
Меняйте конфигурацию по одному параметру за раз и перезапускайте сервис после каждого изменения — так проще понять, какая правка вызвала сбой.
☑️ Чек-лист перед перезапуском Vault
Клиент не подключается к API
Отдельный класс проблем — сервер работает и распечатан, но команды с рабочей машины не проходят. Здесь виновником чаще всего оказывается сеть или аутентификация, а не сам Vault.
Проверьте доступность API простым HTTP-запросом к эндпоинту здоровья, например через curl к /v1/sys/health. Если соединение отклоняется — смотрите файрвол, группы безопасности и адрес прослушивания: Vault, слушающий только 127.0.0.1, недоступен с других машин, и это корректное поведение.
Если соединение устанавливается, но команды возвращают permission denied, дело в токене: он мог истечь, быть отозван или не иметь нужных политик. Выполните vault token lookup, чтобы увидеть срок действия и привязанные политики текущего токена. При необходимости пройдите аутентификацию заново через используемый auth-метод.
Ошибки TLS и сертификатов
Сообщения вида x509: certificate signed by unknown authority или certificate has expired означают, что клиент не доверяет сертификату сервера. Возможные причины: самоподписанный сертификат не добавлен в доверенные, сертификат просрочен, либо имя хоста в адресе не совпадает с именем в сертификате.
Что можно сделать безопасно:
- Проверьте срок действия сертификата, указанного в конфигурации сервера.
- Убедитесь, что клиенту доступен корневой CA: путь к нему можно передать через переменную окружения
VAULT_CACERT. - Сверьте имя хоста в
VAULT_ADDRс полем Subject Alternative Name сертификата.
Флаг -tls-skip-verify подходит только для временной диагностики. Постоянная работа с отключённой проверкой сертификата снимает защиту от подмены сервера, поэтому в продуктивной среде так делать не следует.
⚠️ Внимание: при перевыпуске сертификатов для Vault обновите их на всех репликах кластера и перезапустите сервисы по очереди. Одновременная остановка всех узлов приведёт к полной недоступности хранилища и необходимости заново выполнять unseal.
Сравнение типичных симптомов и причин
Таблица ниже помогает быстро сопоставить наблюдаемый симптом с наиболее вероятной причиной и первым шагом диагностики.
| Симптом | Вероятная причина | Первая проверка |
|---|---|---|
vault status показывает Sealed: true | Хранилище не распечатано после рестарта | Выполнить vault operator unseal |
| Connection refused при любом запросе | Процесс остановлен или слушает другой адрес | Статус службы и секция listener |
| Ошибка x509 при подключении | Клиент не доверяет сертификату сервера | Проверить VAULT_CACERT и срок сертификата |
| Permission denied на все операции | Токен истёк или отозван | vault token lookup, повторный логин |
| Сервис падает сразу после старта | Ошибка конфигурации или недоступен бэкенд хранения | Журнал службы, валидация конфига |
Что делать, если утеряны ключи unseal
Без порогового количества ключей unseal расшифровать хранилище невозможно — это заложено в модель безопасности Vault. Если ключи утеряны, но есть актуальный снапшот бэкенда и работающая копия кластера, можно развернуть новый кластер и восстановить данные из резервной копии с последующей реинициализацией. На будущее: распределите ключи между несколькими ответственными лицами или настройте auto-unseal через доверенный KMS.
Когда стандартные проверки не помогают
Если сервер запущен, распечатан, TLS в порядке, а часть функций всё равно не работает — смотрите глубже: включённые auth-методы и секреты-движки (vault auth list, vault secrets list), политики доступа и журналы аудита, если они настроены. Ошибка может крыться в конкретном плагине или в интеграции, например в недоступности внешней базы данных для динамических секретов.
Перед любыми необратимыми действиями — переинициализацией, сменой бэкенда хранения, отзывом токенов — убедитесь, что у вас есть резервная копия данных и понимание последствий. Для кластерных развёртываний сверяйтесь с официальной документацией HashiCorp Vault под вашу версию: поведение команд и параметров может отличаться между релизами.
Часто задаваемые вопросы
Почему Vault после перезагрузки сервера снова запечатан?
Это штатное поведение: при каждом старте Vault требует процедуры unseal. Чтобы не выполнять её вручную, можно настроить auto-unseal через облачный KMS, HSM или доверенный сервис — если ваша конфигурация это поддерживает.
Команда vault status выдаёт ошибку соединения, хотя сервис запущен. Что проверить?
Сверьте переменную VAULT_ADDR с адресом и схемой (http/https) из секции listener конфигурации. Также убедитесь, что сервер слушает не только loopback-интерфейс, если вы подключаетесь с другой машины.
Можно ли восстановить доступ, если потеряны все ключи unseal?
Нет, без порогового набора ключей расшифровать данные невозможно — это принципиальное свойство модели безопасности. Выход — развёртывание нового кластера и восстановление из резервных копий, если они есть.
Безопасно ли использовать -tls-skip-verify для постоянной работы?
Нет. Этот флаг отключает проверку подлинности сервера и годится только для временной диагностики. Для постоянной работы настройте доверие к CA через VAULT_CACERT или системное хранилище сертификатов.
Vault отвечает permission denied, хотя раньше всё работало. В чём дело?
Чаще всего истёк срок действия токена или изменились политики. Выполните vault token lookup для проверки состояния токена и пройдите аутентификацию заново через ваш auth-метод.