CCcam Hub: что это и как настроить узел шаринга

Если вы уже несколько месяцев работаете с CCcam и настраивали C-line на ресивере — понятие cccam hub рано или поздно возникнет. Я видел много путаницы: люди думают, что hub — это отдельная программа или какой-то особый дистрибутив. На деле это просто роль. Роль, которую обычный CCcam-сервер начинает играть в момент, когда вы подключаете к нему и источники карт, и конечных клиентов одновременно.

В этой статье разберём архитектуру, конфиги, команды и ошибки. Без воды, с реальными примерами.

Что такое CCcam Hub и чем он отличается от обычного сервера

Определение: hub как узел распределения карт

CCcam hub — это CCcam-инстанс, который одновременно выступает клиентом вышестоящих серверов и сервером для нижестоящих клиентов. Он принимает карты по F-line с upstream-источников и раздаёт их вниз по C-line своим пирам или ресиверам. Один узел, два направления трафика.

Никакого специального программного обеспечения не нужно. Один и тот же бинарник CCcam, один и тот же CCcam.cfg. Разница только в том, что прописано в конфиге.

Топология: клиент → hub → upstream-серверы

Классическая схема выглядит так:

[Ресивер 1] ─┐
[Ресивер 2] ─┼──→ [CCcam Hub] ──→ [Upstream A]
[Ресивер 3] ─┘          │──→ [Upstream B]
                         └──→ [Upstream C]

Hub стоит посередине. Он подключается к трём upstream-серверам, агрегирует их карты в общий пул и раздаёт этот пул трём ресиверам. Ресиверам не нужно знать, откуда карта — они просто получают ответ на ECM-запрос.

Отличие от standalone CCcam-сервера

Обычный CCcam-сервер — это конечная точка. У него есть физическая карта в кардридере или softcam, и он раздаёт именно её. Никаких upstream-соединений, только клиенты.

Hub же сам карт не имеет. Он — агрегатор и прокси. Получает ECM-запрос от клиента, пробрасывает вверх к тому upstream, у которого есть нужный CAID, получает CW и отдаёт обратно. В этом суть.

Когда нужен hub, а когда хватит одной C-line

Одной C-line достаточно, если у вас один ресивер и один надёжный upstream. Точка. Как только появляется второй ресивер или второй upstream — hub начинает иметь смысл.

Ещё один сценарий: у вас несколько upstream-провайдеров с разными CAID. Без hub каждый ресивер должен был бы знать обо всех них. С hub — вы прописываете всё один раз на hub-машине, а ресиверы подключаются к одной точке. Намного удобнее управлять.

Архитектура узла: порты, протокол, конфиги

Стандартный порт 12000 и кастомные порты

По умолчанию CCcam слушает на 12000/TCP. Это исторически сложившийся стандарт, именно его ожидают большинство ресиверов. Веб-интерфейс поднимается на 16001/TCP.

На практике многие меняют 12000 на что-то нестандартное — 12100, 15000, 23456. Причина простая: порт 12000 массово сканируется ботами в поисках открытых CCcam-узлов. Нестандартный порт не добавляет безопасности, но снижает шум в логах.

Протокол CCcam (newcamd-совместимость через OScam)

CCcam использует собственный бинарный протокол. Он не совместим с newcamd напрямую — это разные вещи. OScam умеет говорить на обоих языках, поэтому гибридные схемы, где hub на OScam раздаёт карты клиентам по CCcam-протоколу, вполне рабочие.

Если ваши клиенты настроены на newcamd (mgcamd, некоторые сборки Enigma2) — нужен OScam в роли hub, или надо переключать клиентов на CCcam-протокол явно.

Структура CCcam.cfg: F-line, C-line, SERVER LISTEN PORT

На Enigma2-приставках конфиг лежит в /var/etc/CCcam.cfg. На обычном Linux — /etc/CCcam.cfg. Структура одна и та же.

Минимальный конфиг для hub-режима:

# Настройки сервера
SERVER LISTEN PORT : 12000
WEBINFO LISTEN PORT : 16001
WEBINFO USERNAME : admin
WEBINFO PASSWORD : сложный_пароль_здесь

# Подключения к upstream (C-line)
C: upstream1.example.com 12000 myuser mypass
C: upstream2.example.com 15000 user2 pass2

# Разрешённые клиенты (F-line)
F: client1_user client1_pass 2 0 0
F: client2_user client2_pass 2 0 0
F: receiver_user receiver_pass 1 0 0

F-line здесь — это объявление клиента, которому разрешено подключиться. Три числа после логина/пароля: максимальный hop count, флаг share-no-share (0 = делимся), флаг reshare. Подробнее о reshare — в разделе про балансировку.

