Jesse Schokker

NetworkManager est le daemon qui configure le réseau sur tous les serveurs de la famille RHEL, et depuis que RHEL a abandonné les anciens network-scripts, c'est la seule méthode prise en charge. Ce cours accéléré l'utilise comme le fait un serveur dédié : sans interface graphique, en adressage statique, par SSH, avec nmcli et des keyfiles au lieu d'une applet de bureau. Vous y trouverez le modèle périphérique/profil qui dissipe l'essentiel de la confusion autour de nmcli, une configuration statique IPv4 et IPv6 complète à copier et adapter, l'emplacement des profils sur disque selon RHEL 8, 9 et 10, et la façon de modifier le réseau d'une machine distante sans vous enfermer dehors.

Netplan est la couche YAML qui configure le réseau sur Ubuntu Server : vous décrivez adresses, routes et DNS dans un seul fichier, et un générateur transforme cela en configuration pour systemd-networkd. Ce cours accéléré est écrit pour un serveur dédié avec une IP publique statique, sans Wi-Fi, et SSH comme seul point d'entrée. Il couvre l'emplacement des fichiers, la règle de permission 600 réservée à root, un exemple complet de configuration statique IPv4 et IPv6, les commandes generate, try et apply qui évitent de vous verrouiller vous-même dehors, ainsi que les VLANs, les bonds, les bridges, et le fichier cloud-init qui n'arrête pas d'écraser les modifications des utilisateurs.

Un pare-feu OPNsense virtualisé sur votre hôte Proxmox vous donne ce que les fabricants d'appliances facturent à quatre chiffres : un pare-feu/routeur complet qui protège vos VM, avec un snapshot avant chaque mise à jour et sans matériel supplémentaire. Le piège : les détails de configuration (bridges, VirtIO, offloading) décident si le résultat est rock-solid ou étrangement instable. Ce guide couvre les architectures réseau qui fonctionnent sur un serveur dédié, la configuration exacte de VM sur laquelle la communauté s'est mise d'accord, l'installation, et les réserves honnêtes sur les performances et la protection de l'hôte Proxmox lui-même.

Les listes restreintes post-VMware se résument généralement à ces deux options : Proxmox VE, la plateforme Debian/KVM avec tout intégré, et XCP-ng, le descendant de XenServer basé sur Xen et géré via Xen Orchestra. Les deux sont réellement prêts pour la production et réellement gratuits ; ils incarnent simplement des philosophies différentes sur la façon de construire une plateforme de virtualisation. Cette comparaison couvre la scission architecturale (KVM dans Linux vs Xen plus dom0), des modèles de gestion et de support très différents, le stockage et les sauvegardes, les prix actuels des deux côtés, et un verdict sous conditions.

Trois versions LTS d'Ubuntu sont actuellement en service : la 22.04 approche de la fin de son support standard, la 24.04 traverse ses confortables années intermédiaires, et la nouvelle 26.04 « Resolute Raccoon » arrive avec Linux 7.0. Celle qui convient à votre serveur dépend d'où vous en êtes dans le cycle, et la réponse diffère entre nouveaux déploiements et parcs existants. Ce guide donne le tableau des fenêtres de support, ce qui a réellement changé dans la 26.04 pour les opérateurs de serveurs, les raisons honnêtes de rester sur la 24.04 pour l'instant, et la mécanique de la mise à niveau, y compris le moment où s'ouvre le chemin de LTS à LTS après la 26.04.1.

Ubuntu est construit à partir de Debian, il s'agit donc d'une comparaison entre proches parents : même format de paquet, même système d'init, administration largement identique. Les vraies différences résident dans le rythme des versions, les fenêtres de support, la fraîcheur du noyau et qui se tient derrière les mises à jour : un rythme LTS fixe de deux ans avec une couverture payante optionnelle jusqu'en 2036, contre une version communautaire prête quand elle est prête, et gratuite pour toujours. Ce guide détaille ce que les deux partagent réellement, où ils diffèrent vraiment, et quelles charges de travail serveur favorisent lequel, avec les versions actuelles et les dates de support, pas du folklore.

