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.
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.
illyse), qui nous fourni notre ip publique principale (v4 et v6).
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