gbox в Docker: настройка контейнера CCcam/OScam 2026

Если вы дошли до того, что решили упаковать gbox в контейнер — скорее всего, уже наступили на пару граблей с зависимостями и ручными обновлениями. Хорошая новость: gbox Docker контейнер: настройка решаемая задача, хотя и с несколькими нетривиальными моментами, которые нигде нормально не объяснены. Главный из них — gbox работает по UDP, и большинство проблем с «не подключается» решается именно там.

Что такое gbox и зачем запускать его в Docker

Особенности протокола gbox и UDP-обмен

gbox — это peer-to-peer протокол обмена картами, и он принципиально отличается от CCcam или newcamd. Там клиент-серверная модель, здесь — сеть узлов, которые напрямую обмениваются ECM-запросами между собой. Весь трафик идёт по UDP, что важно понимать с самого начала.

Каждый узел gbox слушает один UDP-порт (чаще всего в диапазоне 8000–9000, типичный пример — 8888) и через него же отправляет ответы пирам. Никакого TCP здесь нет. Это не упрощение — это архитектурное решение протокола, и обойти его нельзя.

Преимущества контейнеризации для шаринг-сервера

Docker решает классическую проблему: «на моей машине работало». Вы один раз собираете образ с нужными зависимостями, и он запускается одинаково хоть на Debian 11, хоть на Ubuntu 22.04. Обновить gbox — пересобрать образ и перезапустить контейнер. Откатиться — поднять предыдущий тег образа.

Плюс изоляция. gbox не конфликтует с другими сервисами на том же хосте, а конфиги лежат в отдельном volume и не смешиваются с системными файлами. Для сервера, где крутится несколько шаринг-демонов одновременно, это реально удобно.

Когда Docker оправдан, а когда избыточен

Если у вас роутер с OpenWrt или слабый ARM-бокс с 256 МБ RAM — контейнер будет лишней нагрузкой. Оверхед Docker здесь ощутим. Контейнеризация имеет смысл на x86-сервере или VPS с нормальным объёмом памяти, где вы управляете несколькими сервисами одновременно.

На мощном железе — однозначно да. На роутере — нативный запуск проще и быстрее.

Подготовка образа и Dockerfile для gbox

Выбор базового образа (debian:slim, alpine)

Здесь есть важный момент, который стоит сразу прояснить. Alpine Linux использует musl libc вместо glibc, и бинарники gbox, собранные под glibc, на alpine просто не запустятся — получите segmentation fault или ошибку вида «not found» при попытке exec. Это не баг конфигурации, это несовместимость рантайма.

Берите debian:bookworm-slim или debian:bullseye-slim. Образ весит около 80 МБ, этого достаточно. Alpine выглядит привлекательно из-за минималистичного размера, но для gbox он просто не работает.

Установка зависимостей и сборка бинарника

Сам бинарник gbox динамически слинкован против glibc и libpthread. На debian-slim они уже есть. Дополнительно может понадобиться libssl1.1 или openssl в зависимости от версии gbox. Проверить зависимости конкретного бинарника можно командой ldd ./gbox — выполните её до сборки образа, чтобы знать, что именно устанавливать.

Структура каталогов внутри контейнера

Стандартное расположение конфигов gbox — /var/keys/. Там лежат gbox.cfg, SoftCam.Key, файл пиров peer.info и логи. Некоторые сборки используют /usr/local/etc/gbox/ — смотрите документацию к конкретной версии бинарника. Рабочую директорию в контейнере лучше явно указывать через WORKDIR.

Пример Dockerfile с комментариями

FROM debian:bookworm-slim

# Минимальный набор: glibc уже есть, добавляем только то, что нужно
RUN apt-get update && apt-get install -y --no-install-recommends \
    libssl3 \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*

# Рабочая директория — здесь gbox будет искать конфиги
WORKDIR /var/keys

# Копируем бинарник из локального контекста сборки
COPY gbox /usr/local/bin/gbox
RUN chmod +x /usr/local/bin/gbox

# Конфиги монтируются снаружи через volume, не копируем их в образ
# COPY gbox.cfg .   ← не делаем так, конфиги должны быть на хосте

# UDP-порт — замените 8888 на свой
EXPOSE 8888/udp

