# Настройка файрвола на GPU-сервере > Настройка файрвола на GPU-сервере с ufw: сначала разрешите SSH, фильтруйте IPv6, обойдите ловушку с портами Docker и защитите эндпоинт vLLM с TLS и API-ключом. Источник: https://fullgpu.com/ru/docs/networking-firewall Обновлено: 2026-10-22 Издатель: FullGPU (https://fullgpu.com/) У настройки файрвола на 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-доступу](https://fullgpu.com/ru/docs/ssh-access). ## Не забудьте про 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](https://fullgpu.com/ru/docs/pytorch-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 ``` Подставьте подсеть или интерфейс своей частной сети. Как её запросить, описано на странице [о частной сети](https://fullgpu.com/ru/products/private-networking). ## Защита от DDoS включена На всех публичных IP-адресах ваших серверов работает защита от DDoS, включённая в цену. Она отражает атаки сетевого уровня, но не заменяет файрвол, TLS, аутентификацию и ограничение частоты запросов в ваших собственных сервисах. Если вы заметили необычный трафик или думаете, что ваш сервер атакуют, [создайте тикет в поддержку](https://fullgpu.com/ru/help/getting-support) через личный кабинет. Подробнее — на странице [о защите от DDoS](https://fullgpu.com/ru/products/ddos-protection). ## Устранение неполадок - **Нет доступа после включения ufw.** Не пытайтесь подключиться снова и снова. Создайте тикет в личном кабинете (для этого SSH не нужен), указав сервер и добавленные правила; см. раздел [о работе с тикетами](https://fullgpu.com/ru/help/getting-support). - **Caddy или certbot не может получить сертификат.** Проверьте, что DNS-имя указывает на сервер, что порты 80 и 443 разрешены в ufw и что их не слушает другой процесс (`sudo ss -tlnp`). - **Порт контейнера доступен, несмотря на ufw.** Он опубликован на всех интерфейсах. Пересоздайте контейнер с `-p 127.0.0.1:PORT:PORT`. ## Связанные страницы - [Защита GPU-серверов от DDoS: включена на каждом публичном IP](https://fullgpu.com/ru/products/ddos-protection): Защита GPU-сервера от DDoS всегда включена на каждом публичном IP, без доплаты. Узнайте, что она покрывает, а что нет, и как укрепить защиту API инференса. - [Частная сеть между GPU-серверами](https://fullgpu.com/ru/products/private-networking): Частная сеть между GPU-серверами по запросу: объедините свои серверы FullGPU в изолированную сеть для конвейеров данных и многоузловых задач. Как это работает. - [Инференс LLM на vLLM](https://fullgpu.com/ru/docs/pytorch-vllm): Инференс LLM с vLLM на вашем GPU-сервере: настройте Python через uv, установите PyTorch и vLLM, проверьте OpenAI-совместимый API и запустите его как службу. - [Подключение к GPU-серверу по SSH](https://fullgpu.com/ru/docs/ssh-access): Как подключиться к GPU-серверу по SSH: создайте ключ ed25519 (macOS, Linux, Windows), подключитесь, добавьте коллег и отключите вход по паролю. Готовые команды.