Avant de configurer un FireCluster Géré sur le Cloud dans WatchGuard Cloud

S'applique à : Fireboxes Gérés sur le Cloud

Avant de configurer un FireCluster géré sur le cloud dans WatchGuard Cloud, confirmez les points suivants :

Pour consulter les exigences s'appliquant aux FireClusters gérés localement dans WatchGuard Cloud, consultez les sections Ajouter un Firebox Géré Localement à WatchGuard Cloud et Avant de Configurer un FireCluster.

En Savoir Plus sur la Prise en Charge des Fonctionnalités

Le FireCluster ne prend pas en charge toutes les fonctionnalités Firebox. Pour plus d'informations, consultez Fonctionnalités Non Prises en Charge par un FireCluster Géré sur le Cloud.

Vérifier les Exigences

Pour ajouter un FireCluster géré sur le cloud dans WatchGuard Cloud, vous devez utiliser l'une des options suivantes :

  • Méthode 1 — Ajoutez deux Fireboxes avec les paramètres usine par défaut en tant que FireCluster géré sur le cloud.
  • Méthode 2 — Modifiez un FireCluster actif/passif géré localement en activant la gestion sur le cloud.

Les FireClusters gérés sur le cloud fonctionnent en mode actif/passif. Vous ne pouvez pas ajouter un FireCluster actif/actif géré sur le cloud.

Pour plus d'informations sur ces options, consultez Ajouter un FireCluster Géré sur le Cloud.

Exigences des Comptes Watchguard Cloud

Procédez comme suit :

  • Activez les deux Fireboxes sur votre WatchGuard Portal Account.
  • Allouez l'un des Fireboxes à un compte Subscriber (Service Providers uniquement). Pour ajouter le deuxième Firebox, vous pouvez spécifier son numéro de série. Pour plus d'informations, consultez Allouer les Fireboxes.

Exigences Relatives au Microprogramme

Les FireClusters gérés sur le cloud présentent les exigences suivantes en matière de microprogramme :

  • Les deux Fireboxes du FireCluster doivent posséder la même version de microprogramme Fireware. Pour de plus amples informations concernant la version du microprogramme, consultez la section À Propos de la Page Paramètres du Périphérique.
  • Les deux Fireboxes doivent utiliser Fireware v12.8.2 ou une version ultérieure (ou v12.5.11 ou une version ultérieure pour les Fireboxes T30, T35, T50, M200, et M300).

Exigences des Licences et des Abonnements

Les FireClusters gérés sur le cloud présentent les exigences suivantes en matière de licence :

  • Activez les services d'abonnement sur la clé de fonctionnalité pour un seul membre du cluster. Le membre du cluster actif utilise les services d'abonnement actifs sur la clé de fonctionnalité de l'un des deux membres du cluster.
  • Seul un membre du cluster doit posséder une licence Total Security Suite, Basic Security Suite ou Standard Support.

Les FireClusters gérés sur le cloud présentent les exigences suivantes en matière d'abonnements à l'Assistance :

  • Un abonnement au support technique s'applique à un périphérique individuel, même si celui-ci est configuré en tant que membre d'un cluster. Vous devez disposer d'un abonnement valide à l'assistance pour chaque périphérique du cluster avec le même niveau d'assistance. Si l'abonnement au support technique expire pour un membre du cluster, vous ne pouvez pas mettre à niveau le microprogramme sur ce périphérique. Dans la clé de fonctionnalité, l'abonnement est identifié par l'ancien nom de l'assistance WatchGuard, LiveSecurity Service. Dans les Détails de la Clé de Fonctionnalité, l'entrée de l'abonnement à l'assistance s'affiche sous le format suivant : Fonctionnalité : LIVESECURITY@MMM-JJ-AAAA.

  • Le niveau d'assistance de chaque Firebox du cluster n'est pas visible dans la clé de fonctionnalité. Pour vérifier le niveau d'assistance et les dates d'expiration d'abonnement de chaque membre, rendez-vous sur la page Gérer les Produits de votre compte sur le site Web de WatchGuard. Chaque membre de FireCluster bénéficie du niveau d'assistance acheté pour ce Firebox. Par exemple, si un seul membre d'un FireCluster possède une mise à niveau Assistance Gold, l'autre membre du cluster reçoit le niveau d'assistance correspondant à son propre abonnement d'assistance. Pour de plus amples informations concernant les niveaux d'assistance, consultez la section Comparer les Niveaux d'Assistance.

