Ports de pare-feu requis pour NetBackup 6.x et 7.x

Problème

Quels ports TCP doivent être ouverts à travers un pare-feu afin que les hôtes NetBackup (NBU) 6.x et 7.x puissent communiquer entre eux ?

Cet article n’inclut pas les ports requis pour la communication avec les hôtes NetBackup 5.x, le serveur EMM distant ou d’autres processus hérités.  Ces informations sont abordées dans le manuel NetBackup™ 6.0 Port Usage Guide for Windows and UNIX Platforms et le Guide de sécurité et de chiffrement de NetBackup 7.0.1. Reportez-vous aux articles connexes.

Cause

Les principales modifications apportées à NetBackup 6.0 consistent en l’introduction de PBX pour prendre en charge les connexions CORBA et les sockets de transfert vnetd. 

• PBX écoute sur le port 1556 pour les connexions CORBA entrantes avec les nouveaux processus à plusieurs threads, tout comme vnetd le fait pour les processus à un thread hérités.  Par conséquent, tous les nouveaux processus peuvent être joints via le port 1556, et chaque nouveau processus n’a pas besoin d’écouter sur un port unique. 

• Les sockets de transfert vnetd remplacent le mécanisme de rappel préalablement utilisé pour ouvrir des sockets supplémentaires vers bpcd et d’autres processus clients hérités.  Le socket de transfert, tel que le socket de service, est ouvert de l’hôte de serveur à l’hôte client ; il devient ainsi inutile d’accepter les paquets TCP SYN en provenance des clients NetBackup si seules des opérations de restauration et de sauvegarde standard, initiées par le serveur, sont effectuées.
  
  Par défaut, il n’existe pas de mécanisme de reconnexion client ; le port sortant est donc la seule exigence. Cependant, si les attributs de client ont été modifiés pour désactiver vnetd, vous devrez peut-être ouvrir l’écran Fenêtre de port du serveur et/ou Fenêtre de port réservé au serveur de l’hôte client vers le ou les hôtes de serveur pour les connexions de rappel depuis bpcd et d’autres processus clients.

Si la politique de sécurité autorise les demandes TCP SYN entrantes, ouvrez le port vnetd en mode bidirectionnel. Ainsi, vous ne devrez pas modifier la configuration quand/si le site utilise des fonctionnalités NetBackup initiées par le client qui établissent des connexions des hôtes clients vers le serveur maître.  Par exemple :

• Opérations de sauvegarde/liste/restauration standard demandées par l’utilisateur
• Opérations de sauvegarde/restauration d’application de base de données basées sur un flux (DataSore/DB2/Informix/Oracle/SAP/SQL Server/Sybase/Teradata/XBSA).  Ces types d’opérations initiées par le client nécessitent que l’hôte client se connecte au serveur maître pour mettre en file d’attente les demandes.
• Opérations du client SAN

Pour les communications de serveur à serveur, le port TCP pour PBX (1556) doit être ouvert en mode bidirectionnel, ainsi que le port TCP pour vnetd (13724).  Si les options de connexion au pare-feu sont configurées sur le serveur maître pour le ou les serveurs de médias, vous devrez peut-être ouvrir l’écran Fenêtre de port du serveur et/ou Fenêtre de port réservé au serveur en entrée du ou des hôtes de serveur de médias vers l’hôte de serveur maître pour les connexions de rappel. Le port TCP pour bpcd (13782) devra peut-être être ouvert en sortie du serveur maître vers le ou les hôtes de serveur de médias pour les connexions de démon.  Si les options de connexion au pare-feu sont configurées sur le serveur de médias pour le serveur maître ou d’autres serveurs de médias, les ports de démon (bpdbm, bpjobd, contrôle robotique, etc.) devront peut-être être ouverts de ces hôtes vers le serveur maître. 

Solution

Les ports TCP requis pour la configuration par défaut sans remplacer les options de connexion dans les attributs de client (bpclient), les paramètres de pare-feu (CONNECT_OPTIONS), les serveurs maître et EMM distincts ou les considérations de sécurité héritées sont les suivants : 

• La communication du serveur maître vers les serveurs de médias (et vice-versa) nécessite les ports TCP pour vnetd (13724) et PBX (1556) en mode bidirectionnel.
• La communication du serveur maître vers le client requiert les ports TCP pour PBX (1556) et vnetd (13724) si les clients effectuent des opérations dirigées vers le client : sauvegarde/restauration d’utilisateur, archive utilisateur ou sauvegarde/restauration d’application.
   
• La communication du serveur de médias vers le client requiert le port TCP pour vnetd (13724) et PBX (1556).
• La communication d’un serveur de médias à un autre nécessite les ports TCP pour vnetd (13724) et PBX (1556) en mode bidirectionnel.
   
