Savoir ce que chaque pare-feu autorise — sans jamais perdre votre accès.

Hetzner, DigitalOcean et TransIP aujourd’hui. Ce que vous pouvez faire diffère selon le fournisseur et est déclaré plutôt que supposé : Hetzner et DigitalOcean vous laissent créer un pare-feu et l’attacher à plusieurs serveurs, TransIP donne à chaque VPS un pare-feu propre qu’on ne peut ni renommer ni détacher, et OVHcloud n’a aucune API de pare-feu — son filtrage appartient à l’adresse IP et non à la machine, nous laissons donc le sujet tel quel plutôt que de le signaler désactivé. La page intégrations indique ce qui fonctionne où.

Non. Il gère le pare-feu natif que votre fournisseur vous donne déjà. Les règles sont réécrites vers le cloud : ce qui tourne réellement est le pare-feu du fournisseur — simplement édité depuis un seul endroit, résumé en une phrase et vérifié avant enregistrement. Renommer un pare-feu le renomme aussi chez le fournisseur, plutôt que de lui donner un surnom local.

Elles sont importées telles quelles dès que vous connectez un fournisseur — rien n’est supprimé ni réécrit. Les règles que le fournisseur gère lui-même, exprimées en tags, serveurs, répartiteurs de charge ou clusters Kubernetes plutôt qu’en adresses, ne sont pas modifiables ici parce que notre forme de règle contient des adresses. Elles sont affichées, comptées et conservées intactes lors d’un enregistrement, plutôt que masquées ou supprimées en silence.

Il confronte l’adresse d’où vient votre session aux règles que vous allez appliquer, en ne regardant que les ports qui constituent un chemin de retour — SSH et RDP — et en vérifiant chaque famille d’adresses séparément, pour qu’une règle IPv4 en 0.0.0.0/0 ne vaille pas accès pour quelqu’un connecté en IPv6. Les plages de ports comptent : une règle ouvrant 20-30 est reconnue comme couvrant SSH. Si le changement vous retire l’accès, Confirmer est bloqué jusqu’à ce que vous le reconnaissiez. Tant que la vérification tourne, Confirmer est inerte et le dit.

Seulement si vous choisissez Remplacer, et vous voyez le jeu de règles résultant avant de confirmer — l’alternative est Ajouter, qui verse les règles du modèle par-dessus l’existant. Les modèles intégrés sont en lecture seule ; les vôtres se modifient et se suppriment, et un modèle supprimé se récupère depuis la corbeille pendant quatorze jours.

Seules les règles entrantes ouvertes à n’importe quelle adresse sont examinées. Une règle qui ouvre tous les ports est critique à elle seule ; au-delà, il cherche SSH (22), le bureau à distance (3389) et neuf services de bases de données et de cache — MySQL, PostgreSQL, SQL Server, MongoDB, Redis, Elasticsearch, Memcached, Docker et Kubernetes — chacun donnant un constat critique. FTP et Telnet sont un avertissement plutôt qu’une erreur : non chiffrés, mais pas une base de données. Les plages et les listes séparées par des virgules sont prises en compte, pas seulement les ports exacts. Chaque constat peut être ignoré pour ce contrôle-là.

Oui — liez la règle à une IP dynamique et l’entrée suit votre adresse. Seule l’entrée que nous avons écrite change ; toutes les autres adresses de la règle restent intactes. C’est toujours un hôte unique et jamais une plage, et toujours l’adresse depuis laquelle vous vous êtes réellement connecté, pas une adresse que vous auriez indiquée. Les règles en vigueur sont relues chez le fournisseur avant chaque écriture, et si la règle que nous suivions a disparu, la cible est signalée et alertée plutôt que laissée à pointer en silence vers une adresse périmée.