Les FireClusters gérés sur le cloud présentent les exigences suivantes en matière d'abonnements RMA :

  • Pour mettre à niveau les deux membres du FireCluster vers un abonnement Premium 4-Hour RMA, vous devez acheter cet abonnement pour chaque membre du cluster. Pour de plus amples informations concernant les abonnements Premium 4-Hour RMA, consultez les FAQ du Service RMA sur le site Web de WatchGuard.

Pour de plus amples informations concernant l'activation, le renouvellement et l'expiration des licences, consultez la section À propos des Licences WatchGuard Cloud du Firebox.

Exigences relatives au Matériel et aux Câbles

Assurez-vous que vous avez :

  • Deux Fireboxes activés avec le même numéro de modèle.
  • Le même nombre et le même type de modules d'interface installés aux mêmes emplacements sur chaque Firebox.
  • Au moins une interface Firebox inutilisée à utiliser comme interface cluster dédiée. Pour configurer une interface cluster de secours, vous devez disposer d'une interface Firebox supplémentaire inutilisée.
  • Un câble Ethernet pour chaque interface cluster. Vous pouvez utiliser un câble droit ou croisé pour connecter l'interface cluster d'un membre du cluster à l'interface cluster de l'autre membre du cluster.
  • Un commutateur réseau pour chaque interface interne, invité ou externe activée.
  • Des câbles Ethernet pour connecter les interfaces des deux périphériques aux commutateurs réseau.

Le FireCluster est entièrement pris en charge par tous les périphériques Firebox et XTM, avec les exceptions suivantes :

  • Les périphériques Firebox T10,T15 et NV5 ne prennent pas en charge FireCluster.
  • Les périphériques FireboxV et XTMv ne prennent seulement en charge qu'un FireCluster actif/passif dans un environnement VMware ESXi.
  • Firebox Cloud ne prend pas en charge FireCluster.
  • FireCluster n'est pas supporté du tout pour Hyper-V.

Lorsque vous configurez deux périphériques Firebox sans fil en FireCluster, la configuration doit répondre à ces exigences :

  • Les Fireboxes T10-W et T15-W ne prennent pas en charge FireCluster.
  • Vous ne pouvez pas utiliser d'interfaces sans fil comme interface cluster principale ou de secours.
  • Si l'adresse IP de l'interface cluster est sur une interface qui est pontée à un réseau sans fil, vous ne pouvez pas utiliser une connexion sans fil pour gérer le périphérique.

Certains modèles de Firebox prennent en charge les modules d'interface installables par l'utilisateur. Le nombre de modules d'interface installés sur ces modèles pouvant varier, ces modèles présentent des exigences supplémentaires quant à la configuration d'un FireCluster :

  • Les deux périphériques membres d'un FireCluster doivent être le même modèle de Firebox et posséder le même nombre et le même type de modules d'interface installés dans les mêmes emplacements. Le cluster ne peut pas se former si les configurations matérielles des deux Fireboxes ne sont pas identiques.
  • Vous devez choisir une interface intégrée comme interface cluster principale. Cette configuration vous permet de connecter directement les interfaces intégrées des deux membres. La découverte des membres s'effectue via cette interface lors de la formation initiale du cluster.

Exigences Administratives

Assurez-vous de disposer d'un accès administratif local au FireCluster.

Exigences de Réseau

