HAM – Pilotage de votre station radioamateur à distance.

Le guide est maintenant hébergé ici :  https://project.crx.cloud/Remote_ham_radio_station_setup_guide
J’ai laissé l’ancien guide disponible ici, car il utilisait SEREN à la place MUMBLE pour la VOIP (et aussi sans interface graphique, tout en console côté RASPBERRY).

Version du guide : 1.0.5
Date : 25/04/2020
Update : 06/07/2021


Dans ce guide, je vous propose de mettre en place le pilotage de votre station radioamateur à distance avec des briques « open source » (SEREN pour la VOIP et CRX-COM pour la commande du TRX ou FLRIG).

J’ai pu tester différents logiciels pour faire ce genre d’opération et finalement j’ai retenu cette configuration que je vous propose ici, notez que ce guide évoluera dans le temps au fur à mesure de mes essais.

Dans le passé, j’ai déjà expérimenté une solution de « remote control » sous WINDOWS, pour ce faire vous pouvez utiliser : HAM RADIO DELUXE client/serveur et MUMBLE/MURMURE pour la VOIP mais aussi SKYPE, je ne décrit pas leur utilisation ici, c’est suffisamment simple et documenté sur Internet, par contre n’hésitez pas si vous avez besoin d’un coup de main pour la configuration.

D’expérience, je trouve plus simple le « remote control » avec LINUX, qu’avec WINDOWS. Je trouve que techniquement c’est plus stimulant surtout dans notre loisir qui consiste à expérimenter, de pouvoir regarder dans les codes sources, comprendre comment ça marche et maîtriser complètement notre système de contrôle distant.

Historique de ma station « remote » :

1.0.0 : Station remote historique tournant sous WINDOWS, testée avec : HRD server/SKYPE et VOX (interface VOX conçue pour un FT290 par Jean F6HCC) puis passage en Mumble/Murmure après SKYPE ( testé en 2010 ) et migration vers le FT897 côté transceiver.

1.0.1 : Solution 100% LINUX (2019) premier test avec un Raspberry PI1 et un client avec le FT897, plus de VOX, utilisation du PTT logiciel via le CAT SYSTEM.

1.0.2 : Passage en Raspberry PI4 (Août 2020), ajout d’un service systemd pour le CAT system sur le Raspberry (pour automatiser les choses au démarrage du serveur). Passage en fibre optique sur la station REMOTE et arrêt du WIFI sur le serveur, passage en ETHERNET 1Gb/s. Passage en UDP pour la partie OPEN-VPN.

1.0.3 : Test du client FLRIG sous WINDOWS avec OPEN-VPN et ajout d’un bouton USB VFO
Partie audio réalisé elle avec LINUX/SEREN.

1.0.4 : Automatisation de l’installation LINUX du client et du serveur REMOTE (09/2020).

1.0.5 :
Ajout du pare-feu UFW, plus simple à mettre en place que SHOREWALL.

Sommaire :

Mes recommandations
1. Création d’une matrice de flux réseau
2. Configuration du serveur « REMOTE »
3. Configuration du client.
4. Configuration de votre box internet & tests.
5. Sécurité de votre installation.
6. Implémentation d’OPEN-VPN.
Notes.

Mes recommandations :

Logiciels :

Pas de VPN dans la mesure du possible : Un simple FIREWALL côté serveur est amplement suffisant (latence la plus basse). Attention pour les utilisateurs Français, il conviendra d’utiliser un VPN pour tous les flux car l’emploi direct du réseau INTERNET, n’est pas prévu par la réglementation actuelle.

Si vous souhaitez quand même en utiliser un, vous pouvez utiliser un système hybride à savoir : mettez toujours la VOIP sans VPN et le reste avec (surtout avec un filtrage IP sur la source en place).

Dans le cas ou votre station radio distante tourne avec un modem 4G par contre il faudra passer au VPN, car vous n’aurez pas d’adresse IP publique fixe (à moins d’utiliser un service type DynDNS mais ce n’est pas forcément très pratique et c’est devenu payant).

Ici je vous propose dans la partie 6 de ce guide, l’implémentation d’OPEN-VPN sur un serveur (en IP FIXE ou avec un DYNDNS) et aussi sur votre client WINDOWS ou LINUX.

Un FIREWALL sur votre serveur « remote station » : ici je vous conseil SHOREWALL (qui est un frontend pour IPTABLES), je détaillerai sa configuration ici dans le chapitre 5.

Matériels :

Si c’est pas déjà le cas :
– Ajout de ferrites systématique sur vos alimentations USB, 12V, 5V.
– Ajout de transformateurs sur vos lignes sons si vous n’avez pas d’interface TRX/carte sons.
– Si possible utilisez une alimentation et un HUB USB dédié devant votre RASPBERRY, c’est mieux que d’utiliser l’alimentation du RASBERRY pour tout faire.

