Clients VPN et réseau local : quand utiliser une zone séparée

Placer l’interface du tunnel dans la zone du réseau local est le chemin le plus court vers un VPN qui fonctionne, et c’est généralement le mauvais réglage par défaut. Cela accorde au client distant la même confiance que le réseau local filaire, ce que la tâche exige rarement. Une zone séparée coûte quelques règles et rend la frontière visible. La décision n’est pas de savoir si les zones sont meilleures ; elle est de savoir quelles trois conditions s’appliquent à votre réseau.

Le nom de la zone ne chiffre rien et n’authentifie aucun utilisateur. Il ne fait que regrouper des interfaces pour le modèle de politique du pare-feu.

Ce que l’appartenance à une zone contrôle réellement

Une zone regroupe des interfaces ou du trafic dans le modèle du pare-feu. Ses réglages d’entrée, de sortie et de transfert régissent ensuite des rôles différents. L’entrée est le trafic vers le routeur lui-même ; le transfert est le trafic qui le traverse vers un autre hôte. La documentation d’OpenWrt sur les zones traite entrée, sortie et transfert comme des réglages distincts précisément pour cette raison.

Une autorisation de la zone VPN vers la zone du réseau local n’est pas automatiquement une autorisation inverse. Les règles de transfert sont directionnelles, et une règle qui autorise le trafic du client vers le serveur n’autorise pas les sessions du serveur vers le client. Un client qui peut ouvrir une connexion vers un serveur n’est pas un client vers lequel le serveur peut ouvrir une connexion en retour.

Cette distinction est la raison pour laquelle une zone séparée est utile : vous pouvez énoncer explicitement chaque direction et chaque rôle. Écrivez la direction à côté de chaque règle.

Décision un : entrée, transfert ou les deux

Si les clients distants ont besoin du DNS du routeur, autorisez l’entrée pour ce seul service. S’ils doivent atteindre un serveur de fichiers, autorisez le transfert vers cette destination. La plupart des conceptions VPN ont besoin des deux, mais pour des services différents.

Un accès d’entrée étendu à tous les services locaux n’est presque jamais nécessaire. Traitez l’administration du routeur comme une décision distincte de l’accès aux applications. Si le routeur n’a besoin que de répondre au DNS, écrivez cette unique autorisation et laissez le reste fermé.

Décision deux : quelles ressources les clients distants nécessitent

Listez les plages de clients, les destinations et les services que le VPN doit fournir avant d’écrire des règles. Une liste de destinations est plus utile qu’une étiquette de confiance, car elle survit à une migration du pare-feu.

Gardez les interfaces d’administration séparées de l’accès ordinaire aux applications. Un client distant qui atteint un wiki n’a pas pour autant besoin de la page d’administration du routeur ni de la console de l’hyperviseur.

Si une destination autorisée peut relayer plus loin, la frontière de la zone s’arrête au pare-feu, pas à ce que la destination fait ensuite.

Décision trois : comment vous prouverez la frontière

Testez un flux autorisé et un flux délibérément refusé après chaque changement. Prouver qu’un site se charge ne révèle pas une autorisation large involontaire. Testez depuis la plage d’adresses du client VPN, pas depuis le réseau local, et incluez la direction que vous attendez voir échouer. Notez les deux résultats à côté de la règle.

Préservez l’accès de récupération de la passerelle avant de modifier la politique de la zone distante. Utilisez la configuration gérée persistante plutôt que des modifications à chaud, sinon le prochain redémarrage restaurera l’ancienne confiance. Une copie de la configuration précédente, conservée hors de l’appareil, est le retour arrière le moins cher que vous aurez jamais.

Quand le réseau grandit, documentez l’appartenance et l’objet des règles. Une interface nouvellement connectée ne devrait pas hériter de privilèges simplement parce que quelqu’un lui a donné un nom de zone commode.