Les deux Fireboxes doivent être connectés au réseau et disposer d'un accès à Internet fiable.

La latence du réseau entre les membres du cluster doit être inférieure à 100 ms.

Le FireCluster ne prend pas en charge les réseaux pontés.

Exigences Sans Fil

FireCluster n'est pas pris en charge par les modèles sans fil Firebox T10-W ou T15-W.

Exigences relatives aux Machines Virtuelles (MV)

Dans un environnement VMware, un FireCluster fonctionne comme escompté uniquement si toutes les conditions sont satisfaites. Pour plus d'informations, consultez Configurer un FireCluster sur VMware ESXi.

FireCluster n'est pas supporté pour Hyper-V.

Tous les clients protégés par le cluster doivent pouvoir communiquer avec les deux membres du cluster. VMware ne transmet pas le trafic des clients du même hôte ESXi qu'un membre du cluster vers l'autre membre du cluster d'un autre hôte ESXi. Pour plus d'informations, consultez Configurer un FireCluster sur VMware ESXi.

Vérifier la Configuration de l'Interface Externe

Chaque interface externe doit avoir une adresse IP statique, ou être configurée pour le protocole PPPoE ou DHCP.

Pour plus d'informations sur la manière de configurer l'interface externe, consultez Configurer un Réseau Externe d'un Firebox.

Vérifier la Configuration des Routeurs et des Commutateurs du Réseau

Vous devez posséder un commutateur réseau ou un réseau local virtuel (VLAN) pour chaque interface active du trafic.

Les interfaces cluster principal et de secours doivent appartenir à des sous-réseaux distincts et inutilisés. Veillez à utiliser des sous-réseaux ne chevauchant pas sur les sous-réseaux locaux ou VPN. Afin d'éviter les conflits d'adresses IP avec les adresses IP routables, nous vous recommandons d'utiliser des sous-réseaux APIA (Automatic Private IP Addressing), également connus sous le nom d'adresses de liaison locale (169.254.0.1–169.254.255.254 avec le masque de sous-réseau 255.255.0.0).

Nous vous recommandons de ne pas utiliser de commutateur entre chaque membre pour les interfaces cluster. Si vous utilisez un commutateur entre chaque membre pour les interfaces de cluster, ces dernières doivent être séparées logiquement entre elles sur des VLAN différents.

Planifier la Configuration d'une Interface Cluster

Nous vous recommandons de planifier les adresses IP et les interfaces Firebox que le FireCluster utilisera avant de le configurer. Dans la configuration de FireCluster, vous devez spécifier les adresses IP et les numéros d'interface des interfaces FireCluster suivantes :

Interface cluster

Une interface dédiée à la communication entre les membres du cluster. Les membres du cluster utilisent cette interface afin d'échanger les paquets de pulsation et synchroniser les informations de connexion et de session. Cette interface n'est pas utilisée pour le trafic réseau régulier. Lorsque vous configurez le matériel du cluster, nous vous recommandons de connecter les interfaces cluster de chaque Firebox les unes aux autres. Nous vous recommandons de ne pas user de commutateur entre les interfaces cluster.

Interface cluster de secours (facultatif)

Une interface redondante dédiée à la communication entre les membres du cluster. Nous recommandons une interface cluster de secours uniquement si vous utilisez un commutateur entre les interfaces cluster.

Interface de communication

Une interface utilisée pour envoyer des messages de journal des deux membres du cluster à votre serveur Dimension ou syslog, et pour gérer le maître du cluster de secours. Astuce !

Cette liste présente des exemples d'adresses IP d'un FireCluster géré sur le cloud.

Adresses IP d'un FireCluster Géré sur le Cloud
  Interface Firebox Adresse IP du membre1 Adresse IP du membre2
Interface cluster 0 169.254.0.1/30 169.254.0.2/30
Interface cluster de secours 1 169.254.1.1/30 169.254.1.2/30
Interface de communication 2 10.10.2.3/24 10.10.2.4/24

