Pourquoi copier la configuration du serveur OpenVPN vers une succursale échoue

Copier la configuration du serveur qui fonctionne, changer quelques adresses et appeler cela un profil de succursale produit en général une connexion. C'est le pire résultat, car la succursale tourne alors avec le mauvais rôle, expose du matériel qui ne devrait pas quitter le concentrateur et laisse une association de route que personne ne se souvient d'avoir créée. La connexion cache trois problèmes à la fois, et le tunnel monte avant que quiconque les vérifie.

Traiter la succursale comme un pair avec sa propre identité et son rôle réseau est ce qui rend le profil correct. Le correctif n'est pas une meilleure copie, et le reste de cette page porte sur ce qu'un client devrait réellement détenir.

Deux rôles qui ressemblent à un seul fichier

En mode TLS, les deux pairs ont des tâches complémentaires. Un côté écoute, détient le certificat et la clé du serveur et décide quels clients peuvent se connecter. L'autre côté initie, vérifie l'écouteur et présente sa propre identité.

Un fichier de serveur contient des directives qui n'ont aucun sens sur un client : une adresse d'écoute et un port, un pool d'adresses à distribuer et souvent une liste de poussée pour des réglages que les clients devraient recevoir. Les copier vers une succursale produit un appareil qui tente d'être à la fois écouteur et client.

La clé privée est la partie qui compte le plus. Un client ne doit jamais porter la clé privée du serveur, et il n'a pas besoin non plus de la clé de signature de l'autorité de certification. Un certificat d'autorité est du matériel de confiance public ; la clé de signature appartient là où les certificats sont émis.

Ce qu'un profil de succursale doit contenir

Un profil de succursale a besoin du point de terminaison distant et du transport, de l'identité de serveur de confiance, du certificat et de la clé propres à la succursale, ainsi que des routes et des réglages DNS dont la succursale a réellement besoin. Rien d'autre n'est obligatoire.

Gardez l'identité de la succursale séparée par site. Deux succursales qui partagent un certificat signifient que révoquer l'une désactive l'autre, et les journaux du concentrateur ne peuvent pas les distinguer. Une identité par site est ce qui fait fonctionner à la fois la piste d'audit et l'histoire de révocation.

Soyez prudent avec les flux des appareils. Le paquet Client Export de pfSense génère des profils pour les contextes Remote Access éligibles, et sa liste de serveurs ne comprend que les serveurs configurés dans un mode Remote Access. Un serveur site à site d'un autre mode n'apparaît pas, et cette absence est une information, non une invitation à copier les secrets du serveur.

Si l'appareil n'exporte pas le profil dont vous avez besoin, utilisez son flux de client site à site documenté ou construisez le profil à partir de l'exemple pris en charge de la version installée. N'exportez une sauvegarde du serveur vers la succursale que si le plan est de restaurer un serveur, ce qui n'est pas le cas. Une sauvegarde porte aussi le matériel privé du concentrateur, donc la déplacer vers une succursale est une décision de gestion de clés, pas un transfert de fichier. Gardez-la sur le concentrateur et générez l'identité du client là où les certificats sont émis.

L'association entre pair et réseau est distincte

Un client de succursale qui se connecte avec succès ne peut toujours pas faire passer le trafic de son LAN tant que le concentrateur ne sait pas que ce pair possède ce préfixe. Cette association vit sur le concentrateur, liée à l'identité du client, et elle est distincte de la route propre de la succursale vers les réseaux distants. Sans elle, les hôtes de la succursale paraissent joignables dans les statistiques du tunnel et ne le sont pas en pratique. Le journal du concentrateur est l'endroit où confirmer si l'association a été appliquée.

Ajouter une route dans le système d'exploitation du concentrateur n'est pas la même chose que de dire à OpenVPN quel client possède le préfixe. Sans l'association par client, le paquet atteint l'interface du tunnel et est abandonné parce qu'aucun pair ne revendique la destination.

Côté succursale, le besoin correspondant est une route vers les réseaux qu'elle doit atteindre, plus un routeur de LAN qui sait renvoyer le trafic vers la succursale. La propriété côté serveur et les routes de destination côté client sont des objets distincts, et un tunnel qui fonctionne ne prouve que le premier saut. Notez les deux dans les notes de passation de la succursale, car l'ingénieur suivant n'en trouvera qu'une.

Prouver que la succursale est le pair que vous croyez

Vérifiez l'identité avant de vérifier le trafic. Le journal du concentrateur devrait montrer le nom commun du certificat de la succursale, et l'adresse reçue par le client devrait correspondre au pool ou à l'attribution fixe que vous vouliez. Si le journal montre un autre nom, le profil porte l'identité de quelqu'un d'autre.

Vérifiez ensuite l'association en envoyant une requête depuis un hôte de la succursale vers une ressource côté concentrateur et confirmez qu'elle réussit avec l'adresse source attendue. Testez une destination que la succursale ne doit pas atteindre et confirmez qu'elle échoue, car une route permissive qui fonctionne par hasard n'est pas la même chose qu'une politique correcte.

Enfin, révoquez l'identité de la succursale et confirmez que la connexion échoue tandis que le certificat du concentrateur et les autres sites continuent de fonctionner. Si la révocation casse le concentrateur, des rôles et des identités ont été partagés quelque part, et c'est le constat qui vaut la peine d'être rapporté à la conception.

Une succursale terminée est une succursale dotée d'une identité documentée, d'un profil réservé au client, d'une association entre pair et réseau sur le concentrateur et d'un chemin de retour éprouvé. Inverser le texte d'un fichier de serveur ne vous en donne aucun.