Konfiguracja CCcam Radegast: Pełna konfiguracja& Przewodnik po portach

Jeśli tu trafiłeś, już masz działającą skrzynkę CCcam lub OScam i coś w części Radegast twojego łańcucha jest zepsute. Dokumentacja jest skąpa, wątki na forum sobie przeczą, a nikt nie wydaje się zgadzać co do tego, który plik konfiguracyjny co robi. Ten artykuł obejmuje kompletnyproces konfiguracji i ustawienia protokołu CCcam radegast — od wiązania portu po stronie serwera aż po logi debugowania i tunelowanie. Bez zbędnych informacji, bez fałszywych benchmarków. Tylko linie konfiguracyjne, które naprawdę działają.

Czym właściwie jest protokół Radegast (i dlaczego myli ludzi)

Zamieszanie prawie zawsze zaczyna się od nazewnictwa. Ludzie widzą "Radegast", "newcamd" i "CCcam" używane zamiennie w tym samym poście na forum i zakładają, że są to warianty tej samej rzeczy. Nie są — a mylenie ich zmarnuje godziny twojego czasu.

Radegast vs newcamd vs protokół CCcam

Newcamd to zaszyfrowany protokół używający 3DES. Każde połączenie wymaga wspólnego klucza (14-bajtowy klucz DES w konfiguracji klienta), a uwierzytelnianie odbywa się na poziomie handshake. Rodzimy protokół CCcam to jego własny format binarny z innym handshake i własną warstwą szyfrowania. Radegast nie jest żadnym z nich. To uproszczony, w dużej mierze jawny protokół wymiany słów kontrolnych (CW) — zaprojektowany dla prostoty, a nie bezpieczeństwa.

Praktyczna różnica: w newcamd masz nazwę użytkownika, hasło i klucz DES. W Radegast nie ma nic z tego. Serwer albo pozwala na twoje IP, albo nie. To cały model kontroli dostępu.

Gdzie Radegast pasuje w łańcuchu CCcam/OScam

Większość rzeczywistych konfiguracji, które obejmują Radegast, wygląda tak: instancja OScam znajduje się pomiędzy sprzętem karty (lub źródłem upstream) a resztą sieci. OScam udostępnia nasłuchiwacz Radegast, do którego mogą się łączyć lokalni klienci lub klienci LAN. Jeśli końcowe urządzenie downstream mówi tylko w rodzimym protokole CCcam, łączysz lokalną instancję CCcam z czytnikiem OScam.

Czyste CCcam do Radegast bez OScam pośrodku jest technicznie możliwe, ale słabo wspierane. Obsługa Radegast przez CCcam jest ograniczona w porównaniu do OScam, który ma wsparcie Radegast pierwszej klasy od lat. Jeśli próbujesz sprawić, by CCcam działał jako natywny serwer Radegast bezpośrednio, szybko napotkasz przeszkody. Działającą ścieżką jest OScam jako punkt końcowy Radegast.

Nazewnictwo cs357x (Radegast) i cs378x (Radegast-over-camd35/HTTP)

To tutaj większość dokumentacji całkowicie się rozpada. W terminologii OScam,cs357x to klasyczny protokół czytnika Radegast — jawny. Nazwa pochodzi z historycznych konwencji portowych.cs378x to inna bestia: to wariant camd35-over-TCP (czasami nazywany Radegast-over-HTTP), który dodaje lekką warstwę ochronną na wierzchu.

Kiedy edytujeszoscam.server, ustawiszprotocol = radegast dla połączeń cs357x iprotocol = cs378x dla wariantu camd35/HTTP. Większość przewodników nigdy nie wyjaśnia tej różnicy, co jest powodem, dla którego ludzie kończą próbując losowych słów kluczowych, aż coś zadziała. Kiedy widziszprotocol = cs357x — to starsza notacja i nie jest powszechnie akceptowana w różnych wersjach. Użyjprotocol = radegast w bloku czytnika dla klasycznego protokołu.

Jawny, nieautoryzowany projekt i co to implikuje