Meilleures Pratiques Relatives aux Interfaces Cluster

Observez les meilleures pratiques suivantes relatives aux adresses IP des interfaces cluster :

  • Utilisez une adresse IP inutilisée sur votre réseau. Afin d'éviter les conflits avec les adresses IP routables, nous vous recommandons les adresses APIPA ou les adresses IP d'un sous-réseau privé dédié.
  • Les adresses IP de l'interface doivent être sur le même sous-réseau pour les deux membres du cluster.
  • Si vous disposez d'une interface configurée en tant qu'interface VLAN dédiée, vous ne pouvez pas la choisir comme interface cluster dédiée.
  • Ne configurez pas l'IP du cluster en tant qu'adresse IP par défaut d'une interface Firebox. Par défaut, le Firebox utilise les sous-réseaux 10.0.x.0/24 pour les adresses IP des interfaces. C'est pourquoi nous vous déconseillons d'utiliser les adresses 10.0.x.0/24 pour les adresses IP des clusters. Si vous configurez l'interface cluster de manière à utiliser l'une des adresses IP d'interface d'usine par défaut, un conflit risque de se produire lors du basculement et entraîner son échec.
  • N'utilisez pas les adresses IP du cluster à une quelconque autre fin sur votre réseau, y compris pour les VPN.

Observez les meilleures pratiques suivantes relatives aux interfaces cluster :

  • Afin d'améliorer la tolérance aux dysfonctionnements des cartes d'interface réseau (NIC) du Firebox, nous vous recommandons d'utiliser eth0 en tant qu'interface cluster principale. Si un NIC du Firebox dysfonctionne, le Firebox réattribue automatiquement les numéros d'interface logique. Le Firebox attribue les étiquettes eth dans l'ordre selon lequel les interfaces ont été détectées. Par conséquent, les numéros d'interface logique semblent se décaler vers la gauche. La réattribution des étiquettes peut influer sur le fonctionnement du FireCluster et sur les configurations de l'interface cluster de secours.

    Par exemple, si vous utilisez eth0 en tant qu'interface cluster principale et qu'un NIC distinct eth0 dysfonctionne, le FireCluster continue de fonctionner comme escompté, car l'étiquette d'interface demeure eth0. Le Firebox ne réattribue pas l'étiquette d'interface logique d'eth0, car il n'existe pas d'interface physique à droite d'eth0. Cette configuration protège le FireCluster contre les dysfonctionnements du NIC des interfaces distinctes d'eth0. Seul un dysfonctionnement d'eth0 nuirait au fonctionnement du FireCluster.

    Si vous utilisez eth4 en tant qu'interface cluster principale et que eth3 dysfonctionne, le Firebox réattribue l'étiquette logique eth3. L'interface eth4 devient eth3. Cette situation perturbe le fonctionnement du FireCluster, car les paramètres de configuration de FireCluster du Firebox spécifient eth4 en tant qu'interface cluster principale.

  • Nous vous recommandons de ne pas utiliser de commutateur entre chaque membre pour les interfaces cluster. Si vous utilisez un commutateur entre chaque membre pour les interfaces de cluster, ces dernières doivent être séparées logiquement entre elles sur des VLAN différents.
  • Pour un FireCluster Firebox M5600, nous vous recommandons de choisir l'interface 32 comme interface cluster principale. Pour plus d'informations, consultez À propos de FireCluster avec Interfaces Modulaires.

Meilleures Pratiques Relatives aux Interfaces Cluster de Secours

Le type de connexion entre les interfaces cluster détermine si nous vous recommandons ou déconseillons d'employer une interface cluster de secours.

FireCluster possédant une connexion câblée directe entre les membres du cluster

Nous ne vous recommandons pas d'utiliser une interface cluster de secours pour ce type de configuration, car elle n'offre qu'une redondance limitée.