Файлы CCcam.providers, CCcam.prio, CCcam.channelinfo

Помимо основного конфига, CCcam читает несколько вспомогательных файлов из той же директории:

• CCcam.providers — маппинг CAID:ProviderID на читаемые имена. Нужен для корректного отображения в веб-интерфейсе и приоритизации.
• CCcam.prio — приоритеты карт по CAID/PROVID. Если несколько upstream дают одну и ту же карту — hub выберет ту, что указана с более высоким приоритетом.
• CCcam.channelinfo — маппинг SID на названия каналов. Чисто косметика, влияет только на отображение в веб-морде.

Эти файлы не обязательны для работы, но CCcam.prio реально важен при нескольких upstream с пересекающимися CAID.

Пошаговая настройка hub-узла на Linux/VPS

Требования: Debian/Ubuntu, статический IP, открытые порты

Для работы cccam hub на VPS нужно немного: Debian 11/12 или Ubuntu 22.04, статический IP (динамический — отдельная история с DDNS), и открытые порты 12000 и 16001 в файрволе хостинга. Минимальные требования по железу — 1 vCPU и 512 МБ RAM на 20-30 клиентов. Хочешь больше — бери 1 ГБ и не переживай.

Установка бинарника CCcam (или OScam в режиме hub)

CCcam распространяется как бинарник, исходников нет. Скачиваете версию под свою архитектуру (x86_64 для VPS, armhf/aarch64 для Raspberry Pi), делаете исполняемым и кладёте в PATH:

chmod +x CCcam
mv CCcam /usr/local/bin/CCcam

Конфиг создаёте в /etc/CCcam.cfg по образцу выше. Логи по умолчанию идут в /var/log/CCcam.log.

Минимальный CCcam.cfg для hub-режима

Пример уже был выше. Добавлю важный момент: параметр ALLOW TELNET : yes открывает telnet-интерфейс на порту 16000. Лучше оставить no — telnet без шифрования, а интерфейс вам и не нужен, если есть веб на 16001.

Запуск как systemd unit и логирование

Создайте файл /etc/systemd/system/cccam.service:

[Unit]
Description=CCcam Hub
After=network.target

[Service]
Type=forking
ExecStart=/usr/local/bin/CCcam
Restart=on-failure
RestartSec=10
StandardOutput=append:/var/log/CCcam.log
StandardError=append:/var/log/CCcam.log

[Install]
WantedBy=multi-user.target

Дальше стандартно:

systemctl daemon-reload
systemctl enable cccam
systemctl start cccam

CCcam сам по себе демонизируется, поэтому Type=forking. Если хотите, чтобы systemd сам держал процесс — замените на Type=simple и уберите -d из параметров запуска (если используете скрипт-обёртку).

Проверка статуса через CCcam --rc или веб-интерфейс

После запуска зайдите на http://ваш-ip:16001 — там видно подключённых клиентов, upstream-соединения и доступные карты. Через CLI: netstat -tlnp | grep 12000 — должен показать CCcam в состоянии LISTEN.

Логи смотреть так: tail -f /var/log/CCcam.log. В первые минуты после запуска там пойдут строки о подключении к upstream и о клиентах.

Открытие портов в iptables

Если файрвол активен — нужно явно открыть порты:

iptables -A INPUT -p tcp --dport 12000 -j ACCEPT
iptables -A INPUT -p tcp --dport 16001 -j ACCEPT

Но лучше сразу сделать whitelist по IP — об этом в разделе про безопасность.

Особый случай: hub за NAT без публичного IP

Если ваш hub сидит за домашним роутером без белого IP — клиенты снаружи не подключатся. Варианты: настроить port forwarding на роутере (если есть публичный IP) или использовать reverse SSH tunnel через VPS-релей:

ssh -R 12000:localhost:12000 [email protected] -N

Тогда клиенты подключаются к VPS-адресу, а трафик туннелируется на ваш локальный hub. Работает, но добавляет задержку.

Hub на динамическом IP: DDNS через ddclient

Если IP меняется — нужен DDNS. Установите ddclient и настройте обновление через DuckDNS, Cloudflare DNS API или любой другой сервис. Клиенты прописывают hostname вместо IP в C-line, и при смене IP обновление происходит автоматически в течение TTL записи.

Балансировка карт, кеш-обмен и ECM-таймауты

CACHEEX и CSP — что это и зачем