Radegast nie ma szyfrowania ani uwierzytelniania użytkowników z założenia. Pierwotnym zamiarem był prosty, niskonakładowy rozkład CW w zaufanych lokalnych sieciach. Działa to dobrze w tym przypadku użycia. Ale ten wybór projektowy oznacza, że każdy, kto może dotrzeć do portu, może żądać słów kontrolnych. Brak nazwy użytkownika, brak hasła, brak wymiany kluczy — tylko otwarte połączenie TCP.

Dlatego Radegast jest odpowiedni w zaufanym LAN i naprawdę złym pomysłem w internecie bez tunelu. Więcej na ten temat w sekcji dotyczącej bezpieczeństwa.

Konfiguracja po stronie serwera: Udostępnianie portu Radegast

Strona serwera znajduje się w dwóch plikach OScam:oscam.conf (globalny słuchacz) i potencjalnieoscam.server (gdzie mapujesz konkretne czytniki do wyjścia Radegast). Najpierw popraw blok słuchacza.

OScam oscam.conf blok radegast

Otwórz/etc/oscam/oscam.conf i dodaj[radegast] sekcję, jeśli jeszcze nie istnieje. Minimalny działający blok wygląda tak:

[radegast]

To minimum. OScam będzie nasłuchiwać na porcie TCP 8888 i akceptować połączenia tylko z localhosta oraz z podsieci 192.168.0.x. Nie zostawiajallowed pustego — w niektórych wersjach domyślnie akceptuje wszystkie połączenia, co jest dokładnie tym, czego nie chcesz.

Możesz także dodaćnodeid lubuser parametry w zależności od wersji OScam, ale dla podstawowej konfiguracji LAN powyższe dwie linie pozwolą Ci działać. Zapisz, a następnie uruchom ponownie OScam.

Ustawienie portu nasłuchu i dozwolonych zakresów IP

Port 8888 jest konwencjonalny dla Radegast, ale nie jest obowiązkowy — możesz użyć czegokolwiek powyżej 1024, co nie jest już zajęte. Sprawdź, co jeszcze działa najpierw:ss -tlnp daje pełną listę zajętych portów. Jeśli uruchamiasz także interfejs webowy OScam, zwróć uwagę na konflikty — webif często działa na porcie 8888 lub 16002 w zależności od Twojej wersji. Ustaw jeden z nich na coś innego.

Poleallowed akceptuje pojedyncze adresy IP, zakresy w stylu CIDR lub zakresy oddzielone myślnikami. Dla jednego zaufanego zdalnego hosta:allowed = 192.168.1.50. Dla pełnej podsieci:allowed = 192.168.1.0-192.168.1.255. Trzymaj to wąsko.

Pomyśl także, do którego interfejsu się przypinasz. Domyślnie OScam przypina się do wszystkich interfejsów (0.0.0.0). Jeśli Twoja maszyna ma zarówno zewnętrzną kartę sieciową, jak i wewnętrzną kartę LAN, przypinanie do wszystkich interfejsów oznacza, że port Radegast jest technicznie osiągalny także z zewnętrznej strony — Twoje zasady zapory mogą to zablokować, ale głęboka obrona ma znaczenie. Możesz dodaćbindaddr = 192.168.0.1 wewnątrz[radegast] bloku, aby przypiąć go tylko do interfejsu LAN.

Mapowanie czytnika/CAID do wyjścia Radegast

OScam automatycznie kieruje żądania ECM przez swoją pulę czytników na podstawie dopasowania CAID. Nie potrzebujesz wyraźnego połączenia między czytnikiem a słuchaczem Radegast — tak długo, jak Twój czytnik woscam.server jest w grupie, do której klienci Radegast mają dostęp, routowanie odbywa się wewnętrznie.

Jeśli chcesz ograniczyć, które karty klient Radegast może zapytać, ustawcaid orazident filtry w wpisie czytnika i starannie skonfiguruj grupy. Użytkownik klienta Radegast (automatycznie utworzony lub zdefiniowany woscam.user) może być ograniczony do konkretnych grup, które zawierają tylko czytniki, które chcesz, aby widział.