Le FireCluster utilise l'interface cluster de secours uniquement en cas de dysfonctionnement du câble entre les interfaces cluster principales. Si l'un des NIC du Firebox dysfonctionne, l'interface cluster de secours n'assure pas de redondance, car le Firebox réattribue automatiquement les étiquettes d'interface logique comme indiqué dans la section précédente de cette page.

FireCluster avec un commutateur entre les membres du cluster

Dans cette configuration, les membres du FireCluster sont physiquement séparés par un commutateur, ce qui est déconseillé. Si vous placez un commutateur entre les interfaces cluster, nous vous recommandons de configurer une interface cluster de secours. Le FireCluster utilise l'interface cluster de secours dans les cas suivants :

  • Le câble entre le commutateur et l'interface cluster est défectueux.
  • L'interface du commutateur est défectueuse.
  • Un problème réseau entraîne l'indisponibilité du commutateur.

Si l'un des NIC du Firebox dysfonctionne, l'interface cluster de secours n'assure pas de redondance, car le Firebox réattribue automatiquement les étiquettes d'interface logique. Par exemple, vous spécifiez eth3 en tant qu'interface cluster principale et eth4 en tant qu'interface cluster de secours. Si eth3 dysfonctionne, le Firebox réattribue l'étiquette logique eth3. L'interface désignée jusqu'ici par l'étiquette eth4 se nomme désormais eth3. La réattribution des étiquettes d'interface perturbe le fonctionnement du FireCluster, car les paramètres de configuration de FireCluster spécifient eth3 en tant qu'interface cluster principale et eth4 en tant qu'interface cluster de secours.

Pour obtenir de meilleurs résultats, utilisez eth0 en tant qu'interface cluster principale.

Utilisez une adresse IP inutilisée sur votre réseau. Afin d'éviter les conflits avec les adresses IP routables, nous vous recommandons les adresses APIPA ou les adresses IP d'un sous-réseau privé dédié. Les adresses IP des interfaces cluster de secours doivent appartenir au même sous-réseau. Les adresses IP des interfaces cluster de secours doivent appartenir à un sous-réseau distinct de celui des interfaces cluster principales.

Observez les meilleures pratiques suivantes relatives aux interfaces et aux adresses IP des clusters :

  • Les interfaces cluster principales et de secours doivent être sur des sous-réseaux différents.
  • Ne définissez pas l'adresse IP du cluster de secours sur l'adresse IP par défaut d'une interface Firebox. Par défaut, le Firebox utilise les sous-réseaux 10.0.x.0/24 pour les adresses IP des interfaces. C'est pourquoi nous vous déconseillons d'utiliser les adresses 10.0.x.0/24 pour les adresses IP du cluster de secours. Si vous configurez l'interface cluster de secours de manière à utiliser l'une des adresses IP d'interface usine par défaut, un conflit risque de se produire lors du basculement et entraîner son échec. Les adresses IP du cluster de secours ne doivent pas être utilisées à d'autres fins sur votre réseau, y compris pour les VPN.

Meilleures Pratiques Relatives aux Interfaces de Communication

Utilisez une adresse IP appartenant au même sous-réseau que votre serveur Dimension ou syslog. L'adresse IP de l'interface de communication doit également appartenir au même sous-réseau que votre réseau interne.

Dans WatchGuard Cloud, vous pouvez configurer un FireCluster géré sur le cloud de manière à transmettre les messages de journal à des serveurs Dimension ou syslog pour conserver les messages de journal plus longtemps que la période de rétention des données habituelle dans WatchGuard Cloud.

Étapes Suivantes

Après avoir vérifié toutes les exigences, vous pouvez Ajouter un FireCluster Géré sur le Cloud.

Rubriques Connexes

Ajouter un FireCluster à WatchGuard Cloud

Configurer un Remplacement RMA d'un membre d'un FireCluster Géré sur le Cloud