08 Nov 2020, 00:00

Monitoring des disques sous Linux

Un peu de lecture ici.

iotop

sudo apt install iotop
sudo iotop

Permet de voir, à la manière de top, l’activité I/O des disques par processus. Ne distingue toutefois pas sur quel disque l’activité se produit.

dstat

sudo apt install dstat
dstat pour avoir un aperçu général.
dstat -d -D total,sdk,md0 pour n’afficher que les infos relatives aux disques (-d), et surveiller l’ensemble des I/O dans une colonne (-D total), /dev/sdk dans un autre (-D sdk)et /dev/md0 dans une autre (-D md0).

iostat

sudo apt install sysstat
iostat pour avoir des infos générales depuis le boot.
iostat -y 1 2 pour avoir des infos uniquement dans l’intervalle temporel spécifié ; ici : 1s, analyse répétée 2 fois (1 2). Si le 2e chiffre n’est pas spécifié, l’analyse sera faite en boucle.
iostat -d pour n’inclure que l’info relative aux disques.
iostat -p sdk,md0 pour n’inclure que l’info relative à ces périphériques.
iostat -t pour inclure le timestamp

En cumulant ces options, et avec l’utilisation de watch, on tombe sur un truc comme ça :
watch -t -n 0.1 iostat -p sdk,md0 -d -t -y 1 1

nmon

sudo apt install nmon
nmon puis presser la touche d

06 Nov 2020, 00:00

Eth2 - Prysm via Docker

Exemple de docker-compose (pour Medalla)

Très très très inspiré de ça : https://github.com/stefa2k/prysm-docker-compose

version: "3.6"

x-logging: &logging
        logging:
                driver: "json-file"
                options:
                        max-file: "10"
                        max-size: "100m"

services:

        medalla-prysm-beacon:
                stop_grace_period: 1m
                container_name: medalla-prysm-beacon
                image: gcr.io/prysmaticlabs/prysm/beacon-chain:${PRYSM_DOCKER_TAG}
                hostname: medalla-prysm-beacon
                command: --config-file=/config/beacon.yaml 
#               --p2p-max-peers=1000
                ports:
                        - 4000:4000
                        - 13000:13000/tcp
                        - 12000:12000/udp
                volumes:
                        - ./config/beacon.yaml:/config/beacon.yaml:ro
                        - ${VOLUMES_PATH}/prysm/beacon:/data
                <<: *logging
        medalla-prysm-validator:
                stop_grace_period: 1m
                tty: true
                stdin_open: true
                container_name: medalla-prysm-validator
                image: gcr.io/prysmaticlabs/prysm/validator:${PRYSM_DOCKER_TAG}
                hostname: medalla-prysm-validator
                depends_on:
                        - medalla-prysm-beacon
                command: --config-file=/config/validator.yaml
                volumes:
                        - ./config/validator.yaml:/config/validator.yaml:ro
                        - ${VOLUMES_PATH}/prysm/validator:/wallet
                <<: *logging

# I use a custom defined network
networks:
  default:
    external:
      name: eth_net

Les fichiers de config :

beacon.yaml

############################################################
##
## Read up on parameters on
## https://docs.prylabs.network/docs/prysm-usage/parameters/
##
############################################################

datadir: /data

###############
# Base settings
medalla: true
accept-terms-of-use: true
# p2p-max-peers: 1000

#######################
# Connectivity settings 
p2p-host-ip: ""
p2p-host-dns: ""

rpc-host: 0.0.0.0
monitoring-host: 0.0.0.0

# disable scan of local network
p2p-denylist: ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","100.64.0.0/10","169.254.0.0/16"]

# changing this also needs to be changed in docker-compose.yaml !
p2p-tcp-port: 13000

# enable db backup endpoint
enable-db-backup-webhook: true

##############################
# Connection to eth1 chain container
http-web3provider: http://goerlichain-hostname:8546
web3provider: ws://goerlichain-hostname:8546

