Настройка gbox в Docker-контейнере для CCcam/OScam

Если вы дошли до этой страницы, значит уже знаете, что gbox — не самый простой протокол для жизни за NAT. А gbox Docker контейнер: настройка — это отдельная история, потому что Docker добавляет ещё один сетевой слой поверх уже существующего. Я прошёл через это и собрал здесь всё, что реально работает в 2026 году.

Главная засада не в бинарнике и не в конфигах — она в сети. Большинство гайдов это замалчивают, и люди часами смотрят на "peer offline", не понимая почему.

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

gbox — это UDP-протокол обмена ключами между пирами. В отличие от CCcam или newcamd, он изначально проектировался под прямое P2P-соединение, поэтому очень чувствителен к тому, какой IP и hostname он сообщает партнёрам. Это и создаёт всю головную боль в контейнерной среде.

Особенности протокола gbox и отличие от CCcam/newcamd

CCcam работает по TCP и без проблем живёт за NAT через стандартный проброс порта. newcamd — тоже TCP, тоже терпим к NAT. gbox же использует UDP и при установке соединения сообщает пиру свой адрес напрямую. Если этот адрес окажется внутренним (172.17.0.x из docker0-интерфейса), пир просто не сможет достучаться обратно.

Порт по умолчанию обычно берут в диапазоне 8000–8100, но это настраивается. Важно: только UDP. Никакого TCP. Это значит, что все ваши привычные проверки через telnet или curl тут не помогут — нужен netcat в UDP-режиме.

Преимущества контейнеризации: изоляция, откат, повторяемость

Несмотря на сложность с сетью, смысл в Docker есть. Вы получаете воспроизводимую среду: собрал образ один раз — поднял на любом хосте. Откат при неудачном обновлении OScam — просто вернуться к предыдущему тегу. Никаких конфликтов библиотек с другим ПО на хосте.

Ещё один плюс — конфиги хранятся отдельно от образа (через volume), и вы можете менять oscam.conf без пересборки контейнера. Это важно, потому что gbox-конфиги меняются часто: добавляются пиры, меняются пароли.

gbox внутри OScam vs отдельный демон gbox

Чаще всего gbox запускают именно как протокол внутри OScam — через секцию [gbox] в oscam.conf. Отдельный демон gbox (standalone) встречается редко и в основном у тех, кто работает с очень старыми прошивками ресиверов. В Docker-контексте почти всегда речь идёт об OScam с включённым модулем gbox.

Разница принципиальная: если используете OScam, то всё конфигурируется через стандартные файлы OScam. Отдельный демон gbox требует своего gbox.cfg и своей логики запуска — это другая история.

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

Для сборки OScam с поддержкой gbox нужно пересобирать из исходников — готовые бинарники из большинства репозиториев собраны без нужных флагов. Базовый образ беру debian:bookworm-slim — минимальный footprint, нормальные пакеты.

Базовый образ и зависимости (libssl, libusb, pcsc-lite)

Минимальный набор пакетов для сборки:

FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y \
    build-essential \
    git \
    libssl-dev \
    libusb-1.0-0-dev \
    libpcsclite-dev \
    pcscd \
    pkg-config \
    wget \
    && rm -rf /var/lib/apt/lists/*

pcscd и libpcsclite-dev нужны, если планируете работу с физическими смарт-картами. Если только сетевые ридеры — можно обойтись без них, но лучше оставить для совместимости.

Сборка OScam с поддержкой gbox (USE_GBOX в Config.mk)

Это критический момент, который большинство гайдов просто пропускают. Без флага MODULE_GBOX=1 секция [gbox] в oscam.conf будет молча игнорироваться — никаких ошибок, просто ничего не работает.

RUN git clone https://github.com/oscam-emu/oscam-emu.git /tmp/oscam && \
    cd /tmp/oscam && \
    make -j$(nproc) \
        MODULE_GBOX=1 \
        READER_NAGRA=1 \
        READER_IRDETO=1 \
        WITH_SSL=1 \
        WEBIF=1 \
    && cp ./oscam /usr/local/bin/oscam && \
    rm -rf /tmp/oscam

Проверить, что gbox действительно включён, можно командой oscam --build-info — в выводе должна быть строка с gbox в списке модулей. Или через веб-интерфейс OScam в разделе About.

Структура каталогов: /etc/oscam и /var/oscam

Стандартная структура, которую я использую:

• /etc/oscam/ — все конфиги (oscam.conf, oscam.server, oscam.user и т.д.)
• /var/oscam/ — рабочий каталог (oscam.log, oscam.ac, временные файлы)
• /var/oscam/gbox/ — файлы gbox (gsms, share info)

Оба каталога монтируем как volumes. Никогда не вшивайте конфиги в образ через COPY — это убивает всю гибкость и вынуждает пересобирать контейнер при каждом изменении пира.

VOLUME ["/etc/oscam", "/var/oscam"]

ENTRYPOINT ["/usr/local/bin/oscam", "-c", "/etc/oscam", "-t", "/var/oscam"]

Проброс портов и сетевые режимы

Вот где ломается большинство установок. И именно это — ключевая секция, если вы уже потратили несколько часов на "почему пиры не подключаются".

Почему bridge-режим ломает gbox и когда нужен network_mode: host

В bridge-режиме Docker создаёт виртуальный интерфейс docker0 (обычно 172.17.0.1/16) и даёт контейнеру адрес из этой подсети — например, 172.17.0.3. Когда OScam с gbox устанавливает соединение с пиром, он сообщает ему свой адрес. И сообщает именно 172.17.0.3 — внутренний, недоступный снаружи.

Пир получает этот адрес, пытается подключиться к 172.17.0.3:8000/udp — и, конечно, не может. Снаружи эта подсеть недостижима. Итог: peer offline.

Самое простое решение — network_mode: host. В этом режиме контейнер разделяет сетевой стек хоста, видит реальные интерфейсы и сообщает пирам реальный IP. Работает сразу, без лишних танцев.

version: "3.8"
services:
  oscam:
    build: .
    network_mode: host
    volumes:
      - ./config:/etc/oscam
      - ./data:/var/oscam
    restart: unless-stopped

Проброс UDP-порта gbox (-p 8000:8000/udp) и порта вебинтерфейса 8888

Если host-сеть вам по каким-то причинам не подходит (несколько контейнеров, изоляция сервисов), можно работать в bridge с явным проброшенным UDP-портом. Но тогда нужно дополнительно прописать внешний IP в конфиге gbox.

version: "3.8"
services:
  oscam:
    build: .
    ports:
      - "8000:8000/udp"
      - "8888:8888/tcp"
    volumes:
      - ./config:/etc/oscam
      - ./data:/var/oscam
    restart: unless-stopped

Обратите внимание: порт вебинтерфейса (8888 по умолчанию) пробрасывается по TCP — это единственный TCP в этой схеме. Всё остальное — UDP.

Внешний IP, hostname и параметр gbox в oscam.conf

При работе в bridge-режиме в секции [gbox] нужно явно указать внешний hostname или IP — тот, который пиры смогут достичь снаружи. Если у вас статический IP — вставляйте его напрямую. Если динамический — нужен DDNS (DynDNS, No-IP, собственный). Без этого пиры будут получать от вас внутренний адрес и не смогут подключиться.

Отдельный край: CGNAT. Если ваш провайдер использует carrier-grade NAT, у вас вообще нет публичного IP-адреса, который можно пробросить. В этом случае gbox не будет работать входящими соединениями ни в каком режиме Docker — это ограничение на уровне провайдера, не Docker.

Монтирование конфигов: gbox.cfg, oscam.conf, oscam.server

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

Volume для /etc/oscam с секцией [gbox]

Структура host-каталога, который монтируется в контейнер:

./config/
├── oscam.conf
├── oscam.server
├── oscam.user
└── oscam.dvbapi

Права критически важны. Если OScam внутри контейнера запускается от пользователя с UID 1000, а файлы в ./config/ принадлежат root на хосте — OScam не сможет писать oscam.log и обновлять конфиги. Классическая проблема, которую большинство гайдов игнорируют.

# На хосте, до запуска контейнера:
chown -R 1000:1000 ./config ./data

Или в Dockerfile создайте пользователя с конкретным UID и запускайте от него:

RUN useradd -u 1000 -M -s /bin/false oscam
USER oscam

Параметры [gbox]: hostname, password, port, gsms_text

Минимальная рабочая секция [gbox] в oscam.conf:

[gbox]
hostname                      = your.domain.example.com
password                      = 0123456789ABCDEF
port                          = 8000
gsms_text                     = MyServer
ignore_sids                   = 
local_cards_override          = 0

Пароль — строго 16 hex-символов (0-9, A-F). Это одна из самых частых причин "bad password": люди вводят 14 или 18 символов, или используют символы вне hex-алфавита (G, H...). Никаких пробелов, никаких строчных букв в некоторых реализациях — хотя большинство OScam-сборок нечувствительны к регистру, лучше держать верхний регистр для единообразия.

hostname должен резолвиться в ваш реальный внешний IP. Если у вас нет DDNS и меняется IP — пиры будут отваливаться при каждой смене адреса. Динамический IP без DDNS — это постоянная ручная работа.

Описание пиров в oscam.server (protocol=gbox)

Каждый gbox-пир описывается отдельным ридером в oscam.server:

[reader]
label                         = peer_01
protocol                      = gbox
device                        = peer.hostname.example,8000
password                      = FEDCBA9876543210
inactivitytimeout             = 30
reconnecttimeout              = 30
group                         = 1
caid                          = 0500,1810,1830

Параметр device — это hostname и порт пира, через запятую. password — пароль, который пир назначил для вашего соединения (не ваш собственный из секции [gbox]). У каждого пира свой пароль для вас, и ваш для него — это симметрично, но разные значения.

caid — фильтр по системам кодирования. Без него OScam будет запрашивать у пира всё подряд, что лишняя нагрузка. Указывайте конкретные CAIDs, которые вам нужны.

Запуск, проверка пиров и устранение неполадок

Контейнер запущен — что дальше. Вот как проверить, что всё работает, и где копать когда не работает.

Чтение логов: docker logs и oscam.log внутри тома

Первый инструмент:

docker logs -f oscam_container

Но OScam пишет основной лог в файл, не в stdout. Смотрите ./data/oscam.log на хосте (или /var/oscam/oscam.log внутри). Удобнее всего:

tail -f ./data/oscam.log | grep -i gbox

Уровень логирования для gbox выставляется в oscam.conf:

[monitor]
loglevel                      = 4

Уровень 4 — подробный, увидите все handshake-попытки. Для продакшна можно снизить до 2.

Проверка статуса пиров в вебинтерфейсе OScam

Веб-интерфейс на порту 8888 — самый наглядный способ. Раздел Readers покажет статус каждого пира: Connected, Idle, или ошибку. Если видите Connected — соединение есть. Если видите Connected, но колонка Cards = 0, это другая проблема: соединение установлено, но карт нет.

Статус "Connected" с нулевыми картами означает одно из трёх: у пира нет активного ридера с картой, не совпадают CAID-фильтры, или карта есть, но на неё наложены ограничения по сервисам. Это не сетевая проблема — сеть работает.

Типичные ошибки: peer offline, wrong password, no shares

peer offline — сетевая проблема. Чек-лист:

1. Проверить открытость UDP-порта снаружи: nc -u -v external.ip 8000 или nmap -sU -p 8000 external.ip. Не TCP! Многие проверяют TCP и делают неверный вывод.
2. Проверить firewall на хосте. Docker прописывает правила iptables для проброса портов, но ufw или nftables может блокировать UDP независимо. Проверить: ufw status, nft list ruleset.
3. Проверить, что hostname в [gbox] резолвится в правильный IP.
4. Если bridge-сеть — убедиться, что используете network_mode: host или корректно прописан внешний hostname.

bad password / wrong password — пересчитайте символы. Ровно 16, только hex. Попросите пира прислать пароль заново — иногда копипаст добавляет невидимые символы или пробелы.

no shares (пир online, карт нет) — не сетевая проблема. Смотрите CAID-фильтры в oscam.server, проверьте через веб-интерфейс, какие карты реально видны у пира.

И ещё один нюанс с host-сетью: если у вас несколько gbox-инстансов в разных контейнерах на одном хосте, каждый должен использовать уникальный UDP-порт. В host-сети порты разделяются без изоляции, и два контейнера с портом 8000 конфликтуют — второй просто не запустится.

Всё это — типичные кейсы, которые встречаются при gbox Docker контейнер: настройка на реальных серверах. Изучив их один раз, экономите часы отладки.

Если подытожить опыт: gbox Docker контейнер: настройка — это в первую очередь решение сетевых вопросов, и только во вторую — конфигурация самого протокола. Правильный network_mode и честный внешний hostname решают 80% проблем.