Explication de la partie réseau et rectificatifs

reseau/introduction_ovs.md

@@ -1,11 +1,11 @@
 # Introduction à OpenvSwitch
 
-Pour l'infrastructure réseau nous utiliserons OpenvSwitch.
+Pour l'infrastructure réseau, nous utiliserons OpenvSwitch.
 
-OpenvSwitch est une alternative aux bridges Linux classique. Il permet de créer des switchs (L2/L3) virtuel au seins de Proxmox qui peuvent communiquer entre eux via un lien trunk et qui gèrent très bien les VLANs.
+OpenvSwitch est une alternative aux bridges Linux classiques. Il permet de créer des switchs (L2/L3) virtuels au sein de Proxmox. Ces switchs virtuels gèrent très bien les VLANs. OpenvSwitch permet aussi à plusieurs switchs de communiquer entre eux via un lien trunk (GRE, VXLAN...).
 
 ## Explication rapide du fonctionnement
-
-- OVS Bridge, c'est comme un switch, mais en virtualisé sur lequel on peu branché des CT et VM sur des VLANs et qui peux communiquer avec un autre Bridge via un tunnel GRE. Pour notre usage le bridge n'aura pas d'IP sur l'hôte.
-- OVS Bond, permet d'attacher un groupe d'interface physique à un Bridge OVS ie. un groupe d'interface réseau à un switch virtuel.
-- OVS IntPort, pas possible de bridge des VMs ou des CT dessus, il permet à l'hôte de se brancher au Bridge et d'avoir une IP et éventuellement une VLAN.
+Fonctionnalités principales d'OpenvSwitch :
+- OVS Bridge peut être comparé à un switch virtuel sur lequel on peut brancher des CT et VM sur des VLANs et qui peut communiquer avec un autre switch (bridge) via un tunnel GRE. Pour notre usage, le bridge n'aura pas d'IP sur l'hôte.
+- OVS Bond permet d'attacher un groupe d'interfaces physiques (cartes réseau) à un Bridge OVS. Ce groupe d'interfaces physiques est considéré comme une seule interface virtuelle par le switch. Si deux cartes réseau forment un Bond, leur bande passante est additionnée et si l'une d'entre elles casse, l'autre prend le relais.
+- OVS IntPort permet à l'hôte de se brancher au Bridge, d'avoir une IP et éventuellement une VLAN mais il est impossible de brancher des VMs ou des CT dessus.

reseau/topologie_globale.md

@@ -1,28 +1,28 @@
 # Topologie globale de l'infrastructure
-Le réseau sera découpé en deux sous réseau matérialisé par des switchs virtuel. Le réseau interne accessible directement depuis l'extérieur et le réseau d'administation accessible uniquement via un VPN.
+Le réseau sera découpé en deux sous-réseaux matérialisés par des switchs virtuels : le réseau interne accessible directement depuis l'extérieur et le réseau d'administration accessible uniquement via un VPN.
 
 ## Réseau WAN
 
-Le réseau WAN permettra de faire le lien entre l'extérieur, les pare-feu et les hyperviseurs.
+Le réseau WAN permettra de faire le lien entre l'extérieur, les pare-feux et les hyperviseurs.
 
 ## Réseau Interne
 
-Le réseau interne sera séparé en 5 zones privées.
+Le réseau interne sera séparé en 5 zones privées :
 
-- DMZ qui sera située juste après le firewall et qui contiendra les loadbalancer (HAProxy) et le serveur DNS.
+- DMZ qui sera située juste après le firewall et qui contiendra les loadbalanceurs (HAProxy) et le serveur DNS.
 
-- PROXY qui sera placé juste après la DMZ et qui contiendra les reverses proxy pour les services autres que les environnements CTF ainqi qu'une Mail Gateway pour faire un relai entre l'extérieur et le serveur mail. Ce relai permettra de filtré les mails.
+- PROXY qui sera placée juste après la DMZ et qui contiendra les reverses proxy pour les services autres que les environnements CTF ainsi qu'une Mail Gateway pour faire un relai entre l'extérieur et le serveur mail. Ce relai permettra de filtrer les mails.
 
-- INT qui contiendra les containers des services permanents. La liaison entre INT et PROXY se fera à travers les reverses proxy NGINX et la Mail Gateway.
+- INT qui contiendra les containers des services permanents. La liaison entre INT et PROXY se fera à travers les reverse proxy NGINX et la Mail Gateway.
 
-- CTF qui sera la zone dédiée au reverse proxy CTF et aux containers/VMs des environnements CTF. Le lien avec l'extérieur se ferra directement au niveau de la DMZ via HAProxy.
+- CTF qui sera la zone dédiée au reverse proxy CTF et aux containers/VMs des environnements CTF. Le lien avec l'extérieur se fera directement au niveau de la DMZ via HAProxy.
 
-- DIRTY qui contiendra les containers des services en test
+- DIRTY qui contiendra les containers des services en test.
 
-Les requêtes arriveront sur le pare-feu qui effectura un premier filtrage et transmettra les requêtes sur les ports 80 et 443 à un des loadbalancer, c'est le loadbalancer qui décidera ensuite si la requête sera retransmise à l'un des reverses de la zone INT ou au reverse de la zone CTF.
+Les requêtes arriveront sur le pare-feu qui effectuera un premier filtrage et transmettra les requêtes sur les ports 80 et 443 à un des loadbalanceurs, c'est le loadbalanceur qui décidera ensuite si la requête sera retransmise à l'un des reverse proxy de la zone INT ou au reverse proxy de la zone CTF.
 
-## Réseau Administation
+## Réseau Administration
 
-L'accès au réseau administration se fera grâce à un VPN. Depuis le réseau administration on pourra accéder librement à tout les services hyperviseurs compris. Cela pourra par exemple permettre de mettre en place un système de monitoring.
+L'accès au réseau administration se fera grâce à un VPN. Depuis le réseau administration, on pourra accéder librement à tous les services hyperviseurs compris. Cela pourra par exemple permettre de mettre en place un système de monitoring.
 
-De son côté l'accès à l'interface d'administration de Proxmox se fera aussi par la voie classique. En cas de connexion à pve.krhacken.org, HAProxy vérifiera le certificat client et son CN avant de rediriger vers un des deux panels.
+De son côté, l'accès à l'interface d'administration de Proxmox se fera aussi par la voie classique. En cas de connexion à pve.krhacken.org, HAProxy vérifiera le certificat client et son CN avant de rediriger vers un des deux panels.