Les utilisateurs du VLAN de données de notre siège et de nos futurs bureaux distants devront accéder à des fichiers, à des licences réseau flottantes, etc. à partir de serveurs distants. Nous aurons donc besoin d'un VPN site à site pour le(s) réseau(x) de données. Lors de la mise en place de notre siège, j'ai pensé être intelligent en utilisant un grand sous-réseau (classe B aka 255.255.0.0) pour le VLAN de données et qu'un VPN site à site nous permettrait simplement d'étendre le même sous-réseau à tous les futurs bureaux et que les utilisateurs, où qu'ils soient, puissent se connecter de manière transparente à n'importe quel serveur dans n'importe quel endroit. Cependant, maintenant que je viens de configurer le VPN, j'ai lu que c'était une mauvaise pratique en raison de la latence impliquée par la diffusion du trafic sur Internet.
J'ai deux boîtiers en rack qui exécutent chacun pfSense dans une VM Hyper-V. Ces boîtiers deviendront des pare-feu pour chaque site. Ils deviendront les pare-feu de chaque site avec un VPN site à site entre eux. Les options de configuration de pfSense pour un VPN site à site (je suppose que OpenVPN en mode SSL/TLS est l'option la plus sûre) demandent trois réseaux, le réseau tunnel, le réseau distant et le réseau local. Ma question est la suivante : quelle doit être la taille du réseau de tunnels ? Peut-il s'agir d'un réseau de classe C (255.255.255.0) avec une IP pour chaque bureau ou doit-il être suffisamment grand pour fournir une adresse à chaque appareil dans tous les bureaux ? Dans ce dernier cas, il est clair que je ne pourrais pas donner à chaque bureau un sous-réseau 255.255.0.0 (même si je ne pense pas que cela soit nécessaire), mais devrais-je réduire la taille du sous-réseau du siège social (il compte probablement moins de 500 hôtes actuellement, bien qu'il dispose de dizaines de milliers d'adresses IP) qui était initialement destiné à être notre réseau mondial ?
