Configuration requise pour le pare-feu virtuel vSRX sur Microsoft Hyper-V
Cette section présente la configuration requise pour le déploiement d’une instance de pare-feu virtuel vSRX sur Microsoft Hyper-V.
Configuration logicielle requise
Le tableau 1 répertorie la configuration logicielle requise pour l’instance de pare-feu virtuel vSRX sur Microsoft Hyper-V.
Seule la petite saveur du pare-feu virtuel vSRX est prise en charge sur Microsoft Hyper-V. Les versions multiprocesseurs du pare-feu virtuel vSRX 3.0 sont prises en charge sur Microsoft Hyper-V.
Composant |
Spécification |
---|---|
Prise en charge de l’hyperviseur |
|
Mémoire |
4 Go |
Espace disque |
16 Go (lecteurs IDE ou SCSI) |
vCPU |
2 |
Cartes réseau virtuelles |
8 cartes réseau spécifiques à Hyper-V |
Composant |
Spécification |
---|---|
Prise en charge de l’hyperviseur |
|
Mémoire |
4 Go |
Espace disque |
18 Go (IDE) |
vCPU |
2 |
Cartes réseau virtuelles |
8 cartes réseau spécifiques à Hyper-V |
À partir de Junos OS version 19.1R1, l’instance vSRX Virtual Firewall 3.0 prend en charge le système d’exploitation invité avec 2 vCPU, 4 Go de RAM virtuelle et 18 Go d’espace disque sur Microsoft Hyper-V et Azure pour des performances améliorées.
Configuration matérielle requise
Le tableau 3 répertorie les spécifications matérielles de l’ordinateur hôte qui exécute la machine virtuelle vSRX Virtual Firewall.
Composant |
Spécification |
---|---|
Taille de la mémoire de l’hôte |
4 Go minimum |
Type de processeur hôte |
Processeur multicœur x86 ou x64
Note:
DPDK nécessite la prise en charge d’Intel Virtualization VT-x/VT-d dans le processeur. Voir À propos de la technologie de virtualisation Intel. |
Adaptateur Ethernet Gigabit (10/100/1000baseT) |
Émule la carte réseau Ethernet multiport DEC 21140 10/100TX 100 Mo avec une à quatre connexions réseau. |
Meilleures pratiques pour améliorer les performances du pare-feu virtuel vSRX
Passez en revue les pratiques suivantes pour améliorer les performances du pare-feu virtuel vSRX.
Nœuds NUMA
L’architecture du serveur x86 se compose de plusieurs sockets et de plusieurs cœurs au sein d’un socket. Chaque socket dispose également d’une mémoire utilisée pour stocker les paquets lors des transferts d’E/S de la carte réseau à l’hôte. Pour lire efficacement les paquets de la mémoire, les applications invitées et les périphériques associés (tels que la carte réseau) doivent résider dans un seul socket. Une pénalité est associée au fractionnement des sockets CPU pour les accès à la mémoire, ce qui peut entraîner des performances non déterministes. Pour le pare-feu virtuel vSRX, nous recommandons que tous les vCPU de la machine virtuelle vSRX Virtual Firewall se trouvent dans le même nœud physique NUMA (Non-Uniform Memory Access) pour des performances optimales.
Le moteur de transfert de paquets (PFE) du pare-feu virtuel vSRX cessera de répondre si la topologie des nœuds NUMA est configurée dans l’hyperviseur pour répartir les vCPU de l’instance sur plusieurs nœuds NUMA de l’hôte. Le pare-feu virtuel vSRX exige que vous vous assuriez que tous les vCPU résident sur le même nœud NUMA.
Nous vous recommandons de lier l’instance du pare-feu virtuel vSRX à un nœud NUMA spécifique en définissant l’affinité de nœud NUMA. L’affinité de nœud NUMA limite la planification des ressources de la machine virtuelle du pare-feu virtuel vSRX au seul nœud NUMA spécifié.
Mappage d’interface pour le pare-feu virtuel vSRX sur Microsoft Hyper-V
Chaque carte réseau définie pour un pare-feu virtuel vSRX est mappée à une interface spécifique, selon que l’instance du pare-feu virtuel vSRX est une machine virtuelle autonome ou une paire de clusters pour une haute disponibilité.
À partir de Junos OS version 15.1X49-D100 pour pare-feu virtuel vSRX, la prise en charge du clustering de châssis pour assurer la redondance des nœuds réseau est uniquement disponible sur Microsoft Hyper-V Server 2016 et versions ultérieures.
Notez les points suivants :
En mode autonome :
fxp0 est l’interface de gestion hors bande.
GE-0/0/0 est la première interface de trafic (revenus).
En mode cluster :
fxp0 est l’interface de gestion hors bande.
em0 est le lien de contrôle de cluster pour les deux nœuds.
Toutes les interfaces de trafic peuvent être spécifiées en tant que liens de structure, par exemple ge-0/0/0 pour fab0 sur le nœud 0 et ge-7/0/0 pour fab1 sur le nœud 1.
Le tableau 4 indique les noms d’interface et les mappages d’une machine virtuelle vSRX autonome.
Carte réseau |
Nom de l’interface dans Junos OS |
---|---|
1 |
fxp0 |
2 |
GE-0/0/0 |
3 |
GE-0/0/1 |
4 |
GE-0/0/2 |
5 |
GE-0/0/3 |
6 |
GE-0/0/4 |
7 |
GE-0/0/5 |
8 |
GE-0/0/6 |
Le tableau 5 indique les noms d’interface et les mappages pour deux machines virtuelles de pare-feu virtuel vSRX dans un cluster (nœud 0 et nœud 1).
Carte réseau |
Nom de l’interface dans Junos OS |
---|---|
1 |
fxp0 (nœuds 0 et 1) |
2 |
em0 (nœuds 0 et 1) |
3 |
GE-0/0/0 (nœud 0)GE-7/0/0 (nœud 1) |
4 |
GE-0/0/1 (nœud 0)GE-7/0/1 (nœud 1) |
5 |
GE-0/0/2 (nœud 0)GE-7/0/2 (nœud 1) |
6 |
GE-0/0/3 (nœud 0)GE-7/0/3 (nœud 1) |
7 |
GE-0/0/4 (nœud 0)GE-7/0/4 (nœud 1) |
8 |
GE-0/0/5 (nœud 0)GE-7/0/5 (nœud 1) |
Paramètres par défaut du pare-feu virtuel vSRX sur Microsoft Hyper-V
Le pare-feu virtuel vSRX requiert les paramètres de configuration de base suivants :
Des adresses IP doivent être attribuées aux interfaces.
Les interfaces doivent être liées à des zones.
Des stratégies doivent être configurées entre les zones pour autoriser ou refuser le trafic.
Le tableau 6 répertorie les paramètres d’usine par défaut des stratégies de sécurité sur le pare-feu virtuel vSRX.
Source Zone |
Destination Zone |
Mesures prises par les pouvoirs publics |
---|---|---|
Confiance |
Untrust |
Permis |
Confiance |
Confiance |
Permis |
Untrust |
Confiance |
Nier |