La machine physique sur laquelle tout tourne. Globalement radon a 2 rôles: servir de routeur central pour le sbirenet et faire tourner des machines virtuelles qui hébergent les services.

• Carte mère: Super Micro A2SDi-16C-HLN4F
• 32Go de mémoire flash
• 1 SSD de 120Go
• 2 HDD de 4To chacun (mis en RAID1)
• Boîtier: Fractal Node 304

La disposition est la suivante:

NAME            TYPE FSTYPE        SIZE MOUNTPOINTS
sda             disk btrfs         3.6T 
sdb             disk btrfs         3.6T /data
nvme0n1         disk             119.2G 
├─nvme0n1p1     part vfat          512M /boot
└─nvme0n1p2     part LVM2_member 118.7G 
  ├─nvme-system lvm  ext4           70G /
  └─nvme-swap   lvm  swap           32G [SWAP]

Radon boot avec le bootloader EFISTUB intégré à Linux. C'est un peu un caprice minimaliste pour se passer de GRUB et ses horribles fichiers de configurations à tiroir. La contrepartie c'est qu'au lieu de configurer GRUB (chemin de l'initrd, cmdline linux, etc), il faut expliquer ça au firmware EFI de la carte mère. Ça se fait avec l'utilitaire efibootmgr. La commande pour insérer l'item faisant booter radon est:

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "arch" --loader /vmlinuz-linux --unicode 'initrd=\intel-ucode.img initrd=\initramfs-linux.img root=UUID=a4f4ab91-8ff1-4368-9c42-ffc6ccf05f40 rw quiet console=tty0 console=ttyS1,115200n8'

L'option console=ttyS1,115200n8 est là pour démarrer une console sur le port série 1, qui est connecté à la puce IPMI.

• rngd.service: accumule de l'entropie pour /dev/random.
• openntpd.service: synchronise l'horloge.
• kresd@1.service: resolveur récursif DNS (knot-resolver), utilisé par les machines virtuelles, accessible sur sbirenet.
• sshd.service: serveur openssh sur le port 222.

• nftables.service: firewall nftables.
• systemd-networkd.service: gestion du réseau.

Les fichiers de configurations réseaux sont dans /etc/systemd/network, le firewall est défini dans /etc/nftables.conf.

Radon dispose de 4 ports ethernet (interfaces eno1 à eno4) qui sont aggrégées dans l'interface bridge lan0. Il accède physiquement à internet avec un configuration client DHCP classique sur lan0. Ainsi on peut le brancher à un routeur sur n'importe quel port et de plus on peut en profiter comme d'un switch avec les autres ports.

Cet accès à internet est uniquement utilisé pour connecter des tunnels wireguard.

• Un tunnel vers illyse (interface illyse), qui nous fourni notre ip publique principale (v4 et v6).
• Un serveur wireguard pour sbirenet (interface sbire), qui se connecte également à cerberus.

Les machines virtuelles utilisent des interfaces TAP nommées vm-VMNAME.

Le but est d'avoir une route par défaut sur l'interface illyse, de manière à chiffrer les paquets et les envoyer dans le tunnel. Cependant il faut tout de même une route qui permette aux paquets chiffrés de réellement partir sur internet, par l'interface lan0. De manière générale, on voudrait également que les paquets chiffrés de l'interface sbire soient également envoyés sur le réseau physique lan0 et pas dans illyse (faisant un tunnel dans un tunnel).

Pour résoudre ça, on utilise la fonctionalité “fwmark” (voir improved rule based routing) qui tag les paquets chiffrés sortant des interfaces wireguard. On peut ensuite ajouter une règle (voir ip rule), qui selectionne une autre table de routage pour les paquets taggés (et les envoit sur le réseau physique). La mise de cette magie se passe dans les blocs [RoutingPolicyRule] du fichier /etc/systemd/network/20-illyse.network.

WIP

TODO

TODO