Perfect Homelab [E11] : QDevice et DNS Technitium — sécuriser le cluster avant la migration

Rappel de l’état à la fin de l’E10

#

À la fin de l’E10, voici où on en était :

graph TB
    subgraph MATRIX["CLUSTER MATRIX"]
        Morpheus["Morpheus
ZFS mirror NVMe
nœud principal"]
        Neo["Neo
LVM SSD SATA
nœud secondaire"]
    end
    LXC107["LXC 107 — PBS 4.2.1
10.10.10.7 ✅"]
    LXC130["LXC 130 — Smarthome ✅"]
    PBSNeo["PBS bare metal
à supprimer"]
    LXC253old["LXC 253
Technitium DNS fallback"]

    Morpheus --> LXC107
    Morpheus --> LXC130
    Neo --> PBSNeo
    Neo --> LXC253old

    style Morpheus fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Neo fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style LXC107 fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style LXC130 fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style PBSNeo fill:#fee2e2,stroke:#991b1b,stroke-width:2px,color:#000
    style LXC253old fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000

Les backups PBS de Neo étaient mirrorés sur Morpheus. Il restait trois problèmes à résoudre :

1. Quorum fragile — cluster à 2 nœuds sans QDevice
2. DNS — Technitium sur une VM Freebox sans redondance propre
3. Neo en LVM — impossible de faire de la réplication ZFS native Proxmox

Cet épisode couvre les deux premiers points : réseau, DNS et QDevice. La migration ZFS de Neo — l’opération la plus risquée — fait l’objet de l’E12.

Architecture cible

#

graph LR
    subgraph MATRIX["CLUSTER MATRIX"]
        Morpheus["Morpheus
10.10.10.5
ZFS mirror NVMe"]
        Neo["Neo
10.10.10.6
ZFS single SSD SATA
← migration E12"]
    end
    Oracle["oracle
192.168.0.50
QDevice VM Freebox
← nouveau"]
    subgraph DNS_CLUSTER["DNS Cluster Technitium"]
        ns1["ns1.dns.allfabox.fr
10.10.10.53 — RPi 3B
← nouveau"]
        ns2["ns2.dns.allfabox.fr
10.10.20.53 — LXC 253
← après migration Neo"]
    end

    Morpheus <-->|corosync| Neo
    Morpheus <-->|TCP 5403| Oracle
    Neo <-->|TCP 5403| Oracle
    ns1 <-->|cluster Technitium| ns2

    style Morpheus fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Neo fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Oracle fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style ns1 fill:#f3e8ff,stroke:#7e22ce,stroke-width:2px,color:#000
    style ns2 fill:#f3e8ff,stroke:#7e22ce,stroke-width:2px,color:#000

Partie 1 — Réseau : double NAT et routes statiques

#

Le contexte double NAT

#

Mon infrastructure réseau fonctionne en double NAT :

graph TB
    Internet(["Internet"])
    Freebox["Freebox Ultra
192.168.0.254"]

    subgraph FreeboxLAN["Réseau Freebox — 192.168.0.0/24"]
        Oracle["oracle VM
192.168.0.50
QDevice"]
        UCG["UCG Fiber
192.168.0.100 / 10.10.10.1"]
    end

    subgraph HomeLab["VLAN 10 — 10.10.10.0/24 (homelab)"]
        Morpheus["Morpheus
10.10.10.5"]
        Neo["Neo
10.10.10.6"]
    end

    Internet --> Freebox
    Freebox -->|DMZ| UCG
    Freebox --> Oracle
    UCG --> Morpheus
    UCG --> Neo
    Oracle -->|TCP 5403| Morpheus
    Oracle -->|TCP 5403| Neo

    style Internet fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#000
    style Freebox fill:#fee2e2,stroke:#991b1b,stroke-width:2px,color:#000
    style UCG fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style Oracle fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style Morpheus fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Neo fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000

Pour qu’oracle (192.168.0.50) puisse communiquer avec le cluster Proxmox (10.10.10.0/24), deux éléments sont nécessaires : une route statique sur oracle et une règle firewall sur l’UCG.

Ce qui n’est PAS nécessaire

#

Après tests, deux configurations s’avèrent superflues :

Route statique UCG Fiber — l’UCG est directement connecté aux deux réseaux (192.168.0.0/24 sur son WAN et 10.10.10.0/24 sur son LAN). Il route naturellement entre eux sans règle explicite.

Route statique FreeboxOS — utile uniquement pour les autres appareils du réseau Freebox (192.168.0.x) qui voudraient joindre le homelab. Oracle contourne la Freebox en allant directement vers l’UCG (192.168.0.100).

Route statique sur oracle (netplan)

#

C’est la configuration indispensable — oracle doit savoir que 10.10.10.0/24 est accessible via l’UCG Fiber (192.168.0.100).

La VM Freebox utilise netplan avec cloud-init. Il faut d’abord désactiver la gestion réseau par cloud-init pour que la config survive aux reboots :

# Désactiver cloud-init pour le réseau
sudo bash -c 'echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg'

# Créer un fichier netplan dédié
sudo bash -c 'cat > /etc/netplan/10-homelab-route.yaml << EOF
network:
  version: 2
  ethernets:
    enp0s5:
      dhcp4: true
      routes:
        - to: 10.10.10.0/24
          via: 192.168.0.100
EOF'

# Corriger les permissions (exigées par netplan)
sudo chmod 600 /etc/netplan/10-homelab-route.yaml
sudo chmod 600 /etc/netplan/50-cloud-init.yaml

# Appliquer
sudo netplan apply

# Vérifier
ip route show | grep 10.10.10
# → 10.10.10.0/24 via 192.168.0.100 dev enp0s5 proto static onlink ✅

proto static confirme que la route est persistante et survivra aux reboots.

Règle firewall UCG (zone Externe → Interne)

#

Sans règle explicite, le firewall zone-based de l’UCG bloque le trafic initié depuis oracle vers le cluster. Il faut ajouter :

UCG Fiber → Firewall → Politiques → Externe → Interne → Ajouter
Nom         : Oracle QDevice → Homelab SERVERS
Action      : Accepter
Source      : 192.168.0.50/32
Destination : 10.10.10.0/24
Protocole   : Tous (à restreindre au port TCP 5403 après validation)

Partie 2 — DNS : Technitium sur Raspberry Pi

#

Pourquoi déplacer le DNS sur le RPi

#

L’instance Technitium existante tournait sur une VM Freebox (ns1.dns.allfabox.fr, 192.168.0.153). Elle avait deux problèmes :

• Dépendante du réseau Freebox (192.168.0.0/24), pas directement accessible depuis tous les VLANs du homelab
• Infrastructure non redondée

La cible : Technitium sur le RPi 3B directement dans le réseau homelab (10.10.10.53), avec LXC 253 comme secondaire.

Installation sur le RPi

#

# Préparer le hostname
hostnamectl set-hostname ns1
sed -i 's/raspberrypi/ns1/g' /etc/hosts

# Installer Technitium
curl -sSL https://download.technitium.com/dns/install.sh | sudo bash

Initialisation du cluster Technitium

#

Dans l’interface Technitium (http://10.10.10.53:5380) :

Settings → General → DNS Server Domain Name : ns1.dns.allfabox.fr

Administration → Cluster → Initialize
Cluster Domain  : dns.allfabox.fr
Primary Node IP : 10.10.10.53

Le nœud primaire devient ns1.dns.allfabox.fr accessible sur https://ns1.dns.allfabox.fr:53443/.

Test de résolution

#

dig @10.10.10.53 google.fr
# → 172.217.22.67, query time 119ms ✅

graph LR
    Clients["Clients homelab
VLAN 10 / VLAN 20"]
    subgraph DNSCluster["DNS Cluster Technitium"]
        ns1["ns1.dns.allfabox.fr
10.10.10.53
RPi 3B — Primary"]
        ns2["ns2.dns.allfabox.fr
10.10.20.53
LXC 253 — Secondary"]
    end
    Internet(["Résolveurs upstream"])

    Clients -->|Résolution principale| ns1
    Clients -->|Fallback| ns2
    ns1 <-->|Synchro cluster| ns2
    ns1 -->|Forward| Internet
    ns2 -->|Forward| Internet

    style ns1 fill:#f3e8ff,stroke:#7e22ce,stroke-width:2px,color:#000
    style ns2 fill:#f3e8ff,stroke:#7e22ce,stroke-width:2px,color:#000
    style Clients fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Internet fill:#e2e8f0,stroke:#475569,stroke-width:2px,color:#000

Partie 3 — QDevice : VM oracle sur Freebox Ultra

#

Pourquoi une VM Freebox pour le QDevice

#

Le QDevice corosync doit être totalement indépendant du cluster Proxmox. Si Morpheus et Neo tombent simultanément, le QDevice doit rester accessible. Une VM sur la Freebox Ultra remplit ce rôle parfaitement.

graph TB
    subgraph ProxmoxInfra["Infrastructure Proxmox (à risque)"]
        Morpheus["Morpheus
10.10.10.5
1 vote"]
        Neo["Neo
10.10.10.6
1 vote"]
    end
    subgraph FreeboxInfra["Infrastructure Freebox (indépendante)"]
        Oracle["oracle
192.168.0.50
1 vote — QDevice
TCP 5403"]
    end

    Morpheus <-->|corosync ring| Neo
    Morpheus <--> Oracle
    Neo <--> Oracle

    style Morpheus fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Neo fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Oracle fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000

Création de la VM oracle

#

Dans FreeboxOS → VMs :

Nom    : oracle
CPU    : 1 vCPU
RAM    : 512 Mo
OS     : Debian 12 (Bookworm)
Disque : 10 Go (minimum Freebox)
IP     : 192.168.0.50 (bail statique DHCP)

Installation de corosync-qnetd

#

sudo apt update && sudo apt install -y corosync-qnetd
systemctl status corosync-qnetd
# → active (running), 6.1 Mo RAM seulement ✅

Configuration du QDevice depuis Morpheus

#

# Installer corosync-qdevice sur les deux nœuds
apt install -y corosync-qdevice  # sur Morpheus et Neo

# Copier la clé SSH vers oracle
ssh-copy-id -o PreferredAuthentications=password root@192.168.0.50

# Configurer le QDevice
pvecm qdevice setup 192.168.0.50

Note SSH : oracle est configuré avec AllowUsers allfab et PermitRootLogin no par défaut. Il faut temporairement autoriser root (PermitRootLogin prohibit-password + AllowUsers allfab root) le temps du setup, puis resécuriser après.

Résultat

#

pvecm status

Expected votes : 3  ✅
Total votes    : 3  ✅
Flags          : Quorate Qdevice ✅

Morpheus  10.10.10.5  1 vote  A,V,NMW ✅
Neo       10.10.10.6  1 vote  A,V,NMW ✅
Qdevice   oracle      1 vote          ✅

État intermédiaire

#

Les trois filets de sécurité sont désormais en place. Le quorum est stable à 3 votes et le DNS est opérationnel dans le réseau homelab.

graph TB
    subgraph MATRIX["CLUSTER MATRIX"]
        Morpheus["Morpheus
10.10.10.5
ZFS mirror NVMe"]
        Neo["Neo
10.10.10.6
LVM SSD SATA
⚠️ migration ZFS — E12"]
    end
    Oracle["oracle
192.168.0.50
corosync-qnetd
3 votes ✅"]
    ns1["ns1.dns.allfabox.fr
10.10.10.53
RPi 3B — Primary ✅"]
    LXC107["LXC 107 — PBS 4.2.1
10.10.10.7 ✅"]
    LXC130["LXC 130 — Smarthome ✅"]

    Morpheus <-->|corosync| Neo
    Morpheus <-->|TCP 5403| Oracle
    Neo <-->|TCP 5403| Oracle
    Morpheus --> LXC107
    Morpheus --> LXC130

    style Morpheus fill:#dbeafe,stroke:#1e40af,stroke-width:2px,color:#000
    style Neo fill:#fef3c7,stroke:#b45309,stroke-width:2px,color:#000
    style Oracle fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style ns1 fill:#f3e8ff,stroke:#7e22ce,stroke-width:2px,color:#000
    style LXC107 fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000
    style LXC130 fill:#dcfce7,stroke:#166534,stroke-width:2px,color:#000

Si Morpheus tombe maintenant, Neo conserve le quorum grâce au QDevice — les backups restent accessibles et la domotique tient. On peut engager la migration ZFS de Neo sereinement.

Ce qui reste à faire

#

La suite dans l’E12 :

1. Réinstaller Neo en ZFS — l’opération risquée, rendue sûre par les filets E10/E11
2. Configurer le storage ZFS cluster-wide et recréer le LXC 253 (DNS secondaire)
3. Configurer la zone DNS allfabox.fr avec Split Horizon
4. Activer la réplication ZFS — Morpheus → Neo pour les LXC critiques
5. Activer le HA Manager — bascule automatique en cas de panne