Bare metal et serveur dédié désignent la même chose : une machine physique, louée en entier, sans hyperviseur et sans autre client dessus. La confusion ne porte pas sur le matériel. Elle porte sur l'époque du vocabulaire de l'hébergement à laquelle un fournisseur emprunte ses mots, et ce vocabulaire annonce en général la façon dont la machine vous est vendue : par ticket ou par API, au mois ou à l'heure. Ce guide explique d'où vient chaque terme, présente les différences de modèle d'exploitation que le choix de mots d'un fournisseur signale le plus souvent, vous donne cinq questions à poser avant de commander, et traite le seul cas où aucun des deux termes ne correspond à ce qu'il vous faut.

CentOS Linux n'existe plus (CentOS 8 a atteint sa fin de vie fin 2021 et CentOS 7 a suivi à la mi-2024), et CentOS Stream n'est pas un remplaçant à l'identique. Les deux vrais successeurs sont AlmaLinux et Rocky Linux, et depuis 2023 ils ne fonctionnent plus de la même façon sous le capot : AlmaLinux vise la compatibilité ABI avec RHEL, Rocky conserve la parité binaire 1:1. Ce guide explique ce qui les distingue aujourd'hui, donne un verdict selon vos conditions plutôt qu'un « ça dépend », et détaille les vrais chemins de migration (migrate2rocky, almalinux-deploy, et ELevate pour le saut de version majeure depuis CentOS 7), avec la checklist préalable, le mur d'inhibiteurs et le plan de retour arrière.

Headscale vous donne la moitié de Tailscale qui n'est pas open source : le serveur de coordination. Faites-le tourner vous-même, et les clients Tailscale officiels (avec leur excellent NAT traversal et leur prise en charge multiplateforme) se connectent à une infrastructure que vous contrôlez, sans tarification par utilisateur et sans qu'un tiers détienne les clés de votre réseau. Ce guide est le parcours pratique : installation depuis les packages officiels, TLS fait simplement, utilisateurs et ACL, le relais DERP intégré sur votre propre réseau, et les limites opérationnelles honnêtes d'un projet délibérément restreint.

Proxmox VE vous offre deux façons de découper un serveur : des machines virtuelles complètes via KVM, et des conteneurs système LXC qui partagent le noyau de l'hôte. Le bon choix par workload est généralement clair dès que vous connaissez les trois questions qui tranchent : l'isolation, le noyau et la migration. Ce guide explique comment chacun fonctionne réellement, les compare sur les dimensions qui comptent en pratique, tranche la question de Docker avec les recommandations actuelles de Proxmox lui-même, et se termine par un tableau de décision applicable service par service.

Debian 12 « bookworm » a discrètement franchi une limite en juin 2026 : le support de sécurité standard a pris fin, et la distribution ne tourne désormais plus que sous le régime LTS. Debian 13 « trixie » a quant à elle mûri au fil de sept révisions mineures, ce qui fait de ce moment le bon pour la mise à niveau sur place. Ce guide couvre la procédure complète pour un serveur de production distant : la liste de vérification préalable (dont le piège du renommage d’interface qui peut couper un serveur distant du réseau en pleine mise à niveau), la mise à niveau elle-même en trois commandes, et les changements propres à trixie à vérifier ensuite : /tmp sur tmpfs, le déplacement de sysctl, et OpenSSH 10.