validator.yaml :

############################################################
##
## Read up on parameters on
## https://docs.prylabs.network/docs/prysm-usage/parameters/
##
############################################################

##############
# Connectivity
beacon-rpc-provider: prysm-beacon-hostname:4000
monitoring-host: 0.0.0.0

##############
# Base settings
medalla: true
accept-terms-of-use: true

#####################################
# Validator accounts & key management
wallet-dir: /wallet

###########
# Fun Stuff
graffiti: "My funky graffiti !"

#############
# Performance
dev: true
block-batch-limit: 512
head-sync: true         

Usage général

Pour exécuter une instance du validateur pour gérer les fichiers (en adaptant les chemins de volumes) :

docker run --rm -it -v ./config/validator.yaml:/config/validator.yaml -v ${VOLUMES_PATH}/testnets/medalla/prysm/validator:/wallet --config-file=/config/validator.yaml

On peut ensuite choisir les commandes Prysm ; par exemple :

  • help , qui affiche l’aide
  • accounts
  • wallet

On peut spécifier des drapeaux à la suite de cette commande, mais ils doivent être placés après les commandes de prysm.

Dans ma configuration, je ne sauvegarde le mot de passe nul part sur le disque ; il faut donc le fournir au lancement du validateur ; je recommande donc la comande suivante pour démarrer le validateur :
docker-compose up -d && docker attach medalla-prysm-validator, puis quitter avec Ctrl+P - Ctrl+Q.

Pour lire les logs de la beacon chain, et pouvoir les filtrer par exemple via grep, il faut rediriger la sortie d’erreur vers la sortie standard :
docker logs medalla-prysm-beacon 2>&1 | grep Synced

wallet

Le wallet représente l’ensemble des fichiers gérés par Prysm. On a un seul wallet à la fois. Il peut être de type “importé” ou déterministe (“HD”), ou avec signature distante, mais je ne traite pas ce cas ici.

Un wallet HD va recréer les clés en fonction de la graine fournie/générée ; C’est pratique, mais le validateur (exposé en permanence à Internet) est en possession de la graine, c’est à dire de la possibilité d’accéder aux clés de validations, mais également aux clés de retrait qui permettent de récupérer l’ETH2 ; d’où le risque de sécurité.
Les fichiers seront stockés dans le dossier “derived”.

Un wallet importé va pouvoir traiter, 1 par 1, les fichiers fournis via la command import (voir la section accounts). On peut donc générer nos clés de manière externe (par exemple via eth2-deposit-cli, (ou via ethdo ?)), et n’exposer que les clés de validation, d’où la sécurité augmentée.
Les fichiers seront stockés dans le dossier “direct”.

Si les dossiers “derived” et “direct” existent tous les 2, le validateur ne démarrera pas.

Les commandes :

  • wallet create : permet de créer un nouveau wallet, en choisissant son type ; échouera si un wallet est déjà présent à l’emplacement indiqué
  • edit-config : permet de modifier la configuration d’un wallet HD uniquement
  • recover : pour recréer un wallet HD dont on a déjà la graine
  • help : self-explaining

accounts

Un account représente un validateur, une paire de clés. On peut avoir plusieurs validateurs actifs en même temps. On peut rajouter un ou plusieurs validateurs aux validateurs déjà actifs.

Les commandes :

  • create : crée un nouveau validateur ; implique wallet create si aucun wallet n’existe dans le dossier spécifié
  • delete : permet de supprimer un ou plusieurs validateurs
  • list : permet de lister les validateurs actuellement actifs dans Prysm
  • backup : self-explaining. Exporte clés de validation ET clés de retrait si elles sont présentes dans Prysm
  • import : permet d’ajouter une clé de validateur déjà existante. Semble ne rien faire si le wallet est de type HD ; implique la création d’un wallet de type importé si aucun wallet n’existe. On doit spécifier un dossier qui contient les fichiers keystore, et taper les mots de passe ; les mots de passe peuvent être différents pour chaque keystore, il faut alors les entrer au fur et à mesure de l’importation
  • voluntary-exit : permet de quitter le pool de validateurs. Il est impossible de recommencer à valider avec ces clés, et impossible de retirer ses ethers avant la phase 1, voire la phase 2.
  • help : self-explaining