CACHEEX — это механизм обмена кешированными CW между узлами. Реализован только в OScam, в оригинальном CCcam его нет. Суть: если узел A уже расшифровал ECM для канала X, он кладёт CW в кеш. Узел B, получив тот же ECM, берёт CW из кеша узла A, не гоняя запрос на upstream. Задержка падает до минимума — буквально 5-20 мс вместо 200-400 мс.

Три режима CACHEEX в OScam:

• 1 — только получать кеш от других узлов, своим не делиться
• 2 — только отдавать кеш, самому не использовать чужой
• 3 — и получать, и отдавать (полный обмен)

CSP (Cache Stream Protocol) — надстройка над CACHEEX для эффективной трансляции CW между несколькими hub-узлами. Если у вас один hub — CSP не нужен.

Настройка приоритетов через CCcam.prio

Формат строки в CCcam.prio:

P: CAID:PROVID

Например, для приоритизации Viaccess с конкретным провайдером:

P: 0500:032830
P: 0500:040810
P: 0604:000000

Если два upstream дают одну и ту же карту — hub использует ту, что выше в файле приоритетов. Если CAID не в prio-файле — выбор происходит по времени ответа (быстрее ответил = победил).

Конфликт CAID при нескольких upstream с одинаковой картой решается именно через CCcam.prio — прописываете предпочтительный источник. Без prio-файла hub просто берёт первый ответ, что не всегда оптимально.

ECM/EMM таймауты и значение AU (auto-update)

ECM timeout в CCcam по умолчанию — 3 секунды. Если upstream не ответил за это время, запрос считается неудачным. На нагруженном hub с несколькими upstream это критично: если основной upstream тупит, hub должен быстро переключиться на резервный.

AU (auto-update) — это обновление EMM, необходимое для поддержания карты в актуальном состоянии. Параметр DISABLE AU в CCcam.cfg отключает его. Отключать AU не рекомендуется, если карты физические — они протухнут через несколько недель без обновления.

Reshare: 0, 1, 2 — что означает каждое значение

Reshare — это глубина, на которую hub позволяет передавать карту дальше.

Значение	Поведение	Когда использовать
0	Карта используется только локально на hub, клиентам не передаётся	Редко нужно — у hub нет своего тюнера
1	Карта передаётся клиентам, но клиенты не могут передать её дальше	Стандарт для конечных клиентов
2	Клиенты могут пересылать карту ещё на один хоп	Если у клиента есть свои downstream-устройства

Чем меньше reshare — тем стабильнее и безопаснее. Reshare 2 создаёт длинные цепочки хопов, которые увеличивают задержку и снижают контроль над тем, кто реально использует карту.

Troubleshooting: типовые ошибки hub-узла

Клиент видит карты, но каналы не открываются (ECM timeout)

Это самая частая проблема. Карта в веб-интерфейсе есть, CAID совпадает, но канал не открывается. Причины:

• Расхождение времени сервера более 30 секунд — CCcam рвёт соединения. Проверьте: date, потом ntpdate -u pool.ntp.org. NTP должен быть настроен и синхронизирован.
• ProviderID не совпадает с тем, что прописан в CCcam.providers.
• ECM timeout слишком маленький при медленном upstream.

Диагностика: tail -f /var/log/CCcam.log и смотрите на строки с "ECM" — там будет видно время ответа и статус.

Freeze на 5-10 секунд каждые N минут

Классический симптом слишком длинной цепочки хопов. Если upstream вашего upstream тоже hub — карта может идти через 4-5 хопов. При hop count >4 нарастает джиттер, и каналы начинают подмерзать при смене CW.

Проверьте количество хопов в веб-интерфейсе на вкладке Cards. Если hop >3 — ищите более прямой upstream. Также freeze может быть при нестабильном соединении между hub и upstream: ping -c 100 upstream-host покажет потери пакетов.

no card available при наличии F-line

Upstream подключён, F-line прописан, но клиент получает "no card available". Первым делом — проверить, что CAID и ProviderID в запросе клиента совпадают с тем, что upstream реально предоставляет. Открываете веб-интерфейс → Servers → смотрите список CAID у каждого upstream.

Второй вариант: параметр reshare в C-line выставлен в 0 — карта есть на hub, но не передаётся клиентам. Исправьте на 1.

Connection refused / connect failed

Элементарно: либо CCcam не запущен (systemctl status cccam), либо порт закрыт файрволом (netstat -tlnp | grep 12000), либо upstream-сервер недоступен. Проверяйте в этом порядке.

Hub теряет соединение с upstream после рестарта

CCcam пытается переподключиться к upstream автоматически. Если этого не происходит — скорее всего проблема с DNS-резолвингом (hostname не резолвится) или upstream поменял IP. Попробуйте прописать в C-line IP вместо hostname и посмотрите, поможет ли это.