Restartowanie i potwierdzanie, że port nasłuchuje

Po ponownym uruchomieniu OScam, uruchom to na serwerze:

ss -tlnp | grep 8888

Lub jeśli twój system jest starszy:

netstat -tlnp | grep 8888

Powinieneś zobaczyć coś takiego jak0.0.0.0:8888 (lub twój konkretny adres bind) z PID OScam. Jeśli nic się nie pojawi, OScam nie udało się sparsować bloku konfiguracyjnego lub twoja wersja nie zawiera modułu Radegast. Sprawdź dziennik uruchamiania OScam — loguje, które nasłuchiwacze zostały aktywowane.

Aby potwierdzić, że moduł jest skompilowany:oscam --show-info 2>&1 | grep -i radegast. Jeśli nic nie wraca, twój plik binarny nie ma skompilowanego czytnika/serwera Radegast. Będziesz potrzebować innej wersji. To jest bardziej powszechne, niż ludzie zdają sobie sprawę w przypadku wstępnie zapakowanych wersji.

Konfiguracja po stronie klienta: Odczytywanie źródła Radegast

Gdy serwer potwierdzi, że nasłuchuje, po stronie klienta odbywa się większość codziennego rozwiązywania problemów. Konfiguracja trafia do pliku/etc/oscam/oscam.server na maszynie klienckiej.

Czytnik OScam cs357x w oscam.server

Oto kompletny, działający blok czytnika dla źródła Radegast (cs357x):

[reader]

Poledevice to adres IP i port jako para oddzielona przecinkiem — bez spacji. Polecaid informuje OScam, aby pytał ten czytnik tylko o usługi CAID 0x0500. Bez tego OScam będzie pytał ten czytnik o wszystko i otrzymasz przekroczenia czasu ECM dla CAID-ów, których źródło nie może obsłużyć.

Wymagane pola: device (host,port), protocol, caid, ident

Pomijaniecaid orazident to najczęstszy błąd konfiguracyjny, jaki widziałem. Czytnik połączy się poprawnie, ale OScam kieruje każdy nieznany ECM przez niego, co zwiększa opóźnienie i zapełnia twoje logi nieudanymi zapytaniami. Zawsze filtruj do tego, co źródło faktycznie przenosi.

Poleident format pola toCAID:ProviderID. Jeśli nie znasz identyfikatora dostawcy, zacznij od000000 jako ogólnego, a następnie zawężaj, gdy będziesz mógł zobaczyć rzeczywiste identyfikatory dostawców w logu ECM. Zbyt surowe filtrowanie identyfikatorów jest jedną z przyczyn "połączono, ale brak kart" — omówione w sekcji rozwiązywania problemów.

cs378x dla wariantu camd35/HTTP i kiedy go preferować

Blok czytnika cs378x wygląda niemal identycznie, ale słowo kluczowe protokołu i uwierzytelnienie się zmieniają:

[reader]

cs378x dodaje warstwę nazwy użytkownika/hasła i jest bardziej przyjazny dla NAT, ponieważ klient inicjuje połączenie wychodzące — przydatne, gdy strona serwera znajduje się za zaporą, która pozwala na ruch wychodzący, ale nie przychodzący. Obsługuje również niektóre przypadki brzegowe związane z kodowaniem CW wielobajtowym, które starsze implementacje Radegast robią źle. Dla każdego połączenia, które przekracza internet (nawet przez tunel), cs378x jest mniej problematycznym wyborem.

Na zaufanej sieci LAN, gdzie kontrolujesz oba końce, klasyczny Radegast (cs357x) jest w porządku i ma mniejsze obciążenie.

Grupa, zapasowe i filtrowanie CAID/dostawcy

OScam używa grup do kontrolowania, które czytniki są dostępne dla których użytkowników. Jeśli łączysz OScam → CCcam na tym samym urządzeniu, lokalna instancja CCcam zazwyczaj pojawia się jako automatycznie utworzony użytkownik w OScam z dostępem do grupy zdefiniowanym woscam.user. Upewnij się, że grupa na czytniku Radegast odpowiada temu, do czego ten użytkownik ma dostęp.

