Atelier Camp CHATONS 2022 : "Un chaton nomade et autonome en énergie"

• Autonomie en énergie
• Hébergement de services sur connexion 4G

Présentation du prototype d'expérimentation / démonstration en cours de construction :

• PS #1 : 28w crête : maximum (neuf, pas trop chaud, ciel dégagé, panneau bien orienté), suffisant pour petite batterie, chargeur de téléphone. Un Raspbery Pi, maybe.

• PS #2 : 100W crête, batterie 154 W.h. chargeur et Mini-onduleur intégré;

• PS #3 : 200W crête - 191W observé sur une journée ensoleillée

• Puissance (en W) = débit du robinet

• Quantité d'énergie (en W.h) = quantité d'eau dans la baignoire

• débranché, fournit de la tension, mais pas d'intensité = 0W
• branché en court circuit , intensité max, mais tension nulle = 0W aussi
• entre les deux il y a un point de fonctionement optimal où la puissance fournie par le paneau solaire est maximale. Mais ce point dépends de plusieurs paramètres : le panneau solaire, la température, l'ensoleillement, l'age du capitaine, ...

• ou deuxième type de controleur : PWM (pulse width modulation) - Low cost. S'assurent de ne pas surcharger la batterie mais ne fait pas fonctionner le panneau à sont point optimal).

Q&A

• 1. Un micro-contrôleurs (très faible consomation électrique) qui fonctionnerait tout le temps, pour piloter l'allumage ou l'arrêt du système et collecter des données de capteurs (voire héberger un mini site web de monitoring) fonctionnement sans WiFi et sans routeur 4G quand la batterie est trop déchargée (eventuellement utilisation de LoRa, protocole de communication sans fil très basse consommation électrique, lent mais longue portée)

• batterie : 611€
• panneau solaire : 375 €
• 2x 5m câbles 6mm2 + connecteurs MC4 : 19 €

• panneaux solaires : 20-30 ans (film de protection en verre ou matériau synthétique qui jaunit ou se dégrade), cellules solaires très durable
• batteries au plomb (se recycle très bien, se réemploie potentiellement) beaucoup plus économiques voire batteries usagées usage d'un smartphone à la place de l'odroid pour réduire la consommation électrique
• consommation similaire odroid VS smartphone. quel intérêt d'utiliser un smartphone?

• récup de cellules Li-Ion (10wh, 3Ah) + carte USB (par exemple diymore.cc mais se trouve partout), (autonomie de 4h avec 2 batteries, 8h avec 4)

• bootloader rPi non-libre
• possibilité d'utiliser un SSD nvme et un SSD ou HDD SATA avec l'odroid

• projet flou (idéalement : tout le hackerspace)
• beaucoup de photos, idéalement de la vidéo (vlog)
• yeswiki avec fiche pour chaque étape rendre accessible les données de l'extérieur
• solution classique : VPN - mais requiert donc une partie pas mobile

Le problème

La recherche d'une solution

• 1. utiliser shadowsocks pour encapsuler le traffic wireguard [1], [2]
• 2. utiliser xray avec les protocoles dokodemo-door et reality pour encapsuler le traffic wireguard [3], [6], [7]
• 3. utiliser un fork de wireguard, comme amnesia par exemple [5], qui rajoute des fonctions de camouflage directement dans le protocole wireguard.

La mise en place de la solution retenue

• Je ne détaille pas ici l'installation ni la configuration de wireguard, qui est tout a fait classique, sauf pour les spécificités liées à l'encapsulation avec xray
• Dans les exemples de configuration il faut remplacer les variables du genre $USER_ID, $PRIVATE_KEY, $SHORT_ID, ..., par les valeurs générées à l'aide des commandes suivantes (à exécuter après l'installation de xray)

• # Generate X25519 keys using Xray's built-in command
   _x25519=$(xray x25519)
   PRIVATE_KEY=$(echo "$_x25519" | awk -F': ' '/Private key/{print $2}')
   PUBLIC_KEY=$(echo "$_x25519" | awk -F': ' '/Public key/{print $2}')
   # Generate a unique UUID for the client
   CLIENT_UUID=$(uuidgen)
   # Generate a random short ID
   SHORT_IDS=$(openssl rand -hex 8)
   # Define server address and port
   SERVER_ADDRESS="IP address or DNS name of your wireguard server"
   PUBLIC_PORT=8443
   PRIVATE_PORT=6666
  

• Le port public choisi pour xray est le 8443. L'idée étant de faire croire qu'il s'agit d'une connexion https normale, le mieux serait d'utiliser le port 443. Mais comme nous avons un serveur web sur la même IP, on a pris le port 8443 pour éviter tout conflit. Il devrait être possible de tout mettre sur le port 443 en utilisant un reverse proxy SNI. Nous testerons ça plus tard.
• Le port privé est le port sur lequel écoute le serveur wireguard. Il n'a pas besoin d'être ouvert au niveau du firewall si les seuls clients qui s'y connectent passent par xray. Quand on passe par xray, on s'y connecte uniquement via l'interface loopback.
• Dans les exemples de configuration, on peut voir du google. C'est le nom du serveur web qui est utilisé pour camoufler le traffic. Il n'y à aucune connexion effective vers ce serveur. Et google c'est juste à titre d'exemple parce-que nous ne voulons pas dévoiler le nom que nous avons réellement utilisé. Il convient de choisir un nom DNS qui ne soit pas bloqué des deux coté du VPN et qui n'attire pas l'attention. Il y à d'autres contraintes a respecter [13]

