
En examinant la configuration de n'importe quel pare-feu, il est fort probable que nous voyions une multitude d'adresses IP, de ports, de protocoles et de sous-réseaux. C'est ainsi que les politiques de sécurité réseau sont traditionnellement mises en œuvre pour l'accès des utilisateurs aux ressources. Au départ, l'ordre est maintenu dans la configuration, mais ensuite, les employés commencent à changer de service, les serveurs se multiplient et changent de rôle, des accès pour différents projets apparaissent là où ils ne devraient généralement pas être, et des centaines de sentiers inconnus sont créés.
Concernant certaines règles, il y a peut-être des commentaires comme « demandé par Vasya » ou « ceci est un accès DMZ ». L'administrateur réseau quitte son poste, et tout devient très flou. Ensuite, quelqu'un a décidé de nettoyer la configuration de Vasya, et SAP s'est effondré, car autrefois Vasya avait demandé cet accès pour faire fonctionner SAP en production.

Aujourd'hui, je vais parler de la solution VMware NSX, qui aide à appliquer des politiques d'interaction et de sécurité réseau de manière précise, sans désordre dans les configurations des pare-feu. Je vais montrer les nouvelles fonctionnalités qui ont été ajoutées par rapport à ce que VMware avait précédemment dans ce domaine.
VMware NSX est une plateforme de virtualisation et de sécurité des services réseau. NSX s'occupe des tâches de routage, de commutation, d'équilibrage de charge, de pare-feu et bien d'autres choses intéressantes.
NSX est le successeur de son propre produit VMware vCloud Networking and Security (vCNS) et de l'acquis Nicira NVP.
De vCNS à NSX
Auparavant, le client dans le cloud, construit sur VMware vCloud, avait une machine virtuelle distincte vCNS vShield Edge. Elle servait de passerelle, où de nombreuses fonctions réseau pouvaient être configurées : NAT, DHCP, pare-feu, VPN, équilibreur de charge, etc. vShield Edge limitait l'interaction de la machine virtuelle avec le monde extérieur selon les règles définies dans le pare-feu et le NAT. À l'intérieur du réseau, les machines virtuelles communiquaient librement entre elles au sein des sous-réseaux. Si vous souhaitez vraiment contrôler le trafic, il est possible de créer un réseau séparé pour différentes parties des applications (différentes machines virtuelles) et de définir dans le pare-feu les règles correspondantes pour leur interaction réseau. Mais cela prend du temps, est compliqué et peu intéressant, surtout lorsque vous avez plusieurs dizaines de machines virtuelles.
Dans NSX, VMware a mis en œuvre le concept de micro-segmentation à l'aide d'un pare-feu distribué intégré dans le cœur de l'hyperviseur. Des politiques de sécurité et d'interaction réseau y sont définies non seulement pour les adresses IP et MAC, mais aussi pour d'autres objets : machines virtuelles, applications. Si NSX est déployé au sein d'une organisation, ces objets peuvent inclure un utilisateur ou un groupe d'utilisateurs d'Active Directory. Chaque objet devient un micro-segment dans son propre contour de sécurité, dans le sous-réseau souhaité, avec sa DMZ accueillante :).

