Настройка файрвола на GPU-сервере

У настройки файрвола на GPU-сервере одна цель: должны быть доступны только те порты, которые вы намеренно открыли. У каждого сервера FullGPU есть публичный IPv4-адрес и подсеть IPv6 /64, поэтому всё, что слушает все интерфейсы, доступно извне, если вы это не отфильтруете. На этой странице мы настроим ufw, объясним, как Docker его обходит, а затем покажем, как защитить эндпоинт vLLM с помощью обратного прокси, TLS и API-ключа.

Настройка ufw: сначала разрешите SSH

Разрешите SSH до включения файрвола, иначе потеряете доступ к серверу:

sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verbose

Ответьте y, когда ufw предупредит, что команда может прервать SSH-соединения. Вы увидите Status: active, политики по умолчанию и правило, разрешающее 22/tcp (OpenSSH) для IPv4 и IPv6. Не закрывайте текущую сессию и проверьте новое SSH-подключение из второго терминала.

Если у вас постоянный адрес офиса или VPN, можно разрешить SSH только с него. Добавьте новое правило, прежде чем удалять старое:

sudo ufw allow from 198.51.100.7 to any port 22 proto tcp
sudo ufw delete allow OpenSSH

Более мягкий вариант — sudo ufw limit OpenSSH: так ufw ограничивает частоту повторных подключений с одного адреса. Но важнее любого из этих вариантов вход только по ключу, описанный в руководстве по SSH-доступу.

Не забудьте про IPv6

grep IPV6 /etc/default/ufw
sudo ss -tulpn

ufw фильтрует IPv6, если в /etc/default/ufw указано IPV6=yes, — это значение по умолчанию в Ubuntu. При IPV6=no ufw оставляет IPv6 без фильтрации, и сервисы, которые слушают [::], остаются доступными через вашу подсеть /64. Задайте yes, выполните sudo ufw disable && sudo ufw enable и добавьте свои правила заново, чтобы у них появились копии для IPv6. ss -tulpn выводит все прослушивающие сокеты вместе с процессами: всё, что привязано к 0.0.0.0, * или [::], слушает все интерфейсы. Убедитесь, что это действительно нужно и что файрвол такой сервис охватывает, или привяжите его к 127.0.0.1.

Docker обходит ufw для опубликованных портов

Docker управляет собственными правилами iptables. Когда вы публикуете порт с помощью -p 8000:8000, Docker направляет этот трафик в контейнер по своим правилам, и он вообще не проходит через правила ufw, которые защищают хост. Порт открыт в интернет даже при default deny incoming — на этом попадаются многие конфигурации с vLLM, Jupyter и мониторингом.

1. Публикуйте порт только на loopback-интерфейсе: -p 127.0.0.1:8000:8000 или "127.0.0.1:8000:8000" в Compose.
2. Проверьте привязку командой sudo ss -tlnp | grep 8000. В выводе должно быть 127.0.0.1:8000.
3. С вашего ноутбука команда curl http://203.0.113.10:8000/v1/models (с IP-адресом вашего сервера) не должна устанавливать соединение.
4. Открывайте доступ к сервису через обратный прокси на хосте — его трафик ufw как раз фильтрует.

Чтобы по умолчанию все опубликованные порты привязывались к loopback, добавьте "ip": "127.0.0.1" в /etc/docker/daemon.json, сохранив существующие записи, например среду выполнения NVIDIA, и перезапустите Docker. Для более тонкой настройки есть цепочка iptables DOCKER-USER: Docker проверяет её раньше собственных правил.

Обратный прокси с TLS перед сервисом

Направьте DNS-имя (здесь llm.example.com) на адреса вашего сервера, откройте веб-порты и выберите Caddy или nginx. Обе конфигурации ниже открывают доступ только к путям API /v1/.

sudo ufw allow 80,443/tcp

Caddy

Caddy автоматически получает и продлевает сертификаты. Он есть в репозиториях Ubuntu 24.04 (sudo apt install -y caddy); в 22.04 установите его из собственного репозитория Caddy. Замените содержимое /etc/caddy/Caddyfile на следующее:

llm.example.com {
    handle /v1/* {
        reverse_proxy 127.0.0.1:8000
    }
    handle {
        respond 404
    }
}

Примените конфигурацию командой sudo systemctl reload caddy. Когда сертификат будет выпущен, https://llm.example.com/v1/models начнёт отвечать по HTTPS.

nginx

sudo apt install -y nginx certbot python3-certbot-nginx

Создайте /etc/nginx/sites-available/llm:

server {
    listen 80;
    server_name llm.example.com;

    location /v1/ {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }

    location / {
        return 404;
    }
}

Включите сайт, затем запросите сертификат. certbot добавит конфигурацию HTTPS и настроит продление:

sudo ln -s /etc/nginx/sites-available/llm /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d llm.example.com

proxy_buffering off позволяет потоковым токенам доходить до клиентов по мере генерации, а увеличенный тайм-аут рассчитан на долгую генерацию.

Обязательный API-ключ на OpenAI-совместимых серверах

TLS защищает трафик при передаче, а API-ключ определяет, кто может пользоваться моделью. vLLM требует bearer-токен, если запустить его с --api-key или задать VLLM_API_KEY:

openssl rand -hex 32    # generate a key
vllm serve Qwen/Qwen2.5-7B-Instruct --host 127.0.0.1 --port 8000 \
  --api-key YOUR_KEY

Проверьте со своего ноутбука:

curl https://llm.example.com/v1/models -H "Authorization: Bearer YOUR_KEY"
curl -i https://llm.example.com/v1/models

Первая команда должна вывести модель, а вторая — вернуть статус 401. vLLM применяет ключ к маршрутам /v1, а другие маршруты, например /metrics, могут оставаться открытыми — поэтому прокси больше ничего и не открывает. Лучше используйте переменную окружения, как в настройке systemd из руководства по инференсу LLM (большой языковой модели) на vLLM: ключ, введённый в командной строке, виден другим локальным пользователям в списке процессов. У других OpenAI-совместимых серверов есть похожие параметры.

Частная сеть между вашими серверами

По запросу мы объединяем ваши серверы частной сетью. Используйте её для трафика между ними: синхронизации данных, NCCL и rendezvous в torchrun, внутренних API и метрик. Разрешите этот трафик в ufw по подсети или по интерфейсу (найти его можно с помощью ip -br addr):

sudo ufw allow from 10.0.0.0/24
# or
sudo ufw allow in on PRIVATE_INTERFACE

Подставьте подсеть или интерфейс своей частной сети. Как её запросить, описано на странице о частной сети.

Защита от DDoS включена

На всех публичных IP-адресах ваших серверов работает защита от DDoS, включённая в цену. Она отражает атаки сетевого уровня, но не заменяет файрвол, TLS, аутентификацию и ограничение частоты запросов в ваших собственных сервисах. Если вы заметили необычный трафик или думаете, что ваш сервер атакуют, создайте тикет в поддержку через личный кабинет. Подробнее — на странице о защите от DDoS.

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

• Нет доступа после включения ufw. Не пытайтесь подключиться снова и снова. Создайте тикет в личном кабинете (для этого SSH не нужен), указав сервер и добавленные правила; см. раздел о работе с тикетами.
• Caddy или certbot не может получить сертификат. Проверьте, что DNS-имя указывает на сервер, что порты 80 и 443 разрешены в ufw и что их не слушает другой процесс (sudo ss -tlnp).
• Порт контейнера доступен, несмотря на ufw. Он опубликован на всех интерфейсах. Пересоздайте контейнер с -p 127.0.0.1:PORT:PORT.