Placez la passerelle VPN à côté de Windows XP, pas dedans

Quelque part dans le bâtiment se trouve une machine qui exécute une application que personne ne peut remplacer, sur un système d’exploitation qu’il ne faut connecter à rien. Partir de l’adaptateur réseau de cet hôte est le moyen le plus rapide de voir où le tunnel doit se trouver. Dans la plupart des conceptions, il n’a rien à faire sur l’hôte. Déplacez-le d’un saut vers une passerelle maintenue, et le vieux problème se réduit à l’application avec laquelle il a commencé.

Commencez par l’adaptateur de l’hôte, pas par un client VPN

Ouvrez les propriétés de l’adaptateur et donnez à l’hôte une adresse fixe sur un petit segment dédié, avec la passerelle comme route par défaut. L’hôte n’a alors besoin ni de client tunnel, ni d’identifiants de tunnel, ni d’entrées de table de routage vers le réseau d’entreprise au sens large. Si l’application a besoin d’un seul sous-réseau distant, ajoutez exactement cette unique route.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

Cette commande épingle une seule destination sur la passerelle et laisse tout le reste non routable, ce qui est la forme voulue. Confirmez le résultat avec route print plutôt qu’en faisant confiance au code de sortie. Vérifiez ensuite que l’application résout toujours le nom de son serveur, car un hôte hérité avec un résolveur cassé ressemble exactement à une panne réseau, et réparer le résolveur est un travail de cinq minutes alors que reconstruire une application après un changement réseau erroné ne l’est pas. Chaque destination que l’hôte ne peut pas atteindre est une chose de moins à laquelle une vieille pile réseau peut être amenée à s’attaquer.

Mettez le tunnel sur du matériel que vous pouvez mettre à jour

La passerelle veut deux interfaces : une face au segment de l’hôte et une face à l’endroit où vit l’application, le tunnel se terminant sur la seconde. Cet équipement peut recevoir des mises à jour de firmware, remplacer sa configuration cryptographique et journaliser les flux sans que personne ne touche à la vieille machine. Son fournisseur livre aussi des correctifs pour l’implémentation du tunnel, que l’hôte ne recevra jamais. Deux machines et une échéance ne justifient pas de copier une recette à secret statique depuis un message de forum.

Donnez à chaque passerelle sa propre identité de pair au lieu de cloner une configuration client sur toute une flotte. Lorsqu’une unité est remplacée, révoquez l’ancienne identité au moment même où vous mettez la nouvelle en ligne, sinon vous vous retrouvez avec deux copies non contrôlées qui s’authentifient au même point de terminaison. Stockez les clés là où le plan de gestion de la passerelle les attend, traitez une sauvegarde de configuration comme un secret et vérifiez qui peut pousser cette configuration, car elle décide désormais de ce que l’hôte hérité peut atteindre.

Autorisez des services, pas des réseaux

Écrivez la politique en termes de protocole, de port et de direction entre les deux raccordements. Un seul port autorisé vers une seule adresse d’application est la réponse habituelle, et un chemin administratif via un hôte de rebond couvre le reste.

L’administration à distance de l’hôte hérité ne devrait pas emprunter la même règle que l’application, et tester le refus compte autant que rédiger la règle. Envoyez une requête depuis l’hôte vers une destination dont vous attendez le refus et confirmez que le refus vient de la politique et non d’une route manquante. Journalisez les flux que vous autorisez tant que la conception est nouvelle, afin de voir ce que l’application utilise réellement et non ce que sa documentation prétend. Fusionner deux sous-réseaux parce qu’un tutoriel ponté semblait plus court est la façon dont un segment hérité devient discrètement un point d’appui.

N’exposez pas l’écouteur hérité directement à Internet comme raccourci autour de la passerelle. Gardez le chemin administratif séparé du chemin applicatif afin que la compromission de l’un ne livre pas l’autre. Une règle qui n’est jamais exercée est une règle que personne n’a vérifiée, et c’est pourquoi la destination refusée fait partie de la campagne d’acceptation.

La reprise doit fonctionner sans le tunnel

Décidez qui met à jour et rétablit la passerelle avant la première panne, et assurez-vous que cette personne peut y accéder sans le tunnel qu’elle termine. L’accès console, un port de gestion local ou un chemin hors bande comptent tous comme réponses. Une passerelle qui ne peut être configurée que via le tunnel qu’elle fournit est un piège qui attend patiemment un mauvais envoi de firmware.

Écrivez le runbook de la panne que vous rencontrerez réellement : tunnel en panne, passerelle morte, disque de l’hôte disparu. Conservez l’image de restauration de l’hôte dans le cadre de l’accord de support qui existe encore, et rappelez-vous qu’une restauration restaure aussi l’état logiciel et les identifiants contenus dans cette image. Restaurez d’abord sur le segment isolé, confirmez que l’application démarre et ne reconnectez quoi que ce soit qu’ensuite ; lorsque la passerelle change, mettez à jour le runbook et l’inventaire dans la même séance.

Certificats, horloges et avertissements de signature

L’expiration du certificat d’un programme d’installation ne prédit pas à elle seule ce que dira aujourd’hui un contrôle de signature. Les conseils de Microsoft sur les horodatages Authenticode expliquent qu’un horodatage peut garder une signature vérifiable après l’expiration du certificat de signature, et que la validation dépend toujours de la signature, de la chaîne de confiance et du vérificateur qui fait le travail. Deux machines dotées de magasins de confiance différents peuvent donc être en désaccord sur le même fichier. Un signataire expiré n’est pas la preuve qu’un binaire est malveillant, et une signature valide n’est pas la preuve que le logiciel est maintenu.

Ne reculez pas l’horloge système et ne désactivez pas les contrôles de signature pour faire tourner un vieux programme d’installation. Obtenez un artefact autorisé auprès de celui qui prend encore en charge l’application et laissez-le dire ce que la plateforme accepte. Traitez les messages affirmant qu’une compilation précise fut la dernière pour XP comme de l’histoire et non comme une cible d’installation, car l’exigence réelle dépend de l’application ; si un travail de préservation est vraiment nécessaire, gardez-le sur un segment isolé à l’écart de l’accès de production et documentez pourquoi il existe.