DHCP Server et Cluster HA pfSense : qui distribue les IP's ?
-
Contexte : milieu pro - pfSense 2.1 en configuration CARP et pfSync
Besoin : Compréhension plus fine de la réservation des baux DHCP
WAN : deux liens (un sDSL et un aDSL) eux mêmes en HSRP
LAN : deux routeurs
DMZ : pas de DMZWIFI : pas de Wifi
Autres interfaces : pfSync
Règles NAT : pas utile pour cette demande (à priori)
Règles Firewall : pas utile pour cette demande (à priori, pas de filtrage DHCP)Packages ajoutés : ntop
Autres fonctions assignées au pfSense : VPN IPsec et OpenVPN
Questions :
- Est il possible que le membre MASTER distribue les baux DHCP et que de temps en temps le membre BACKUP en attribue aussi ?
- Pourquoi un bail peut il avoir une date d'expiration dans le passé ? => Janvier 1970 (encadré de rouge) dans les copies écran en fin de sujet.
- Malgré des synchros forcées entre le deux membres, différences de bail entre les deux membres.
Pistes imaginées :
- Stop/Start du DHCP Server
- Reset des baux affectés
Recherches :
- Vérification du NTP sur chaque nœud,
- Vérification et constatation par l'utilisateur final que le bail DHCP est passé quelques fois sur le membre MASTER et une autre fois sur le BACKUP
- Le 2eme nœud est bien indiqué comme Failover Peer de réplication, advskew<20 sur le 1er nœud, et >20 sur le 2eme.
Le serveur DHCP est paramétré pour indiquer comme Default Gateway l'adresse IP CARP du LAN.
Avez vous aussi constaté que les adresses distribuées puissent basculer entre deux membres d'un même cluster ?
Merci pour vos avis sur ce sujet.
-
Je ne peux pas répondre pour la version 2.2. En version 2.1.5 j'ai eu récemment un problème sur un cluster chez un client. Le serveur DHCP ne semblait plus fonctionner. Les clients concernés utilisait l'adresse ip d'autoconfiguration (169. …) Après analyse il s'est avéré que pour d'obscures raisons (mauvaises) le client avait modifié la date système des machines concernées. Le retour à la bonne date système règlait immédiatement le problème.
- Est il possible que le membre MASTER distribue les baux DHCP et que de temps en temps le membre BACKUP en attribue aussi ?
En cas de bascule ou ou non ?
- Pourquoi un bail peut il avoir une date d'expiration dans le passé ? => Janvier 1970 (encadré de rouge) dans les copies écran en fin de sujet.
- Malgré des synchros forcées entre le deux membres, différences de bail entre les deux membres.
Les matériels qui font tourner Pfsense ont il connu des défaillances, des reboots que vous n'auriez pas détecté ? Des messages éventuellement dans Pfsync ?
La configuration du cluster semble être tout à fait correcte. Par contre l'architecture réseau avec les deux accès internet derrière Pfsense laisse septique. -
(Bon schéma ! bravo !)
Je ne suis pas sûr que la fonction de cluster soit très utile pour le service DHCP/DNS.
Pour être plus prévis, je pense que le clustering pfSense est vraiement destiné à basculer le filtrage (firewall).Je suis persuadé qu'une machine fiable qui fournit l'essentiel DHCP/DNS devrait être interne et non sur un firewall.
Par exemple, s'il y a un domaine Windows (avec un DC) la meilleure place pour le DHCP/DNS est justement le DC (qui a forcément déjà besoin d'un DNS).
(Cela dit, quand cette machine ne tourne pas, cela est ennuyeux.) -
Je ne peux pas répondre pour la version 2.2. En version 2.1.5 j'ai eu récemment un problème sur un cluster chez un client. Le serveur DHCP ne semblait plus fonctionner. Les clients concernés utilisait l'adresse ip d'autoconfiguration (169. …) Après analyse il s'est avéré que pour d'obscures raisons (mauvaises) le client avait modifié la date système des machines concernées. Le retour à la bonne date système règlait immédiatement le problème.
- Est il possible que le membre MASTER distribue les baux DHCP et que de temps en temps le membre BACKUP en attribue aussi ?
En cas de bascule ou ou non ?
- Pourquoi un bail peut il avoir une date d'expiration dans le passé ? => Janvier 1970 (encadré de rouge) dans les copies écran en fin de sujet.
- Malgré des synchros forcées entre le deux membres, différences de bail entre les deux membres.
Les matériels qui font tourner Pfsense ont il connu des défaillances, des reboots que vous n'auriez pas détecté ? Des messages éventuellement dans Pfsync ?
La configuration du cluster semble être tout à fait correcte. Par contre l'architecture réseau avec les deux accès internet derrière Pfsense laisse septique.- Pas de reboot intempestif,
- Nous n'avons pas eu de bascule,
- Je n'ai pas analysé les logs pfSync à ce jour de façon détaillé.
Sur le point de l'architecture des 2 routeurs derrière les deux accès Internet, en quoi votre avis est septique ? :-)
-
salut salut
a mon avis si vous monter une muraille de chine au nord mais qu'au sud vous ne faite pas la meme chose c'est un peu comme si vous aviez simplement mis un panneau passez par derrière tout es ouvert.
personnellement je en serais que trop de faire une muraille de chine a tout les niveaux d'accès avec de regle spécifique pour chaque trous
Cordialement.
-
Sur le point de l'architecture des 2 routeurs derrière les deux accès Internet, en quoi votre avis est septique ? :-)
En façade vous avez posé une porte blindée (Pfsense) et derrière vous fermez la porte du jardin avec un cadenas à 3 euros. C'est l'image qui décrit votre architecture actuelle.
Sur le plan méthodologique, aujourd'hui, l'état de l'art c'est un point de passage unique entre les différentes zones d'une architecture. Ici nous en avons 3, et tous connectés à Internet ! Comment avoir une chance de maitriser les flux réseau dans ces conditions ? Je ne sais pas ce que sont ces routeurs mais il devraient être de l'autre côté de Pfsense. Vous avez trois portes à surveiller ai lieu d'une. Sans parler des interactions possibles …
Il existe des configurations complexes avec de multiples firewall mais il n'y a qu'une seule politique de filtrage pour l'ensemble. Les outils d'administrations de ces produits permettent de le faire. Si la politique prévoit que le trafic ssh (par exemple) est interdit à l'entré d'une zone réseau alors les règles des différents firewalls feront en sorte d'interdire ce trafic partout où cela est nécessaire. Ce que l'on ne sait pas faire avec Pfsense. -
Sur le point de l'architecture des 2 routeurs derrière les deux accès Internet, en quoi votre avis est septique ? :-)
En façade vous avez posé une porte blindée (Pfsense) et derrière vous fermez la porte du jardin avec un cadenas à 3 euros. C'est l'image qui décrit votre architecture actuelle.
Sur le plan méthodologique, aujourd'hui, l'état de l'art c'est un point de passage unique entre les différentes zones d'une architecture. Ici nous en avons 3, et tous connectés à Internet ! Comment avoir une chance de maitriser les flux réseau dans ces conditions ? Je ne sais pas ce que sont ces routeurs mais il devraient être de l'autre côté de Pfsense. Vous avez trois portes à surveiller ai lieu d'une. Sans parler des interactions possibles …
Il existe des configurations complexes avec de multiples firewall mais il n'y a qu'une seule politique de filtrage pour l'ensemble. Les outils d'administrations de ces produits permettent de le faire. Si la politique prévoit que le trafic ssh (par exemple) est interdit à l'entré d'une zone réseau alors les règles des différents firewalls feront en sorte d'interdire ce trafic partout où cela est nécessaire. Ce que l'on ne sait pas faire avec Pfsense.Merci pour vos réponses et vos avis :-)
Je vous précise donc la configuration des modems/routeurs sDLS et aDSL.
Ces deux équipements sont montés en HSRP (Offre Orange Business Services). Seul un équipement est actif à la fois : par défaut le sDSL, en cas de rupture le lien aDSL prend le relais. Ces deux modems ne sont vus que comme une seule et unique Gateway : X.Y.Z.214. Nous avons procédé lors de l'installation à des essais de coupure de liens sDSL : la bascule se fait bien en aDSL, les deux routeurs pfSense ne bronchent pas.
Nous sommes donc sur une infrastructure de bascule redondante sur les équipements opérateurs.
Sur ces réponses, croyez vous donc que la sécurité soit comprise (hormis une boulette de config pfSense).
Dans l'attente de vos réponses,
A+
-
Je pense que nous nous sommes mal compris. Mon avis concerne les routeurs 192.168.10.254 et 192.168.3.254 qui se trouvent dans le lan et qui sont, sur le schéma montrés comme connectés à Internet.
-
Je pense que nous nous sommes mal compris. Mon avis concerne les routeurs 192.168.10.254 et 192.168.3.254 qui se trouvent dans le lan et qui sont, sur le schéma montrés comme connectés à Internet.
Les deux autres routeurs 192.168.10.250 et 192.168.3.250 sont chargés de créer un VPN entre les deux sites. Je n'ai pas la main sur ces équipements, malheureusement :-( Donc je rejoins votre avis sur la sécurité : je ne sais pas si le routeur 192.168.10.250 est bien (ou mal) configuré !
Votre avis me permettra peut être de faire prendre conscience au Client qu'il va falloir s’intéresser à ce routeur ;-)
-
C'est très différent mais pas plus sûr pour autant. Les connexions vpn devraient être réalisées sur pfsense soit sur les équipements actuellement présents connectés à une interface spécifique ou bien directement gérées par Pfsense. On accorde souvent une confiance excessive aux liens vpn. Le problème reste que l'on ne sait pas qui est à l'autre bout réellement et comment il travaille. Idéalement un lien vpn dpit être filtré et ne déboucher que dans une dmz prévue pour cela. Le reste du réseau doit resté isolé et protégé.
En espérant que cela apporte de l'eau à votre moulin. -
C'est très différent mais pas plus sûr pour autant. Les connexions vpn devraient être réalisées sur pfsense soit sur les équipements actuellement présents connectés à une interface spécifique ou bien directement gérées par Pfsense. On accorde souvent une confiance excessive aux liens vpn. Le problème reste que l'on ne sait pas qui est à l'autre bout réellement et comment il travaille. Idéalement un lien vpn dpit être filtré et ne déboucher que dans une dmz prévue pour cela. Le reste du réseau doit resté isolé et protégé.
En espérant que cela apporte de l'eau à votre moulin.J'espère pouvoir supprimer ces routeurs un de ces jours et assurer des VPN Network2Network uniquement avec le cluster pfSense :-)
