Oui je sais, plusieurs mois sans article, et là, juste un « message de service ». Non pas que ça soit dingue comme opération en plus, surtout que j’ai quand même bien dérivé de mon objectif initial (un peu comme pour le smarpthone), mais il fallait le mentionner. Petit retour rapide sur le pourquoi du comment, le déroulé, certains choix, etc.

L’historique de la bête

Ça fait un moment que l’idée de déménager le serveur me trotte dans la tête. En effet, le vénérable MiniSP 2014, qui date en fait de 2013, va donc sur ses neuf ans. Ça fait un bail que j’ai des soucis de performances disque avec, et il a eu chaud dans tous les sens du terme avec l’incendie de l’année dernière. Il est passé par une quantité de méthodes d’installation, la dernière en date est un Proxmox 5.4, oui je sais, ça fait un moment que le 7 est sorti, mais bon, vu l’âge de la machine, j’ai envie de dire, hein, pas pressé. Mais si j’envisageais déjà un déménagement l’année dernière, ça fait partie des choses qui sont passées en arrière-plan, entre procrastination et changements de priorités. Tout juste j’avais préparé un plan de migration, qui on le verra, a été grandement remanié pour l’occasion. Et pour cause…

Remember…

La mauvaise surprise d’OVH

Mais coup de tonnerre, OVH m’a envoyé un mail voilà quelques temps pour m’annoncer que SBG4, le datacenter où se trouve mon serveur rescapé, va être reconstruit, et que donc pour l’occasion, ils coupent tout, sans intention de rallumer; Date butoir : 28 février 2022. Les malins, ça leur permet de se débarrasser des anciennes gammes qui étaient encore à prix contenus, pas pour rien non plus que je le gardais sous le coude pépère… ils me proposent d’aller voir dans d’autres gammes, avec à la clé, si je reste chez OVH (pour des histoires d’adresse IP si je voulais les conserver), un tarif augmenté de 20€ par mois minimum. Branle-bas de combat, s’agirait de se bouger donc.

On ressort le plan de migration, direction Hetzner, comparaison des prix et des gammes de serveurs chez OVH toujours; non pas Scaleway, pas envie/besoin de créer un énième compte en ligne. Au passage, OVH m’a créé un ticket de support pour proposer son aide pour migrer les données, enfin surtout dire qu’ils filent un petit pourliche pour le premier mois d’un nouveau serveur. Quand j’ai répondu que j’étais en train de déménager ailleurs, le ticket a été vite fermé. Ils sont plus réactifs que quand on leur pose une vraie question…

La commande chez Hetzner, presque un sans faute, mais aussi une (très) mauvaise surprise

Je suis déjà client, je joue régulièrement avec le public cloud, mais là, on passe aux choses sérieuses. Le serveur, c’est celui que je visais au départ, l’AX41-NVMe, avec la fiche technique qui fait se lécher les babines, dont voici les principaux critères :

• AMD Ryzen 5 3600 (6C12T, 3.6GHz)
• 64Go de RAM
• 2x SSD 512Go
• Réseau Gigabit

Aucune surprise sur le prix du serveur, la disponibilité, et la rapidité d’installation (que j’ai du refaire, j’y reviendrai). C’est sur le réseau où j’ai pris une sacrée piqure : depuis milieu d’année dernière, Hetzner se voit contraint de reporter sur les clients finaux les couts d’achat des blocs d’IP, en raison d’explosion des tarifs liés à la pénurie et aux brokers qui s’en foutent plein les poches; et ils n’ont pas la taille d’un OVH pour absorber ces couts. Et non, je n’envisage pas encore de me passer d’IP supplémentaire et tout faire en IPv6, c’est pas encore possible partout (coucou NordNet, pouvez-pas demander à Orange de vous mettre à jour, après tout vous utilisez leur backbone). Mais voilà, au niveau tarif, on est sur un 182€ le setup :

Pour ceux qui ont l’habitude du manager OVH, on est sur du formulaire plus qu’austère, mais qui est ultra-léger et qui fonctionne, je n’ai pas eu à rafraichir ou recommencer plusieurs fois. Le serveur était marqué disponible « within minutes » et en effet, il a été livré à la vitesse de l’éclair. On peut directement passer sa clé SSH pour l’installation, c’est toujours plus sympathique que de voir arriver un mot de passe root par mail…

Le faux départ, et ensuite, que du bonheur

