Équivalent de DMVPN + NHRP avec PFSense/OpenVPN
-
Bonjour à tous,
Je souhaite mettre en place une connexion directe entre mes 8 sites distants (qu'ils puissent communiquer sans passer par un site maître, full mesh donc, ils disposent bien évidemment tous d'une (plusieurs) IP publique dédiée).
Pour répondre à ce besoin utiliser DMVPN + NHRP sont à mon sens les solutions les plus adaptées mais je n'ai pas ici accès aux produits Cisco.
Je me tourne donc vers PFSense : existe-t'il un moyen de mettre en place une topologie full mesh à travers PFSense ? (je me doute qu'il est possible de configurer un serveur OpenVPN sur chaque site (et son réseau virtuel associé) et d'y associer N-1 clients OpenVPN (par site) connectés aux réseaux virtuels des autres sites mais cette approche ne m'emballe pas plus que ça. En effet, disposant de déjà 8 sites et ce nombre étant amené à évoluer je souhaite éviter la multitude de configurations (nombre-de-sites^2) à effectuer et les erreurs humaines qui en découleront. NHRP étant ici plus adapté puisqu'il implique seulement (nombre-de-sites*2) configurations, les sites distants récupérant la liste des autres sites sur un serveur central).
Merci d'avance pour vos propositions.
-
Bien sur que pfSense peut être utilisé pour un réseau 'full mesh' ou 'hub and spoke'.
NB : full mesh de N points = N*(N-1)/2 liens et N config vers N-1 sitesMais est ce bien le job d'un firewall ?
Ou, à partir de combien de sites, on confie le RPV (Réseau Privé Virtuel) à un opérateur ?MPLS existe depuis des années et fait le job, après en effet la sécurisation est une question …
Enfin voulez-vous être tech chez l'opérateur ou chez une entreprise finale ? -
Bonjour @jdh,
Je n'ai pas la possibilité d'utiliser MPLS ici.
NB : full mesh de N points = N*(N-1)/2 liens et N config vers N-1 sites
Histoire d'être sur de ne pas être passé à côté de quelque chose concernant pfSense :
Pour un exemple avec 3 sites, la seule implémentation full mesh possible est la suivante ? ->
Site 1:
- Conf serveur OpenVPN (réseau virtuel en 10.250.1.0/24 par ex.)
- Conf client OpenVPN vers serveur OpenVPN site 2.
- Conf client OpenVPN vers serveur OpenVPN site 3.
Site 2:
- Conf serveur OpenVPN (réseau virtuel en 10.250.2.0/24 par ex.)
- Conf client OpenVPN vers serveur OpenVPN site 1.
- Conf client OpenVPN vers serveur OpenVPN site 3.
Site 3:
- Conf serveur OpenVPN (réseau virtuel en 10.250.3.0/24 par ex.)
- Conf client OpenVPN vers serveur OpenVPN site 1.
- Conf client OpenVPN vers serveur OpenVPN site 2
Merci d'avance,
-
je n'ai pas ici accès aux produits Cisco.
Je n'ai pas la possibilité d'utiliser MPLS ici.En effet, cela est plutôt du ressort d'un opérateur …
Soit vous considérez que votre besoin a pour solution une offre opérateur,
soit vous essayez de créer vous même votre propre vpn, et plus il y aura de sites plus ce sera difficile ...Usuellement on réalise plutôt un RPV avec Ipsec plutôt qu'OpenVpn car on considère qu'Ipsec est meilleur pour le site à site.
Mais à partir d'un certain nombre de sites, la solution opérateur s'impose ...Quelqu'un avec un peu d'habileté pourrait générer la partie de conf et l'insérer dans chaque fichier de conf des firewall.
Mais faut-il le faire ? -
Bonjour,
Avez-vous regardé à l'utilisation de openbgpd ou quagga_ospf ? (package dans pfsense)
Je n'ai peut pas pas compris votre demande car je connais peu cisco.
Cordialement,
Mathieu
-
première réflexion:
- les sites ont-il réellement besoin de tous discuter les uns avec les autres ? C'est assez peu courant. Mais cela peut être un cas d'usage justifié.
deuxième réflexion:
- l'ajout de site suit quelle cadence ? si c'est deux ou trois sites par an, le temps (et donc coût)de mise en place de la configuration manuelle (conditionnée à la réponse à la première réflexion) sera certainement moindre que le temps passé à configurer ces nouveaux sites.
Perso j'ai déployé et j'exploite encore à l'heure actuelle ce genre de configuration.
J'utilise pfSense en physique (plateforme Proliant) et en virtuel VMWare.
Même en virtuel, correctement configuré et tuné avec utilisation du crypto engine AES NI on obtient de bonnes perf (~650mbit/s par tunnel openVPN sur Xeon à 2,4Ghz, MTU à 1500).J'ai toujours configuré manuellement le routage car le temps passé est négligeable (merci la config XML et un bon éditeur). Et aussi parce que je fais grand usage du policy based routing ou des gateway group pour gérer la redondance et l'équilibrage de charge. Il faut toujours évaluer le risques et l'impact d'erreurs humaines dans une configuration pseudo manuelle versus un systèmes automatiques. Par expérience, l'erreur humaine dans un système automatique distribué produit généralement un joli chaos.
Petite note concernant le MPLS, il ne garantit en rien la confidentialité des échanges vis à vis de l'opérateur qui peut "TAPer" le trafic chez lui comme bon lui semble. Il s'agit juste de créer des canaux privatifs dans une infrastructure mutualisée entre plusieurs clients. Sans IPSEC c'est proche de 0 en terme de confidentialité des échanges. Je loue et j'exploite plusieurs longueurs d'ondes 10G chez un opérateur de transport, même si je maîtrise le niveau 2 j'utilise systématique une solution de cryptage (openVPN, ipsec) sur ces liens, et d'autant plus sur mes liens diversifiés qui passent par l'étranger.
Pour ceux qui pourraient encore douter de la capacité de pfSense à répondre aux besoins d'une configuration entreprise, tout cela est fait dans le domaine de la finance et dans le respect des règles de conformité les plus strictes s'appliquant à ce domaine.
Bien entendu, chaque contexte impose ses contraintes.
-
Merci de ton retour Juve.
Mon job : m'occuper de l'infra générale et des infras d'un groupe d'entreprises familliales en cours de construction.
L'étape n°1 est de définir un découpage 'générique' en vlan des sites (avec l'adressage ip v4 correspondant). Fait.
L'étape 2 sera de relier en mpls les différents sites et de contrôler finement les vlan communiquant entre eux (site à site)
Ultimement le patron serait tenté de réduire le nombre de firewall à 1 central.De ton expérience, je tire l'idée que mpls ou pas, un firewal (bien configuré) par site assurant le routage inter vlan via des tunnels OpenVpn contruits sur mpls, serait finalement une bonne couche sécuritaire protectrice face à l'inhérente faiblesse sécuritaire du mpls opérateur.
Exemple :
tous les sites : 1 fw (le même) avec 2 WAN (Internet + MPLS).
sur chaque site, l'ip wan mpls est fixé à 172.16.X.10 et le routeur mpls fourni 172.16.X.1.
sur chaque fw, on défini un tunnel OpenVPN vers tous les autres fw (172.16.Y.10 sauf X lui-même), soit N-1 liens depuis chacun des N firewalls.- sur chaque tunnel, on définit quels ip range = quel vlan ont le droit d'échanger avec les vlan en face.
Chaque firewall sera construit sur base hardware solide type HP Proliant ou Dell R20x suffisamment burné (mémoire, proc Xeon supportant AES-NI, voire carte dédiée cryptage, et cartes réseaux type Broadcom ou Intel Pro).
Le tout relié à un chassis (switch) local gérant le L3 inter vlan du site.
C'est l'idée ou je me vautre de tout mon long ?
(NB : je comprends aussi qu'il faudra choisir un cryptage qui perd le moins de bande passante, par exemple blow-fish)
- sur chaque tunnel, on définit quels ip range = quel vlan ont le droit d'échanger avec les vlan en face.
-
Je vais donner la recette que j'applique depuis 2008, et qui fonctionne de mieux en mieux du fait de l'amélioration globale des télécommunication et des technologies.
Je la fais en résumé ultra concisC'est éprouvé, sur des structures dépassant les 200 sites distants, avec un taux de disponibilité excellent dans chacun des cas.
L'objectif initial de ce design, à l'époque réalisé pour une grande industrie présente à l'international, était de réduire les coût de communication (MPLS=$$) tout en augmentant la flexibilité et accélérant le temps de déploiement (industrialisation).J'annonce tout de suite que cela nécessite du personnel compétent.
Le design du SI- Un ou plusieurs Datacenter centraux hébergeant le SI
- Des sites distants accueillant le personnel et des systèmes locaux (filer, rodc, TOIP, sécurité d'accès etc.)
Les principe de base:
- Le MPLS coûte cher, est engageant dans le temps, se déploie pas vite, est compliqué à l'international, n'est pas flexible, une offre de débit catastrophique, nécessite du hardware, n'est pas top secure
- La virtualisation ca marche bien quand c'est bien utilisé
- Les offres d'interconnexion à Internet sont de plus en plus fiable et capacitives avec des coûts faibles
- Les flux applicatifs sont principalement (en terme de volumétrie) du Datacenter en direction du poste client.
- Un plan d'adressage IP bien pensé (RFC1918 et RFC6598)
Au niveau technique:
Au Datacenter:
- Cluster de firewall physique pfSense sur plateforme serveur Intel (CPU, RAM, carte Intel Pro 10g, LACP, commutation redondée etc.)
- Connectivité Internet par opérateur de transport, 1gbit/s ou plus
- Tous les serveurs qui font pleins de choses intéressante pour le business de l'entreprise
- Aucun routage L3 dans la commutation Datacenter, le cluster de firewall étant le routeur central (dans certains cas, plusieurs cluster de firewall physiques)
- Des dizaines de vlan pour segmenter chaque zone de confiance, chaque vlan étant une interface logique pfSense
- Matrice de flux intégrale, aucune règle laxiste
Dans les sites distants:
- Une ou deux (ou plus) connexions Internet de type grand publique ou semi Pro (Exemple Livebox Pro). Fibre optique si possible, VDSL, ADSL2
- un cluster de serveurs physique 2 ou 3 noeuds sous licence VMWare (ROBO) (les petits DL20 pour les petits sites)
- du stockage local et du stockage locale repliqué synchrone entre ces 3 noeuds (Storevirtual VSA).
- Une commutation de site généralement redondante (cluster de switch ou de châssis, dépend si le site à 30 personnels ou 2000)
- le cluster VMware supporte tous les services locaux et nécessaire au fonctionnement du site
-> RODC, serveur d'impression, Filer M$, relais TOIP, gestion des accès physiques etc., pfSense portail captif, serveur de backup
-> un cluster de pfSense, configurés en boot automatique (si arrêt électrique), gérant le filtrage inter vlan local et surtout la mise en oeuvre de tunnels (openVP N ou IPSEC) vers le ou les sites centraux, via la ou les lignes Internet locales - principe de filtrage local:
-> filtrage inter vlan géré sur firewall local
-> aucun filtre vers site central pour faciliter la charge d'exploitation, le filtrage étant réalisé à l'entrée du Datacenter.
Ces "bundles" étant entièrement automatisés au déploiement, pré configurés et envoyés aux quatre coins du monde.
Ca marche, ca coûte un prix raisonnable et c'est 100% customisable pour accueillir de nouveaux services. -
Merci de ce retour précieux.
(Evidemment du personnel compétent mais j'espère être celui là).
On doit écrire aussi MPLS=$$ et Ligne Internet = plus facile/rapide à disposer.
J'ajouterai : attention à bien gérer les fw pour limiter les entrées (NAT forward) sur tous les sites : que du strict nécessaire !