installation de xray sur le serveur

{
   "log": {
       "loglevel": "debug"
   },
   "inbounds": [
       {
           "listen": "0.0.0.0",
           "port": $PUBLIC_PORT,
           "protocol": "vless",
           "settings": {
               "clients": [
                   {
                       "id": "$USER_ID",
                       "flow": ""
                   }
               ],
               "decryption": "none"
           },
           "streamSettings": {
               "network": "tcp",
               "security": "reality",
               "realitySettings": {
                   "show": false,
                   "dest": "www.google.com:443",
                   "xver": 0,
                   "serverNames": [
                       "www.google.com"
                   ],
                   "privateKey": "$PRIVATE_KEY",
                   "shortIds": [
                       "$SHORT_ID"
                   ]
               }
           }
       }
   ],
   "outbounds": [
       {
           "protocol": "freedom",
           "tag": "direct"
       }
   ]
}

Modification de la configuration wireguard du serveur

Intallation de xray sur le client

services.xray = {
    enable = true;
    settingsFile = "/etc/xray/config.json";
  };

  environment.etc."xray/config.json" = {
    source = /var/src/secrets/xray-config.json;
    user = "root";
    group = "root";
    mode = "0444";
  };

{
   "log": {
       "loglevel": "warning"
   },
   "inbounds": [
       {
           "tag": "wireguard",
           "port": $PRIVATE_PORT,
           "protocol": "dokodemo-door",
           "settings": {
               "address": "127.0.0.1",
               "port": $PRIVATE_PORT,
               "network": "udp"
           }
       }
   ],
   "outbounds": [
       {
           "protocol": "vless",
           "settings": {
               "vnext": [
                   {
                       "address": "$SERVER_ADDRESS",
                       "port": $PUBLIC_PORT,
                       "users": [
                           {
                               "id": "$USER_ID",
                               "encryption": "none",
                               "flow": ""
                           }
                       ]
                   }
               ]
           },
           "streamSettings": {
               "network": "tcp",
               "security": "reality",
               "realitySettings": {
                   "show": false,
                   "fingerprint": "chrome",
                   "serverName": "www.google.com",
                   "publicKey": "$PUBLIC_KEY",
                   "shortId": "$SHORT_ID",
                   "spiderX": ""
               }
           },
           "tag": "proxy"
       }
   ]
}

Modification de la configuration wireguard sur le client

• d'une part dans sa section [Interface] pour limiter le MTU à 1300 octets (MTU = 1300), comme pour le serveur
• d'autre part dans la section [Peer] correspondante au serveur wireguard, pour utiliser comme adresse de destination celle du service xray local au lieu de la véritable adresse du serveur wireguard (Endpoint = 127.0.0.1:$PRIVATE_PORT)
• et enfin, pour que la machine cliente puisse rediriger tout son trafic internet via le VPN wireguard, il fallait changer le paramètre allowedIPs de la section [Peer] correspondante au serveur wireguard. En effet, si on laisse 0.0.0.0/0, ::/0, on redirige aussi le trafic destiné a xray à l’intérieur du VPN. Et du coup ça se mord la queue et ne fonctionne plus. Pour ce faire on peut s'aider du site https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator qui permet de générer une liste de plages IP qui englobe tout internet sauf certaines adresses.

Résultats

Références

• 1. https://lowendtalk.com/discussion/170940/how-to-obfuscate-wireguard-traffic
• 2. https://www.reddit.com/r/WireGuard/comments/ucz53b/hiding_wireguard_with_ssh_to_avoid_restrictions/
• 3. https://btwiusearch.net/posts/wg-xray/
• 4. https://www.protectstar.com/en/blog/blocking-campaign-russia
• 5. https://docs.amnezia.org/documentation/amnezia-wg/*
• 6. https://www.40huo.cn/blog/wireguard-over-vless.html
• 7. https://computerscot.github.io/wireguard-over-xray.html
• 8. https://cscot.pages.dev/2023/04/13/cloudflare-warp/
• 10. https://github.com/XTLS/Xray-core
• 11. https://github.com/XTLS/Xray-core/discussions/2954
• 12. https://xtls.github.io/en/config/outbounds/wireguard.html
• 13. https://cscot.pages.dev/2023/03/02/Xray-REALITY-tutorial/#Determine-camouflage-website

1. Accès au code source de YesWiki sur GitHub avec git

git config --global user.name "Votre nom ou pseudo"
git config --global user.email "votre.email@votre-domaine.tld"