Ustawieniefallback = 1 na czytniku Radegast informuje OScam, aby używał go tylko wtedy, gdy inne czytniki zawiodą. Przydatne, jeśli masz główną lokalną kartę, a źródło Radegast jest zapasowe — zapobiega to niepotrzebnemu przesyłaniu ECM do zdalnego, gdy lokalna karta może to obsłużyć.

Rozwiązywanie problemów: Brak kart, brak dekodowania, połączenie odrzucone

To jest sekcja, która naprawdę ma znaczenie. Większość przewodników wrzuca blok konfiguracji i na tym kończy. Prawdziwa praca zaczyna się, gdy konfiguracja jest gotowa, a coś nadal nie działa.

Odczytywanie logów OScam z poziomem debugowania 4 dla ruchu czytnika

Pierwszy krok: zwiększ logging. Woscam.conf w sekcji[global]:

[global]

Następnie uruchom ponownie z poziomem debugowania:oscam -d 255 (z wiersza poleceń) lub dodajdebuglevel = 255 do bloku[global] dla trwałego logowania debugowania. Na poziomie 4+ zobaczysz poszczególne linie ECM pokazujące CAID, identyfikator dostawcy, sam hex ECM oraz to, czy czytnik zwrócił CW czy odpowiedź "nie znaleziono". Na poziomie 255 otrzymujesz wszystko — hałaśliwe, ale pełne.

Linia ECM, która się udaje, wygląda mniej więcej tak:ECM 0500<hexstring> CW znaleziono (127ms) przez radegast_lan. Niepowodzenie wygląda tak:ECM 0500<hexstring> CW nie znaleziono. Różnica między "nie znaleziono" a "brak odpowiedzi" ma znaczenie — zobacz poniżej.

'Połączenie odrzucone' vs 'połączono, ale brak odpowiedzi ECM'

"Połączenie odrzucone" oznacza jedną rzecz: połączenie TCP nie powiodło się. Port nie nasłuchuje lub zapora ogniowa odrzuciła SYN. Sprawdź serwer za pomocąss -tlnp | grep 8888, a następnie sprawdź iptables/nftables po stronie serwera. Zweryfikuj równieżdozwoloną listę woscam.conf — OScam odrzuca połączenia z adresów IP, które nie znajdują się na tej liście, zanim czytnik je zobaczy, co może wyglądać jak odmowa zapory ogniowej po stronie klienta.

"Połączono, ale brak odpowiedzi ECM" to zupełnie inny problem. Ścieżka TCP jest w porządku. Coś na poziomie protokołu jest nie tak. Niedopasowanie CAID lub identyfikatora to najczęstsza przyczyna — źródło upstream po prostu nie ma karty, która może odszyfrować żądany serwis. Sprawdź za pomocą tcpdump:tcpdump -i any port 8888 -X podczas gdy klient próbuje dekodować. Jeśli widzisz pakiety ECM docierające do serwera i nic nie wraca, serwer otrzymał żądanie, ale nie mógł znaleźć CW.

Niedopasowanie CAID/dostawcy i puste listy kart

Czytnik, który łączy się, ale zwraca puste listy kart, prawie zawsze ma problem z filtrowaniem. Albo polecaid w czytniku nie pasuje do tego, co niesie źródło, albo poleident ma identyfikator dostawcy, który nie istnieje na karcie.

Otwórz interfejs webowy OScam na serwerze (port 8888 lub 16002 — nie ten sam port co Radegast, wybierz różne wartości dla każdego) i sprawdź status czytnika. Powinien pokazać, jakie CAID-y i identyfikatory dostawców zgłasza karta. Porównaj to z konfiguracją swojego czytnika po stronie klienta. Nawet pojedynczy znak szesnastkowy w identyfikatorze dostawcy spowoduje pusty wynik bez komunikatu o błędzie.