ENTRYPOINT ["/usr/local/bin/gbox"]

Ключевой момент: конфиги в образ не копируем. Они должны монтироваться с хоста, иначе при пересборке образа потеряете все настройки и peer-лист.

Проброс портов и сетевая конфигурация

Почему gbox требует UDP, а не TCP

Это самая частая причина, по которой gbox «не работает в Docker». Люди прописывают -p 8888:8888 и удивляются, что пиры не подключаются. Без явного указания /udp Docker маппит только TCP. UDP-пакеты до контейнера не доходят.

Протокол gbox использует UDP на уровне дизайна — для быстрого peer-to-peer обмена без overhead TCP-соединения. Менять это нельзя, это не опция в конфиге.

Маппинг порта: -p 8888:8888/udp

Правильная команда запуска выглядит так:

docker run -d \
  --name gbox \
  -p 8888:8888/udp \
  -v /opt/gbox:/var/keys \
  gbox-image:latest

Если у вас нестандартный порт в gbox.cfg — маппите именно его. Порт внутри контейнера должен совпадать с тем, что слушает демон. Хостовый порт (левая часть) можете менять, но тогда пиры должны подключаться именно к нему.

Режим host network против bridge

С network_mode: host контейнер видит сетевые интерфейсы хоста напрямую. UDP-трафик приходит без дополнительного NAT внутри Docker. Это проще и надёжнее для gbox, особенно когда у вас несколько пиров с разными IP.

Но host network убивает изоляцию — контейнер делит сетевое пространство с хостом, и конфликты портов становятся вашей проблемой. Если на хосте уже что-то слушает порт 8888, контейнер не запустится. Для bridge-режима нужен аккуратный маппинг и понимание, что внешние пиры будут видеть IP хоста, а не контейнера — это обычно и нужно.

Открытие порта на firewall и роутере (port forwarding)

Docker открывает порт на хосте, но если между интернетом и хостом стоит firewall или NAT-роутер — этого недостаточно. На роутере нужно настроить port forwarding: внешний UDP 8888 → внутренний IP хоста, UDP 8888. На firewall хоста — разрешить входящий UDP на этот порт.

Для iptables это выглядит так: iptables -A INPUT -p udp --dport 8888 -j ACCEPT. Для ufw: ufw allow 8888/udp.

Монтирование конфигов и хранение данных

Volume для gbox.cfg и SoftCam.Key

Это критично. Если хранить конфиги внутри слоя образа, при каждом docker pull или пересборке они сбрасываются. Единственный правильный способ — volume с хоста.

Создаёте на хосте директорию, например /opt/gbox/keys/, кладёте туда gbox.cfg, SoftCam.Key и монтируете её в /var/keys контейнера. Всё, что gbox пишет в рабочую директорию (логи, peer-лист, временные файлы), теперь сохраняется на хосте.

Сохранение peer-листа между перезапусками

gbox хранит список активных пиров в файле peer.info или похожем (зависит от версии). Без volume этот файл пропадает при остановке контейнера, и при следующем старте демон начинает с нуля — заново устанавливает соединения, что занимает время. С volume файл сохраняется, и переподключение происходит быстрее.

Права доступа и владелец файлов

Частая проблема: контейнер запускается от пользователя с UID, отличным от владельца смонтированных файлов. gbox не может прочитать SoftCam.Key — и молчит об этом, просто не отвечает на ECM-запросы.

Проверяйте права: ls -la /opt/gbox/keys/. Если gbox в контейнере работает от root (UID 0) — проблем нет. Если от другого пользователя — chown -R UID:GID /opt/gbox/keys/ на хосте, где UID совпадает с пользователем внутри контейнера.

Пример docker-compose.yml

version: '3.8'

services:
  gbox:
    image: gbox-image:latest
    container_name: gbox
    restart: unless-stopped
    ports:
      - "8888:8888/udp"
    volumes:
      - /opt/gbox/keys:/var/keys
    environment:
      - TZ=Europe/Moscow
    # Раскомментировать для host network (убрать ports: выше):
    # network_mode: host

Переменная TZ важна — gbox чувствителен к системному времени. Если хост и контейнер живут в разных таймзонах, могут появиться странные ошибки при обмене ECM. Устанавливайте таймзону явно.

