Passerelle VPN combinée ou séparée : choisir selon le domaine de défaillance

Deux appareils semblent plus résilients qu'un seul jusqu'à ce que vous remarquiez qu'ils partagent la même multiprise, le même hyperviseur et le même lien amont. Compter les boîtiers répond à une question que personne n'a posée ; la question utile est ce qui tombe en même temps. Écrivez d'abord le contrat de défaillance, puis laissez-le choisir la topologie. Le runbook ci-dessous produit cet enregistrement.

Ce qui s'arrête pendant un redémarrage

Pour une passerelle combinée, listez ce qui disparaît pendant un redémarrage, une mise à jour ratée ou une panne matérielle. Si l'accès à internet et la connectivité privée s'arrêtent ensemble, cette interruption partagée fait désormais partie de votre exigence de disponibilité, que quelqu'un l'ait écrit ou non. Le même exercice s'applique à un seul appareil qui termine plusieurs rôles : la liste des services qu'il coupe est la vraie spécification.

Pour des passerelles séparées, listez ce qui reste partagé : l'alimentation, l'hôte de virtualisation, le lien amont, le fournisseur d'identité, le réseau de gestion. Deux appareils derrière un commutateur en panne sont un seul domaine de défaillance avec deux noms d'hôte. Une séparation qui ignore ces dépendances est un schéma, pas une conception.

Comptez aussi la propriété de la maintenance. Un autre appareil apporte la configuration, la supervision, les sauvegardes et une seconde procédure de reprise, et rien de tout cela n'est gratuit.

Marquez où chaque règle est appliquée

Suivez un paquet du client vers une ressource privée et retour, et marquez chaque endroit où une politique s'applique. Un second routeur ajoute un autre point où la préférence de route, la traduction ou l'état de connexion peuvent diverger du premier. La plupart des défaillances mystérieuses d'une conception à deux passerelles vivent sur cette couture.

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

Notez où la protection VPN finit et où la politique interne commence. Si le chemin entre les deux appareils est permissif, la seconde boîte n'a pas créé de frontière ; elle a seulement déplacé l'endroit où une frontière aurait pu être. Sur une seule plateforme, des zones de politique distinctes peuvent encore être efficaces, et leur efficacité doit être évaluée d'après les règles plutôt que rejetée parce que le matériel est partagé.

Arrêtez-vous si vous ne pouvez pas dire quel appareil applique la règle qui compte. Cet écart est le constat, pas un détail à régler plus tard.

Le confinement est une frontière, pas un châssis

Un appareil séparé ne contient une compromission que lorsque le chemin qui le traverse est limité à ce dont l'autre côté a besoin. Si les deux appareils acceptent n'importe quel trafic l'un de l'autre, un attaquant qui atterrit sur l'un a la même portée qu'avant. L'affirmation de confinement appartient au jeu de règles, pas à l'inventaire. Lisez les règles, dites quels flux sont autorisés, puis décidez si la séparation a acheté quoi que ce soit.

La même logique s'applique aux utilisateurs. Un utilisateur VPN auquel on fait confiance à cause du réseau d'où il vient fait confiance à l'emplacement plutôt qu'à l'identité, et les recommandations NIST sur le zéro confiance décrivent l'alternative : authentifier et autoriser chaque requête vis-à-vis de la ressource. Ce principe tient quel que soit le châssis qui termine le tunnel.

Si la séparation existe pour satisfaire une ligne de conformité plutôt que pour changer un flux, dites-le dans l'enregistrement. Un contrôle que personne ne peut expliquer est le premier retiré sous pression.

Récupérez ce que vous pouvez réellement joindre

Demandez quel chemin de reprise survit quand l'un ou l'autre rôle meurt. Quand le seul moyen d'atteindre une passerelle VPN cassée passe par cette passerelle, un appareil de rechange ailleurs n'aide pas l'administrateur qui doit la réparer. Un chemin hors bande, une console et un retour arrière documenté sont les pièces qui rendent la conception récupérable.

systemctl status strongswan
nft list ruleset
ip -brief address

Dimensionnez la conception pour la charge de travail complète prise en charge plutôt que pour un chiffre de chiffrement isolé, car le filtrage et l'inspection consomment le même matériel. Utilisez la documentation du fournisseur et vos propres mesures au lieu de supposer que la séparation est plus rapide ou plus lente. Puis écrivez l'enregistrement de décision : quels flux sont autorisés, quelles dépendances sont partagées, ce qu'une fenêtre de maintenance coupe, quelles preuves de capacité vous avez et qui possède chaque étape de reprise. Cet enregistrement est assez court pour être relu et assez précis pour y revenir.

Le runbook se termine quand le contrat de défaillance est écrit, que le chemin de transfert a un point d'application nommé par règle, que le confinement est décrit par des flux plutôt que par un nombre d'appareils, et que la reprise fonctionne depuis l'extérieur du composant défaillant. Choisissez l'arrangement le plus simple qui satisfait ces exigences.