Auparavant, le périmètre de sécurité était unique pour l'ensemble du pool de ressources, protégé par un commutateur de bordure, tandis qu'avec NSX, il est possible de protéger une machine virtuelle spécifique des interactions superflues même au sein d'un même réseau.
Les politiques de sécurité et d'interaction réseau s'adaptent si un objet est déplacé vers un autre réseau. Par exemple, si nous déplaçons une machine avec une base de données vers un autre segment de réseau ou même vers un autre data center virtuel associé, les règles définies pour cette machine virtuelle continueront de s'appliquer indépendamment de sa nouvelle position. Le serveur d'applications pourra toujours interagir avec la base de données.
Le vCNS vShield Edge a été remplacé par le NSX Edge. Ce dernier dispose de tout le nécessaire de l'ancien Edge, plus plusieurs nouvelles fonctionnalités utiles. C'est de cela dont nous allons parler ensuite.
Quelles sont les nouveautés du NSX Edge ?
La fonctionnalité du NSX Edge dépend de NSX. Il en existe cinq : Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Tout ce qui est nouveau et intéressant n'est visible qu'à partir de l'édition Advanced. Y compris la nouvelle interface, qui s'ouvre dans un nouvel onglet jusqu'à la migration complète de vCloud vers HTML5 (VMware promet l'été 2019).
Pare-feu. Comme objets auxquels les règles s'appliqueront, il est possible de sélectionner des adresses IP, des réseaux, des interfaces de passerelle et des machines virtuelles.


DHCP. En plus de la configuration de la plage d'adresses IP qui seront automatiquement attribuées aux machines virtuelles de ce réseau, des fonctionnalités de NSX Edge sont devenues disponibles. Binding et Relay.
Dans l'onglet Bindings il est possible de lier l'adresse MAC d'une machine virtuelle à une adresse IP si l'on souhaite que l'adresse IP ne change pas. Il est surtout important que cette adresse IP ne fasse pas partie du pool DHCP.

Dans l'onglet Relay La retransmission des messages DHCP est configurée pour les serveurs DHCP situés en dehors de votre organisation dans vCloud Director, y compris les serveurs DHCP de l'infrastructure physique.

Routage. Auparavant, vShield Edge ne permettait que le routage statique. Désormais, le routage dynamique compatible avec les protocoles OSPF et BGP est disponible. Les configurations ECMP (actif-actif) sont également désormais accessibles, ce qui permet le basculement du type « actif-actif » vers des routeurs physiques.

Configuration d'OSPF

Configuration de BGP
Parmi les nouveautés, la configuration du transfert de routes entre différents protocoles.
Redistribution des routes.

Équilibrage de charge L4/L7. L'en-tête X-Forwarded-For est maintenant disponible pour HTTPs. Sans cela, tout le monde était mécontent. Par exemple, si vous avez un site que vous équilibrez, sans le transfert de cet en-tête, tout fonctionne, mais dans les statistiques du serveur web, vous ne voyiez pas les IP des visiteurs, mais les IP de l'équilibreur. Maintenant, tout est correct.
De plus, dans l'onglet Règles d'application, il est désormais possible d'ajouter des scripts qui contrôleront directement l'équilibrage du trafic.

VPN. En plus du VPN IPSec, NSX Edge prend en charge :
- VPN L2, permettant d'étendre les réseaux entre les sites géographiquement éloignés. Ce type de VPN est nécessaire, par exemple, pour que lors d'un déménagement vers un autre site, une machine virtuelle reste dans le même sous-réseau et conserve son adresse IP.

- SSL VPN Plus, qui permet aux utilisateurs de se connecter à distance au réseau d'entreprise. Cette fonctionnalité était disponible au niveau de vSphere, mais c'est une nouveauté pour vCloud Director.

Certificats SSL. Des certificats peuvent maintenant être installés sur NSX Edge. Cela soulève à nouveau la question de savoir qui avait besoin d'un équilibreur sans certificat pour https.

Groupes d'objets. Dans cet onglet, vous pouvez définir des groupes d'objets pour lesquels certaines règles d'interaction réseau s'appliqueront, par exemple des règles de pare-feu.
Ces objets peuvent être des adresses IP et MAC.


Il y a également une liste de services (combinaison protocole-port) et d'applications qui peuvent être utilisées pour établir des règles de pare-feu. Seul l'administrateur du portail vCD peut ajouter de nouveaux services et applications.


Statistiques. Statistiques des connexions : le trafic qui passe par la passerelle, le pare-feu et l'équilibreur.
État et statistiques pour chaque tunnel IPSEC VPN et L2 VPN.

