Публикация по HTTPS

Сервис слушает только 127.0.0.1 и наружу сам не публикуется. TLS терминирует ваш обратный прокси.

Порт зависит от способа установки: 8443 у Docker-поставки, 8080 у пакета deb/rpm. Проверить: ss -ltnp | grep tetra (или docker compose ps).

Конфигурация nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;
    server_name tetra.example.local;

    ssl_certificate     /etc/ssl/certs/tetra.crt;
    ssl_certificate_key /etc/ssl/private/tetra.key;

    # Событие может содержать объёмный фрагмент текста, перехваченный у сотрудника.
    client_max_body_size 10m;

    location / {
        proxy_pass http://127.0.0.1:8443;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 120s;
    }
}

server {
    listen 80;
    listen [::]:80;
    server_name tetra.example.local;
    return 301 https://$host$request_uri;
}

X-Real-IP обязателен

Без него в каждом событии будет зафиксирован адрес прокси вместо адреса рабочей станции сотрудника — расследовать инциденты будет нечем.

Отдельная аутентификация на прокси не нужна

В панели есть собственный вход по логину и паролю. Basic-auth на nginx поверх него сломает работу сенсоров: они обращаются к тому же адресу и предъявляют свой токен, а не пароль оператора.

Какие адреса должны быть доступны

Путь	Кто обращается	Аутентификация
/ и остальная панель	операторы в браузере	вход по логину
/events	сенсоры на рабочих станциях	токен сенсоров
/sensor/updates.xml, /sensor/tetra-sensor.crx	Chrome при проверке обновлений расширения	без аутентификации

Последние два адреса открыты сознательно: при проверке обновлений расширения Chrome не отправляет ни cookie, ни токены, а неудачное обновление проходит молча — парк просто перестал бы получать новые версии. Секретов в пакете нет: он подписан ключом, который лежит только в вашей базе и только в зашифрованном виде, а адрес сервера и токен сенсоров приходят из вашей же managed-политики. Не закрывайте их basic-auth и не ограничивайте по IP так, чтобы рабочие станции их не видели.

Внешний адрес и адрес в политике

Если сотрудники обращаются к серверу по другому имени, чем вы открываете панель (внешний DNS против внутреннего или VPN-адреса), поправьте поле «Адрес сервера» в Настройки → Развёртывание расширения — именно оно попадает в блок политики для рабочих станций.