> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/fr/module-4-reseau/04-firewall-nat-vlans.md).
# Règles de pare-feu, NAT et VLAN
## Vue d'ensemble des règles réseau
**Règles réseau** sont le mécanisme central de contrôle de tout le trafic circulant dans un réseau VergeOS. Elles remplacent les fonctionnalités traditionnellement assurées par des pare-feu, routeurs et commutateurs distincts — tous gérés depuis une seule liste de règles sur chaque réseau.
Chaque réseau externe, interne et VPN dans VergeOS possède son propre ensemble de règles. Les règles définissent quel trafic est autorisé, bloqué, traduit ou routé. Comme les réseaux internes sont **sécurisé par défaut** (aucun trafic ne circule tant que des règles ne l’autorisent pas), il est essentiel de comprendre les règles pour construire des topologies réseau fonctionnelles et sécurisées.
Les règles sont accessibles depuis le tableau de bord de n’importe quel réseau en cliquant **Règles** dans le menu de gauche.
## Types de règles
VergeOS prend en charge trois actions de règle, chacune ayant un objectif distinct :
### Règles de pare-feu (Accepter / Bloquer / Rejeter)
Les règles de pare-feu contrôlent quels paquets sont autorisés à traverser le réseau :
| Action | Comportement |
| ------------ | ------------------------------------------------------------------------------------------------------------ |
| **Accepter** | Autoriser les paquets correspondant aux critères définis à passer |
| **Bloquer** | Ignorer silencieusement les paquets correspondants — l’expéditeur ne reçoit aucune réponse |
| **Rejeter** | Rejeter les paquets correspondants et envoyer un ICMP « destination inaccessible » à la source (si possible) |
Utilisez **Accepter** des règles pour autoriser explicitement le trafic qui doit l’être. Utilisez **Bloquer** dans la plupart des scénarios de blocage (l’abandon silencieux empêche la reconnaissance). Utilisez **Rejeter** lorsque vous voulez que l’expéditeur sache immédiatement que la connexion a été refusée.
### Règles NAT/PAT (Traduire)
**Traduire** fournissent la traduction d’adresses réseau (NAT) et la traduction d’adresses et de ports (PAT). Les utilisations courantes comprennent :
* **SNAT (NAT source)** — Masquer les adresses des VM internes derrière une seule IP externe pour l’accès Internet sortant
* **DNAT (NAT de destination)** — Mapper une IP/port externe vers l’IP/port d’une VM interne pour l’accès à un service entrant (par exemple, publier un serveur web)
* **NAT 1:1** — Mapper une IP externe complète vers une IP interne complète (tous les ports)
* **Redirection de port** — Traduire un port externe spécifique vers un port interne différent
Les règles NAT utilisent l’action **Traduire** avec la direction **Entrant** pour DNAT et **Sortante** pour SNAT.
### Règles de route statique (Route)
**Routage** définissent comment le trafic sort d’un réseau. L’utilisation la plus courante est la **passerelle par défaut** règle qui envoie tout le trafic sortant via la DMZ vers un réseau externe. Les règles de route peuvent également définir des chemins spécifiques pour la communication entre réseaux.
## Ordre de traitement des règles
Les règles sont traitées **de haut en bas**. La première règle correspondante l’emporte — dès qu’un paquet correspond à une règle, aucune autre règle n’est évaluée pour ce paquet.
**L’ordre est important.** Considérez cet exemple :
1. **Règle NAT** — Traduire le trafic entrant sur le port 443 vers la VM interne `10.100.0.50:443`
2. **Règle de pare-feu** — Bloquer le trafic entrant sur le port 443
Si ces règles sont inversées (blocage d’abord, puis NAT), le trafic sera bloqué avant même que la règle NAT ne le voie. Placez toujours les règles NAT/Traduction **au-dessus** des règles de pare-feu associées lorsqu’elles doivent traiter le trafic en premier.
Pour modifier l’ordre des règles, sélectionnez une règle dans la liste des règles et utilisez l’option **Déplacer** pour la repositionner.
```mermaid
graph TD
PKT["Paquet entrant"] --> R1["Règle 1 : Traduire
Port 443 → 10.100.0.50"]
R1 -->|"Correspondance"| XLATE["Paquet traduit
vers la VM interne"]
R1 -->|"Pas de correspondance"| R2["Règle 2 : Accepter
Port 22 de l’admin"]
R2 -->|"Correspondance"| ACCEPT["Paquet accepté"]
R2 -->|"Pas de correspondance"| R3["Règle 3 : Bloquer
Tout le reste"]
R3 --> DROP["Paquet bloqué"]
style PKT fill:#e3f2fd,stroke:#1565c0
style XLATE fill:#e8f5e9,stroke:#2e7d32
style ACCEPT fill:#e8f5e9,stroke:#2e7d32
style DROP fill:#fce4ec,stroke:#c62828
```
## Paramètres des règles
Chaque règle est configurée avec un ensemble cohérent de paramètres :
| Paramètre | Description |
| --------------- | ----------------------------------------------------------------------------------------- |
| **Nom** | Libellé descriptif pour l’administration (par ex., `Autoriser HTTPS`, `SNAT vers le WAN`) |
| **Action** | Accepter, Bloquer, Rejeter, Route ou Traduire |
| **Protocole** | TCP, UDP, ICMP ou TOUT |
| **Direction** | Entrant ou sortant |
| **Interface** | Interface spécifique ou quelconque |
| **Source** | D’où provient le trafic — voir les sélecteurs d’adresse ci-dessous |
| **Destination** | Vers où le trafic doit être acheminé |
| **Cible** | Vers où diriger réellement le trafic (utilisé avec les actions Route et Traduire) |
| **Épingler** | Épinglez éventuellement la règle en haut ou en bas de la liste des règles |
### Filtrage des ports
Pour les protocoles TCP et UDP, vous pouvez spécifier :
* Un **un seul port** (par ex. `443`)
* Un **une plage de ports** (par ex. `8000-8999`)
* Plusieurs ports à l’aide de règles distinctes
### État de suivi de connexion
Les règles avancées peuvent filtrer selon l’état de connexion (Nouveau, Établi, Associé, Non suivi) pour l’inspection stateful des paquets.
## Sélecteurs d’adresse
Le **Source**, **Destination**, et **Cible** les champs utilisent des sélecteurs d’adresse — des options flexibles pour indiquer d’où vient le trafic ou où il va :
| Sélecteur | Description |
| ----------------------------- | ---------------------------------------------------------------------------------------------- |
| **Alias** | Sélectionnez un alias nommé (un groupe d’IP/CIDR) défini sur ce réseau |
| **N’importe lequel/Aucun** | Correspond à n’importe quelle adresse — aucun filtre appliqué |
| **Personnalisé** | Saisissez une IP spécifique, un CIDR ou une plage d’IP (par ex., `192.168.1.50-192.168.1.100`) |
| **Par défaut** | Assistant pour les règles de route — définit la route par défaut (0.0.0.0/0) |
| **Mes adresses IP** | Sélectionnez une IP définie sur ce réseau (IP virtuelles, IP statiques, alias) |
| **Adresse de mon réseau** | L’intégralité du sous-réseau de ce réseau |
| **Mon IP de routeur** | L’IP du routeur de ce réseau (adresse unique) |
| **Autre adresse IP** | Sélectionnez une IP spécifique d’un autre réseau |
| **Adresse d’un autre réseau** | Sélectionnez l’intégralité du sous-réseau d’un autre réseau |
| **Autre IP de routeur** | Sélectionnez l’IP de routeur d’un autre réseau |
| **Autre réseau IP DMZ** | Sélectionnez l’IP côté DMZ d’un autre réseau (utilisée pour le routage entre réseaux) |
{% hint style="success" %}
Utilisez l’outil de **sélecteurs d’aide** (Mon IP, IP DMZ d’un autre réseau, etc.) au lieu de coder en dur des adresses IP. Les sélecteurs d’aide se mettent automatiquement à jour si les adresses réseau changent, et ils permettent aux règles de fonctionner correctement lorsqu’elles sont clonées dans des recettes ou des modèles de locataire.
{% endhint %}
## Alias réseau
**Alias** vous permettent de regrouper plusieurs adresses IP ou plages CIDR dans un ensemble nommé, puis de référencer cet ensemble dans les règles. Cela simplifie la gestion lorsque le même groupe d’adresses apparaît dans plusieurs règles.
Pour créer un alias :
1. Accédez à **Réseaux → Alias → Nouveau**
2. Saisissez un **Nom** (par ex. `Serveurs Web`, `Administrateurs de confiance`)
3. Définissez l’ **ensemble d’adresses** — saisissez des IP/CIDR sous forme de liste séparée par des barres verticales (par ex., `10.10.10.10|10.200.10.0/24`) ou ajoutez des entrées individuellement
4. Définissez **Portée de publication**: **Privé** (ce cloud uniquement) ou **Globale** (disponible pour les locataires)
5. Cliquez sur **Soumettre**
Lors de la création des règles, définissez la Source ou la Destination **Type** vers **Alias** et sélectionnez l’alias souhaité dans la liste déroulante.
{% hint style="warning" %}
Après avoir modifié un alias, vous devez cliquer sur **Appliquer les règles** sur chaque réseau qui l’utilise pour que les modifications prennent effet.
{% endhint %}
## Limitation de débit (réduction du trafic)
Des règles individuelles peuvent avoir **la limitation** activée pour limiter le débit du trafic. Lors de la création ou de la modification d’une règle, cochez **Activer la limitation** et configurez :
* **Débit** — La valeur numérique du débit
* **Type de débit** — Des unités telles que paquets/seconde, Mo/jour, octets/heure, etc.
* **Burst** — Tolérance de rafale au-dessus de la limite de débit
La limitation de débit peut également être appliquée au **niveau du réseau** (sur le routeur du réseau) pour limiter tout le trafic circulant dans le réseau, pas seulement des règles spécifiques.
## Diagnostics des règles
VergeOS fournit trois niveaux de diagnostics au niveau des règles :
### Suivre les statistiques de la règle
Activez l' **Suivre les statistiques de la règle** case à cocher sur n’importe quelle règle pour compter les paquets et les octets traités par cette règle. Les statistiques sont visibles depuis la liste des règles, ce qui vous permet de voir quelles règles traitent activement le trafic et dans quelle mesure.
Pour un suivi à l’échelle du réseau, activez le paramètre `statistiques` du réseau afin de suivre automatiquement chaque règle (reportez-vous à l’interface actuelle pour l’intitulé exact).
### Tracer / Déboguer la règle
Activer **Tracer/Déboguer la règle** sur une règle spécifique pour tracer tous les paquets qui lui correspondent. C’est inestimable pour le dépannage — vous pouvez voir exactement quels paquets atteignent une règle et s’ils sont acceptés, bloqués ou traduits.
### Inspection de bas niveau
Pour des diagnostics avancés, connectez-vous à la console du réseau et exécutez :
```bash
nft list ruleset
```
Cela affiche l’intégralité du **nftables** ruleset configuré par VergeOS, montrant les règles réelles au niveau du noyau en vigueur. C’est utile pour les ingénieurs support qui diagnostiquent des problèmes complexes d’interaction entre règles.
## Création des règles : pas à pas
Cet exemple crée un ensemble de règles courant pour un réseau interne qui a besoin d’un accès Internet et d’un serveur web entrant :
**Étape 1 : Route par défaut (accès Internet sortant)**
1. Accédez au réseau interne → **Règles → Nouveau**
2. **Nom :** `Passerelle par défaut`, **Action :** Route, **Direction :** Sortante
3. **Destination :** Par défaut, **Cible :** IP DMZ d’un autre réseau → sélectionnez votre réseau externe
4. Soumettre et appliquer les règles
**Étape 2 : SNAT (masquer les IP internes derrière une IP externe)**
1. **Nom :** `SNAT sortant`, **Action :** Traduire, **Direction :** Sortante
2. **Source :** Adresse de mon réseau, **Cible :** IP DMZ d’un autre réseau → sélectionnez le réseau externe
3. Épingler en **haut** (SNAT doit être traité avant les règles de pare-feu)
4. Soumettre et appliquer les règles
**Étape 3 : DNAT (publier le serveur web)**
1. **Nom :** `DNAT HTTPS`, **Action :** Traduire, **Protocole :** TCP, **Direction :** Entrant
2. **Destination :** Mes adresses IP → sélectionnez l’IP externe, **Port :** 443
3. **Cible :** Personnalisé → `10.100.0.50` (serveur web interne), **Port :** 443
4. Soumettre et appliquer les règles
**Étape 4 : Accepter l’HTTPS entrant**
1. **Nom :** `Autoriser HTTPS`, **Action :** Accepter, **Protocole :** TCP, **Direction :** Entrant
2. **Port de destination :** 443
3. Soumettre et appliquer les règles
{% hint style="warning" %}
Cliquez toujours sur **Appliquer les règles** après avoir créé ou modifié des règles. Les règles sont en attente jusqu’à leur application — elles ne prennent effet que lorsque vous les appliquez explicitement.
{% endhint %}
## Trunking VLAN
Les VLAN dans VergeOS sont configurés au **réseau externe** niveau à l’aide du marquage 802.1Q. Chaque réseau externe peut être mappé à un identifiant VLAN spécifique sur un réseau physique, permettant la segmentation du trafic sans câblage physique supplémentaire.
### Création d’un réseau externe balisé VLAN
1. Accédez à **Réseaux → Nouveau réseau externe**
2. Définissez **Type de couche 2** vers `VLAN`
3. Saisissez le **ID de couche 2** (l’ID VLAN 802.1Q, par ex., `100`)
4. Sélectionnez le **Réseau d'interface** (le réseau physique sur lequel ce VLAN repose)
5. Configurez l’adressage IP et soumettez
Plusieurs réseaux externes peuvent utiliser différents identifiants VLAN sur le même réseau physique, offrant une séparation logique pour la gestion, la production, la DMZ et le trafic des locataires.
### Q-in-Q (double balisage)
Pour les environnements de fournisseurs de services qui nécessitent un double balisage VLAN, sélectionnez un **réseau externe** (pas un réseau physique) comme réseau d’interface. Cela empile une seconde étiquette VLAN au-dessus de l’étiquette existante.
## Vue d’ensemble du VPN
VergeOS inclut une connectivité VPN intégrée utilisant deux protocoles :
### WireGuard
Protocole VPN moderne et performant, avec une cryptographie de pointe et une charge de configuration minimale. Recommandé pour la plupart des cas d’usage VPN.
### IPsec
Protocole VPN standard du secteur, destiné aux environnements qui doivent interfacer des équipements IPsec tiers (Cisco, pfSense, etc.).
### Cas d’usage de WireGuard
* **Site à site entre systèmes VergeOS** — Connectez deux installations VergeOS via un tunnel chiffré. Chaque côté crée une interface WireGuard et configure l’autre comme pair à l’aide d’un échange de clés publiques.
* **Site à site avec des pairs tiers** — Connectez un système VergeOS à n’importe quel point de terminaison compatible WireGuard.
* **Accès distant pour les utilisateurs** — Fournissez un accès VPN sécurisé pour des utilisateurs individuels. VergeOS peut générer automatiquement des fichiers de configuration de pair à télécharger vers les logiciels client WireGuard pris en charge.
WireGuard est rattaché à un réseau VergeOS (généralement un réseau interne qui a accès à toutes les ressources que le VPN doit atteindre). Après avoir créé l’interface et les définitions des pairs, cliquez sur **Appliquer les règles** pour activer les règles de pare-feu et de routage générées automatiquement.
### Cas d’usage IPsec
* **Connectivité avec des appareils tiers** — Connectez-vous à Cisco, pfSense, FortiGate ou à d’autres appareils compatibles IPsec sur des sites distants.
* **VPN de locataire** — Configurez un tunnel IPsec au sein d’un locataire pour une connectivité site à site vers l’infrastructure distante du locataire.
La configuration IPsec consiste à créer un **réseau VPN**, à configurer **Phase 1** (négociation IKE) et **Phase 2** (paramètres de chiffrement/tunnel), puis à appliquer les règles de pare-feu générées automatiquement.
{% hint style="success" %}
WireGuard est recommandé plutôt qu’IPsec chaque fois que possible. Il offre de meilleures performances, une configuration plus simple et est moins vulnérable aux erreurs de configuration de sécurité.
{% endhint %}
## Micro-segmentation
La micro-segmentation est une stratégie de sécurité qui divise le réseau en segments isolés, chacun avec ses propres contrôles de sécurité. VergeOS est conçu spécifiquement pour cette approche :
### Comment VergeOS permet la micro-segmentation
1. **Réseaux internes comme segments** — Chaque réseau interne constitue par défaut une frontière de sécurité isolée. Créez des réseaux distincts pour les niveaux web, applicatif, base de données, gestion et développement.
2. **Règles de pare-feu granulaires** — Définissez des politiques de trafic par règle précisant le protocole, le port, la source, la destination et la direction. N’autorisez que le trafic exact dont chaque niveau a besoin.
3. **Alias réseau pour les groupes de politique** — Regroupez les IP associées en alias (par ex., `Serveurs Web`, `Clients-DB`) et référencez-les dans les règles pour une application cohérente des politiques.
4. **Isolation des locataires** — Chaque locataire (VDC) fonctionne avec sa propre DMZ et ses propres réseaux internes, offrant une encapsulation réseau complète entre locataires.
5. **Mise en miroir des ports pour la visibilité** — Surveillez le trafic sur n’importe quel segment de réseau pour l’analyse de sécurité sans perturber la production.
6. **VPN pour des chemins chiffrés** — Utilisez WireGuard ou IPsec entre des segments réseau sensibles pour une défense en profondeur.
### Modèle de conception Zero Trust
```mermaid
graph TB
sous-graphe "Zero-Trust Multi-Tier"
WEB["Niveau Web
10.100.0.0/24
Accepter : 443 entrant"]
APP["Niveau applicatif
10.100.1.0/24
Accepter : 8080 depuis Web uniquement"]
DB["Niveau BD
10.100.2.0/24
Accepter : 3306 depuis App uniquement"]
end
WEB -->|"Port 8080 uniquement"| APP
APP -->|"Port 3306 uniquement"| DB
INET["Internet"] -->|"Port 443 uniquement"| WEB
style WEB fill:#e3f2fd,stroke:#1565c0
style APP fill:#fff3e0,stroke:#e65100
style DB fill:#fce4ec,stroke:#c62828
style INET fill:#f5f5f5,stroke:#616161
```
Chaque niveau est un réseau interne distinct avec des règles explicites. Le niveau web n’accepte que HTTPS depuis Internet. Le niveau applicatif n’accepte que le port 8080 depuis le niveau web. Le niveau de base de données n’accepte que le port 3306 depuis le niveau applicatif. Aucun autre trafic n’est autorisé — tous les chemins sont définis explicitement.
{% hint style="info" %}
**Pont VMware**
VMware répartit le pare-feu et le NAT entre NSX-T DFW (micro-segmentation au niveau de la vNIC), NSX-T Edge (NAT et routage statique Tier-0/Tier-1) et les groupes de ports vDS (VLAN). VergeOS les unifie en listes de règles par réseau : les règles de pare-feu remplacent DFW, les règles de traduction remplacent le NAT NSX Edge, les règles de route remplacent les routes statiques Tier-0/Tier-1, l’ordre des règles remplace les catégories de politiques NSX, et le VPN WireGuard est fourni nativement dans la plateforme.
{% endhint %}
{% hint style="info" %}
**Pont Nutanix**
Nutanix nécessite l’add-on Flow pour la micro-segmentation, la configuration du pont OVS pour les VLAN, et une infrastructure externe pour le NAT/routage/VPN. VergeOS inclut des règles de pare-feu, des règles NAT/PAT, des règles de route, le VPN WireGuard/IPsec, des alias d’adresse et la limitation de débit et les statistiques par règle intégrées à chaque réseau.
{% endhint %}
## Points clés
| Concept | Résumé |
| ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Types de règles** | Accepter/Bloquer/Rejeter (pare-feu), Traduction (NAT/PAT), Route (routes statiques) |
| **Ordre de traitement** | De haut en bas — la première correspondance l’emporte ; placez le NAT avant les règles de pare-feu associées |
| **Sélecteurs d’adresse** | Utilisez des assistants (Mon IP, IP DMZ d’un autre réseau) plutôt que des IP codées en dur pour plus de portabilité |
| **Alias** | Groupes nommés d’IP/CIDR pour une gestion cohérente des politiques sur plusieurs règles |
| **Limitation de débit** | Limitation par règle ou à l’échelle du réseau sur le routeur |
| **Diagnostics** | Suivi des statistiques par règle, Trace/Débogage pour l’inspection au niveau des paquets, `nft list ruleset` pour une vue de bas niveau |
| **VLAN** | Marquage 802.1Q défini par réseau externe ; Q-in-Q via un réseau externe comme interface |
| **VPN** | WireGuard (recommandé) pour le site à site et l’accès distant ; IPsec pour la compatibilité avec des tiers |
| **Micro-segmentation** | Réseaux internes séparés par niveau + règles de moindre privilège = architecture Zero Trust |
## Étapes suivantes
Avec les règles de pare-feu, le NAT, les VLAN et le VPN configurés, explorez le laboratoire pratique pour mettre ces concepts en pratique : [**Laboratoire : Configuration réseau →**](/learn-the-platform/fr/module-4-reseau/lab.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.verge.io/learn-the-platform/fr/module-4-reseau/04-firewall-nat-vlans.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.