Réseau Linux : routage et pare-feu nftables

L'entreprise a changé d'opérateur Internet il y a deux jours. Depuis, les clients n'arrivent plus à suivre leurs conteneurs en ligne, alors qu'au bureau le portail s'affiche parfaitement. L'opérateur a répondu à votre ticket en une heure : le problème ne se situe pas chez lui. La direction vous donne la matinée pour rendre le portail aux clients, et pour répondre par écrit à une seule question : qui avait raison ? Vous commencez par délimiter la panne au lieu de chercher au hasard : le même test depuis le bureau et depuis Internet écarte la moitié des suspects. Puis une capture de paquets tranche le débat avec l'opérateur, preuve à l'appui. Vous descendez ensuite couche par couche : l'adresse, la route, les voisins, et une passerelle qui n'existe plus depuis le changement de box. Vous apprenez à reconnaître, à la seule forme de l'erreur, un service qui n'écoute pas d'un pare-feu qui filtre, et vous prenez le pare-feu sur le fait dans le journal du noyau. Le lab va là où s'arrêtent les tutoriels. Comprendre pourquoi une règle fausse depuis le premier jour a fonctionné pendant des années. Ouvrir exactement un port dans nftables, sans ouvrir l'administration à Internet ni fermer le bureau. Puis rendre chaque correction durable, et le prouver sans redémarrer, avant de rédiger le rapport d'incident que liront la direction et l'opérateur. Le bureau, la box de l'opérateur et un client sur Internet sont simulés sur la machine : vous pouvez casser la route et le pare-feu sans perdre votre terminal. À la fin, l'état du serveur et votre rapport sont vérifiés, et le résultat compte pour votre classement.