git config --global pull.rebase true

2. Installation de PHP et de quelques autres outils nécessaires au développement de YesWiki

apt-get install libnss3-tools php-common php-fpm php-curl php-gd php-json php-mysql php-xml php-mbstring php-zip php-json  curl jq -y
curl -1sLf 'https://dl.cloudsmith.io/public/symfony/stable/setup.deb.sh' | sudo -E bash
apt install symfony-cli
symfony server:ca:install 
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('sha384', 'composer-setup.php') === 'dac665fdc30fdd8ec78b38b9800061b4150413ff2e3b6f88543c636f7cd84f6db9189d43a81e5503cda447da73c7e5b6') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
mv composer.phar /usr/local/bin/composer
chmod +x /usr/local/bin/composer

3. Récupération d’une copie locale du code source de YesWiki

• si votre compte est membre de l’organisation GitHub de YesWiki vous pourrez travailler directement sur les dépôts officiels, comme dans les instructions que je donne. Si ce n’est pas le cas il faudra vous faire des forks des dépôts sur GitHub et adapter ce que j’explique pour travailler sur ces forks (voir la documentation de GitHub)
• je décris comment récupérer une copie locale des différents dépôts de code source de YesWiki et les lier entre eux en utilisant un script développé par MrFlos. Comme à chaque fois qu’on vous dit d’exécuter sur votre ordinateur un script téléchargé sur internet, il est fortement recommandé de bien examiner le contenu de ce script pour bien comprendre ce qu’il va faire et pour vérifier qu’il ne contient pas de code malveillant.

mkdir Developpements
wget https://forge.mrflos.pw/mrflos/nixos-config/raw/branch/main/scripts/init_yeswiki_repos.sh
less init_yeswiki_repos.sh

nano init_yeswiki_repos.sh

chmod +x init_yeswiki_repos.sh 
./init_yeswiki_repos.sh

cd ~/Developpements/yeswiki
rm tools/markdown # extension obsolète
rm tools/loginldap # nécessite d’avoir un serveur LDAP et d’être configuré pour pouvoir être utilisée
rm tools/lang/yeswiki-extension-lang # extension obsolète

4. Installation de VSCodium

curl -fSsL https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo/raw/master/pub.gpg | sudo gpg --dearmor | sudo tee /usr/share/keyrings/vscodium.gpg >/dev/null
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/vscodium.gpg] https://download.vscodium.com/debs vscodium main" | sudo tee /etc/apt/sources.list.d/vscodium.list
apt update
apt install codium

5. Installation de MariaDB et création d’une base de donnée pour YesWiki

apt install mariadb-server
mysql_secure_installation

CREATE DATABASE yeswiki;
CREATE USER 'yeswiki' IDENTIFIED BY 'mettre ici son mot de passe préféré !!!';
GRANT ALL PRIVILEGES ON yeswiki.* TO 'yeswiki';

6. Configurer TLS pour le serveur web de test

cd ~/Developpements/yeswiki
symfony server:ca:install

6. Lancer un serveur web de test

cd ~/Developpements/yeswiki
symfony server:start

J'ai réalisé le premier véritable programme informatique, lors de mon travail sur un ancêtre de l'ordinateur : la machine analytique de Charles Babbage.

• Les assets (css, js, ...) ne se chargaient pas dans le navigateur.
• La configuration de l'instance d'étherpad à utiliser n'était pas prise en compte
• Il y avait des erreurs php dans une dépendance de libreto

• j'ai créé une pull request sur le dépot git du package Yunohost
• et j'ai créé une autre pull request sur le depot git de Libreto

• Il est possible d’avoir un environnement de développement relativement évoluée dans le terminal avec, entre autres, de la coloration syntaxique, de l’aide à la saisie et à la navigation dans le code et l’ouverture simultanée de plusieurs fichiers, en utilisant des logiciels comme neovim ou emacs. Mais ces outils ne sont pas faciles à prendre en main quand on n’a pas l’habitude de les utiliser. Et il faut s’accorder pour utiliser le même outil. (La division entre utilisation d’emacs et de vi/vim/neovim est légendaire, voir l’artice sur la guerre des éditeurs de texte sur Wikipedia). Et je n’ai personnellement jamais réussi à me mettre à apprendre la foultitude de raccourcis claviers qu’il est nécessaire de maitriser pour utiliser l’un ou l’autre de manière efficace. Quand je fais de l’administration système j’utilise nano pour éditer des fichiers. Et ça me suffit largement. Et bien qu'il soit possible d'avoir de la coloration syntaxique avec nano, quand je fais du développement je suis plus a l’aise avec un IDE graphique comme Eclipse ou VSCodium.

• Quand on développe une application web, tout ne peut pas se passer dans le terminal. On est fréquemment appelé à faire des aller-retours entre l’environnement de développement pour modifier le code et le navigateur web pour tester l’application ou chercher des solutions sur internet. Alors les trolls vont me dire qu’il existe des navigateurs web en mode texte. Mais, heu…, non merci.