GhostNet

Публикация сервисов и настройка HTTPS в GhostNet

GhostNet позволяет не только объединять устройства, но и превращать их в полноценные узлы корпоративной сети с собственными именами (DNS) и защищенными веб-сервисами (HTTPS). Этот документ описывает путь от локальной службы до доверенного сайта в зоне .ghost.

1. Фаза 1: Присвоение доменного имени (Alias)

Прежде чем публиковать сайт, узлу нужно присвоить человекочитаемое имя. В GhostNet это делается через систему Aliases.

  1. Зайдите в панель управления Lighthouse (через Админ-режим агента).
  2. Найдите нужный узел (например, 10.0.0.5) и нажмите INFO.
  3. В поле DNS Alias введите желаемое имя, например: wiki.ghost или portal.
  4. Нажмите SAVE.

Результат: Через 10–30 секунд (после обновления PeerList) все узлы сети смогут обращаться к этому агенту по имени wiki.ghost.

2. Фаза 2: Объявление службы в сети

Чтобы другие участники сети знали, какие порты открыты на вашем узле, их нужно "опубликовать".

  1. Запустите меню gna_agent на целевой машине.
  2. Выберите пункт "6. Опубликовать ресурс (сайт/сервис)".
  3. Нажмите "Добавить сервис".
  4. Введите параметры:
    • Название: Например, "Corporate Wiki".
    • Порт: Например, 80 (для HTTP) или 443 (для HTTPS).
    • Протокол: http, https, ssh и т.д.

Результат: Эта информация попадет в AgentReport и отобразится в веб-панели и на "Портале входа" (welcome.html) для других пользователей.

3. Фаза 3: Получение SSL-сертификата для сайта

Для того чтобы ваш сайт открывался по HTTPS без ошибок, он должен иметь сертификат, подписанный вашим Центром Сертификации (gna_ca_server).

Способ 1: Через Веб-панель (PKI Manager)

  1. Перейдите во вкладку PKI MANAGER в панели управления.
  2. В блоке Manual Certificate Issue заполните форму:
    • Common Name (CN): Введите ваш домен, например wiki.ghost.
    • Group (OU): Выберите Servers.
    • Validity: Укажите срок действия (например, 365 дней).
    • Is Admin: Оставьте флажок пустым (для обычного сайта права админа не нужны).
  3. Нажмите ISSUE & DOWNLOAD.

Обработка полученного JSON

Система выдаст вам ответ в формате JSON. Это сделано для удобства автоматизации. Пример ответа:

{
  "private_key_pem": "-----BEGIN PRIVATE KEY-----\nMIIEvAIBADANB...",
  "certificate_pem": "-----BEGIN CERTIFICATE-----\nMIIDdTCCAl2g...",
  "message": "OK",
  "success": true
}

Как превратить это в ключи для веб-сервера (Nginx/Apache/Docker):

  1. Вы должны сохранить содержимое полей в два отдельных файла:
  2. Значение private_key_pem -> в файл site.key (не забудьте заменить \n на реальные переносы строк).
  3. Значение certificate_pem -> в файл site.crt. Важно: Эти файлы используются вашим веб-сервером (например, Nginx) для настройки SSL-прослушивателя на порту 443.

4. Фаза 4: Установка доверия (Root CA)

Даже если ваш веб-сервер настроен правильно с полученными ключами, браузеры будут выдавать предупреждение "Ваше подключение не защищено". Это происходит потому, что ваш персональный Центр Сертификации не входит в стандартный список доверия Microsoft или Google.

Чтобы исправить это, нужно установить Root CA на все клиентские устройства.

Способ 1: Автоматически через gna_agent (Рекомендуется)

  1. Запустите gna_agent с правами администратора.
  2. Выберите пункт "10. Установить доверенный Root CA".
  3. Агент самостоятельно:
    • Скачает актуальный ca_cert.pem с Lighthouse.
    • В Windows: добавит его в "Доверенные корневые центры сертификации" через системную утилиту certutil.
    • В Linux: скопирует в /usr/local/share/ca-certificates/ и выполнит update-ca-certificates.

Способ 2: Вручную через браузер

  1. Скачайте файл корневого сертификата из панели управления Lighthouse (кнопка "Download Root CA").
  2. В браузере (Chrome/Firefox) зайдите в Настройки -> Безопасность -> Управление сертификатами.
  3. Импортируйте скачанный файл в список "Доверенные корневые центры".

5. Практический пример: Настройка HTTPS для Lighthouse

Если вы хотите, чтобы сама панель управления GhostNet открывалась по адресу https://base:9000 без ошибок доверия, выполните следующие шаги:

  1. Выпустите сертификат для Common Name: base (или того имени, которое вы дали узлу 10.0.0.1) в панели PKI Manager.
  2. Скопируйте JSON ответа.
  3. Извлеките ключи:
    • Содержимое private_key_pem сохраните в файл web_key.pem в папку с gna_lighthouse.
    • Содержимое certificate_pem сохраните в файл web_cert.pem в ту же папку.
  4. Перезапустите Lighthouse.
    • При запуске Lighthouse проверит наличие этих файлов. Если они есть, он активирует HTTPS-сервер на порту 9000.
    • В логах появится запись: [INFO] TLS keys found. HTTPS panel enabled.

6. Технические нюансы и безопасность

6.1. Почему используется JSON?

Мы намеренно возвращаем ключи в формате JSON, а не просто скачиваемым файлом. Это позволяет администраторам писать простые скрипты на Python или Bash для автоматического обновления сертификатов на десятках серверов.

Например, короткий скрипт может распарсить этот JSON и автоматически разложить ключи по папкам Nginx:

# Пример концепции автоматизации
cat cert_response.json | jq -r .certificate_pem > /etc/nginx/ssl/site.crt

cat cert_response.json | jq -r .private_key_pem > /etc/nginx/ssl/site.key

systemctl reload nginx

6.2. Соответствие имен

Критически важно: имя, которое вы вводите в поле Common Name (CN) при выпуске сертификата, должно символ в символ совпадать с именем (Alias), по которому вы заходите на сайт.

  • Если сертификат выписан на wiki.ghost, а вы заходите по 10.0.0.5 — браузер покажет ошибку ERR_CERT_COMMON_NAME_INVALID.
  • Всегда используйте доменные имена .ghost.

6.3. Безопасность приватных ключей

Помните, что gna_ca_server не хранит копии ваших приватных ключей после их выдачи.

⚠️ Важно: Если вы закрыли окно с JSON-ответом, не сохранив private_key_pem, восстановить его невозможно. Вам придется выпускать сертификат заново.

7. Устранение неполадок

Сайт открывается по IP, но не по имени

Проверьте следующие пункты:

  1. В панели Lighthouse у узла прописан правильный Alias.
  2. Прошло более 30 секунд с момента добавления записи (время кэширования и обновления конфигурации).
  3. На клиенте выполнен сброс DNS-кэша: 
    ipconfig /flushdns

Браузер всё равно ругается на сертификат

  1. Проверьте дату на компьютере. Если системное время сбито, сертификат будет считаться недействительным (не вступившим в силу или просроченным).
  2. Проверьте корневой сертификат. Убедитесь, что вы установили Root CA именно того сервера, который выписал этот сертификат. Это особенно актуально при пересоздании Root CA.

Порт занят

Если вы публикуете сервис на стандартном порту (например, 80 или 443), убедитесь, что на этой машине не запущен другой веб-сервер (Apache, Nginx, IIS), который уже занял этот порт.

Эта документация дает пользователю четкое понимание того, как работает связка "Имя -> Публикация -> Шифрование -> Доверие".