Quand votre serveur subit une attaque, « on se fait DDoS » n'est pas exploitable ; « SYN flood, quatre millions de paquets par seconde, sources usurpées, ciblant le port 443 » l'est. La différence entre les deux tient à une capture de paquets de trente secondes et un examen structuré de celle-ci. Ce guide couvre la capture en toute sécurité sur une machine déjà saturée (tcpdump, pas l'interface graphique de Wireshark), le workflow de tri dans Wireshark (Protocol Hierarchy, Conversations, I/O Graphs) et les signatures de filtres d'affichage des vecteurs d'attaque courants, pour terminer sur la façon de transformer les constats en mitigation.

Les exigences réelles d'un cluster Proxmox tiennent en une phrase : trois nœuds, une liaison privée à faible latence entre eux, et un stockage que les nœuds survivants peuvent atteindre. Tout le reste (quorum, fencing, Ceph contre réplication) n'est que la justification derrière ces trois points. Ce guide couvre ce que le clustering apporte avant même que la HA entre en jeu, pourquoi le quorum fait de trois le chiffre magique, les règles réseau de corosync que l'on viole en premier, les trois stratégies de stockage, et à quoi ressemble réellement un failover quand un nœud tombe à 3 h du matin.

WireGuard est le protocole sur lequel s'appuient les trois produits, donc « WireGuard vs Tailscale » part du mauvais postulat. La vraie question est de savoir qui gère votre control plane : le SaaS de Tailscale, un Headscale auto-hébergé, la stack entièrement ouverte de NetBird, ou personne (WireGuard brut). Ce guide dresse clairement la carte protocole-vs-control-plane-vs-relais, compare les quatre options sur les critères qui comptent vraiment pour votre choix, explique pourquoi WireGuard en mode noyau et en userspace performent différemment, et livre un verdict du point de vue d'un opérateur d'infrastructure, y compris l'angle que les résultats de recherche écrits par les éditeurs eux-mêmes ignorent : l'accès mesh aux réseaux de management et hors bande.

Le réseau est le point où la plupart des nouvelles installations Proxmox s'enlisent : l'installation fonctionne, la première VM démarre, puis "comment lui donner une IP ?" se transforme en un après-midi passé sur des fils de forum à moitié pertinents. Le modèle sous-jacent est en réalité simple : les VM se branchent sur des bridges Linux, et tout le reste n'est que variations. Ce guide construit ce modèle correctement : ce qu'est vraiment vmbr0, les configurations bridged, routed et NAT chez un hébergeur, les bridges VLAN-aware, le bonding bien fait, la place de la couche SDN, et comment modifier tout cela sans vous couper vous-même l'accès.

Si votre serveur exécute une distro Debian, Ubuntu ou de la famille RHEL à jour, vos règles « iptables » s’exécutent presque certainement déjà à l’intérieur de nftables. La commande iptables est un shim de compatibilité depuis 2019. La vraie question n’est pas de savoir lequel l’emporte ; c’est de savoir si vous devez continuer à écrire des règles dans une syntaxe legacy par-dessus le nouveau moteur. Ce guide couvre ce qui a réellement changé au niveau architectural, une comparaison de syntaxe côte à côte, ce que disent honnêtement les données de performance, et un chemin de migration qui ne casse pas Docker et ne vous enferme pas dehors.

Vous avez un serveur bare metal et vous voulez qu'il fasse tourner des machines virtuelles et des conteneurs au lieu d'un seul système d'exploitation. Proxmox VE transforme ce matériel brut en une plateforme de virtualisation complète : un hôte basé sur Debian avec une interface web, la virtualisation complète KVM, des conteneurs système LXC, du stockage et un réseau intégrés, et aucune licence d'hyperviseur par socket à acheter. Ce guide parcourt tout le chemin, d'un serveur vierge jusqu'à un hôte fonctionnel. Nous installons Proxmox VE 9.2 depuis l'ISO, corrigeons les dépôts APT et effectuons la mise à jour, comprenons le réseau en bridge par défaut, examinons le stockage, créons une première VM et un premier conteneur LXC, et terminons par un durcissement de base. À la fin, vous aurez un nœud unique prêt pour la production, que vous pourrez faire évoluer plus tard vers un cluster.

Les attaques DDoS se répartissent en trois grandes familles : les floods volumétriques qui saturent votre tuyau, les attaques de protocole qui épuisent l'état des connexions, et les floods applicatifs qui ressemblent à du trafic légitime. Chacune épuise une ressource différente, chacune exige donc une défense différente, et aucune couche à elle seule n'arrête les trois. Ce guide met en correspondance les formes d'attaque courantes avec la ressource qu'elles visent et la mitigation qui fonctionne réellement contre elles, explique ce qu'un pare-feu sur le serveur peut arrêter et ce qu'il ne peut pas, et se termine par un plan d'action concret pour la réponse à incident quand votre serveur est attaqué.

Un serveur fraîchement provisionné commence à recevoir des sondes SSH quelques minutes après la mise en ligne de son IP ; les études par honeypot montrent que la plupart des machines exposées sont attaquées en moins d'un jour. La bonne nouvelle : les défenses qui comptent tiennent dans une checklist courte et sans éclat d'une heure, pas dans un projet de recherche en sécurité. Ce guide parcourt les huit étapes dans l'ordre (utilisateurs et clés SSH, base de pare-feu, mises à jour automatiques, fail2ban, synchronisation horaire, audit des services à l'écoute et journalisation) avec les commandes exactes pour Debian/Ubuntu et la famille RHEL, plus une liste honnête de ce à quoi ne pas gaspiller votre première heure.