Интеграция gbox с OScam в одном стеке

Связка gbox-ридера в oscam.server

OScam умеет работать с gbox как клиент, используя встроенный reader с протоколом gbox. В файле /etc/oscam/oscam.server добавляете секцию:

[reader]
label                = gbox_peer
protocol             = gbox
device               = gbox:8888
user                 = oscam
password             = oscam
group                = 1
caid                 = 0500,1800,0604

Здесь gbox — имя сервиса в docker-compose сети. OScam резолвит его как внутренний DNS-адрес контейнера. Никаких IP прописывать не нужно — Docker Compose создаёт общую сеть и раздаёт имена сервисов как hostname.

Сетевое взаимодействие между контейнерами

По умолчанию все сервисы в одном docker-compose.yml попадают в общую bridge-сеть. Контейнер oscam может обратиться к контейнеру gbox по имени gbox — и наоборот. Это работает прозрачно без дополнительной конфигурации.

Если контейнеры запускаются отдельными docker run командами — создайте общую сеть вручную: docker network create sharing-net и добавляйте к ней контейнеры через --network sharing-net.

Настройка newcamd/cs378x для локального обмена

Если OScam стоит как сервер, а gbox как клиент — можно использовать cs378x или newcamd для передачи ключей от OScam обратно в gbox. В oscam.conf включите нужный протокол:

[cs378x]
port                 = 12000@0500:000000

А в gbox.cfg пропишите OScam как локальный кардсервер. Оба контейнера общаются по внутренней Docker-сети, внешние порты для этого взаимодействия открывать не нужно.

Диагностика и устранение типовых ошибок

Пиры не подключаются: проверка UDP и NAT

Первым делом проверяйте, доходит ли UDP вообще до контейнера. На хосте запускаете: tcpdump -i any udp port 8888 -n и просите пира попробовать подключиться. Если пакеты не появляются — проблема до хоста: либо роутер не пробрасывает порт, либо firewall блокирует.

Отдельная история — CGNAT. Если провайдер выдаёт серый IP (часто это диапазоны 100.64.0.0/10 или 10.0.0.0/8), входящий UDP физически недоступен снаружи. Тут не поможет ни Docker, ни проброс портов на роутере. Нужен VPN-туннель до узла с белым IP, или Wireguard, или аренда VPS с публичным адресом.

Контейнер падает при старте: логи и права

Смотрите логи сразу после запуска: docker logs -f gbox. Типичные причины краша при старте — отсутствие gbox.cfg в рабочей директории, неверные права на volume, или несовместимый бинарник (тот самый alpine/musl случай).

Если бинарник не запускается с ошибкой «Exec format error» — скорее всего, архитектура не совпадает. Бинарник arm, а хост x86, или наоборот.

Нет ECM-ответов: проверка SoftCam.Key и времени

gbox синхронизирует время с пирами и чувствителен к рассинхрону системных часов. Расхождение в несколько минут может привести к отказу в обмене ECM без каких-либо явных ошибок в логах. Проверяйте время на хосте: date и timedatectl. NTP должен работать.

Если SoftCam.Key лежит не там или контейнер не может его прочитать — gbox стартует, пиры подключаются, но декодирования нет. Проверяйте путь к файлу и права: docker exec gbox ls -la /var/keys/.

Команды диагностики: docker logs, tcpdump, netstat

Быстрый чеклист для диагностики:

• docker logs -f gbox — живые логи запуска и работы
• docker exec gbox netstat -ulnp — проверка, слушает ли gbox UDP-порт
• tcpdump -i any udp port 8888 -n — приходят ли пакеты на хост
• docker exec gbox ls -la /var/keys/ — наличие и права на конфиги
• docker inspect gbox | grep -A 20 NetworkSettings — IP контейнера и маппинг портов

Ещё один moment: если запускаете несколько шаринг-контейнеров в режиме network_mode: host на одном хосте — следите за конфликтами портов. Два демона не могут слушать один UDP-порт одновременно. Каждому контейнеру — свой порт в gbox.cfg.

В итоге gbox Docker контейнер: настройка сводится к трём вещам: правильный базовый образ с glibc, корректный маппинг UDP-порта, и volume для конфигов. Всё остальное — детали, которые вы разберёте через docker logs.