06 Nov 2020, 00:00

Notes sur eth2-deposit-cli, version 1.0.0

Install depuis git

git clone https://github.com/ethereum/eth2.0-deposit-cli.git
# ou pour la branche de dev :
git clone https://github.com/ethereum/eth2.0-deposit-cli.git -b dev

# pour installer eth2deposit module
# à refaire à chaque update pour updater le module pip3
pip3 install ./
# si besoin de changement de version, on peut désinstaller la version en conflit avec 
pip3 uninstall eth2deposit

cd eth2.0-deposit-cli

Nouvelle graine :

./deposit.sh new-mnemonic
Si plusieurs validateurs, crée 1 deposit_data cumulatif, et plusieurs keystore.json (le nom des fichiers contient le timestamp).
On doit pouvoir ajouter l’option --chain mainnet pour passer directement la chaine cible sans avoir à la choisir.

Graine existante (pour régénerer des clés, ou générer des nouvelles clés)

!!! ATTENTION A LA DOUBLE VALIDATION !!!

./deposit.sh existing-mnemonic

Choisir l’index de départ (si 2 clés ont déjà générées et que l’on souhaite en générer une nouvelle 3e, entrer 2 ; si on veut regénérer des clés dejà existantes, entrer 0 pour toutes les générer).
Choisir le nombre de clés à générer.
Les clés sont générées dans le dossier validator_keys.

Régén avec ancienne version de la méthode de dérivation (par exemple v0.2.0)

Dans eth2deposit\deposit.py, ligne 30, hardcoder la graine à restaurer après mnemonic = en la mettant entre apostrophes.

11 Jul 2020, 00:00

Logrotate

Doc ubuntu

Config de la rotation stockée dans /etc/logrotate.d/mon-journal-a-rotater

De cette forme :

/path/to/my/logfile {
	monthly        # can be daily, weekly
	rotate 12      # keep 12 history files
	compress       # gzip the old logs
	delaycompress  # gzip old logs except the more recent one
	missingok      # does not stop if a file is missing
	notifempty     # does not rotate if file is empty
	create 644 root root # permissions, user and group for the newly created file
}

Force rotation :
logrotate -fv /etc/logrotate.d/mon-journal-a-rotater (force, and verbose)
On peut spécifier directement le fichier de configuration général, /etc/logrotate.conf, qui inclue tout ce qui se trouve dans /etc/logrotate.d/ si on veut rotater l’ensemble des logs.

20 Jun 2020, 00:00

Nmap

Ping scan : nmap -sn 10.0.0.1-255

Nmap est plus efficace lorsqu’il est lancé avec les droits root, car il peut aller directement consulter la table ARP, alors que sans les droits root, il tente la connection sur un/des ports courants.

https://security.stackexchange.com/questions/74493/different-results-using-nmap-with-without-sudo

Parfois, même ainsi, tous les appareils en ligne ne sont pas listés (genre 10 resultats maximum). Il semble que passer l’option -v pour augmenter la verbosité aide à les visualiser tous.

Pour n’avoir que les IP affichées, on peut poser ça après notre commande nmap : | grep report | awk '{print $5}'

29 May 2020, 00:00

