Homelab "Cortex" & Sécurité ZTNA.

1. Topologie Matérielle : Le "Router on a Stick"

Contrairement aux installations domotiques classiques qui empilent les équipements (une box, un routeur matériel, un NAS externe, un serveur de calcul), j'ai opté pour une approche d'hyperconvergence radicale. L'ensemble de mon réseau repose sur un seul PC serveur (le nœud Proxmox nommé cortex[cite: 2]) relié à un switch manageable.

Cette machine ne se contente pas d'héberger des machines virtuelles : elle est le cœur absolu du réseau. Avec sa carte réseau physique connectée en trunk au switch, tout le trafic (entrant, sortant, et inter-VLAN) passe obligatoirement par le serveur. La VM 114 (NetworkManager)[cite: 2] fait ainsi office de pare-feu et de routeur global, m'offrant un contrôle absolu sur les paquets via des règles iptables/nftables strictes.

2. Zero Trust Network Access (ZTNA)

Héberger ses propres services (comme ce portfolio ou un cloud personnel) pose le problème de l'exposition. Ouvrir les ports 80 et 443 sur un routeur grand public expose immédiatement l'IP publique de la connexion internet aux scanners automatisés (Shodan, botnets).

La solution implémentée ici est une architecture Zero Trust. Aucun port réseau n'est ouvert vers l'extérieur. L'accès public est géré par un daemon hébergé sur le conteneur LXC 117 (tunnelCloudflare)[cite: 2]. Ce daemon initie une connexion sortante chiffrée vers les serveurs de périphérie de Cloudflare.

[Utilisateur Web] -> [Cloudflare Edge (WAF)]
                           │
                 (Tunnel Chiffré Sortant)
                           │
                           ▼
[CT:117 tunnelCloudflare] (Déchiffrement / Auth)
                           │
                           ▼
[CT:105 nginxproxymanager] (Reverse Proxy Interne)
                           │
      ┌────────────────────┼────────────────────┐
      ▼                    ▼                    ▼
[CT:118 portfolio]   [CT:104 nextcloud]   [CT:106 paperless]

Le trafic légitime traverse ce tunnel et atterrit sur le conteneur 105 (nginxproxymanager)[cite: 2] qui sert de Reverse Proxy interne. Nginx lit les entêtes HTTP et dispatche la requête vers le bon conteneur, comme le 118 (portfolio)[cite: 2] que vous consultez actuellement. En parallèle, tout le trafic DNS interne est filtré par le conteneur 102 (adguard)[cite: 2] pour bloquer la télémétrie indésirable au niveau du réseau.

3. Intégration Robotique : Le Jumeau Numérique

L'un des avantages de posséder un hyperviseur puissant au centre de son réseau est la capacité d'y déporter les calculs lourds. Actuellement, la logique de contrôle bas niveau de mon bras robotique collaboratif s'exécute sur une carte externe (Raspberry Pi) située au plus près du matériel.

Cependant, cette Raspberry Pi se contente de calculer l'impédance et de commander les moteurs : elle ne possède pas la puissance graphique ou de calcul CPU nécessaire pour faire tourner un simulateur complexe. Pour pallier cela, la Raspberry Pi broadcast les données angulaires des joints en temps réel sur le réseau local.

Le serveur cortex intercepte ce flux UDP/DDS. Grâce aux ressources allouées aux conteneurs 112 (ros2) et 110 (AI)[cite: 2], le serveur calcule la cinématique directe et met à jour instantanément un Jumeau Numérique (Digital Twin) dans un environnement RViz/Gazebo. Cela me permet d'avoir un retour visuel 3D et d'enregistrer la télémétrie du robot sans jamais saturer la charge CPU de la carte embarquée.

4. Allocation des Ressources (Matrice Proxmox)

Pour minimiser l'overhead (surcoût de virtualisation), 90% des services tournent dans des conteneurs Linux (LXC) partageant le kernel de l'hôte. Les Machines Virtuelles (KVM) ne sont utilisées que lorsque l'isolation matérielle ou un OS spécifique est impératif (ex: HomeOS).

Le stockage NAS est géré de manière native, partagé avec les conteneurs Alpine et Debian via des points de montage (Bind Mounts), évitant la latence réseau des protocoles SMB/NFS virtuels.