Chaque pair OpenVPN a-t-il besoin d’une ligne remote ? Pas exactement

Deux configurations de pair sont comparées côte à côte, l’une comporte une ligne remote et l’autre non, et la conclusion est que l’une des deux est cassée. Cette inférence est fausse assez souvent pour valoir la peine d’être décortiquée. La directive décrit où le premier paquet doit être envoyé. Elle ne choisit pas si le processus agit comme un client qui initie ou comme une passerelle qui attend, et elle ne décide pas quel côté prouve son identité à l’autre.

Ce que remote spécifie réellement

Une entrée remote nomme un hôte, éventuellement un port et un transport, et éventuellement plusieurs de ces entrées à essayer dans l’ordre.

Son absence a un sens défini et non indéfini : le processus attend et n’agit pas sur les paquets d’une adresse à moins que ce pair ne s’authentifie. Une passerelle qui sert des utilisateurs itinérants n’a donc aucune raison de nommer l’un d’eux à l’avance.

Lisez l’entrée comme une relation d’adresses. La confiance accordée à l’extrémité distante est répondue par les certificats et les options de vérification, non par le fait qu’une adresse ait été écrite.

Trois dispositions décident de la réponse

Un client itinérant a besoin d’une destination, car il doit initier et il ignore où se trouve la passerelle sans elle. Une passerelle multi-clients n’a pas besoin de destination par utilisateur, car les clients arrivent et s’authentifient. Une liaison délibérée entre deux pairs aux extrémités connues peut avoir une destination d’un côté, des deux côtés ou d’aucun, selon le côté qui initie.

Coller une adresse de client fixe dans une passerelle générale est l’erreur qui découle de l’ignorance de ces catégories. Elle fonctionne pour l’unique pair dont l’adresse a été enregistrée et trompe tous les autres.

Rien dans la directive ne transforme une configuration en serveur multi-clients, et rien dans sa présence n’empêche un rôle de serveur. La référence OpenVPN 2.6 documente séparément les arguments optionnels et le comportement en l’absence de remote, ce qui donne une idée de leur indépendance.

Les rôles de transport sont un autre axe

En TCP, un côté attend et l’autre établit la connexion. Ce sont des directives distinctes de la destination, et les mélanger produit une paire où les deux attendent ou les deux établissent la connexion.

Il existe aussi un rôle de filtre de source TCP, ce qui rend fausse l’affirmation plate qu’un serveur ne peut jamais contenir remote.

En UDP, il n’y a pas de connexion à établir, donc les deux extrémités utilisent le transport UDP correspondant et la directive indique seulement où viser. Les changements d’adresse d’un pair authentifié sont gérés par un comportement dédié plutôt qu’en ajoutant des entrées. Avoir le bon transport est une condition préalable pour que la destination ait un sens, et confondre les deux produit des configurations qui semblent plausibles et n’achèvent jamais une poignée de main.

Pourquoi un remote absent n’est pas une porte ouverte

Un processus sans destination refuse encore le trafic des pairs qui ne s’authentifient pas, et c’est la partie que les gens manquent lorsqu’ils lisent la ligne absente comme un écouteur ouvert à tous.

L’authentification et la destination sont indépendantes, et la première est celle qui compte pour la confiance.

L’erreur inverse est plus dangereuse. Une adresse source fixe peut donner l’impression d’un contrôle d’accès parce qu’elle est précise et facile à vérifier, mais elle ne prouve rien sur qui se trouve à l’autre bout. Conservez la vérification des certificats et les contrôles d’identité qui lient un certificat à son rôle. Les remplacer par une correspondance d’adresse échange un contrôle réel contre son apparence.

Notez ce que la configuration suppose

Pour chaque côté, consignez trois choses : comment le premier paquet atteint le pair, quel côté peut accepter le transport et ce que chaque côté vérifie de l’autre.

Ces hypothèses sont la conception. Les directives n’en sont que l’orthographe.

Si les deux fichiers diffèrent, vérifiez s’ils expriment des hypothèses différentes au lieu de supposer que l’un est faux. Une paire de fichiers symétrique n’est ni nécessaire ni suffisante pour un tunnel fonctionnel, et l’asymétrie est souvent la partie qui fait fonctionner une topologie.