Tous les articles

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 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é.

Le ping n'est qu'une partie de ce que ressent un joueur. Un aller-retour complet traverse l'échantillonnage de l'entrée, le dernier kilomètre, le transit et le peering, une file d'attente sur le serveur, puis l'attente du prochain tick de simulation avant que le monde ne réagisse. Ce guide détaille d'où vient réellement le délai ressenti, comment le tick rate et le netcode changent la donne, pourquoi le jitter et le packet loss nuisent plus qu'un ping élevé mais stable, et le levier que l'hébergeur maîtrise le plus : placer le serveur près des joueurs, sur du matériel qui tient son tick rate.

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.

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.

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.

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.