• La communication du client vers le serveur maître requiert les ports TCP 1556 (PBX) et 13724 (vnetd) pour les opérations initiées par le client (utilisateur ou application), mais pas pour celles initiées par le serveur.
• La communication du client vers le serveur maître requiert les ports TCP 1556 (PBX) et 13724 (vnetd) pour les restaurations dirigées vers le client (nouveau dans la version 7.6). 
   
• La communication du client SAN vers les serveurs maître/de médias (et vice-versa) nécessite les ports TCP pour vnetd (13724) et PBX (1556) en mode bidirectionnel. 
   
• La communication des consoles d’administration Java/Windows vers les serveurs maître et de médias nécessite les ports TCP pour vnetd (13724) et PBX (1556) en mode bidirectionnel.  
   
• Sauvegarde et restauration de VMware :
  
  La communication depuis l’hôte de sauvegarde vers vCenter requiert le port TCP 443.
  
  Si vous utilisez le générateur de requêtes (VIP), la communication du serveur maître vers vCenter requiert le port TCP 443.
  
  Si vous utilisez le type de transport nbd, la communication de l’hôte de sauvegarde vers l’hôte ESX requiert le port TCP 902.
   
• Sauvegarde et restauration de SharePoint :
  
  La communication du serveur frontal vers les hôtes de client SQL (et vice-versa) requiert les ports TCP pour vnetd (13724) et PBX (1556) en mode bidirectionnel.
  
  La communication du serveur frontal vers les hôtes de client SQL utilise également le service d’accès à distance au Registre qui requiert les ports TCP 135, 137, 138, 139 et 445.
  Consultez cet article de Microsoft : http://msdn.microsoft.com/fr-fr/library/cc288143.aspx 
     
• Si vous utilisez la technologie de restauration granulaire (GRT) :
  
  Les clients doivent se connecter au serveur de médias sur les ports 111 (portmap) et 7394 (nbfsd).
   
• Si vous utilisez OpsCenter :
  
  Les navigateurs Web requièrent les ports TCP pour http (80) et https (443) afin de se connecter à l’interface utilisateur graphique Web d’OpsCenter. Les ports 8181 et 8443 ou 8282 et 8553 peuvent être utilisés comme des alternatives.
  
  Les générateurs de rapports personnalisés requièrent le port TCP 13786 pour se connecter au serveur OpsCenter.
  
  Ouvrez le port 13724 (vnetd) entre le serveur OpsCenter et le serveur maître si vous exécutez le rapport de licence de capacité.
  
  Le serveur OpsCenter utilise également le port UDP 162 en sortie pour le protocole d’interruption SNMP.
   
• Sauvegarde et restauration des filers NDMP :
  
  La communication du serveur de médias (DMA) vers le filer NDMP (bande ou disque) requiert le port TCP 10000.
  
  La propriété SERVER_PORT_WINDOW est utilisée en entrée pour la communication du filer vers le serveur de médias à des fins de sauvegarde/restauration NDMP distante et peut également être utilisée pour optimiser le transfert de fichiers de catalogue (données TIR) avec la sauvegarde/restauration NDMP locale et à trois voies.
   
• Si vous utilisez VxSS avec NetBackup Access Control (NBAC) :
  
  Les serveurs maîtres requièrent les ports TCP 2821 (vrts-at-port) et 4032 (vrts-auth-port) pour la communication avec le serveur VxSS. 
  
  Les serveurs de médias requièrent les ports TCP 2821 (vrts-at-port) et 4032 (vrts-auth-port) pour la communication avec le serveur VxSS. 
  
  Les clients requièrent le port TCP 2821 (vrts-at-port) pour la communication avec le serveur VxSS.
  
  Les consoles d’administration Java/Windows requièrent le port TCP 2821 (vrts-at-port) pour la communication avec le serveur VxSS.
     
• Si vous utilisez le plug-in OpenStorage par DataDomain :
  
  Nécessite un accès au port TCP 2049, au port UDP/TCP 111 et au port mountd sur la baie de disques cible DataDomain.
  
  Pour la duplication optimisée, l’accès au port TCP 2051 est également requise.
      
• Si vous utilisez la duplication optimisée (y compris la réplication automatique d’image) :
  
  Pour la communication MSDP à MSDP, le serveur de stockage source a besoin d’accéder aux ports 10102 (spad) et 10082 (spoold) sur le serveur cible.
  
  Pour la communication MSDP à PDDO, le serveur de stockage source a besoin d’accéder aux ports 443 (SPA) et 10082 (spoold) sur le serveur cible.
  
  Pour la communication PDDO à PDDO, le serveur de stockage source a besoin d’accéder aux ports 443 (SPA) et 10082 (spoold) sur le serveur cible.
   
• Pour la réplication automatique d’image (AIR)
  
  En plus des ports pour la duplication optimisée, ouvrez également le port TCP 1556 (PBX) entre les serveurs maîtres.
   
