Quand un client d’accès distant doit servir de passerelle de site distant

Un ordinateur portable connecté à un VPN peut joindre le siège. L’imprimante et le serveur de fichiers du même bureau ne le peuvent pas, car rien ne transmet leurs paquets dans ce tunnel ni ne rapporte les réponses. Transformer le client en passerelle de site distant est une décision de routage et de responsabilité avant d’être une décision de configuration. Le nom du protocole sur la boîte ne répond pas à la question de savoir si ce rôle est pris en charge.

Ce que l’étiquette du protocole ne vous dit pas

OpenVPN documente une conception de site à site où un connecteur transmet tout un sous-réseau, et Access Server la met en œuvre avec un rôle de passerelle et un routage explicite. Un autre produit vendu comme VPN SSL peut n’exposer que des fonctions d’utilisateur distant, sans moyen pris en charge d’annoncer un réseau derrière le client. La version compte aussi, car une fonction présente dans une édition n’est pas une promesse pour une autre. Lisez l’implémentation que vous exploitez réellement et traitez une recette écrite pour un autre produit comme un indice, non comme une conception.

La question à trancher d’abord est de savoir si le propriétaire du VPN prend en charge le rôle de transmission. Sinon, aucun routage côté client ne le rend pris en charge.

Le contrat a deux faces : le site distant et le siège

Côté site distant, un seul hôte assure la transmission, le filtrage et la reprise. Il lui faut un chemin réfléchi depuis chaque appareil du site, et la connexion VPN extérieure doit rester joignable via le réseau sous-jacent même lorsque le tunnel est arrêté. Côté siège, quelqu’un doit définir le sous-réseau du site, accepter l’identité de la passerelle et autoriser des ressources précises. Aucune moitié ne fonctionne seule.

Le chemin de retour est la partie que l’on oublie. Une adresse de tunnel pour le client n’annonce pas le sous-réseau qui le suit, aussi les routeurs du siège ont besoin d’une route pointant vers la passerelle VPN pour ce préfixe.

Dans une conception routée, le concentrateur transmet les paquets du préfixe du site et le routage du LAN amont sait renvoyer les réponses. Dans une conception traduite, la source que voit le siège est réécrite, ce qui peut supprimer le besoin d’une route de retour tout en masquant quelle machine du site a envoyé le trafic. Ce compromis appartient au document de conception, car les journaux applicatifs et les règles d’accès perdent l’identité par appareil dès que la traduction entre en jeu.

Routé ou traduit : choisissez le chemin de retour en connaissance de cause

Choisissez routé lorsque l’identité par appareil et la politique par hôte importent et que vous pouvez maintenir la route de retour sur chaque routeur concerné.

Choisissez traduit lorsque vous ne pouvez pas ajouter de routes mais acceptez que le siège voie une seule adresse source. Des conceptions mixtes existent et sont plus difficiles à raisonner, alors notez quels préfixes sont routés et lesquels sont traduits. Vérifiez ensuite le choix par une capture aux deux extrémités plutôt qu’en faisant confiance à l’état du tunnel.

Un contrôle utile est asymétrique : demandez une ressource depuis un appareil du site, puis confirmez que la réponse quitte le siège vers le préfixe du site. traceroute -n 10.60.4.20 depuis un hôte du siège montre si ce chemin passe par la passerelle VPN.

Exploitez-le comme une infrastructure, pas comme une connexion

Décidez comment la passerelle démarre, s’authentifie, se met à jour et reprend sans personne connecté. Le renouvellement des identifiants, les demandes multifactorielles, le comportement en veille et qui réagit lorsque le site perd l’accès deviennent tous des questions d’exploitation. Plusieurs personnes partageant un même chemin réseau ne doivent pas hériter des privilèges personnels de l’utilisateur de la passerelle, aussi l’autorisation des ressources, la portée de la journalisation et la politique de panne ont besoin d’un propriétaire nommé. Partager un compte pour éviter l’enrôlement de chaque appareil n’est pas une conception.

Comparez la solution à une passerelle de site prise en charge dans les mêmes exigences avant de vous engager. Réutiliser un vieux poste de bureau n’élimine ni la maintenance ni la reprise, et le prix d’occasion ne décrit pas le coût d’exploitation.

Validez les applications du site prévues, leur trafic de retour et une destination refusée dans le cadre d’un plan approuvé. Le succès ressemble à un service réseau maîtrisé avec une identité de site nommée et une politique explicite, non à une fenêtre de client affichant Connecté.