VPN semi-géré : l’étiquette ne dit pas qui est d’astreinte

À huit heures du matin, une connexion tombe, et la première question est qui doit la réparer. L’expression VPN semi-géré n’y répond pas, car elle désigne un arrangement commercial et non un partage du travail. Deux fournisseurs peuvent employer la même expression avec des répartitions opposées : l’un entretient l’équipement côté client, l’autre ne surveille que sa propre passerelle. Tant que les tâches ne sont pas écrites, l’étiquette est une supposition déguisée en description.

Partez de la connexion qui a échoué

Nommez l’extrémité qui a cessé de répondre, l’heure, et ce que faisait l’utilisateur quand cela a cassé. Énumérez ensuite les composants de ce chemin : l’ordinateur portable, le circuit local, la passerelle côté client, la passerelle du fournisseur et la ressource derrière elle. Chacun a soit un responsable dans l’accord, soit un trou. Les trier prend dix minutes et décide des trois heures suivantes.

Un symptôme partagé par plusieurs utilisateurs désigne un composant commun, tandis qu’un symptôme qui suit un seul ordinateur portable désigne le client. Cette distinction place le ticket dans la bonne file avant que quiconque ouvre une configuration.

Réglez les deux extrémités avant les réglages

Décidez qui possède la passerelle côté client et qui possède l’extrémité distante. Une fois ces deux points réglés, chaque partie sait ce qu’elle peut inspecter et ce qu’elle doit demander. Tout le reste de l’accord devient plus simple à partir de là.

Un fournisseur peut superviser sa propre passerelle tandis que le client reste responsable d’un circuit local chez un fournisseur d’accès, d’un service d’annuaire ou de l’application de destination. Un équipement appartenant au client peut néanmoins relever d’un contrat de maintenance du fournisseur, et c’est pourquoi la propriété et la personne qui entretient la boîte sont deux questions différentes. Écrivez les deux réponses pour chaque extrémité, car c’est sur la seconde que les renouvellements divergent d’ordinaire.

Les objets partagés n’ont besoin que d’un seul responsable

Les identités, les identifiants, les préfixes protégés, les propositions et l’accord de routage de retour sont des objets partagés, et les objets partagés pourrissent le plus vite. Si les deux parties peuvent en modifier un, toutes deux le feront, et chaque changement paraît localement correct tandis que le flux convenu casse. Donnez à chaque objet un responsable et un processus de changement, et exigez que l’autre partie soit prévenue avant qu’un changement soit appliqué. L’alternative est un journal des changements qui se lit comme deux personnes réparant des moitiés différentes de la même machine.

La panne classique est un changement de sélecteur d’un côté et un changement de NAT de l’autre la même semaine. Aucun des ingénieurs n’a mal fait, et le tunnel a quand même cessé de porter l’application.

Qui prend le premier signalement

Décidez à l’avance qui est appelé en premier, ce que chaque partie est autorisée à lire, et le moment où le dossier change de mains. Fournissez l’extrémité, l’heure de la tentative et le flux autorisé pour que les deux parties puissent corréler le même événement.

Un résumé d’état étroit est généralement plus utile qu’une configuration non expurgée, et il ne divulgue pas de secrets. La supervision appartient à qui possède le composant, non à qui possède le logo, demandez donc quelle partie voit l’état du tunnel, laquelle voit l’application, et qui est réveillé par chaque alerte. Placez la route hors horaires à côté de chaque alerte, car un tableau de bord pour lequel personne n’est d’astreinte est de la documentation.

Définissez l’autorité de changement avec le même soin. Un fournisseur qui modifie un sélecteur pendant que le client modifie le NAT rend les deux configurations locales plausibles et le tunnel échoue toujours.

Ce que l’étiquette ne dit jamais

Inscrivez la maintenance logicielle, la rotation des identifiants, les sauvegardes approuvées de la configuration et le chemin de restauration dans l’accord réel. Un modèle de responsabilité partagée comme le modèle que publie AWS montre jusqu’où le partage peut se déplacer entre services, et c’est un exemple et non une définition des conditions de votre fournisseur. Déduire quoi que ce soit de l’expression semi-géré est la façon dont une conversation de renouvellement découvre un trou.

Le périmètre devrait nommer l’exploitant normal et le chemin d’escalade de chaque dépendance. Quel que soit le nom que le devis donne au service, c’est cette liste qui compte en pratique.