Par contre, j’ai perdu un peu de temps parce que j’ai commencé à configurer l’OS tout de suite, avant de me rendre compte que le partitionnement n’irait pas pour Proxmox : il manque LVM ! En effet, par défaut, le script d’installation d’Hetzner configure certes les disques en RAID1, mais ce sont des groupes de RAID pour chaque partition créée. Fort heureusement, on peut redémarrer en rescue et relancer le script d’installation qui va tout refaire from scratch, par contre, débutants, vous transpirerez quelques minutes sur la gestion du partitionnement. En effet, j’ai voulu rester en RAID1, mais je ne savais pas comment il allait s’occuper du mix RAID + LVM. Je n’ai pas mis longtemps à trouver la solution, mais la documentation gagnerait quelques exemples supplémentaires.

Ensuite, l’installation de Proxmox est triviale, on suit les instructions de Julien qui sont un peu plus à jour que la doc d’Hetzner, et une fois redémarré, Proxmox est prêt à l’emploi. Il faut quand même passer par la case configuration du réseau. La documentation suffit, sinon quelques recherches feront l’affaire. Sans surprise parce que je suis mauvais en réseau, j’ai raté l’étape IPv6, mais il semblerait que la solution ne soit pas loin, donc affaire à suivre. Je suis allé au plus simple, parce que je manquais de temps, donc affectation directe d’IP, et je verrai ensuite pour le firewalling.

Pour le déménagement en lui-même, même si j’avais prévu de refaire certaines VMs de zéro, je n’avais clairement pas le temps de tout faire. Je suis donc parti sur une des forces de l’utilisation des machines virtuelles : l’utilisation des sauvegardes ! Comme je n’ai pas un gros besoin de disponibilité, j’ai prévenu un peu en avance que j’allais déménager des trucs, et le jour où j’ai voulu bouger, j’ai coupé les machines, créé une sauvegarde (format lzo, fichier unique), transféré via rsync sur le nouveau serveur, une petite commande de restauration, et voilà. Enfin presque voilà, on reconfigure une partie du matériel (genre CPU pour repasser sur le défaut, la plateforme qu’on passe à q35 parce que pourquoi pas, et on vire une carte réseau inutile), on démarre, on reconfigure le réseau pour utiliser une de nos chères IPs, un test rapide, et hop bascule DNS de l’alias principal; ah oui, j’avais préparé cette partie en amont pour me réduire la charge de travail de ce côté-là. Le petit bémol vient dans le transfert vers Hetzner, avec un vieux serveur OVH bridé à 250Mbit/s, ça prend du temps, 1h pour les plus grosses machines transférées.

Ça m’a rappelé ce vieux truc sur AOL…

Et quand je disais que j’avais donc dévié du plan initial, au-delà de l’absence de recréation des VMs from scratch, j’ai aussi fait l’impasse sur certaines machines qui n’étaient plus en utilisation. Ça permet de gagner du temps et de l’espace, car un des gros points faibles de ce nouveau serveur est clairement l’espace libre disponible : 430Go effectif, c’est léger, mais c’est en partie parce qu’en l’état certaines machines sont surdimensionnées et je n’ai pas encore mis en place les backups externalisés. La migration aura au final tenu dans seulement deux machines effectivement restaurées (même si j’ai quand même fait une copie de certaines autres, au cas où), dont la configuration aura été simplifiée au maximum. Ce qui veut dire que oui, pour l’instant le blog tourne toujours sur une machine dépassée, qu’il est plus que nécessaire de remplacer.

Ce qui va mieux, ce qui sera mieux

Clairement, quand je vois la réactivité de la machine qui héberge le blog, c’est un truc de fou. Dites-vous bien que le backup de la VM a pris un peu plus d’une heure à être réalisé, pour seulement 100Go de données. L’écriture ne dépassait pas les 30Mo/s… Même le SSH prenait du temps à me donner la main sur le serveur, maintenant, les actions sur les services et les redémarrages VM sont instantanés ou presque. Parcourez le blog, si vous avez l’impression d’être sur un site statique, non, c’est toujours WordPress. Mais clairement, on sent la différence notamment sur les opérations en backoffice.

J’ai aussi décidé de tester le firewall embarqué dans Proxmox. Déjà parce que pourquoi pas. Ensuite parce qu’au bout de deux jours, j’ai pris un mail d’abuse me disant que le BSI, un quasi équivalent de l’ANSSI chez nous, avait détecté des services en écoute sur mes IPs qui sont exploitables pour des attaques par réflexion/amplification. Et c’était vrai. Et ça m’a permis aussi de voir, en faisant l’inventaire sur les différentes VMs, que c’était assez bordélique et qu’il trainait aussi des reliquats de trucs que j’avais jamais utilisé. Le truc le moins trivial de cette activation de firewall, c’est le fait qu’il faille l’activer au niveau de la VM, mais aussi de la carte réseau de la VM, sinon, ça ne s’active pas. Surprenant. En tout cas j’ai eu la bonne surprise de voir qu’il était ready pour l’IPv6, et que les règles que j’ai créé seront appliquées directement. La configuration est relativement simple :