Również: niektóre wersje OScam mają moduł Radegast skompilowany, ale z subtelnie uszkodzoną enumeracją CAID. Jeśli wszystko inne się zgadza, a nadal otrzymujesz puste listy, przetestuj zcaid iident całkowicie usuniętymi — jeśli karty się pojawią, twoje wartości filtrowania były błędne. Dodawaj je z powrotem po jednym.

Problemy z MTU, NAT i zaporą ogniową w internecie

Jeśli uruchamiasz Radegast przez łącze WAN (już zły pomysł dla tekstu jawnego, ale spróbujmy to zdebugować), fragmentacja MTU może cicho uszkodzić ładunki ECM. Klasycznym objawem jest przerywane dekodowanie — niektóre kanały działają, inne nie, a wydaje się to losowe. Uruchomping -M do -s 1400 remote_server_ip z klienta, aby przetestować MTU ścieżki. Jeśli otrzymasz odpowiedzi o potrzebie fragmentacji, obniż MTU w tunelu lub dodaj regułę clamp.

CGNAT to trudniejszy problem. Jeśli maszyna kliencka znajduje się za NAT klasy operatorskiej, przychodzące połączenia do tej maszyny po prostu nie będą działać — cs357x wymaga, aby serwer był osiągalny. Użyj cs378x (klient inicjuje połączenie wychodzące) lub skonfiguruj tunel WireGuard, który tworzy stabilną trasę routowalną.

Zawieszenia i CW-nie znaleziono na kanałach o wysokim bitrate

Zawieszanie po kilku sekundach, szczególnie na kanałach o wysokim bitrate, jest prawie zawsze problemem z opóźnieniem. Okresy kryptograficzne DVB-S2 trwają około 10 sekund. Klient musi otrzymać świeżą CW, zanim obecna wygaśnie. Jeśli twój czytnik Radegast znajduje się na wolnym łączu WAN z RTT powyżej 200 ms, okrążenie ECM może zająć wystarczająco dużo tego okna, że CW przychodzi za późno.

Kanały UHD są gorsze — czasami używają krótszych okresów kryptograficznych i wyższej częstotliwości ECM. Łącze, które jest w porządku dla SD, zamarznie na UHD. Mierz rzeczywiste czasy odpowiedzi ECM w dzienniku debugowania (wartość czasu w linii ECM). Cokolwiek powyżej 2-3 sekund jest problemem dla większości kanałów. Napraw podstawowe routowanie, zanim obwinisz protokół.

Mieszany firmware na starszych odbiornikach to osobny przypadek brzegowy. Niektóre starsze firmware STB błędnie odczytują CW z źródła Radegast — bajty przychodzą w odwrotnej kolejności — co powoduje przerywane czarne ekrany, które znikają i ponownie zamarzają w przybliżonym cyklu 10-sekundowym. Jeśli widzisz to na jednym konkretnym odbiorniku, ale nie na innych, firmware STB jest podejrzany, a nie twoja konfiguracja OScam.

Wzmocnienie bezpieczeństwa i niezawodności dla Radegast

Ta część jest pomijana w większości opisów, co jest częścią powodu, dla którego Radegast ma reputację jako niebezpieczny. To nie wina protokołu — został zaprojektowany dla zaufanej sieci LAN. Problem polega na tym, że ludzie używają go poza tym kontekstem bez dodatkowej ochrony.

Nigdy nie wystawiaj portu Radegast w formacie jawnym do otwartego internetu

Surowy Radegast na publicznym IP oznacza, że każdy, kto może dotrzeć do portu 8888, może wysyłać żądania ECM i odbierać CW. Twoja zapora ogniowadozwolona lista pomaga, ale spoofing IP i przejmowanie są realne w otwartym internecie. Poza problemem kontroli dostępu, dane same w sobie są w formacie jawnym w sieci — widoczne dla każdego na ścieżce między klientem a serwerem.

Jeśli masz otwarty port 8888 w regułach przekierowania portów swojego routera i przypisany do publicznego adresu IP, zamknij go teraz. Użyj zamiast tego tunelu.