Commencez par les tests sur votre réseau LAN puis par INTERNET & tenez compte de la latence de votre ligne et de votre matériel, réduisez/augmenter le débit et la qualité du son si besoin, la vitesse du port série (espace entre chaque byte envoyé et aussi vitesse de récupération des infos ( via pooling avec FLDIGIT ) je détaille tout cela dans ce guide.

Côté client :

– Disposant d’un petit PC DELL avec 1G de RAM, j’y installe une UBUNTU 18 que je met ensuite à jour, puis j’y installe LUNBUTU, une version allégée idéale ici sur mon mini PC que j’utilise pour le contrôle de la station à distance, j’ai également un PC sous WINDOWS 10 et une machine virtuelle DEBIAN pour la VOIP cela fonctionne aussi très bien.

Si vous voulez utiliser des logiciels de mode numérique avec votre station distance, je vous conseil côté client un PC Windows ou LINUX mais avec plus de 1G de RAM car après tests ici avec JACK (outil pour créer des câbles virtuels sous LINUX ) il s’avère qu’il faut +de 1G de RAM pour que cela tourne correctement surtout si ensuite vous lancez WSJT ou tout autre logiciel de modes numériques.

Enfin soyez vigilent sur la qualité de votre micro-casque, surtout sur une station distante, l’idéal est de disposer d’un PTT.

Côté serveur :

– Pour mes essais j’ai testé avec un RASPBERRY-PI-1 disposant de 512Mo de RAM avec processeur ARMv6 ce qui suffit amplement ici, si vous disposez d’un RASPBERRY plus puissant tant mieux, la latence n’en sera que meilleure, notez que j’ai migré mon installation sur un RASPBERRY-PI-4 (Aout 2020), j’ai installé les même logiciels et j’en suis très satisfait j’en ai aussi profité pour passer d’une connexion WIFI à ETHERNET pour la station et aussi le passage en fibre optique côté Internet.

– Notez que j’utilise un RAMDISK pour les LOGS afin de ne pas fatiguer la carte mémoire, et que les périphériques USB sont branchés
sur un petit HUB USB alimenté sur une alimentation 5V dédiée, dans le but ici de ne pas solliciter de trop le RASPBERRY.

– Concernant la carte son, ici on utilise une carte son USB, de ce côté là vous avez l’embarra du choix, ici une carte à 10€ fonctionne très bien, mais comme pour le RASPBERRY, si vous avez mieux tant mieux pour vous.

– Côté interface sons, j’ai testé avec et sans transformateur audio, sur ma dernière interface j’ai simplement des résistances et condensateurs (2x 10k+100k). Notez que je n’ai pas noté de perte de qualité sur mes tests en les supprimant.

1. Création d’une matrice de flux réseau :

Le contrôle distant vous impose ici de connaitre les ports réseaux que l’on va configurer sur notre RASBERRY
puis sur notre BOX INTERNET, ici je vous conseil :

– Pour les gens en 3G/4G ou les grands voyageurs, notez que ici vous n’aurez pas de ports réseau à ouvrir, il vous faudra installer un client OPEN-VPN sur le RASBERRY, disposer d’un provider VPN et vous connecter sur votre passerelle au démarrage du serveur RASPBERRY. De là votre client qui pilote votre station radio devra lui aussi disposer d’un client VPN configuré sur le même réseau, les accès se feront au travers le VPN.

Pour les gens en IP fixent avec une BOX INTERNET classique des 2 côtés c’est mon cas, vous avez rien à faire avec une configuration VPN, c’est pas la peine, sauf si vous chercher une solution qui marchera quand vous êtes en voyages, pour cela il vous faudra obligatoirement un VPN ou un accès SSH direct (avec tunnels).

Voici une matrice que vous devez remplir avec les ports de votre choix, notez bien les valeurs,
car il faudra configurer tout cela sur votre BOX internet :

– Choix d’un port SSH non standard, choisissez une valeur entre 2200 et 2600 par exemple.

– Choix d’un port VOIP : choisissez une valeur entre 3000 et 9000 par exemple.

– Choix d’un port pour la commande du TRX : choisissez une valeur entre 4000 et 9090 par exemple, si vous disposez d’un rotor et d’autres équipements sur le port série ajouter autant de ligne que vous n’en avez besoin (ici j’ai 9090 pour CRX-COM et 5209 pour FLRIG ).

Ici je rempli avec ceci :

Port côté serveur radio Port visible côté Internet Description
22 2235 (TCP) Accès SSH distant ( + tunnel pour VNC )
8110 8110 (UDP) Accès VOIP.
9090 9090 (TCP) Accès CRX-COM (websocket)
5209 5209 (TCP) Accès FLRIG (test)

Mon serveur RASPBERRY aura l’adresse IP : 192.168.0.166 ( ici avec une FREEBOX en .254 ).

Pensez à filtrer l’IP source pour le port SSH (afin de limiter qui accède à votre RASPBERRY depuis Internet), c’est important pour la sécurité de votre installation.

Quand vous avez fini vos tests, pensez à désactiver les ports inutilisés sur votre BOX.

2. Configuration du serveur « REMOTE »

Ici j’ai un RASPBERRY-4 sous la main, donc j’ai fait avec, bien sur vous pouvez utiliser n’importe quel PC LINUX que vous souhaitez dédié à l’application « Serveur REMOTE ». Je pense que le hardware RPI est le plus adapté et le meilleur marché pour ce type d’application.

Installation de l’OS ici Raspberry PI OS (anciennement RASBIAN) :

Ici je commence par graver l’image ISO avec le logiciel WINDOWS WIN32DISKIMAGER sur ma carte SD,
je ne saurai vous recommander une carte SD type SAMSUNG, c’est vendu avec adaptateur mini SD vers SD,
ici j’ai 32Gb ce qui est largement suffisant.

La version « Lite » est suffisante, vous pouvez la télécharger ici :
https://www.raspberrypi.org/software/operating-systems/

Si vous souhaitez utiliser un mode graphique sur le RASPBERRY (avec VNC par exemple),
il faudra utiliser la version : « Raspberry Pi OS with desktop« .

Ici je vous propose d’installer côté serveur :

– SCREEN ( pour ce qui ne connaissent pas, cela vous permet de lancer vos logiciels dans une console avec un écran par application ).
– CRX-COM ( ici pour le pilotage du poste via port série depuis votre navigateur WEB ).
– PYTHON / COM/TCP ( permet de partager votre port série par le réseau, complémentaire à CRX-COM, il vous permettra de tester FLRIG ).
– SEREN ( il permet de partager l’audio, il est possible de se connecter à plusieurs personnes sur un flux audio ).

Ici on démarre qu’en mode console pas la peine de charger un serveur graphique qui sert à rien ici, pour ce faire :

Lancez cette commande sur le RASBERRY :

root@f4eyq-raspberrypi1 opt # raspi-config

Dans boot options (3) choisissez « B1 Desktop / Cli » puis : « B1 Console ».
Redémarrez l’ensemble.

Côté réseau :

Rien de spécifique ici, je configure une adresse IP à mon RASPBERRY : (ici 192.168.0.166)

pi@rmtrpi-f4eyq-1-56 ~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto eth0
iface eth0 inet static
 address 192.168.0.166
 gateway 192.168.0.254
 netmask 255.255.255.0
 broadcast 192.168.0.255

Côté HARDWARE :

Avant de continuer vous devez brancher vos câbles USB sur le RASPBERRY, interface CAT system et autres cartes sons USB si c’est pas déjà fait. Voici une série de commandes qui vous seront utiles pour mieux connaître la partie HARDWARE :

pi@rmtrpi-f4eyq-1-56 ~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

On y voit :
– Ma carte son USB « C-Media »
– Mon interface YAESU USB/série : « Prolific Technology, Inc. PL2303 Serial Port »

Côté cartes sons, le RASPBERRY en a une intégrée que l’on ne vas pas utiliser ici,
Il vous faut créer le fichier de blacklist ci dessous puis redémarrer le PI, enfin configurer ALSA :

# Créer ce fichier puis redémarrer le pi :
vim /etc/modprobe.d/raspi-blacklist.conf
blacklist snd_bcm2835

#Ensuite configuration alsa : 
vim /usr/share/alsa/alsa.conf

# Modifier comme ceci ( changer 1 par l'ID de votre carte ) exemple : 

defaults.ctl.card 1
defaults.pcm.card 1

#Relancer la commande aplay -l pour visualiser l'ID.

Notez bien que la carte son USB est : CARD 0 et DEVICE 0 c’est important pour la suite.

pi@rmtrpi-f4eyq-1-56 ~ $ aplay -l
**** Liste des Périphériques Matériels PLAYBACK ****
carte 0: Device [C-Media USB Audio Device], périphérique 0: USB Audio [USB Audio]
  Sous-périphériques: 0/1
  Sous-périphérique #0: subdevice #0
root@f4eyq-raspberrypi1 ~ # cat /etc/modprobe.d/alsa-base.conf
options snd-usb-audio index=-2

Pensez à désactiver le « loopback audio » c’est à dire la copie du sons du haut-parleur vers le micro pour cela,
Lancer alsamixer, choisissez votre micro (via flèches) puis appuyez sur la touche « m » pour faire disparaître le symbole « m » :

Sinon le son du micro sera renvoyé sur le haut parleur.

Côté logiciels serveur :   ( SEREN pour la VOIP et CRX-COM ou PY-SERIAL pour la commande du TRX ) :

J’ai conçu un script qui automatise la configuration :
https://git.crx.cloud/f4eyq/crx-com/tree/master/scripts

L’installation se fait via cette commande : ( en une seule ligne, vous pouvez aussi lancez chaque commande une par une )

wget --output-document /tmp/setupcrx.bash https://git.crx.cloud/f4eyq/crx-com/raw/master/scripts/setup_server.bash;chmod +x /tmp/setupcrx.bash;/tmp/setupcrx.bash;

Ensuite, il faut modifier le fichier station.conf :

pi@rmtrpi-f4eyq-1-56 remote $ pwd
/opt/crx/conf/remote
pi@rmtrpi-f4eyq-1-56 remote $ ll
total 16
-rw-r--r-- 1 root root 47 sept. 30 09:43 station.conf
lrwxrwxrwx 1 root root 36 nov.  21 05:36 voip.conf -> /opt/crx/conf/remote/voip_hight.conf
-rw-r--r-- 1 root root 33 sept. 30 09:49 voip_hight.conf
-rw-r--r-- 1 root root 31 sept. 30 09:49 voip_low.conf
-rw-r--r-- 1 root root 29 sept. 30 09:49 voip_mid.conf
pi@rmtrpi-f4eyq-1-56 remote $

pi@rmtrpi-f4eyq-1-56 remote $ cat station.conf
REMOTE_MODE="y"
SOUND_CARD="plughw:0,0"
STATION_NAME="f4eyq-1"

J’y renseigne le nom de ma station remote ici « f4eyq-1 » et aussi l’ID de ma carte son (voir ci dessus la commande aplay -l qui permet d’obtenir l’ID).

Ensuite j’ajoute la VOIP pour qu’elle se lance au démarrage du PI (via le fichier /etc/rc.local), pour ce faire j’ajoute cette ligne :

sudo su - pi -c "screen -dm -S pistartup /opt/crx/seren/voip.bash --start";

Avant de redémarrer votre PI, je vous invite à tester la commande : ( à lancer en tant que l’utilisateur pi )

/opt/crx/seren/voip.bash --start

Celle-ci va lancer le logiciel de VOIP SEREN avec la bonne configuration.

Notez que SEREN va écouter sur le port 8110 en UDP.

La partie commande est installé via le script d’installation, j’ai pour cela prévu 2 scripts « SYSTEMD » :

pi@rmtrpi-f4eyq-1-56 opt $ ll /etc/systemd/system
total 72
-rw-r--r-- 1 root root 1551 avril 29  2019 autologin@.service
drwxr-xr-x 2 root root 4096 mai   27  2020 bluetooth.target.wants
lrwxrwxrwx 1 root root   44 sept. 30 09:49 crx_com_tcp.service -> /opt/crx/crx-com/scripts/crx_com_tcp.service

Notez que par défaut c’est CRX-COM qui est utilisé pour gérer les commandes via ce service :
/opt/crx/crx-com/scripts/crx_com_tcp.service

Le service CRX-COM va écouter sur le port 9090 en TCP.

Pour changer le port d’écoute de CRX-COM voici comment procéder :
– Se rendre dans le dossier : /opt/crx/crx-com
– Editez le fichier config.ini

Puis changer cette variable avec le numéro de port que vous souhaitez :
LISTEN_PORT

Relancez ensuite le service :

systemctl stop crx_com_tcp.service
systemctl start crx_com_tcp.service

Si vous avez besoin, voici la page du projet CRX-COM :
https://project.crx.cloud/crx-com

Pour ceux qui veulent changer la qualité de la VOIP (et donc jouer avec la bande passante) cela se fait via cette commande :

pi@rmtrpi-f4eyq-1-56 scripts $ cd /opt/crx/crx-com/scripts
pi@rmtrpi-f4eyq-1-56 scripts $ sudo ./voip.bash --switch="low"

Bien sur vous pouvez choisir entre :  low, mid, hight(défaut).

Pour ceux qui veulent tester avec FLRIG :

Il faut utiliser ce script : /opt/crx/crx-com/scripts/tcp_serial_catsystem.service

Puis ces commandes : ( on va simplement désactiver CRX-COM et activer TCP-SERIAL à la place )

sudo systemctl stop crx_com_tcp.service
ln -s /opt/crx/crx-com/scripts/tcp_serial_catsystem.service /etc/systemd/system/tcp_serial_catsystem.service
sudo systemctl daemon-reload
sudo systemctl enable tcp_serial_catsystem.service
sudo systemctl start tcp_serial_catsystem.service


3. Configuration du client.

Partie VOIP :

La configuration cliente se fait comme pour la partie serveur,
On installe la solution via cette commande :

wget --output-document /tmp/setupcrx.bash https://git.crx.cloud/f4eyq/crx-com/raw/master/scripts/setup_client.bash;chmod +x /tmp/setupcrx.bash;/tmp/setupcrx.bash;

Comme pour la partie serveur, on va configurer le tout via le station.conf,
à la différence du serveur, on va renseigner ici l’IP et le PORT pour la VOIP,
On passe aussi la variable REMOTE_MODE à n.

REMOTE_MODE="n"
STATION_REMOTE_PORT=8110
STATION_REMOTE_HOST=192.168.0.166
SOUND_CARD="plughw:0,0"
STATION_NAME="f4eyq-remote"

Notez que une fois le système fonctionnel via votre LAN, vous pourrez alors modifier :
STATION_REMOTE_PORT=[votre port UDP VOIP]
STATION_REMOTE_HOST=[votre IP publique]

Avec le port et l’IP Publique de votre BOX (pour un accès distant à votre station REMOTE).
Notez que vous devez aussi vérifier l’ID de la carte son (via aplay -l) et ajuster le station.conf si besoin.

Partie « commande » du TRX :

Pour cela si vous utilisez CRX-COM, connectez vous sur le site : https://ham.crx.cloud/
Le gros avantage par rapport à FLRIG et que votre client est dans votre navigateur WEB (pas de mise à jour faire).

Lancer la configuration CAT via le bouton CAT :
– Rentrez l’IP et le port du RASPBERRY (cliquez sur le bouton « Run-Https »), acceptez alors l’alerte de sécurité SSL.
– Puis cliquez sur le bouton « Connect ».
– Puis renseignez les informations du TRX ( constructeur, port et vitesse ).
– Enfin cliquez sur le bouton « Save apply config, connect ».

Votre navigateur WEB va alors communiquer avec le RASPBERRY PI « ‘REMOTE ».

Voici comme exemple ma configuration :
– J’ai renseigné l’adresse IP publique de ma BOX, le port de CRX-COM (ici 9090)
– Le modèle de mon Transceiver ici FT897
– Le port de l’interface CAT ici /dev/tty/USB0
– Et la vitesse du port ici 4800 bauds.

Si vous utilisez FLRIG, lancer le programme puis cliquez sur « Config »/ »Setup »/ »TCP-IP » :
Renseignez alors l’IP et le port distant.

Puis dans « Config »/ »Setup »/ »Transceiver » vous pouvez choisir votre TRX.

4. Configuration de votre box internet & tests :

Ici le serveur sera visible via 4 ports ( avec FIREWALL pour limiter tous les accès à une IP distante ) :
– 1 port pour le contrôle distant : SSH (et pour ceux qui utilisent VNC avec un tunnel SSH sur le port 5900)
– 1 port pour la VOIP.
– 1 port pour le port série via Python (pour ceux qui test FLRIG).
– 1 port pour le port séria via CRX-COM.

Pour ceux qui utilise OPEN-VPN, dans ce cas, faite passez tous vos ports via le VPN et la VOIP en dehors. Notez que si vous voulez expérimenter vous pouvez aussi faire passer la VOIP par le VPN mais gare à la latence (ping > 100ms).

Reportez vous à la matrice de flux que vous avez définie dans l’étape 1.

Tests :

Sur votre PC client :
– Commencer par régler tous les niveaux sons : à 50% pas plus (micro et sortie son).

Sur le RASPBERRY :
– Comme le client, mettez bien tous les niveaux son à 50% pour commencer et régler sur votre interface son, vos 2 résistances ajustables.
– Je vous conseil aussi d’utiliser les binaires suivant pour générer des sons côté LINUX via ces 2 commandes :

speaker-test -t sine -f 1750

aplay /usr/share/sounds/alsa/Front_Center.wav

Ensuite l’idée c’est d’ajuster l’encodage audio et la fréquence de récupération des données CAT suivant :
– Votre débit réseau et celui de votre serveur.
– La latence entre vous et votre serveur.

Pour ce faire, je vous conseil, un talki VHF, mettre votre station de base sur la fréquence du talki avec une charge fictive et passer en émission. Sinon j’utilise pas mal aussi le WEB SDR http://websdr.ewi.utwente.nl:8901/ pour contrôler la configuration finale.

Ajuster les scripts que l’on a créé lors de l’installation pour avoir un minimum de latence audio/cat.

Vous pouvez aussi activer le son du micro ( via la commande alsamixer sur le RASPBERRY ), branchez un HP externe sur votre RASPBERRY, puis comparez le son du HP côté RASPBERRY avec celui de votre client VOIP.

Pour avoir la latence la plus faible, ici je descend à ~200 ms (avec un pi1, beaucoup moins avec un pi4).
Ici vous pouvez ajuster la valeur -b (bitrate) dans les scripts VOIP :

– Ici j’ai mis : 500000 par défaut.
– Vous pouvez ajuster celle ci à minima à 6000 côté client et côté serveur ( on passe alors de 16kb/sec à environ 2kb/sec ).

Voici ce que je recommande :

Pour le RASPBERRY PI 1 : Paramètre C : 0

Pour le RASPBERRY PI 4 : Paramètre C : 3 à 5

=> Cela va agir sur la qualité d’encodage OPUS et donc sur l’utilisation CPU.

Si vous souhaitez une configuration audio « HQ » (62Kb/sec), voici ce qu’il faut utiliser (côté client et côté serveur) :

Côté client, utiliser : -C 5 -b 500000

seren -t 1 -S -n f4eyq-remote -c [IP DU SERVEUR] -d plughw:1,0 -C 5 -b 500000

Côté serveur, utiliser aussi : -C 5 -b 500000

seren -S -a -n f4eyq-1 -d plughw:0,0 -C 5 -b 500000

Notez pour ceux qui veulent modifier les valeurs côté client/serveur, vous pouvez éditer ces fichiers,
Normalement j’ai déjà tout pré-configuré.

/opt/crx/crx-com/scripts

voip_hight.conf
voip_low.conf
voip_mid.conf

5. Sécurité de votre installation :

Côté matériel :

– Onduleur / parafoudre. ( si possible ).
– Pouvoir brancher/débrancher le poste à distance (via un relais/sortie GPIO du RASPBERRY).
– Certain on même pensé à cela pour les antennes : https://vimeo.com/133917999
– Prévoir un timeout sur l’émission (en cas de coupure réseau) – solution à réfléchir, je suis preneur de vos pistes.

Côté logiciels :

A faire ici à minima :
Mettre vos mots de passe dans un conteneur sécurisé ( https://keepass.info/ ) ou dans un EXCEL chiffré par exemple.
Essayer au maximum de ne pas tout faire en root, lancer si possible les logiciels avec un utilisateur lambda côté serveur, ici « pi ».
Créez vous un utilisateur sur le RASPBERRY :  ( générez vous un mot de passe via : https://passwordsgenerator.net/ )

useradd bastien
passwd bastien
mkdir /home/bastien
chown bastien:bastien /home/bastien

Editez le fichier : /etc/ssh/sshd_config
Avec ceci :
DenyUsers pi

Profitez en aussi pour mettre un mot de passe costaud pour l’utilisateur pi (avec le générateur de mot de passe ci dessus) et la commande passwd pi

Notez qu’il faut éviter de supprimer l’utilisateur pi car il est utilisé par les scripts/services RASPBERRY.
Enfin pensez à utiliser votre clé SSH (plus simple et plus sécurisé que de simple mot de passe).

Limiter les connexions au port SSH sur votre BOX ( en limitant les adresses IP Sources qui y accède ).

Mettez en place un FIREWALL IPTABLES sur le RASPBERRY, ici je passe par SHOREWALL un outil,
qui nous génère les règles IPTABLES à la volée, notez que UFW marche aussi très bien.

Pare-feu UFW (option 1) : 

UFW s’installe et se configure plus simplement que SHOREWALL c’est pourquoi je vous le propose ici :

Remplacer [MON IP PUBLIQUE CLIENTE] par l’IP publique de votre client « REMOTE »,
Attention à adapter aussi l’IP du LAN ici : 192.168.1.0/24   ( il possible que ce soit 192.168.0.0/24 chez vous ) :

#installation de UFW 
apt install ufw

#politique par défaut, on bloque tout en INPUT, on autorise tout en sortie :
ufw default deny incoming
ufw default allow outgoing

#politique d'accès SSH + port 8110/UDP et 5209/TCP pour le remote control du TRX : 
ufw allow in proto tcp from 192.168.1.0/24 to any port 22 comment 'Allow ssh lan'
ufw allow in proto tcp from [MON IP PUBLIQUE CLIENTE]/32 to any port 22 comment 'Allow ssh r44'

ufw allow in proto udp from [MON IP PUBLIQUE CLIENTE]/32 to any port 8110 comment 'Allow remote voip'
ufw allow in proto tcp from [MON IP PUBLIQUE CLIENTE]/32 to any port 5209 comment 'Allow remote crxcom'

#pour activer le firewall, attention cela coupe le SSH lorsque l'on active le FW, il faut se réconnecter ensuite. 
ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y

#pour afficher la politique de sécurité :
sudo ufw status verbose
sudo ufw status numbered

#exemple pour effacer une règle : 
sudo ufw delete 3

Notez que si vous utilisez un serveur TIGHTVNC/VNC, il faudra aussi ouvrir le port TCP 5901 :

ufw allow in proto tcp from 192.168.1.0/24 to any port 5901 comment 'Allow remote vnc'


Pare-feu SHOREWALL (option 2):  

Voici ma configuration (faite sur un PI1 avec 2 cartes réseau WIFI/LAN), qui peut vous inspirer je pense :

root@f4eyq-raspberrypi1 shorewall # cat /etc/default/shorewall

startup=1

root@f4eyq-raspberrypi1 shorewall # cat zones

#ZONE TYPE
zfw firewall
zlan2eth ipv4
zlan2wlan ipv4

root@f4eyq-raspberrypi1 shorewall # cat interfaces

#ZONE INTERFACE
zlan2eth eth0
zlan2wlan wlan0

root@f4eyq-raspberrypi1 shorewall # cat policy

#SOURCE DEST POLICY LOG LEVEL
zfw all ACCEPT
zlan2eth all DROP $LOG
zlan2wlan all DROP $LOG
all all REJECT $LOG

Définissez vos IP d’administration / de remote ici par exemple ici : ( vous remplacerez IPADMINSECOURS, IPPUB1.XXX et IPADMIN1 par vos IP )

root@f4eyq-raspberrypi1 shorewall # cat params

LOG=info
MGMT_WLAN=IPADMIN1,IPADMIN2,IPPUB1.XXX
MGMT_ETH=IPADMINSECOURS

root@f4eyq-raspberrypi1 shorewall # cat rules

#ACTION SOURCE DEST PROTO DPORT SPORT ORIGDEST RATE
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

ACCEPT zlan2eth:$MGMT_ETH $FW tcp 22
ACCEPT zlan2wlan:$MGMT_WLAN $FW tcp 22

ACCEPT zlan2wlan:$MGMT_WLAN $FW udp 3105
ACCEPT zlan2wlan:$MGMT_WLAN $FW tcp 4207
ACCEPT zlan2wlan:$MGMT_WLAN $FW tcp 5209

ACCEPT $FW zlan2eth all
ACCEPT $FW zlan2wlan all

Ping(ACCEPT) zlan2eth $FW
Ping(ACCEPT) zlan2wlan $FW

Maintenant qu’on a défini notre politique, on va relancer SHOREWALL, on ne devrait pas avoir d’erreur :

root@f4eyq-raspberrypi1 shorewall # /etc/init.d/shorewall restart
[ ok ] Restarting shorewall (via systemctl): shorewall.service.

En cas de pépin, on peut lister les détails des logs par :

root@f4eyq-raspberrypi1 shorewall # journalctl -xe

Gardez toujours une connexion SSH en plus quand vous configurez votre FIREWALL ( pour ne pas vous couper la branche ! ).
Enfin testez via un scan de port que tout va bien : nmap -P0 [ADRESSE IP] pour voir si votre politique de sécurité est OK,
Puis faite un accès SSH depuis une de vos IP d’administration si tout va bien, votre FIREWALL est fonctionnel.

Une fois tout OK, on met SHOREWALL au démarrage du PI et on redémarre le serveur :

root@f4eyq-raspberrypi1 shorewall # systemctl enable shorewall
Synchronizing state of shorewall.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable shorewall
Created symlink /etc/systemd/system/basic.target.wants/shorewall.service → /lib/systemd/system/shorewall.service.


6. Implémentation d’OPEN-VPN :
(optionnel)

Notez que ici je met à disposition un pack VPN pour les membres VIP du CRX-CLOUD. Si vous voulez avoir votre propre serveur suivez l’étape « Implémentation OPENVPN côté serveur », sinon contacter moi pour obtenir votre pack client.

Ici je vous propose de voir comment implémenter la partie OPEN-VPN côté client et pour les plus motivés/experts d’entre vous côté serveur,
voici le récapitulatif :

[RASPBERRY-PI:Client OPENVPN] ————-[INTERNET] [ SERVEUR OPEN-VPN ] [INTERNET] ————- [ PC-CLIENT : Client OPENVPN ]

Implémentation OPENVPN sur le client :

La configuration OPENVPN et presque similaire à WINDOWS et LINUX.

Notez que ici le VPN est destiné à transférer de la VOIP et des commandes CAT ( donc proche du temps réel ), c’est pourquoi on travaille en UDP.

Pour WINDOWS, voici ma configuration, celle-ci se trouve ici :
C:\Users\{utilisateur}\OpenVPN\config\ elle doit être avec l’extension « .ovpn » :

client
dev tun
proto udp
remote monserveurvpn 8443
resolv-retry infiniteµ
nobind
persist-key
persist-tun
remote-cert-tls server
ca ca.crt
cert f4eyq-laptop1.crt
key-direction 1
key f4eyq-laptop1.key
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
#comp-lzo
verb 0

Celle-ci utilise ces fichiers de « chiffrements » en provenance de ma PKI :

ca.crt
f4eyq-laptop1.crt
f4eyq-laptop1.key
ta.key

Pour LINUX, voici ma configuration sur le RASPBERRY :

client
dev tun
proto udp
remote monserveurvpn 8443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
ca ca.crt
cert f4eyq-raspberrypi.crt
key-direction 1
key f4eyq-raspberrypi.key
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
verb 0


Implémentation OPENVPN côté serveur :

Cette étape n’est à suivre que si vous souhaitez avoir votre propre serveur VPN (il vous faudra un serveur dédié sur Internet au mieux ou au pire votre connexion ADSL/FIBRE mais avec une adresse IP fixe).

Là cela se corse un peu niveau technique, car vous allez devoir utiliser une PKI pour générer les clés et certificats des clients VPN.
Ici j’utilise que l’OS DEBIAN, mais cela fonctionne sur tout serveur LINUX.

Configuration de votre « PKI » :

Je commence par installer EASY-RSA, c’est un ensemble d’outil pour gérer une PKI LINUX, celle-ci est souvent utilisée avec OPEN-VPN.

cd /opt/
git clone https://github.com/OpenVPN/easy-rsa.git
cd /opt/easyrsa/easyrsa3/
cp vars.example vars

Dans le fichier vars, je vais modifier ceci :

export KEY_COUNTRY="FR"
export KEY_PROVINCE="IDF"
export KEY_CITY="VilleDeMonServeur"
export KEY_ORG="monVpn"
export KEY_EMAIL="admin@mondomaine.fr"
export KEY_OU="myOu"

Ensuite je vais définir la durée de vie des certificats que je génère : (ici 1 an pour les clients et la clé du serveur PKI l’AC elle vivra 5 ans).

set_var EASYRSA_CA_EXPIRE 1825
set_var EASYRSA_CERT_EXPIRE 365

Ensuite je commence par initialiser ma PKI :

# ./easyrsa init-pki

Puis l’AC qui me servira à signer et générer les certificats clients :

# ./easyrsa build-ca nopass

Maintenant je peut générer le certificat de mon serveur VPN :

# ./easyrsa gen-req monserveurvpn nopass
# ./easyrsa sign-req server monserveurvpn

Cela va générer 2 fichiers :

=> /opt/easyrsa/easyrsa3/pki/issued/monserveurvpn.crt
=> /opt/easyrsa/easyrsa3/pki/private/monserveurvpn.key

Maintenant je génère les clés de sécurité utilisé côté clients/serveur :

# ./easyrsa gen-dh
# openvpn --genkey --secret ta.key

Cela générer 2 fichiers :

=> /opt/easyrsa/easyrsa3/ta.key
=> /opt/easyrsa/easyrsa3/pki/dh.pem


Configuration du service OPEN-VPN cible :

Maintenant que j’ai généré tous mes fichiers de chiffrement, je peux attaquer la configuration du service OPEN-VPN,
Ici par sécurité on peut utiliser une VM dédiée pour la PKI ou tout faire sur le même serveur à vous de voir :

Je déploie ici mes fichiers de ma PKI vers mon service OPEN-VPN :

cp /opt/easyrsa/easyrsa3/ta.key /etc/openvpn/server/ta.key
cp /opt/easyrsa/easyrsa3/pki/ca.crt /etc/openvpn/server/ca.crt
cp /opt/easyrsa/easyrsa3/pki/issued/monserveurvpn.crt /etc/openvpn/server/server.crt
cp /opt/easyrsa/easyrsa3/pki/private/monserveurvpn.key /etc/openvpn/server/server.key
cp /opt/easyrsa/easyrsa3/pki/dh.pem /etc/openvpn/server/dh2048.pem

Et enfin sa configuration cible, je ne rentre pas dans les détails techniques, si vous avez besoin une documentation est fournie en ligne sur le site OPEN-VPN :

port 8443
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh2048.pem
topology subnet
server 10.77.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
client-config-dir /etc/openvpn/ccd
ccd-exclusive
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/server/ta.key 0
auth SHA256
cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 5

Ici j’utilise un fichier par client dans le sous-dossier « ccd » :
Mais c’est optionnel si vous définissez votre pool d’IPs clientes.

Exemple :

# cat /etc/openvpn/ccd/f4eyq-raspberrypi
ifconfig-push 10.77.0.25 255.255.255.0

Voilà j’espère que ce guide vous aura aidé dans la réalisation de votre « remote station config open source ».
N’hésitez pas à me contacter si vous avez des remarques/idées sur le sujet ( f4eyq ( at ) crx.cloud ).

73 à tous !

PS : Pour les utilisateurs donateurs du projet CRX-RADIO-CLOUD, je peux vous fournir un pack de connexion VPN avec un fichier ZIP contenant la configuration VPN cliente (fichier OVPN+certifcat & clé). Si vous êtes intéressé, me contacter par email : f4eyq ( at ) crx.cloud. Pour disposer d’une latence minimale, j’ai limité à 30 clients réparti sur 2 serveurs dédiés, sachant que je dispose ici de 2x 1GB de bande passante Internet chez OVH.

Notes :
RASPBERRY PI OS : https://www.raspberrypi.org/software/operating-systems/
WIN32DISKIMAGER : https://sourceforge.net/projects/win32diskimager/

Softs VOIP testés sous LINUX :
PAROLE : http://holdenc.altervista.org/parole/index.html
SEREN : http://holdenc.altervista.org/seren/index.html
IC706 : https://github.com/csete/ic706-remote/blob/master/src/audio_server.c
MUMBLE/MURMURE.

Contrôle distant :
CRX-COM : https://project.crx.cloud/crx-com-rasb-ft817
FLRIG.

Firewall :
SHOREWALL : https://shorewall.org

Solution VPN : https://openvpn.net

Solution Windows testée :
Windows : MUMBLE/MURMURE/SKYPE + HAM Radio Deluxe client/serveur,
Et VIRTUAL AUDIO CABLE pour les modes digitaux en VOIP.

Articles relatifs :
Welcome

Remote ham radio operation through a Raspberry Pi

New-FLDIGI Install Script for Raspberry Pi (Latest Version – 3.23.13)

Matériels :
Férites : https://fr.aliexpress.com/ ( cherchez ferite, vous y trouverez votre bonheur ).