• un IPset par host avec les IPs 4 et 6 associés
• des alias ou des IPset pour les machines externes (genre celle pour le monitoring)
• un Security group par host, avec des règles ciblant l’IPset
• J’affecte chaque security group à la VM associée

Ça sera probablement amélioré dans le futur, du style créer des security groups pour les règles communes à toutes les machines (ICMP, SSH et monitoring), ou créer des alias pour les IPs et ajouter ces alias dans les IPset, mais c’est déjà un gros plus par rapport à la situation précédente. Et aussi, contrairement à ce que j’ai pu faire sur un des VPS que j’ai déployé ou le firewall est géré par ufw via ansible, je trouve ça plus avancé et souple à l’usage. Le seul bémol, c’est que pour l’instant, je n’ai pas l’impression qu’on puisse gérer ce firewall via d’autres outils que l’interface web. Ni Ansible ni le provider terraform ne semblent armés, dommage. Je chercherai peut-être à mettre en front un firewall type pfsense, mais là aussi, l’industrialisation des règles de flux sera importante, et pfsense ne semble pas plus exploitable que Proxmox, donc ça sera à chercher, encore.

Un autre point qui va clairement être aussi géré dans un avenir proche, c’est l’accès au Proxmox. Je viens de passer le MFA sur le compte root via TOTP, mais l’idée, c’est d’arrêter de m’en servir pour mieux identifier qui fait les actions, y compris les miennes (nous serons au moins deux sur le serveur). Pareil, tout repose uniquement sur l’interface web.

Et enfin, les backups, ça c’est le boulot des jours qui viennent. Ça tombe bien, Hetzner vient de baisser le tarif des storage box, on va donc pouvoir mettre en place un espace déporté pour que les VMs soient directement stockées en Finlande. Sans exclure une petite copie sur mon NAS parce que pourquoi pas

Il n’est pas rare, pour des plateformes Kubernetes à destination des clients, qu’on déploie aussi un serveur Gitlab pour gérer les sources des packages Helm et autres Dockerfile à l’usage des applications qui seront déployées. Ce serveur voit ses accès filtrés par IP, du coup, avec une IP dynamique (merci Orange), compliqué de gérer en permanence des règles de flux pour y accéder. Il y a heureusement une solution qui demande un peu de taf.

C’est dans le titre, l’idée va être de faire passer les connexions git et gitlab via un proxy Socks, créé par une connexion SSH. Cette connexion doit se faire sur une machine qui remplit deux critères, avoir une ip fixe, et avoir accès au serveur Gitlab. Si on établit la connexion SSH au serveur en question, c’est parfait ! Et cette connexion passe par un rebond au travers du VPN du boulot, rebond connecté au réseau privé du gitlab par un autre VPN. Ouais le réseau c’est chiant, mais c’est souvent comme ça qu’on procède, pas de connexions SSH via réseau public (et pas question de laisser le SSH ouvert à grand vent).

Notez bien que la configuration « proxy » est utilisable même avec un setup de rebond tel que je l’ai déjà présenté par le passé. C’est pas génial ça ?

On commence donc par créer la connexion/proxy. Il s’agit simplement d’ouvrir un port dynamique qui sera automatiquement paramétré en tant que proxy Socks. Avec OpenSSH sous Linux (ou Windows via WSL), c’est super simple :

$ ssh -D 9999 gitlab.domain.tld

À partir de là, on peut configurer nos différents clients pour utiliser ce proxy afin de joindre le domaine utilisé pour le gitlab. Si vous voulez ouvrir le port systématiquement, vous pouvez passer par le fichier ~/.ssh/config :

Host gitlab.domain.tld
  DynamicForward 9999

À ajouter aux autres éventuels réglages spécifiques pour cette connexion (user, clé SSH particulière, etc).

Pourquoi pas le localforward ?

J’ai déjà joué au localforward par le passé, par exemple pour le master k3s. Ça fonctionne bien dans ce cas-là, mais pour Gitlab, l’interface web me mixait des liens en 127.0.0.1:9999/groupe/projet/... et des liens en gitlab.domain.tld/groupe/projet/... et ces liens-là tombaient naturellement dans le vide. Pas du tout pratique donc, le proxy permet d’être complètement transparent, et de ne pas avoir à jouer avec son fichier hosts, ce qui n’est déjà pas une sinécure sous Linux, encore moins sous Windows.

