Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Debian

Bloquer la version de NodeJS pour Mastodon 4.2.0

Rédigé par dada / 28 septembre 2023 / Aucun commentaire


La toute dernière version de Mastodon s'accompagne d'un petit souci d'administration si vous utilisez Debian 12 (Bookworm) comme système d'exploitation pour votre serveur : NodeJS.

En effet, la version de NodeJS officiellement supportée est, malgré ce que dit la documentation, la 16.x et pas plus alors que Debian 12 embarque la version 18 dans ses valises. Pas de 18, pas de 20, donc. Enfin, pas exactement. Il est possible de les utiliser au prix d'une bidouille officiellement diffusée dans les réponses aux différents soucis relayés dans Github.

Enfin, si comme moi, vous n'avez pas envie de vous embêter plus que ça, voici comment faire pour être tranquille.

Installer le dépôt NodeJS 16 pour Debian 12

On commence par les keys :

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://deb.nodesource.com/gpgkey/nodesource-repo.gpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/nodesource.gpg

On ajout le dépôt : 

sudo echo "deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_16.x bookworm main
deb-src [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_16.x bookworm main" > /etc/apt/sources.list.d/nodesource.list

On fait le pinning qui va bien :

Dans /etc/apt/preferences.d/nodejs-mastodon ajoutez : 

Package: nodejs*
Pin: release o=Debian*
Pin-Priority: -1

Package: *
Pin: release o=deb.nodesource.com
Pin-Priority: 99

Vous pouvez maintenant supprimer la version NodeJS de Debian et installer la version des dépôts que vous venez d'ajouter : 
apt update
apt purge nodejs
apt install apt install nodejs=16.20.2-deb-1nodesource1

Un apt-cache pour vérifier tout ça : 

nodejs:
  Installed: 16.20.2-deb-1nodesource1
  Candidate: 16.20.2-deb-1nodesource1
  Version table:
     18.13.0+dfsg1-1 -1
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        150 http://deb.debian.org/debian unstable/main amd64 Packages
 *** 16.20.2-deb-1nodesource1 500
        500 https://deb.nodesource.com/node_16.x bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

Vous êtes tranquille maintenant ! Du moins, tant que NodeJS 14 est maintenu, ce qui commence à devenir un souci.

Rapport d'incident : j'ai cassé diaspodon.fr

Rédigé par dada / 08 mars 2022 / Aucun commentaire


Il y a des jours où la confiance vous embarque bêtement.

Fin février, je me lançais dans la mise à niveau de l'intégralité de l'infrastructure qui propulse les différents services que j'ai sous ma responsabilité : des instances Mobilizon, Peertube, Pixelfed et Mastodon. Une mise à niveau, c'est quand on passe d'une version majeure à une autre d'un système d'exploitation. Ce n'est jamais anodin (update != upgrade).

Étape 1 - 27 février 2022 - 15h45

Après avoir testé avec succès ces mises à niveau sur des serveurs de moindre importance, plein de confiance, je finis par couper diaspodon.fr pour m'en occuper. D'abord, un dump de la base de données PostgreSQL 9.6 puis un snapshot complet des volumes et, hop, la mise à niveau.

Étape 2 - 27 février 2022 - 16h30

Une fois la mise à niveau terminée sans problème, je relance le serveur, teste un ou deux trucs et retourne vaquer à mes occupations passionnantes du moment (coucou TWW3).

Étape 3 - 4 mars 2022 environ

Une semaine plus tard, Greenman me signale qu'on ne peut plus correctement le mentionner (le fameux @ + pseudo). Pas grave, me dis-je, c'est le seul avec ce souci. 48h plus tard, après un week-end chargé, je suis réveillé par des SMS des copains qui signalent tous une inactivité bizarre depuis au moins 9h. C'est cassé.

Étape 4 - 7 mars 2022 - 10h ~ 12h

La documentation était pourtant claire : à la fin de la mise à niveau (cf Étape 1), il fallait impérativement mettre à jour les index des bases de données pour éviter le cauchemar absolu : les duplicated entries. Chose que je n'ai pas faite sans sourciller. Devinez quoi ? J'ai du en virer, de ces cochonneries. Merci encore à Luc pour son aide formidable. Une fois corrigé à la main les dizaines de duplicate, je passe à la mise à jour qui fini par passer.
La tant attendue et redoutée mise à niveau de PostgreSQL 9.6 à PostgreSQL 13 est correctement finalisée. Il était temps.

Étape 5 - 7 mars 2022 - 12h ~ 13h

J'ai l'impression de voir le bout du tunnel quand, finalement, non. Sidekiq, outil nécessaire au fonctionnement de Mastodon, refuse de redémarrer.
Il s'avère, chers ami-e-s, que Debian 11 n'est pas complètement compatible avec la configuration officielle de Mastodon. Cette version de Debian n'a plus les bonnes dépendances pour faire tourner jemalloc, bidule connu des admin d'instance Mastodon pour contrôler la consommation en mémoire du logiciel. Quand, le 28 février, j'ai nettoyé les vieux paquets « inutilisés », j'ai cassé une deuxième fois l'instance.

Une fois compris, j'ai réinstallé les dépendances Ruby de Mastodon en virant l'option  RUBY_CONFIGURE_OPTS=--with-jemalloc et l’occurrence dans la configuration du service systemd de sidekiq.

Étape 6 - 7 mars 2022 - 13h15

Une conclusion

Lisez la doc, ou Luc, bordel !

Se faire un réveil 4.0 avec un Raspberry Pi

Rédigé par dada / 15 janvier 2020 / 10 commentaires


Je me suis toujours méfié des objets connectés. Ce n'est un secret pour personne : une grande partie des babioles vendues sous la bannière IoT ou objet connecté sont des machins non sécurisés, non maintenus, non écologiques et d'un intérêt plus que discutable.


Ceci dit, avec l'aide de la WebThings Gateway de Mozilla, il est possible de commencer à jouer avec son matériel existant pour le rendre connecté. Ce truc permet de garder le contrôle des-dits machins connectés puisque le cerveau de ces choses sera dans votre salon et pas sur des serveurs obscurs à l'autre bout du monde.

Un exemple que je vous propose : mettre de côté votre ancien réveil, qui marche très bien, pour le remplacer par un Raspberry Pi.

Les ingrédients

Pour ce faire, il vous faudra :
  • un Raspberry Pi (du Zero au RP4)
  • des enceintes classiques
  • un câble jack
  • l'URL de streaming de FranceInfo

Le Raspberry Pi

Vous allez commencer par utiliser WebThings Gateway comme système d'exploitation de votre Raspberry Pi. C'est une Rasbpian, basée sur Debian donc, modifiée par Mozilla, rien de plus.
Je ne vais pas m'éterniser sur la procédure d'installation : c'est très simple.
Il suffit d'aller télécharger l'image disponible ici, de flasher la carte SD avec et de placer cette-dite carte dans l'ordinateur.

Une fois que la bête a démarré, un nouveau réseau Wifi va apparaître. Connectez vous y depuis votre PC et suivez la procédure de configuration :
  • connectez-la au réseau wifi de votre box
  • créez un compte utilisateur
  • choisissez l'URL qui va bien
L'attribution de l'URL peut prendre du temps, ne paniquez pas, ne touchez à rien : Mozilla vous enverra un lien par mail quand tout sera effectif.

Installer l'extension Radio

Par défaut, WTG ne fait pas grand chose. Tout comme pour Firefox, Mozilla s'appuie sur les gens pour fournir des extensions en pagaille. Et ça marche plutôt pas mal si j'en crois le dépôt officiel.

Je vous laisse cliquer dans les menus pour installer Radio : Settings > Add-ons > le + en bas à droite -> Internet radio. 

L'add-on vient avec quelques webradios inconnues au bataillon. Pas grave, on va installer celle qui nous intéresse : la radio d'État.


Pour récupérer l'adresse de streaming, je suis passé par ce lien qui m'a permis de trouver ça :
  • http://direct.franceinfo.fr/live/franceinfo-midfi.mp3
Il est possible que le flux change ou qu'il ne soit pas vraiment fonctionnel alors prenez le temps de le vérifier. L'autre jour, par exemple, j'avais bien un flux lu mais il ne contenait pas le moindre son : méfiez-vous.

Maintenant, vous devriez avoir WTG correctement configuré dans votre Raspberry Pi. Il ne reste plus qu'à créer la règle qui va permettre d'allumer tout ça aux heures voulues.

Mettre en place le réveil 4.0

WTG fonctionne, en gros, avec deux principes : les choses (things) et les règles (rules).

Les règles permettent de faire faire des choses à vos choses. Vous suivez ?


Dans le cadre du réveil, on va s'amuser à dire à WTG d'activer la chose radio, avec le volume qui va bien, à l'heure qui va bien. Le panneau de création d'une règle est coupé en deux :
  • À gauche, la ou les conditions d'entrée
  • À droite, la ou les conditions de sortie


On va remarquer la complexité relative de la règle puisqu'il faut :
- Deux choses Clock qui déclenchent deux événements à 7h du matin
- Une chose Radio qui allume la radio
- Une chose Radio qui fixe le volume

En une seule phrase, la logique ressemble à ça : À 7h du matin, tu allumes la radio et à 7h du matin, tu montes le volume à 75.
La partie volume de ma règle n'est pas obligatoire. Elle est présente dans mon exemple parce que le volume de base, 50, est trop faible à mon goût.

Aller un peu plus loin

Dans mon cas personnel, j'ai décidé d'ajouter une règle qui arrête la radio à 8h. Pourquoi ? Parce que je dois impérativement décoller à 8h sans quoi je rate mon train.


Si vous avez capté la logique, j'ai utilisé une chose Clock qui se déclenche à 8h et une chose Radio qui arrête la boucle d'informations du matin.

Et voilà !

Conclusion

Vous n'avez plus qu'à laisser votre imagination tourner. Avec WTG, vous pouvez avoir des objets connectés qui se contrôlent depuis un ordinateur dans votre salon que vous pouvez arrêter quand vous le voulez et qui est entièrement open-source.

C'est sans intérêt, donc indispensable ! Bonne année !

Nextcloud, PHP-FPM, Nginx et Kubernetes

Rédigé par dada / 14 janvier 2019 / 7 commentaires




Ma première installation de Nextcloud dans Kubernetes était basée sur l'image Docker contenant Apache2. Aucun souci notable au niveau de la synchro des agendas, des fichiers ou encore des contacts. Par contre, la génération des miniatures des photos s'est révélée être un drame : Apache s'emballait et entraînait le nœud sur lequel il tournait avec lui, dans la tombe. Il me fallait une solution, j'ai donc décidé de changer de conteneur et de prendre celui basé sur PHP-FPM.

Un pod avec deux conteneurs

On entend souvent la rumeur racontant qu'un pod ne contient qu'un conteneur. C'est souvent vrai, mais c'est aussi faux. Dans l'exemple qui va suivre, le pod gérant Nextcloud contiendra le conteneur officiel de Nextcloud et un conteneur Nginx.

Contexte

Pour suivre, sachez que mon cluster, celui grâce auquel vous lisez ces quelques lignes, gère son système de fichier avec Rook, dont j'ai déjà parlé ici. Mes nœuds sont chez Hetzner, ce sont des CX21, du cloud public donc, et mes services sont exposés en NodePort derrière un Nginx configuré en LoadBalancer. Maintenant que vous savez ça, on peut y aller.

Le Deployment

On va commencer par balancer le Yaml qui marche : 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextcloud-deployment
spec:
  selector:
    matchLabels:
      app: nextcloud
  replicas: 1
  template:
    metadata:
      labels:
        app: nextcloud
    spec:
      containers:
      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
      - name: nextcloud
        image: nextcloud:14.0-fpm
        ports:
        - containerPort: 9000
        volumeMounts:
        - name: pv-nextcloud
          mountPath: /var/www/html
        resources:
          limits:
            cpu: "1"
      volumes:
      - name : nginx-config
        configMap:
           name: nginx-config
      - name: pv-nextcloud
        flexVolume:
          driver: ceph.rook.io/rook
          fsType: ceph
          options:
            fsName: myfs
            clusterNamespace: rook-ceph
            path: /nextcloud2

Il n'y a pas le Service associé pour la simple et bonne raison que chacun fait comme il le veut. Si vous êtes chez DigitalOcean, OVH ou chez un des GAFAM qui propose du k8s, vous aurez un LoadBalancer qui va bien. Si vous êtes comme moi, vous êtes réduit à faire du NodePort.

Ce qu'il faut comprendre

Vous remarquerez qu'il y a deux conteneurs : Nginx et Nextcloud-FPM. Nginx écoute sur le port 80 et va router le trafic à travers vers le port 9000 du conteneur de Nextcloud.

Nginx

      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
On va faire gober à Nginx deux points de montage : sa configuration et les sources de Nextcloud. Sans les sources de l'application, Nginx ne pourra pas avoir accès aux fichiers PHP, et ne servira donc à rien. On va donc prendre le point de montage originalement dédié à Nextcloud pour le monter une deuxième fois dans un deuxième conteneur, celui de Nginx.

Lifecycle

Remarquez la présence de la section lifecycle, elle permet d’exécuter ce que vous voulez au démarrage du conteneur. Quand j'apprenais à me servir de ce couple, je ne comprenais pas pourquoi Nginx ne voulait pas correctement fonctionner. J'ai passé du temps à comprendre que le conteneur Nginx et le conteneur Nextcloud n'avaient pas le même docRoot :
  • Nginx : /srv/html
  • Nextcloud : /var/www/html
Comprenez que les requêtes Nginx allaient chercher des fichiers dans /srv/html/blabla.php quand Nextcloud annonçait la présence de ses sources dans /var/www/html/blabla.php. Le bordel.

C'est là que je n'ai trouvé pas idiot l'idée de créer le chemin manquant au démarrage du pod avec un postStart. Du coup, j'avais Nginx et Nextcloud au diapason. Il est sans doute possible de configurer Nginx pour surcharger son docRoot, mais c'était l'occasion de jouer avec des commandes en amont de la création d'un conteneur.

Les deux points de montage

On a donc un point de montage pour les sources de Nextcloud :
        - name: pv-nextcloud
          mountPath: /var/www/html
Et un point de montage pour la configuration de Nginx :
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf

Là aussi, j'ai perdu un peu de temps avant de comprendre qu'il fallait balancer toute la configuration de Nginx et pas seulement ce que j'ai l'habitude de mettre dans les sites-enabled. C'est du moins à faire quand on écrase le nginx.conf du pod. En y réfléchissant, c'est sans doute plus simple de modifier le point montage pour n'ajouter qu'un fichier dans le fameux sites-enabled.

Pour gérer la configuration de Nginx, je passe par une ConfigMap :
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  nginx.conf: |
    worker_processes  1;

    error_log  /var/log/nginx/error.log warn;
    pid        /var/run/nginx.pid;

    events {
        worker_connections  1024;
    }

    http {
        include       /etc/nginx/mime.types;
        default_type  application/octet-stream;

        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';

        access_log  /var/log/nginx/access.log  main;

        sendfile        on;
        #tcp_nopush     on;

        keepalive_timeout  65;

        #gzip  on;

        server {
            listen 80;

            add_header X-Content-Type-Options nosniff;
            add_header X-XSS-Protection "1; mode=block";
            add_header X-Robots-Tag none;
            add_header X-Download-Options noopen;
            add_header X-Permitted-Cross-Domain-Policies none;
            add_header Referrer-Policy no-referrer;

            root /var/www/html;

            location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
            }

            location = /.well-known/carddav {
                return 301 $scheme://$host/remote.php/dav;
            }
            location = /.well-known/caldav {
                return 301 $scheme://$host/remote.php/dav;
            }

            # set max upload size
            client_max_body_size 10G;
            fastcgi_buffers 64 4K;

            # Enable gzip but do not remove ETag headers
            gzip on;
            gzip_vary on;
            gzip_comp_level 4;
            gzip_min_length 256;
            gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
            gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

            location / {
                rewrite ^ /index.php$request_uri;
            }

            location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
                deny all;
            }
            location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
                deny all;
            }

            location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
                fastcgi_split_path_info ^(.+\.php)(/.*)$;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                # fastcgi_param HTTPS on;
                #Avoid sending the security headers twice
                fastcgi_param modHeadersAvailable true;
                fastcgi_param front_controller_active true;
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_intercept_errors on;
                fastcgi_request_buffering off;
            }

            location ~ ^/(?:updater|ocs-provider)(?:$|/) {
                try_files $uri/ =404;
                index index.php;
            }

            # Adding the cache control header for js and css files
            # Make sure it is BELOW the PHP block
            location ~ \.(?:css|js|woff|svg|gif)$ {
                try_files $uri /index.php$request_uri;
                add_header Cache-Control "public, max-age=15778463";
                add_header X-Content-Type-Options nosniff;
                add_header X-XSS-Protection "1; mode=block";
                add_header X-Robots-Tag none;
                add_header X-Download-Options noopen;
                add_header X-Permitted-Cross-Domain-Policies none;
                add_header Referrer-Policy no-referrer;

                # Optional: Don't log access to assets
                access_log off;
            }

            location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
                try_files $uri /index.php$request_uri;
                # Optional: Don't log access to other assets
                access_log off;
            }
        }

    }