Live-USB 64b Hybrid Debian Buster avec secureboot
sudo aptitude install live-build live-tools
mkdir buster_live && cd buster_live
mkdir auto && cp /usr/share/doc/live-build/examples/auto/* ./auto/

Editer le fichier auto/config pour qu’il contienne ceci :

#!/bin/sh

set -e

lb config noauto \
	--architectures 'amd64' \
	--archive-areas 'main contrib non-free' \
	--bootappend-live 'boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr' \
	--binary-images 'iso-hybrid' \
	--distribution 'buster' \
	--linux-flavours 'amd64' \
	--source 'false' \
	"${@}"

Entrer la commande lb config, puis aller éditer le fichier config/package-lists/live.list.chroot et ajouter les paquets désirés. Je propose ceci :

live-boot
live-config
live-config-systemd

#FIRMWARE
firmware-linux firmware-atheros firmware-b43-installer firmware-bnx2x firmware-brcm80211 firmware-intelwimax firmware-iwlwifi firmware-libertas firmware-myricom firmware-netxen firmware-qlogic firmware-realtek broadcom-sta-dkms

#UTILS
nmap rcconf gparted hfsprogs ntfs-3g hfsplus hfsutils dosfstools lightdm bash-completion chntpw dcfldd bootlogd less mesa-utils numlockx ethtool grub2 ssh gdisk testdisk python-tk iftop nethogs pm-utils dmraid aptitude apt-file smartmontools debootstrap pciutils usbutils cifs-utils e2fsprogs mtools screen lvm2 net-tools mdadm lsscsi haveged rng-tools cryptsetup efibootmgr efivar ncdu wireless-tools dnsutils git iperf iperf3 lshw

# TEAMVIEWER
libqt5webkit5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs

# DESKTOP
hplip system-config-printer xsane simple-scan mate-desktop-environment caja-open-terminal mesa-utils firefox-esr-l10n-fr chromium-l10n pulseaudio pavucontrol pavumeter mate-media-common mate-media mate-settings-daemon-dev mate-settings-daemon-common mate-settings-daemon chromium engrampa unrar pluma bluez blueman pulseaudio-module-bluetooth gddrescue ddrescueview vlc rdesktop conky network-manager-gnome webcamoid cheese

Puis entrer la commande sudo lb build.

A noter qu’il est possible de décomposer la commande sudo lb build en la succession suivante :

sudo lb bootstrap
sudo lb chroot
sudo lb binary

Il est possible d’aller modifier/ajouter manuellement des fichiers entre l’étape chroot et l’étape binary. Par exemple :

sudo mkdir ./chroot/home/user/
sudo cp /etc/skel/.* ./chroot/home/user/
sudo mkdir ./chroot/home/user/Bureau/
sudo chown 1000:1000 ./chroot/home/user -R

et y ajouter des fichiers, qui seront disponibles directement sur le bureau du live.
On peut éditer les alias :
nano chroot/home/user/.bashrc

On peut aussi ajouter le .inputrc tant qu’à faire
nano ./chroot/home/user/.inputrc

Si on souhaite recommencer la création du live, on peut utiliser la commande sudo lb clean qui ne conserve que le cache des paquets, du bootstrap et la config. On peut aussi utiliser les options --binary ou bien --chroot pour conserver les étapes antérieures.
On peut également utiliser l’option --cache pour supprimer également le cache et repartir complètement à 0.

21 Dec 2019, 00:00

Compiler et installer inadyn sous Debian Buster

J’ai besoin du logiciel inadyn pour mettre à jours mes enregistrements dyndns chez OVH.
La version de Inadyn packagée par Debian est trop ancienne, et non compatible avec OVH, contrairement aux versions plus récentes dispos sur github.

Compilation et installation

## Prérequis
sudo aptitude install wget libssl-dev libgnutls28-dev autoconf libconfuse2 libconfuse-dev checkinstall pkg-config

## Répertoires nécessaires pour checkinstall
sudo mkdir /usr/local/share/doc
sudo mkdir /usr/local/share/man
sudo mkdir /usr/local/share/doc/inadyn


## libite
wget -c https://github.com/troglobit/libite/releases/download/v2.1.0/libite-2.1.0.tar.xz
tar -xvf libite-2.1.0.tar.xz
cd libite-2.1.0/
./configure
make -j5
sudo checkinstall ## Valider avec entrée plusieurs fois ; modifier les valeurs si souhaité
sudo dpkg -i libite_2.1.0-1_amd64.deb
sudo ldconfig	


## inadyn
cd ..
wget -c https://github.com/troglobit/inadyn/releases/download/v2.5/inadyn-2.5.tar.xz
tar -xvf inadyn-2.5.tar.xz
cd inadyn-2.5/
./configure
make
checkinstall
sudo dpkg -i inadyn_2.5-1_amd64.deb

Fichier de conf

/etc/inadyn.conf

provider default@ovh.com {
    ssl         = true
    username    = monsite-admin
    password    = superpassword
    hostname    = {domaine.monsite.fr}
    checkip-command = /root/.local/bin/scripts/checkIP.sh
}

provider default@ovh.com:2 {
    ssl         = true
    username    = monsite-admin
    password    = superpassword
    hostname    = {autredomaine.monsite.fr}
    checkip-command = /root/.local/bin/scripts/checkIP.sh
}

Pour que les utilisateurs du serveur ne puissent lire les identifiants :

sudo chmod 600 /etc/inadyn.conf

On peut ajouter autant de hostname qu’on veut, en changeant le chiffre après default@ovh.com:.
Les username/password doivent être définis sur l’interface OVH.

Script de reconnaissance d’IP (checkIP.sh)

#!/bin/sh
curl ipecho.net/plain; echo

Chemin à mettre en concordance avec inadyn.conf.
Ne pas oublier de sudo chmod +x checkIP.sh.

Crontab

Je préfère lancer le programme ponctuellement et régulièrement via cron que de le laisser tourner en demon.
Voici mon entrée dans le crontab pour ce faire :

# Lance inadyn toutes les 5 minutes
*/5 * * * * /usr/local/sbin/inadyn -1 -f /etc/inadyn.conf > /dev/null 2>&1

