Makka Diarra

Je voulais faire sortir certains services conteneurisés par un tunnel VPN plutôt que par la connexion par défaut. Le montage est courant : un conteneur gluetun tient le tunnel, les autres partagent sa pile réseau et sortent par lui. Sur le papier, c'est trois lignes de configuration.

Le premier obstacle a été l'établissement du tunnel lui-même, avec une erreur d'appairage côté OpenVPN : la clé annoncée par le pair ne correspondait pas à celle attendue. Le genre de panne qui ne laisse aucune ambiguïté sur la cause une fois qu'on la voit, et aucune piste tant qu'on ne la voit pas.

Le second a été plus intéressant, parce qu'il ne ressemblait pas à une panne. Une fois le tunnel stable, des choses sans rapport ont cessé de fonctionner sur l'hôte. gluetun installe ses propres règles nftables pour forcer le trafic dans le tunnel et empêcher les fuites, ce qui est précisément ce qu'on attend de lui. Sauf que ces règles cohabitaient avec celles déjà en place, et que rien dans la configuration du conteneur ne le dit.

C'est ce que j'en retiens, et ça dépasse largement ce cas : un conteneur qui gère lui-même son filtrage n'est pas un service de plus sur la machine, c'est un second administrateur du pare-feu. Il faut savoir ce qu'il écrit avant de le lancer, pas après. Le réflexe utile n'est pas de lire sa documentation mais de comparer l'état du jeu de règles avant et après son démarrage.

La configuration n'a rien d'un serveur d'inférence : une GTX 1060 avec 6 Go de mémoire vidéo, et 44 Go de mémoire vive. La question que je me posais n'était pas de savoir si ça tiendrait la charge, mais ce qu'une machine de ce calibre permet réellement avec un modèle à mélange d'experts servi par llama.cpp, derrière une interface Open WebUI.

La contrainte structurante est immédiate : le modèle ne tient pas en mémoire vidéo. Tout le sujet devient donc un arbitrage, couche par couche, entre ce qu'on place sur le GPU et ce qu'on laisse au processeur. Un mélange d'experts complique encore les choses, puisque les paramètres actifs ne sont qu'une fraction du total, et que la répartition optimale ne suit pas l'intuition qu'on aurait sur un modèle dense.

J'ai passé l'essentiel du temps à faire varier les paramètres de répartition et à mesurer, plutôt qu'à chercher une configuration recommandée quelque part. C'est de loin la meilleure décision que j'ai prise sur ce projet : les réglages qui circulent sont calibrés sur du matériel récent, et ils ne transposent pas. Sur une carte de cette génération, le point où le transfert mémoire coûte plus cher que le calcul gagné arrive beaucoup plus tôt qu'annoncé.

Le résultat est utilisable au quotidien pour ce à quoi je le destinais, et ne le serait pas pour un usage exigeant en latence. La conclusion qui vaut au-delà de mon cas : sur ce type de matériel, aucune configuration trouvée en ligne ne remplace une demi-journée de mesures sur sa propre machine.

Mon infrastructure personnelle tourne en continu, ce qui change tout par rapport à un environnement qu'on monte pour apprendre puis qu'on éteint. Les services sont conteneurisés, le trafic sortant de certains d'entre eux passe par un tunnel dédié, le filtrage est géré par nftables sur l'hôte, et l'ensemble est supervisé et sauvegardé.

Le principe que je tiens le plus est le cloisonnement. Il est tentant de regrouper les services par commodité, parce que c'est plus simple à câbler et que tout communique déjà. C'est aussi ce qui fait qu'une compromission d'un service exposé devient une compromission de tout le reste. Séparer coûte du temps au moment de la construction, et n'en fait gagner qu'une seule fois, le jour où ça sert.

Sur les sauvegardes, la seule chose qui compte est la restauration. Une sauvegarde qu'on n'a jamais restaurée n'est pas une sauvegarde, c'est une intention. Vérifier prend une heure, et c'est la seule heure qui garantit le reste.

Ce que je referais autrement : moins d'empilement au départ. La tentation d'un lab est de reproduire une architecture d'entreprise pour le plaisir de la faire tourner, alors que ce qui se transmet ensuite en contexte professionnel, ce sont les décisions et les arbitrages, jamais le nombre de briques. Un montage simple qu'on maîtrise entièrement apprend davantage qu'un montage ambitieux qu'on subit.