Une VM Azure a besoin du tunnel : client invité ou passerelle VPN ?

Une charge de travail dans une VM Azure doit atteindre un réseau privé par un tunnel. La question qui décide de la conception n'est pas quel produit VPN est meilleur ; c'est de savoir si une autre machine aura un jour besoin de ce chemin. Répondez à cela d'abord et le reste de l'architecture se choisit généralement tout seul. Si vous vous trompez, vous héritez d'une VM devenue discrètement un routeur que personne n'a documenté.

Deux tâches qui se ressemblent

Une VM peut être un point de terminaison ou un point de transit, et la différence n'est pas le logiciel que vous installez mais qui consomme le tunnel. Comme point de terminaison, l'invité exécute un client pour ses propres processus. Comme point de transit, il transfère les paquets d'autres charges de travail, ce qui en fait une partie de votre topologie réseau.

La plupart des demandes pour une seule VM sont la première tâche habillée du langage de la seconde. Quelqu'un dit « la VM est notre VPN » alors qu'il veut dire qu'une application dessus doit atteindre une base de données de l'autre côté.

Condition un : quelque chose d'autre a-t-il besoin du côté distant ?

Si la réponse est non, installez le client dans l'invité et arrêtez de concevoir. Rien dans ce choix n'exige la passerelle gérée, et rien n'en fait une passerelle pour ses voisins. Vous ajoutez une route à l'intérieur d'un seul système d'exploitation.

Si la réponse est oui, ou probablement oui d'ici un an, traitez-le maintenant comme une conception réseau. Les autres VM n'atteignent une VM de transit que lorsque la table de routes du sous-réseau les y envoie et que la NIC accepte le trafic transféré, donc le travail consiste en tables de routes et autorisations de transfert, pas en une autre installation de client.

Condition deux : pouvez-vous conserver le chemin d'administration ?

Un client VPN qui installe une route large peut capturer le chemin que vous utilisez pour administrer la VM. Si la liste de destinations du tunnel chevauche le réseau de gestion, votre session SSH ou RDP tombe à l'instant où le client se connecte, et le correctif doit être appliqué par la console série ou par une reconstruction.

Vérifiez avant et après. Sous Linux, ip route get <management-ip> indique quelle interface et quelle source le noyau utiliserait maintenant ; comparez avec la réponse pendant que le tunnel est actif. Un tunnel divisé avec une liste explicite de destinations est plus facile à défendre qu'une route par défaut, et c'est généralement ce dont la charge a réellement besoin.

Condition trois : qui applique les correctifs à minuit ?

Un client invité, c'est votre système d'exploitation, votre version de client et vos certificats. C'est très bien quand vous exploitez déjà la VM et son cycle de correctifs. C'est un mauvais échange quand la VM n'existe que pour porter le tunnel. Comptez les heures de correctifs avant de déclarer le client invité moins cher. Une mise à jour de client qui exige un redémarrage est une panne que vous avez planifiée pour une machine qui existe pour maintenir le tunnel.

La passerelle gérée déplace cette maintenance vers la plateforme. Vous possédez toujours l'identité, l'autorisation et les chemins réseau derrière, mais vous ne redémarrez pas une machine pour appliquer une mise à jour de client.

Ce que la passerelle gérée ne fait pas

Azure VPN Gateway est un service de connectivité VNet avec ses propres dispositifs site à site et point à site. Ce n'est pas une règle qui interdit un logiciel VPN dans l'invité, et ce n'est pas un remplacement direct pour un client dont une application a besoin.

Ce qu'elle offre, c'est une connexion au niveau réseau, accessible par de nombreuses charges via le routage. Ce qu'elle n'offre pas, c'est un tunnel que seul un processus sur une VM utilise, limité à l'identité de ce processus. Cette portée n'est pas une limitation dont il faut s'excuser ; c'est précisément l'intérêt de la conception avec client invité. Une application, une route, un jeu d'identifiants, aucun effet sur les autres VM du sous-réseau.

La comparaison n'oppose donc pas géré et logiciel. Elle oppose connectivité à l'échelle du réseau et connectivité à l'échelle du processus, et la seconde est légitime quand un seul processus en a besoin.

Planifiez le chemin de croissance avant d'en avoir besoin

Si le besoin passe d'une VM à un sous-réseau, reconstruisez la conception au lieu d'élargir les préfixes autorisés du client. Réutiliser une session commode comme routeur non documenté lie chaque consommateur à la durée de vie de cette VM, à ses identifiants et à sa fenêtre de correctifs.

Le bon point de départ, une fois la connexion à l'échelle du réseau plutôt que de la charge, est la présentation d'Azure VPN Gateway.

Avant de choisir, écrivez trois lignes : ce qui a besoin du côté distant, qui administre la VM et qui corrige le tunnel. Si les trois réponses désignent une seule charge, un client invité est la conception honnête. Si l'une d'elles désigne un sous-réseau, concevez la couche réseau maintenant.