Eh oui, il y a tout dedans. Ça déforme l'affichage de ce billet, m'enfin. C'est une configuration Nginx classique.

On peut quand même s'arrêter sur la configuration du fastcgi_pass : il tape sur le 127.0.0.1 et le port 9000 du conteneur Nextcloud. Je n'ai pas encore gratté pour comprendre le pourquoi du comment mais je suppose que les deux conteneurs tournant dans le réseau du pod, ils se comportent comme deux services dans une seule et même machine. À confirmer.

On apply tout ça

Attention ! Avant de balancer le Deployment, balancez le yaml de la ConfigMap. Sans ça, Nginx ne chargera pas votre configuration !
dada@k8smaster1:~$ kubectl apply -f configmap.yaml
dada@k8smaster1:~$ kubectl apply -f nextcloud.yaml
Si tout se passe bien, vous devriez pouvoir voir ça :
dada@k8smaster1:~$ kubectl get pods
nextcloud-deployment-d6cbb8446-87ckf   2/2     Running   0          15h
Remarquez que Kubernetes vous montre bien qu'il y a deux conteneurs dans ce pod : 2/2.

Pour aller plus loin

Je ne parle pas des vérifications de l'état des conteneurs. Il faudrait placer des sondes liveness et readness pour parfaitement vérifier l'état des conteneurs. Sans ça, si l'un des services tombe, Kubernetes ne sera pas forcément en mesure de le détecter et de relancer le pod.
Il est aussi possible, pour respecter le concept de micro-service, de ne pas concaténer deux conteneurs dans un seul pod mais de faire un pod par conteneur et des services associés. Ça demande plus de travail pour un résultat qui, dans mon cas, n'apporte pas grand chose.