21 Dec 2019, 00:00

Mermaid
graph TB
SubGraph1 --> SubGraph1Flow
    subgraph "./debian-base-install.sh"
    SubGraph1Flow(Install Base Server)
    SubGraph1Flow -- apt install --> SubGraph1Flow1(Server with dependencies)
    SubGraph1Flow1 -- clone mmg-tools in /mmg --> SubGraph1Flow2(Repository)
    SubGraph1Flow2 -- create user mmg --> SubGraph1Flow3(installed application)
    SubGraph1Flow3 -- copy docker/$ENV/* docker/ --> SubGraph1Flow4(configured application)
    SubGraph1Flow4 -- docker-compose up --> SubGraph1Flow5(running dockers)
end

SubGraph2 --> SubGraph2Flow
    subgraph "./deploy_backend.sh"
    SubGraph2Flow(Install Back End Volume)
    SubGraph2Flow -- clone mmg-server in /tmp --> SubGraph2Flow1(Repository)
    SubGraph2Flow1 -- configure files --> SubGraph2Flow2(configured application)    
    SubGraph2Flow2 -- composer install --> SubGraph2Flow3(installed application)
    SubGraph2Flow3 -- mv /tmp /volumes --> SubGraph2Flow3(application deployed in volumes)    

end
SubGraph3 --> SubGraph3Flow
    subgraph "./deploy_frontend.sh"
    SubGraph3Flow(Install Front End Volume)
    SubGraph3Flow -- clone mmg-client in /tmp --> SubGraph3Flow1(Repository)
    SubGraph3Flow1 -- npm install $ENV --> SubGraph3Flow2(installed application)
    SubGraph3Flow2 -- build sass --> SubGraph3Flow3(generated css files)
    SubGraph3Flow3 -- npm run build --> SubGraph3Flow4(built application)
    SubGraph3Flow4 -- mv /tmp /volumes --> SubGraph3Flow5(application deployed in volumes)    

end
SubGraph4 --> SubGraph4Flow
    subgraph "Missing functionnality"
    SubGraph4Flow(Install Database Volume)
    SubGraph4Flow -- manually copy existing volume --> SubGraph4Flow1(Volume set)
end

SubGraph1[Install Server] --> SubGraph2[Install Back End]
SubGraph2 --> SubGraph3[Install Front End]
SubGraph3 --> SubGraph4[Install DATABASE]   

20 Dec 2019, 00:00

Vrac git

Interface graphique basique mais fonctionnelle : gitg

Configuration

git config --global credential.helper "cache --timeout=3600"
#pour  mettre les identifiants du serveur distant en cache pendant 1h

Configuration du nom/mail enregistrés lors des commits :
git config user.name "my_username"
git config user.email "<>" (pour un mail vide)
Ça sera enregistré dans .git/config sous la forme

[user]
        name = my_username
        email = <>

Ça peut être configuré globalement avec git config --global

Remote

“remote” représente un serveur distant avec lequel on se synchronise. Il a un nom, typiquement “origin”.
Pour voir le remote actuel :
git remote -v

Pour le modifier :
git remote set-url origin
suivi de l’URL (généralement trouvable dans l’interface web du dépôt). Ceci peut être utilisé pour passer de HTTPS à SSH : par exemple pour une URL https de type :
origin https://git.example.org/myself/myproject/
il faut entrer la commande :
git remote set-url origin git@git.example.org:myself/myproject

On peut changer le nom du remote :
git remote rename oldname newname

Versionning

git init : crée les fichiers nécessaires au fonctionnement de git (.git/)

HEAD : l’emplacement sur l’arbre où l’on se situe actuellement

git status

git add : pour tracker un dossier, fichier (ou plus fin ?)
git commit : valide le diff, -m pour message custom

git diff : liste les modifications depuis le dernier commit (ajouter --cached si sortie vide)
git show [commit] : liste les différences entre le commit actuel (ou spécifié) et le commit précédent

git fetch : lit les nouvelles modification sur le serveur distant
git pull : applique ces modifications sur notre arborescence locale
git pull --rebase : pour ne pas faire de commmit lorsqu’on repositionne notre HEAD

git log : voir l’historique des commits

git branch : pour lister les branches (git branch new-feature pour créer une branche)
git checkout : changer de branche
git checkout -b new-feature : crée la branche new-feature et m’y positionne
git push --set-upstream origin new-feature : réplique la branche new-feature sur le serveur distant

git push : après avoir commit, envoie le(s) commit sur le serveur distant
git stash : met en “presse papier” les diffs actuel et se resync avec le commit le plus récent
git stash apply : réapplique ce “presse-papiers”
# le combo des 2 peut permettre de résoudre une situation “modifié des 2 côtés” en mettant de côté notre travail, récupérant les modifs sur le serveur distant puis réappliquant nos diff dessus

06 Dec 2019, 00:00

Serveur OpenVPN ponté sous Debian Buster

Mentionné sans aucun password, en rajouter si désiré.
Prévu pour permettre un lien avec le réseau local distant, mais sans redirection de l’ensemble du trafic via VPN.

Préparation générale

apt install bridge-utils openvpn

Création de la PKI et des certificats/clés

cd /etc/openvpn
make-cadir easy-rsa/
cd easy-rsa
nano vars

Trouver les lignes qui définissent les noms de notre organisation et les modifier comme souhaité ;
Passer la taille de clés à 4096b ;
Changer le temps d’expiration par défaut du CA et des certificats en nombre de jours(ici, 10 ans)

set_var EASYRSA_REQ_COUNTRY    "FR"
set_var EASYRSA_REQ_PROVINCE   "IDF"
set_var EASYRSA_REQ_CITY       "Paris"
set_var EASYRSA_REQ_ORG        "Ma badass orga"
set_var EASYRSA_REQ_EMAIL      "me@example.net"
set_var EASYRSA_REQ_OU         "Mon OU qui déchire"

set_var EASYRSA_KEY_SIZE        4096

set_var EASYRSA_CA_EXPIRE       3650

set_var EASYRSA_CERT_EXPIRE     3650

# Le CRL a aussi une date d'expiration, on la passe à 10 ans
set_var EASYRSA_CRL_DAYS        3650

Puis on lance toute la procédure

# Initier la PKI ;
# Supprime la PKI si déjà existante
./easyrsa init-pki

# Créer les params Diffie-Hellman
./easyrsa gen-dh

# Créer les fichier de l'autorité de certif
./easyrsa build-ca nopass  # nopass pour absence de mot de passe
# Génération et signature de la CSR (signing request) du server, avec définition du Common Name
./easyrsa gen-req mon-server-vpn nopass
./easyrsa sign-req server mon-server-vpn # le "server" indique le type
# Vérification si souhaitée
openssl verify -CAfile pki/ca.crt pki/issued/mon-server-vpn.crt

# Génération et signature d'un kit de connexion pour un client
./easyrsa gen-req mon-pc-client nopass
./easyrsa sign-req client mon-pc-client

Les certificats sont dans issued, les clés dans private.

Génération TLS
Ce fichier devra être présent sur chacun des clients

openvpn --genkey --secret ta.key
mv ta.key /etc/openvpn/easy-rsa/pki/

Réseau

Activer forward IPv4

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.d/10-network.conf

Fichier /etc/network/interfaces qui crée le bridge et l’adaptateur TAP au démarrage ;
vérifier la cohérence des noms d’interface

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
    pre-up openvpn --mktun --dev tap0
    post-down openvpn --rmmtun --dev tap0
    bridge_hw 00:11:22:aa:bb:cc
    bridge_ports eth0 tap0
    address 192.168.1.2
    netmask 255.255.255.0
    gateway 192.168.1.1

Les interfaces impliquées dans le bridge (eth0, tap0) n’ont pas besoin d’être configurées dans ce fichier.
La directive bridge_hw permet de spécifier l’adresse MAC du bridge (qui sera constatée depuis le réseau, le routeur etc). Par souci de simplicité, je conseille de la fixer à la même valeur que la carte réseau physique (eth0 par exemple). Sinon, il me semble qu’elle prendra la première valeur “alphabétique” entre les différentes cartes réseau impliquées, et l’adresse de la carte tap0 peut varier d’un démarrage à l’autre.

Définition du fichier de conf du server

On peut récupérer le fichier d’exemple ainsi :

cd /etc/openvpn/server
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz ./
gunzip ./server.conf.gz
mv server.conf mon-server-vpn.conf

En voici une version minimaliste, à mettre dans /etc/openvpn/server/ :

port 1194
proto udp
dev tap0 # doit être en accord avec le fichier interfaces
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/mon-serveur-vpn.crt
key /etc/openvpn/easy-rsa/pki/private/mon-server-vpn.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/pki/dh.pem
server-bridge
keepalive 10 120
cipher AES-256-CBC
compress lz4-v2
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 3
explicit-exit-notify 1

# Pour TLS
tls-auth /etc/openvpn/easy-rsa/pki/ta.key 0  #" 0 pour le server, 1 pour les clients
#auth SHA256  ## ???

On peut vérifier qu’il se lance bien via

openvpn /etc/openvpn/server/mon-server-vpn.conf

Si “Initialization Completed”, c’est gagné.

Rotation des logs

Dans la section précédente, on a défini /var/log/openvpn/openvpn.log comme chemin pour les journaux de connexion.
On peut le logrotater avec le fichier /etc/logrotate.d/openvpn qui contiendra ceci :

/var/log/openvpn/openvpn.log {
    missingok
    weekly
    compress
    rotate 8
}

Source

Activation du service (donc démarrage automatique) via systemd

systemctl enable openvpn-server@mon-server-vpn.service

Le nom entre @ et .service doit correspondre au nom du fichier de configuration.

Ajout du timestamp dans les logs

nano /etc/systemd/system/multi-user.target.wants/openvpn-server@mon-server-vpn.service
et supprimer --suppress-timestamps de la ligne ExecStart=

(même remarque que ci-dessus concernant le nom du fichier)

Client

Installer le client VPN souhaité selon la plateforme.
Le fichier de conf doit être en conformité avec le serveur.
Sous Windows, avec OpenVPN GUI, si on met les chemins complets, syntaxe de type :

"C:\\Users\\myuser\\OpenVPN\\ca.crt"

Si les fichiers sont dans le même dossier que la conf, on peut mettre simplement les noms de fichier.
Un fichier de conf client compatible avec le fichier de conf serveur ci-dessus :

client

# Adapter les noms de fichier
ca ca.crt
cert mon-pc-client.crt
key mon-pc-client.key

# Adapter l'IP/domaine et le port
remote example.com 1194

dev tap
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
cipher AES-256-CBC
compress lz4-v2
verb 3
tls-auth ta.key 1

Pour lancement auto via systemd :

systemctl enable openvpn-client@mon-pc-client.service

Révocation de certificat

cd /etc/openvpn/easy-rsa/
./easyrsa revoke mon-pc-client
./easyrsa gen-crl   ## Crée/update pki/crl.pem

## Ajouter le fichier dans la conf server
echo "crl-verify /etc/openvpn/easy-rsa/pki/crl.pem" >> /etc/openvpn/server/mon-server-vpn.conf

Puis restart le server ; la clé de mon-pc-client ne sera désormais plus acceptée.
Il faut relancer la commande ./easy-rsa gen-crl à chaque fois qu’un certificat est révoqué, pour mettre à jour le fichier crl.pem.

Attention : le CRL a aussi une durée d’expiration ! Elle peut être paramétrée dans le fichier vars. Pour la visualiser :
openssl crl -in pki/crl.pem -text | grep "Next Update"

Réactivation d’un certificat révoqué

Je n’ai pas trouvé de commande intégrée pour ce faire. Voici comment le faire à la main, bien que ça semble un peu hacky.

D’abord on trouve le serial correspondant au client à réactiver (ici, “monClientRevoque”) :
cd /etc/openvpn/easy-rsa && cat pki/index.txt | grep monClientRevoque qui donne un résultat de ce genre :
R 300956789123Z 200356789123Z 40FDF33486D24371D96668D056CBF883 unknown /CN=monClientRevoque

Il faut éditer ce fichier pour remplacer le R initial par un V, et supprimer le 3e champ (ici 200356789123Z) ; on a donc une ligne de ce genre :
V 300956789123Z 40FDF33486D24371D96668D056CBF883 unknown /CN=monClientRevoque
ATTENTION, il faut que le nombre de tabulations aligne correctement la ligne avec les autres lignes valides, sinon on aura des erreurs plus tard.

Puis on regénère le CRL avec la commande suivante :
./easy-rsa gen-crl

Le client devrait à nouveau avoir le droit de se connecter. Si on besoin de récupérer les fichiers du kit de connexion, ils sont disponibles dans ./pki/revoked/certs_by_serial, ./pki/revoked/private_by_serial et ./pki/revoked/reqs_by_serial et nommés en fonction du numéro de série (ici 40FDF33486D24371D96668D056CBF883).

Il est conseillé de replacer ces 3 fichiers à leurs emplacements initiaux (pki/issued/, pki/private/ et pki/reqs/), et avec le nom initial (monClientRevoque), pour éviter des erreurs si l’on souhaite révoquer à nouveau ce client.
Il y’aura toutefois un message d’impossibilité de supprimer le fichier dans pki/certs_by_serial/, mais ce message n’est pas bloquant.

Lister les clients connectés

cat /var/log/openvpn/openvpn-status.log | sed '/CLIENT_LIST/!d' | cut -d"," -f2 | sed '/CLIENT_LIST/d' | sort -d