Tunelowanie Radegast przez SSH lub WireGuard/OpenVPN

Lokalne przekierowanie portów SSH jest najszybszym rozwiązaniem, jeśli już masz dostęp SSH do serwera:

ssh -L 8888:127.0.0.1:8888 user@your_server_ip -N

To przypisuje port 8888 lokalnie na maszynie klienckiej i przekierowuje go przez zaszyfrowane połączenie SSH do localhost:8888 serwera. Twój czytnik OScam na kliencie wskazuje wtedy na127.0.0.1,8888 zamiast adresu IP serwera. Ruch Radegast jest szyfrowany od końca do końca i nigdy nie trafia do otwartego internetu jako tekst jawny.Lista dozwolonych powinna zawierać127.0.0.1

aby to działało.WireGuard jest czystszą opcją dla trwałej konfiguracji. Gdy tunel WireGuard jest ustanowiony, czytnik Radegast wskazuje na wewnętrzny adres IP WireGuard serwera (np.10.0.0.1,8888

), a cały ruch automatycznie przechodzi przez zaszyfrowany tunel. Nie ma potrzeby utrzymywania sesji SSH. Na Raspberry Pi lub podobnym urządzeniu o niskiej mocy, WireGuard dodaje minimalne obciążenie CPU w porównaniu do OpenVPN.

Zaostrzenie listy dostępu 'dozwolonych' i grup per-czytnikNawet w sieci LAN, nie zostawiajdozwolonych

ustawionych na szeroki zakres, chyba że każde urządzenie w tym zakresie powinno mieć dostęp. Jeśli tylko jedna maszyna powinna się połączyć, umieść tylko adres IP tej maszyny na liście. OScam rejestruje odrzucone próby połączenia, więc możesz zobaczyć, czy coś nieoczekiwanego próbuje się połączyć.

System grup OScam jest również twoim przyjacielem w tej sytuacji. Jeśli dane uwierzytelniające klienta (lub IP, w przypadku dostępu Radegast na podstawie IP) zostaną skompromitowane, dobrze skonfigurowana struktura grup ogranicza zasięg szkód. To skompromitowane połączenie może dotrzeć tylko do czytników w przypisanych grupach — nie do całej puli kart.

Preferowanie cs378x, gdy zdalne połączenie jest nieuniknione

Jeśli absolutnie musisz uruchomić połączenie w stylu Radegast przez internet i tunel nie jest opcją, cs378x jest lepszym wyborem niż surowe cs357x. Warstwa uwierzytelniająca oznacza, że losowy adres IP nie może po prostu połączyć się i zacząć pobierać CW — potrzebują ważnych danych uwierzytelniających. To nie jest szyfrowanie w silnym sensie, ale jest znacząco lepsze niż otwarty Radegast.Połącz cs378x z wąskąlistą dozwolonych

Uzyskanie poprawnej konfiguracji i ustawienia protokołu CCcam radegast polega głównie na zrozumieniu, w której warstwie występuje problem — TCP/zapora, routowanie CAID, czy sam protokół — oraz posiadaniu odpowiednich narzędzi debugujących, aby je odróżnić. Powyższe linie konfiguracyjne stanowią bazę roboczą. Gdy coś się psuje, log ECM OScam i szybki tcpdump powiedzą ci dokładnie, gdzie łańcuch jest zerwany.

Ostatni przypadek brzegowy, który warto zauważyć: jeśli robisz pełne ustawienie i konfigurację protokołu CCcam radegast od podstaw i OScam cicho ignoruje twój[radegast] blok, zawsze najpierw sprawdźoscam --show-info. Binarna wersja skompilowana bezREADER-RADEGAST przeanalizuje plik konfiguracyjny bez błędu i po prostu nie aktywuje nasłuchującego — bez ostrzeżenia, bez wpisu w logu, po prostu port, który nigdy się nie otwiera. To zaskakuje wielu ludzi korzystających z prekompilowanych pakietów z repozytoriów, które kompilują z minimalnym zestawem funkcji.