Wireguard sur Debian 9

Rédigé par dada / 07 janvier 2019 / 2 commentaires



Heztner, c'est vraiment un hébergeur qui propose un cloud peu cher et performant. Vraiment. Par contre, il n'y a que ça. Jusqu'à peu, nous n'avions pas la possibilité d'ajouter des volumes pour gonfler l'espace disque des machines et pas de réseau privé. Maintenant, les volumes sont là, mais toujours pas de réseau privé. Tant pis, on va le faire à la main.

On m'a parlé de Wireguard : un outil simple, puissant et sécurisé pour monter des VPN entre nos serveurs. J'ai testé, j'approuve. Je n'aime pas le réseau, c'est pas mon truc mais avec Wireguard et mes balades sous Kubernetes, je commence à presque apprécier cette chose.

Voici donc comment mettre en place des connexions privées entre vos machines pour y faire transiter ce que vous voulez sans que ça se balade sur l'Internet mondial.

Installation de Wireguard

Au moment où j'écris ces lignes, l'outil n'est disponible que dans les dépôts unstable. C'est chiant, mais rien de grave.

Ajouter les dépôts installables

# echo "deb http://deb.debian.org/debian/ unstable main" > /etc/apt/sources.list.d/unstable-wireguard.list

Faire un peu de pinning