D’ailleurs en parlant des windowsiens, pour ceux qui seraient coincés en enfer et qui utiliseraient encore PuTTY, voire MobaXTerm (oui y’a des masochistes), autant j’ai réussi à faire un truc avec PuTTY honteux au point que je ne détaillerai pas ici, autant MobaXTerm m’a résisté, impossible de créer un tunnel sur une machine derrière un rebond. Windows 10 et 2021, préférez WSL, ça fonctionnera très bien. Vous n’êtes pas obligés d’utiliser un navigateur dans WSL pour pouvoir accéder au port en question, c’est pas super ça ?

Git, tellement souple

En ligne de commande, git est particulièrement intéressant pour l’utilisation de proxy Socks. Pour un clone de départ, il suffit de paramétrer la variable ALL_PROXY avant de faire son clone :

$ ALL_PROXY=socks5://127.0.0.1:9999 git clone https://gitlab.domain.tld/group/project.git

Quoi, c’est tout, c’est aussi simple ? Ben oui, par contre, c’est valable que pour la session en cours. Git est heureusement incroyablement intelligent, et vous pouvez configurer ce proxy pour le dépot de manière persistante :

$ git config http.proxy socks5://127.0.0.1:9999

Les prochaines commandes sur le dépôt tenteront d’interagir avec l’upstream via le proxy configuré. Et foireront si vous oubliez d’ouvrir la session SSH évidemment. Nickel.

UPDATE: je suis tombé sur un article dont j’ai perdu le lien qui explique que sur du git récent on peut carrément définir le proxy pour tout un domaine dans la conf globale. Donc dans le ~/.gitconfig, ça ressemble à ça:

[http "https://gitlab.domain.tld/"]
    proxy = socks5://127.0.0.1:9999

Du coup plus besoin de faire ALL_PROXY=... et git config ..., ça le fait automatiquement, y compris pour les nouveaux clones

Gitlab, une affaire de navigateurs

Pour les navigateurs, c’est un poil différent. Pour Firefox, les paramètres sont natifs, ouvrez le menu des préférences et cherchez proxy, vous verrez le bouton qui va bien.

Il suffit de configurer un proxy Socks 5, sans authentification, avec les mêmes paramètres qu’au dessus. Attention, ça implique de passer toutes les connexions de tous les onglets en cours dans le proxy, car le paramètre est global. Pour une gestion plus fine, il faudra une extension permettant plus de contrôles.

Pour les navigateurs basés sur Chromium, c’est plus compliqué. Par défaut, il n’embarque aucun paramètre natif et repose, notamment sous Windows, sur le proxy global déclaré dans les paramètres réseau. Il faut donc obligatoirement une extension pour faire le boulot, j’ai sélectionné Proxy SwitchyOmega qui m’a donné satisfaction.

Elle permet de déclarer plusieurs proxys, de facilement switcher entre les proxys, il y a même un mode dynamique qui permet de switcher entre plusieurs proxys en fonction du domaine (je n’utilise Chromium que pour des besoins ultra ciblés, malgré tout, il arrive de devoir basculer rapidement d’un projet à l’autre). Bref, vous aurez toutes les clés pour accéder comme il faut à l’interface de votre serveur Gitlab sans risque de conflits de liens/domaines.

Pas que pour Gitlab

Ce système de tunnel SSH est exploitable comme alternative aux VPN qu’on nous vend ad nauseam dans les vidéos Youtube. Il m’est arrivé de tester rapidement des accès à une plateforme par ce biais via plusieurs serveurs dans différents réseaux, pour évacuer un problème dépendant du fournisseur d’accès (déjà eu un incident client déclaré mais au final lié à Orange). Par contre, une des promesses des VPN est de pouvoir contourner les géoblocages mis en place par des plateformes de fourniture de contenu par abonnement, mais la plupart des ranges des hébergeurs sont déjà identifiés et bloqués (vécu par un collègue avec un VPS chez OVH au Canada pour tenter d’accéder au catalogue Netflix US).

Dans l’absolu, vous pouvez faire passer tout type de trafic et d’applications, soit de manière native, soit de manière un peu détournée. Entre le début et la fin de l’écriture/mise en forme de cet article, j’ai rajouté tsocks à ma trousse à outils qui me permet de faire passer… des connexions SSH au travers du proxy SOCKS ouvert… par une autre connexion SSH. Oui, c’est assez tordu, et un jour je vous expliquerai peut-être l’immense bêtise qui m’a poussé à devoir procéder de la sorte.