Proxmox VE embarque tout ce qu'il faut pour ne jamais perdre une VM, et les réglages par défaut n'en exploitent presque rien. Des snapshots qui vivent sur le même disque que la VM, des archives vzdump ponctuelles sans politique de rétention, et aucun test de restauration : voilà comment les hôtes de virtualisation se retrouvent réellement en difficulté. Ce guide construit la vraie stratégie en trois niveaux : à quoi servent réellement les snapshots, les sauvegardes vzdump planifiées correctement (modes, rétention, fleecing), et à partir de quand la déduplication, la vérification et la synchronisation hors site de Proxmox Backup Server justifient une seconde machine.

Un serveur Linux fraîchement installé ne possède aucune règle de pare-feu. Chaque listener que vous démarrez devient instantanément accessible depuis l'ensemble d'Internet. La solution est une base courte et bien comprise : default-deny en entrée, autoriser le trafic established, et une allow-list explicite pour les services que vous faites réellement tourner. Ce guide construit cette base dans nftables règle par règle, explique les points que tout le monde rate (ICMP et IPv6), montre la même politique dans ufw et firewalld, et explique comment éviter de vous verrouiller vous-même dehors, ainsi que le piège de la publication de ports Docker.

Proxmox VE est une plateforme de virtualisation gratuite et open source qui s'exécute directement sur un serveur physique, transformant une machine en hôte pour des machines virtuelles complètes et des conteneurs légers. Mais ce n'est pas le seul hyperviseur bare-metal : VMware ESXi, XCP-ng et Hyper-V résolvent chacun le même problème différemment, et le bon choix dépend bien plus des licences, du clustering et de l'écosystème de votre équipe que des fonctionnalités brutes. Ce guide explique ce qu'est réellement Proxmox VE, ce que signifie un hyperviseur bare-metal, et comment les quatre principaux prétendants se comparent en matière de coût, de gestion, de haute disponibilité, de stockage et de sauvegarde, avec un tableau comparatif, un cadre de décision tranché et des liens vers le bon serveur pour le déployer.

Un serveur dédié Linux vous offre une machine physique entière sans hyperviseur en travers du chemin, mais quelle distribution y faire tourner ? Ubuntu, Debian, les successeurs de CentOS et RHEL font chacun des compromis différents sur la cadence de publication, le support et le coût. Ce guide explique ce qu’est réellement un serveur Linux bare metal, quand il l’emporte sur un VPS ou une instance cloud, et comment choisir une distribution selon la charge de travail et les besoins de support, avec une comparaison côte à côte et des liens vers le serveur adapté à chacune.