Pourquoi ? Parce qu'avec le dépôt que vous venez d'ajouter, si vous n'y faites pas attention, vous allez massacrer la stabilité de votre machine.
# printf 'Package: *\nPin: release a=unstable\nPin-Priority: 150\n' > /etc/apt/preferences.d/limit-unstable

Installer les paquets

On va d'abord installer les headers pour permettre à Wireguard de bien s'installer :
apt install linux-headers-$(uname -r)
On peut maintenant installer la bête :
# apt update && apt install wireguard
C'est installé !

Configuration

Exemple simple

On va prendre deux serveurs et on va s'amuser à les interconnecter. Sur les deux machines, nous allons générer les clés privées et publiques :
wg genkey | tee privatekey | wg pubkey > publickey

Configuration de l'interface réseau

Tout va se passer dans le fichier wg0.conf, qui sera placé dans /etc/wireguard/. Sur la première machine, son contenu va ressembler à ça :
# Votre premier serveur
[Interface]
Address = 10.0.42.1
PrivateKey = kEQpUJDtur3yHqtoto42Y0+FXNK5lyJoUhh2g21BFWo=  
ListenPort = 1190

# Votre deuxième serveur
[Peer]
PublicKey = MnL98kIZYrHgopn1U3kptoto42L/8MqgyqKh2g2Hixo= 
Endpoint = IP.DE.MON.PEER:1190
AllowedIPs = 10.0.42.2/32
Sur la deuxième machine :
# Votre deuxième serveur
[Interface]
Address = 10.0.42.2
PrivateKey = kEQpUJDtur3yHqtoto42Y0+FXNK5lyJoUhh2g21BFWo=  
ListenPort = 1190