Также CCcam иногда не переподключается после длительного разрыва — в этом случае помогает перезапуск сервиса. Для автоматики можно настроить watchdog-скрипт через cron, который проверяет наличие процесса и соединений.

Безопасность hub-узла и защита от утечек

Firewall: ограничение доступа по IP к 12000 порту

Открытый 12000 порт — это приглашение для сканеров. На порту 12000 постоянно висят боты, пытающиеся подобрать логины. Правильное решение — whitelist по IP:

# Разрешаем только конкретный IP клиента
iptables -A INPUT -p tcp --dport 12000 -s 1.2.3.4 -j ACCEPT
# Всё остальное — дропаем
iptables -A INPUT -p tcp --dport 12000 -j DROP

Если клиентов много и их IP меняются — хотя бы ограничьте по подсети или используйте fail2ban для автоматической блокировки после N неудачных попыток.

Сложные пароли и уникальные username для каждого peer

Никаких "user1/pass1". Генерируйте уникальные логины и пароли для каждого peer — тогда при компрометации одного клиента легко отозвать именно его доступ, не трогая остальных. Пароль минимум 16 символов, случайный. openssl rand -base64 16 выдаёт подходящий вариант.

Защита веб-интерфейса (WEBINFO USERNAME/PASSWORD)

Веб-интерфейс на 16001 — это goldmine для тех, кто хочет знать ваши C-line и F-line. Никогда не оставляйте его открытым без пароля и никогда не открывайте на весь интернет. Лучше всего: привязать к localhost и ходить через SSH tunnel:

ssh -L 16001:localhost:16001 user@hub-server

Тогда веб-морда доступна только вам через туннель, а в файрволе порт 16001 вообще не открыт снаружи.

Логи: что писать, что не писать

CCcam по умолчанию пишет достаточно подробные логи, включая логины клиентов и их запросы. Это полезно для отладки, но logs могут быть большими. На продакшн-hub настройте ротацию через logrotate: файл /etc/logrotate.d/cccam с ротацией ежедневно и хранением 7 дней достаточно.

Никогда не логируйте пароли — в стандартном CCcam они и так не попадают в лог, но если пишете обёртки или скрипты мониторинга — следите за этим.

Что выбрать: CCcam или OScam в роли hub

CCcam — простота, но закрытый код и старая кодовая база

Последняя версия CCcam вышла в 2014 году. Это не метафора — буквально 2014. С тех пор никаких обновлений, патчей безопасности, улучшений. Код закрытый, баги не исправляются.

При этом CCcam реально прост в настройке. Один конфиг, минимум параметров, работает из коробки. Для небольшого hub на 5-10 клиентов это вполне рабочий вариант. Но понимайте, что вы используете заброшенный инструмент.

OScam — открытый код, гибкость, CACHEEX, поддержка newcamd

OScam активно разрабатывается. Последние сборки — 2024-2025 года. Открытый исходный код, компилируется под любую архитектуру включая ARM для Raspberry Pi.

Конфигурация сложнее: нужно разобраться с /etc/oscam/oscam.server, /etc/oscam/oscam.user, /etc/oscam/oscam.dvbapi. Зато получаете CACHEEX, детальный мониторинг через веб-API, тонкую настройку таймаутов и приоритетов. Для нагруженного hub — это не просто лучший выбор, это единственный разумный.

Гибридная схема: OScam как hub + CCcam-протокол наружу

Мой любимый вариант для реального применения cccam hub. OScam поднимается как hub, принимает upstream по своему протоколу или через CCcam-совместимость, а наружу клиентам раздаёт по CCcam-протоколу через модуль protocol = cccam в oscam.server. Клиентам не нужно ничего менять — они видят обычный CCcam-сервер.

Минимальный oscam.server для upstream-соединения:

[reader]
label         = upstream_a
protocol      = cccam
device        = upstream1.example.com,12000
user          = myuser
password      = mypass
reconnecttimeout = 30

И oscam.user для клиентов:

[account]
user     = client1
pwd      = client1_pass
group    = 1
au       = 1

Производительность при 50+ клиентах

На 50+ одновременных клиентах CCcam начинает ощутимо загружать CPU и давать нестабильность. Это не домыслы — это задокументированная проблема с блокирующей архитектурой CCcam.

OScam обрабатывает параллельные ECM-запросы эффективнее за счёт многопоточности. На том же железе (1 vCPU, 1 ГБ RAM) OScam держит 100+ клиентов без деградации там, где CCcam начинает тормозить уже на 50.