• Pour les appliances NetBackup 5xxx :
  
  Ouvrez les ports 22 (ssh), 80 (http) et 443 (https) en entrée pour l’administration intrabande.
  
  Ouvrez les ports 80 (http) et 443 (https) en entrée d’IPMI (Intelligent Platform Management Interface) pour l’administration extrabande.
  
  Ouvrez le port 5900 en sortie d’IPMI pour la console à distance KVM/l’interface de ligne de commande et la redirection virtuelle d’images ISO/de CD-ROM à partir de NetBackup Integrated Storage Manager (appliances 5020/5200).  
                 Le port 623 sera également utilisé s’il est ouvert.
  
  Ouvrez le port 7578 en entrée d’IPMI pour l’accès de l’interface de ligne de commande à la console à distance (appliances 5220/5x30).
  
  Ouvrez le port 5120 en entrée d’IPMI pour la redirection virtuelle d’images ISO/de CD-ROM à partir de la console à distance (appliances 5220/5x30).
  
  Ouvrez le port 5123 en entrée d’IPMI pour la redirection virtuelle des disquettes à partir de la console à distance (appliances 5220/5x30).
  
  Ouvrez le por 443 (https) en sortie du serveur Symantec Call Home pour la surveillance proactive du matériel et la messagerie.
  
  Ouvrez le port 443 (https) en sortie du serveur Symantec Critical System Protection (SCSP) pour le téléchargement des certificats SCSP.
  
  Ouvrez le port 162 (snmp) en sortie du serveur SNMP pour les interruptions SNMP et les alertes.
  
  Ouvrez le port 11111 entre les appliances PureDisk pour la découverte de la topologie multinœuds.

•  Pour NetBackup CloudStore Service Container (nbcssc), ouvez le port 5637.

Considérations pour NetBackup 7.0.1

Les processus bpcd et vnetd s’exécutent maintenant de façon autonome.  Avec les autres processus hérités, ils s’enregistrent désormais auprès du PBX au démarrage.  Les connexions aux processus hérités qui contactaient précédemment le port vnetd préféreront utiliser le port PBX 1556.  Si le port PBX est inaccessible, le port vnetd sera utilisé.  Si le port vnetd est inaccessible, le port de démon sera utilisé.  L’ouverture du port TCP 1556 en sortie pour la communication des serveurs NetBackup vers les clients NetBackup empêchera les retards lors de tentatives d’utilisation de PBX.  De même, l’ouverture du port TCP 1556 en entrée empêchera les retards pour les demandes initiées par les clients et adressées au serveur maître. 

Notez que la communication de la console Java vers le serveur maître utilise le port vnetd pour la connexion à bpjobd et le port PBX pour toutes les autres connexions. 

À des fins d’efficacité, la mise à niveau/l’installation ajoute également des options de connexion de « 1 0 2 » pour localhost.  Les sockets internes sur l’interface de bouclage vers les processus sur le même hôte utiliseront les ports de démon au lieu de transmettre les communications via vnetd ou PBX.

Considérations pour NetBackup 7.1

NetBackup Access Control (NBAC) a été intégré à NetBackup, et les processus nbatd et nbazd seront utilisés à la place de vxatd et de vxazd.  Ces processus s’enregistrent auprès du PBX pour les connexions entrantes via le port PBX 1556, ce qui rend inutile l’ouverture de ports sur le serveur VxSS.

Les processus écoutent également sur les ports TCP 13783 et 13722 respectivement.  Ces numéros de port sont enregistrés auprès de l’IANA à l’aide des noms de service d’origine, « vopied » et « bpjava-msvc ». Ils sont résolus par NetBackup à l’aide de ces noms d’origine.  Les hôtes de version antérieure ne connaissent pas les nouveaux processus disponibles via le port 1556 et continueront à contacter vxatd et vxazd via les ports 2821 (vrts-at-port) et 4032 (vrts-at-auth).

Les sauvegardes de snapshots peuvent rencontrer de brefs retards lors de la suppression de snapshots si le port 1556 n’est pas ouvert du client vers le serveur maître.

Considérations pour NetBackup 7.5

La fonction Resilient Client requiert l’ouverture du port 13724 (vnetd) en mode bidirectionnel entre le serveur de médias et les hôtes clients.  Si vous utilisez des opérations dirigées vers le client, le port 13724 (vnetd) doit être ouvert en mode bidirectionnel entre le client et le serveur maître.  Cette fonction ne peut pas utiliser le port 1556 (PBX).

Les sauvegardes de snapshots peuvent rencontrer des retards avant et après le transfert de données si le port 1556 n’est pas ouvert du client vers le serveur maître.

Considérations pour NetBackup 7.6

La fonction de restauration dirigée vers le client requiert l’ouverture des ports TCP 1556 (PBX) et 13724 (vnetd) du client vers le serveur maître pour la connexion aux ports de liste de fichiers, que la restauration soit initiée par le serveur ou le client.

Considérations pour la traduction d’adresses réseau (NAT) et de port (PAT)

L’utilisation de NAT et de PAT n’est pas prise en charge avec NetBackup.  Consultez l’article TECH15006 dans la section Articles connexes pour plus de détails.