# Votre premier serveur
[Peer]
PublicKey = MnL98kIZYrHgopn1U3kptoto42L/8MqgyqKh2g2Hixo= 
Endpoint = IP.DE.MON.PEER:1190
AllowedIPs = 10.0.42.1/32
Non, je n'ai pas changé les clés, la flemme. Pensez quand même à vérifier que vous n'avez pas fait de coquille en copiant/collant tout ça. C'est souvent en se trompant entre les clés qu'on perd un temps fou à déboguer.

Interface

La partie [Interface] porte bien son nom : c'est là que vous allez définir l'IP de la machine sur laquelle vous bossez, configurer sa clé privée et le port qui sera utilisé par Wireguard. Allez récupérer la clé privée générée quelques secondes auparavant et remplacez ma valeur de test.

Peer

La partie [Peer], qui porte aussi bien son nom si on speak l'english, permet de configurer un pair, c'est à dire un serveur distant qui va pouvoir passer par le VPN pour faire des coucous à votre première machine.
Endpoint est à remplir avec la véritable IP de la machine et AllowedIPs doit contenir les IP (ou range) VPN de vos machines clientes. Pas la véritable IP publique.

Tester la connexion

On va activer la connexion en tapant ça sur les deux machines :
root@master:/etc/wireguard# wg-quick up wg0
Vous devriez avoir une réponse, pour le premier serveur, dans le genre : 
root@test1:/home/dada# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.42.1 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.42.2/32 dev wg0
Et pour le deuxième : 
root@test2:/home/dada# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip address add 10.0.42.2 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip route add 10.0.42.1/32 dev wg0
Maintenant, si tout s'est bien passé, vous devriez pouvoir faire des pings sur les IPs VPN des machines !

Démarrer Wireguard avec la machine

Avec systemd :
systemctl enable wg-quick@wg0.service
Ça fait quelques semaines que mon infra tourne avec Wireguard sans le moindre souci de latence, de déconnexion ou de bogue. C'est du bon !

Fil RSS des articles de ce mot clé