Journalisation. Dans l'onglet Paramètres d'Edge, vous pouvez définir le serveur pour l'enregistrement des journaux. La journalisation fonctionne pour DNAT/SNAT, DHCP, Firewall, routage, équilibreurs de charge, VPN IPsec, VPN SSL Plus.
Pour chaque objet/service, les types d'alerte suivants sont disponibles :
— Débogage
— Alerte
— Critique
— Erreur
— Avertissement
— Remarque
— Info

Tailles NSX Edge
En fonction des tâches à accomplir et des volumes VMware vous pouvez créer des NSX Edge des tailles suivantes :
NSX Edge
(Compact)
NSX Edge
(Large)
NSX Edge
(Quad-Large)
NSX Edge
(X-Large)
vCPU
1
2
4
6
Mémoire
512 Mo
1 Go
1 Go
8 Go
Disque
512 Mo
512 Mo
512 Mo
4,5 Go + 4 Go
Affectation
Une
application, test
data center
Petit
ou moyen
data center
Chargé
firewall
Balancement
charges au niveau L7
Ci-dessous dans le tableau – les métriques de performance des services réseau en fonction de la taille de NSX Edge.
NSX Edge
(Compact)
NSX Edge
(Large)
NSX Edge
(Quad-Large)
NSX Edge
(X-Large)
Interfaces
10
10
10
10
Sous-interfaces (Trunk)
200
200
200
200
Règles NAT
2,048
4,096
4,096
8,192
Entrées ARP
Jusqu'à écriture
1,024
2,048
2,048
2,048
Règles FW
2000
2000
2000
2000
Performance FW
3 Gbps
9,7 Gbps
9,7 Gbps
9,7 Gbps
Pools DHCP
20,000
20,000
20,000
20,000
Chemins ECMP
8
8
8
8
Routes statiques
2,048
2,048
2,048
2,048
Pools LB
64
64
64
1,024
Serveurs virtuels LB
64
64
64
1,024
Serveur LB / Pool
32
32
32
32
Vérifications de santé LB
320
320
320
3,072
Règles d'application LB
4,096
4,096
4,096
4,096
Clients L2VPN Hub à Étoile
5
5
5
5
Réseaux L2VPN par Client/Serveur
200
200
200
200
Tunnels IPSec
512
1,600
4,096
6,000
Tunnels SSLVPN
50
100
100
1,000
Réseaux privés SSLVPN
16
16
16
16
Sessions simultanées
64,000
1,000,000
1,000,000
1,000,000
Sessions/seconde
8,000
50,000
50,000
50,000
Débit LB (Proxy L7)
2,2 Gbps
2,2 Gbps
3 Gbps
Débit LB (Mode L4)
6 Gbps
6 Gbps
6 Gbps
Connexions LB/s (Proxy L7)
46,000
50,000
50,000
Connexions simultanées LB (Proxy L7)
8,000
60,000
60,000
Connexions LB/s (Mode L4)
50,000
50,000
50,000
Connexions simultanées LB (Mode L4)
600,000
1,000,000
1,000,000
Routes BGP
20,000
50,000
250,000
250,000
Voisins BGP
10
20
100
100
Routes BGP redistribuées
Pas de limite
Pas de limite
Pas de limite
Pas de limite
Routes OSPF
20,000
50,000
100,000
100,000
Entrées LSA OSPF Max 750 Type-1
20,000
50,000
100,000
100,000
Adjacences OSPF
10
20
40
40
Routes OSPF redistribuées
2000
5000
20,000
20,000
Total des routes
20,000
50,000
250,000
250,000
→
D'après le tableau, il est recommandé d'organiser la répartition sur NSX Edge pour des scénarios de production, uniquement à partir de la taille Large.
Pour aujourd'hui, c'est tout. Dans les prochaines parties, je vais passer en revue la configuration de chaque service réseau NSX Edge.
Source : habr.com
