> 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/knowledge-base/fr/backup-dr/veeam-worker-networking.md).
# Configuration de l’accès réseau pour les travailleurs Veeam Backup & Replication
## Vue d’ensemble
Veeam Backup & Replication (VBR) déploie **workers** — des VM Linux auxiliaires qui traitent les charges de sauvegarde et déplacent les données de sauvegarde — à la demande. Dans ce guide, le **fournisseur** est le système racine — le système VergeOS de plus haut niveau (lui-même le tenant racine) qui héberge vos tenants et exécute VBR. Le **serveur VBR** (`veeamHost`) est une seule VM hébergeant les deux composants principaux de Veeam : le **serveur de sauvegarde** (le cœur de gestion de l'infrastructure de sauvegarde) et un **référentiel de sauvegarde** (l'emplacement de stockage où arrivent les sauvegardes). Lorsque VBR protège des charges de travail à la fois dans le fournisseur et à l'intérieur d'un tenant, les workers qu'il déploie de chaque côté doivent pouvoir se joindre mutuellement — et joindre directement le serveur VBR, où se trouve le référentiel de sauvegarde — sans être bloqués par le NAT du tenant ni routés via des sauts supplémentaires.
L'intégration elle-même — le package VergeOS oVirt-engine, l'ajout des systèmes et des tenants à Veeam en tant que **Managers VergeOS**, et les exigences de version — est couverte dans [l'intégration de Veeam avec VergeOS](/automate-protect-and-extend/integrations-and-apis/veeam.md). Ce guide couvre uniquement le *réseau* dont les workers ont besoin : le **chemin de données** montré dans la [Topologie d'exemple](#example-topology) ci-dessous — le réseau externe plat que les workers utilisent pour déplacer le trafic de sauvegarde une fois déployés.
Le modèle sous-jacent est simple :
* **Charges de travail du fournisseur uniquement :** attachez à la fois le serveur VBR et son worker directement au `Externe` réseau du fournisseur. C'est toute la configuration — tout partage déjà un même domaine de couche 2, donc le serveur VBR et le worker se joignent directement sans aucune règle de pare-feu créée manuellement.
* **Charges de travail du tenant :** étendez ce même `Externe` réseau dans chaque tenant au niveau de la couche 2, puis déployez un worker à l'intérieur du tenant sur le réseau étendu. C'est la voie la plus simple pour la sauvegarde des tenants — elle donne à chaque composant l'accès dont il a besoin sans élaborer à la main des règles de pare-feu.
Ce design plat, à couche 2 partagée, est volontairement la façon la plus simple de faire fonctionner Veeam sur VergeOS. Si votre environnement nécessite une isolation plus forte des tenants ou un réseau de sauvegarde dédié, voir [Déploiements plus complexes](#more-complex-deployments) à la fin de ce guide.
Ce guide parcourt le cas complet avec tenant, qui place le serveur VBR du fournisseur et les deux workers sur le **même domaine de diffusion de couche 2** tout en exposant l'interface utilisateur du tenant sur ce même réseau. Il utilise la [Réseaux de couche 2 du locataire](/run-the-platform/tenants/layer-2-networks.md) fonctionnalité de VergeOS `Externe` pour relier un tenant directement au [réseau du fournisseur](#provider-only-deployment-no-tenants) ci-dessous.
{% hint style="info" %}
**Points clés**
* Le `Externe` réseau du fournisseur est transmis tel quel au tenant via un réseau de couche 2 de tenant — aucun étiquetage VLAN n'est requis si vous transmettez le réseau externe principal/plat.
* Comme chaque composant se trouve sur le même domaine de couche 2 externe, **aucune règle de pare-feu n'a besoin d'être créée manuellement** — le réseau plat donne au serveur VBR et aux workers l'accès dont ils ont besoin.
* VBR attribue lui-même les adresses IP des workers lors du déploiement de chaque worker. Elles sont **pas** gérées par le DHCP de VergeOS — choisissez des adresses en dehors de la plage DHCP de votre réseau externe.
* Le tenant obtient tout de même sa propre adresse IP d'interface utilisateur routable via un **IP virtuelle**, indépendamment du passage de couche 2.
{% endhint %}
## Déploiement fournisseur uniquement (sans tenants)
Si vous ne protégez que des charges de travail dans le fournisseur (le système racine) et qu'aucun tenant n'est impliqué, cela se réduit à une configuration beaucoup plus simple — omettez simplement les parties relatives au tenant :
1. Attachez le **serveur VBR** serveur VBR `Externe` réseau Externe [Étape 1](#step-1-deploy-the-vbr-server-on-the-providers-external-network)).
2. Déployez le **worker côté fournisseur** sur ce même `Externe` réseau avec une IP statique en dehors de la plage DHCP (voir [Étape 5](#step-5-deploy-the-workers)).
C'est tout. Les étapes 2 à 4 n'existent que pour étendre le réseau Externe à un tenant, vous pouvez donc les ignorer entièrement. Tout partage déjà le domaine de couche 2 du réseau Externe, donc le serveur VBR et le worker communiquent directement sans aucune règle de pare-feu créée manuellement.
Lorsque des tenants sont ajoutés plus tard, étendez le même `Externe` réseau dans chacun d'eux avec un réseau de couche 2 de tenant et déployez-y un worker — c'est le flux de travail pour les tenants documenté dans le reste de ce guide.
## Topologie d'exemple
| Rôle | Emplacement | Réseau | Exemple d'IP |
| ------------------------------- | ---------------------------- | ---------------------------------------------- | -------------------------------------- |
| Serveur VBR (`veeamHost`) | Fournisseur | `Externe` | `10.1.2.214` (statique) |
| Interface utilisateur du tenant | Attribuée par le fournisseur | `Externe` (IP virtuelle détenue par le tenant) | `10.1.2.10` |
| Worker côté fournisseur | Fournisseur | `Externe` | `10.1.2.30` (statique, défini par VBR) |
| Worker côté tenant | Tenant (`VeeamTenant1`) | `ExterneL2` | `10.1.2.13` (statique, défini par VBR) |
```mermaid
graph TB
subgraph Fournisseur["Fournisseur (système racine) — Externe 10.1.2.0/24"]
VBR["veeamHost — serveur VBR
10.1.2.214"]
PWorker["Worker côté fournisseur
10.1.2.30"]
end
subgraph Tenant["Tenant: VeeamTenant1"]
PhysExt["Physique - Externe
(créé automatiquement par Réseau de couche 2 de tenant)"]
ExtL2["ExterneL2
Réseau Externe, non étiqueté, Type d'adresse IP : Aucun"]
TWorker["Worker côté tenant
10.1.2.13"]
PhysExt --> ExtL2
ExtL2 --> TWorker
end
VBR ---|"Réseau de couche 2 de tenant
(même domaine de diffusion L2)"| PhysExt
VBR <-.->|"direct, sans NAT"| PWorker
PWorker <-.->|"direct, sans NAT"| TWorker
VBR <-.->|"direct, sans NAT"| TWorker
TenantUIVIP["Interface utilisateur du tenant
IP virtuelle 10.1.2.10
(détenue par VeeamTenant1)"]
Fournisseur --- TenantUIVIP
style Fournisseur fill:#e8f5e9,stroke:#2e7d32
style Tenant fill:#fff3e0,stroke:#e65100
```
Comme tout se trouve sur le même sous-réseau, le serveur VBR et les deux workers peuvent communiquer directement entre eux, et l'interface d'administration du tenant reste joignable à sa propre IP sur ce même réseau — aucun transfert de port ni route supplémentaire à maintenir.
## Exigences
**Toujours :**
* Le [Intégration de Veeam avec VergeOS](/automate-protect-and-extend/integrations-and-apis/veeam.md) en place — les exigences de version sont satisfaites, le package oVirt-engine est activé, et le système est ajouté à l'inventaire Veeam en tant que **Manager VergeOS**
* accès Administrateur de cluster au niveau du fournisseur
* Le `Externe` réseau déjà configuré et en fonctionnement
* Veeam Backup & Replication déployé en tant que VM sur le fournisseur — dans ce guide, un seul **serveur VBR** hébergeant à la fois le serveur de sauvegarde et un référentiel de sauvegarde
* Consultez les [Considérations et limites](https://helpcenter.veeam.com/docs/vbr/userguide/uh_limitations.html?ver=13) pour savoir ce que l'intégration prend et ne prend pas en charge avant de planifier votre déploiement
**Chemin tenant uniquement :**
* Un tenant existant (ce guide utilise `VeeamTenant1` comme exemple), ajouté à Veeam en tant que son propre Manager VergeOS
## Étape 1 : Déployer le serveur VBR sur le réseau Externe du fournisseur
Déployez votre serveur Veeam Backup & Replication en tant que VM avec une NIC attachée directement au `Externe` réseau du fournisseur, et donnez-lui une IP statique dans ce sous-réseau (par ex. `10.1.2.214`).
{% hint style="info" %}
Cette VM est une configuration VM VergeOS standard — aucun réseau spécial n'est requis ici. Elle doit simplement se trouver sur le même `Externe` réseau que vous bridgerez vers le tenant dans les étapes suivantes.
{% endhint %}
## Étape 2 : attribuer au tenant une IP virtuelle d'interface utilisateur sur le réseau Externe
Cela permet de conserver l'interface d'administration du tenant joignable sur le même réseau que le serveur VBR, indépendamment du passage de couche 2 configuré plus tard.
1. Accédez au **Externe** tableau de bord réseau du fournisseur.
2. Cliquez **Adresses IP** dans le menu de gauche, puis **Nouveau**.
3. **Type**: `IP virtuelle`
4. **Adresse IP**: l'adresse que vous souhaitez que l'interface du tenant utilise (par ex. `10.1.2.10`)
5. **Type de propriétaire**: `tenant`
6. **Propriétaire**: sélectionnez votre tenant (par ex. `VeeamTenant1`)
7. Cliquez **Soumettre**.
8. Depuis le **Externe** tableau de bord réseau, cliquez **Appliquer les règles**.
9. Accédez au tableau de bord réseau du tenant (**Réseaux** > **Tableau de bord** > **Locataires** > double-cliquez sur le tenant) et cliquez **Appliquer les règles** là aussi.
Détails complets : [Attribution d'adresses IP externes à un tenant](/run-the-platform/tenants/assign-ip-to-tenant.md).
## Étape 3 : Créer la connexion de réseau de couche 2 du tenant
Cela relie directement le tenant au `Externe` réseau du fournisseur au niveau de la couche 2.
1. Dans le menu du haut, accédez à **Locataires** > **Liste**.
2. Cliquez sur le nom du tenant (par ex. `VeeamTenant1`) pour ouvrir le tableau de bord du tenant.
3. Dans la navigation de gauche, développez **Réseau** et cliquez sur **Réseaux de couche 2**.
4. Cliquez **Nouveau**.
5. **Réseau**: sélectionnez le `Externe` réseau du fournisseur.
6. Basculez **Activé** sur ON (bleu).
7. Cliquez **Soumettre**.
VergeOS provisionne automatiquement une NIC sur le nœud du tenant connectée à `Externe`, plus un **Physique - Externe** réseau à l'intérieur du tenant qui s'y branche.
{% hint style="warning" %}
**Ne pas étiqueter le réseau créé automatiquement**
Si VergeOS crée automatiquement un réseau Externe correspondant à l'intérieur du tenant, laissez-le non étiqueté — l'interface est déjà sur le bon réseau. Voir [Configurer les réseaux de couche 2 du tenant](/run-the-platform/tenants/layer-2-networks.md) pour l'explication complète des composants créés automatiquement.
{% endhint %}
Détails complets et étapes de suppression/nettoyage : [Configurer les réseaux de couche 2 du tenant](/run-the-platform/tenants/layer-2-networks.md).
## Étape 4 : Créer le réseau Externe côté tenant pour l'attachement du worker
Si votre tenant dispose déjà de son propre réseau par défaut nommé `Externe` (utilisé pour l'accès sortant/NAT normal), VergeOS ne créera pas un second réseau portant le même nom — vous en ajouterez donc un manuellement par-dessus le `Physique - Externe` réseau backend créé automatiquement, sous un nom différent (cet exemple utilise `ExterneL2`).
1. Connectez-vous au **interface utilisateur du locataire**.
2. Accédez à **Réseaux** > **Nouveau réseau externe**.
3. **Nom**: `ExterneL2`
4. **Type de couche 2**: `Aucun` (simple transit brut — le VLAN/l'étiquetage, le cas échéant, est déjà pris en charge par l'interface Physique - Externe)
5. **Réseau d'interface**: `Physique - Externe`
6. **Type d'adresse IP**: `Aucun`
{% hint style="info" %}
**Pourquoi Type d'adresse IP : Aucun**
Veeam attribue et gère lui-même l'adresse IP du worker lorsqu'il déploie la VM du worker. Laisser Type d'adresse IP sur `Aucun` maintient VergeOS à l'écart de cette attribution — c'est un pur passage de couche 2, correspondant à la façon dont [les réseaux internes de couche 2](/run-the-platform/networking/internal-layer2.md) fonctionnent lorsqu'un tiers gère l'attribution des IP.
{% endhint %}
7. Cliquez **Soumettre**, puis **Mise sous tension** le réseau.
Pour la référence complète des champs concernant la création d'un réseau externe (options VLAN, IP statique, règles de routage), voir [Comment créer un réseau externe](/knowledge-base/fr/networking/create-external-network.md).
## Étape 5 : Déployer les workers
Déployez les workers depuis Veeam en utilisant son intégration VergeOS — VergeOS n'a besoin d'aucune configuration supplémentaire ici en dehors des réseaux créés ci-dessus. Reportez-vous à [la documentation de Veeam](https://helpcenter.veeam.com/docs/vbr/userguide/uh_workers_add.html?ver=13) pour connaître les étapes exactes de déploiement des workers pour votre version de Veeam.
* **Worker côté fournisseur**: attachez au `Externe` réseau du fournisseur. Donnez-lui une IP statique en dehors de la plage DHCP de votre réseau Externe (dans cet exemple, le réseau Externe distribue `10.1.2.200`–`10.1.2.201` via DHCP, donc `10.1.2.30` est un choix statique sûr).
* **Worker côté tenant**: attachez au `ExterneL2` réseau du tenant. Là encore, utilisez une IP statique en dehors de la plage DHCP du fournisseur (par ex. `10.1.2.13`).
{% hint style="warning" %}
**Éviter les conflits de plage DHCP**
Parce qu'il s'agit d'adresses statiques définies dans le worker Veeam (et non demandées au DHCP de VergeOS), vérifiez bien qu'elles n'entrent pas en conflit avec la plage DHCP du réseau Externe ou avec toute autre adresse statique attribuée sur ce sous-réseau.
{% endhint %}
Une fois les deux workers en ligne, eux et le serveur VBR devraient tous pouvoir se joindre directement sur `10.1.2.0/24`, et l'interface utilisateur du tenant reste joignable à son IP virtuelle (`10.1.2.10`) sur le même réseau.
## Vérification
* Depuis le serveur VBR, confirmez que les deux workers apparaissent comme joignables/sains dans la console Veeam.
* Depuis chaque worker, confirmez qu'il peut joindre directement le serveur VBR et l'autre worker (par ex. `ping`) sans avoir besoin d'une route via la passerelle NAT du tenant.
* Confirmez que l'interface d'administration du tenant est joignable à son IP virtuelle depuis le même réseau que le serveur VBR.
* Dans l'interface du tenant, sous **Réseaux** > **Liste**, confirmez `Physique - Externe` et `ExterneL2` sont tous deux présents et en cours d'exécution.
## Dépannage
{% hint style="warning" %}
**Problèmes courants**
* **Le worker ne peut pas joindre le serveur VBR ni l'autre worker**: vérifiez `ExterneL2` (côté tenant) est sous tension et que son **Réseau d'interface** est `Physique - Externe`, pas le `Externe` réseau du fournisseur.
* **L'interface utilisateur du tenant est inaccessible à son IP virtuelle**: vérifiez **Appliquer les règles** a été exécuté à la fois sur le `Externe` réseau du fournisseur et sur le tableau de bord réseau du tenant après l'attribution de l'IP virtuelle.
* **Conflit de nom lors de la création du réseau de couche 2**: si VergeOS ne semble pas créer un `Externe` réseau correspondant à l'intérieur du tenant, c'est probablement parce que le tenant possède déjà un réseau par défaut portant ce nom. Créez manuellement le réseau destiné au worker (Étape 4) sous un nom différent, en utilisant `Physique - Externe` comme interface.
* **Conflits d'IP du worker**: vérifiez que l'IP statique définie dans le worker Veeam ne se trouve pas dans la plage DHCP du réseau Externe et ne soit pas en conflit avec une autre IP statique/virtuelle déjà utilisée sur ce sous-réseau.
{% endhint %}
## Déploiements plus complexes
La topologie de ce guide est conçue pour faire fonctionner Veeam rapidement — un domaine de couche 2 plat, aucune règle de pare-feu — et fonctionne bien pour les laboratoires, les preuves de concept et les petits environnements de production. Des environnements plus grands ou plus sensibles en matière de sécurité peuvent nécessiter :
* **Un réseau de sauvegarde dédié.** Au lieu d'étendre le `Externe` réseau principal, créez un VLAN séparé pour le trafic de sauvegarde et faites-le passer dans chaque tenant sous forme de [réseau de couche 2 de tenant](/run-the-platform/tenants/layer-2-networks.md). Cela maintient les données de sauvegarde hors de votre réseau de production et vous permet de façonner ou de limiter ce trafic indépendamment.
* **Un accès routé avec des règles de pare-feu explicites.** Si l'extension d'un domaine de couche 2 partagé dans les tenants n'est pas acceptable — par exemple, en cas d'exigences strictes d'isolation des tenants — gardez chaque tenant derrière ses propres réseaux routés/NATés et créez des règles de pare-feu pour les ports spécifiques dont Veeam a besoin entre le serveur VBR, les workers et les référentiels. Voir [Ports](https://helpcenter.veeam.com/docs/vbr/userguide/uh_used_ports.html?ver=13) dans le Guide utilisateur Veeam pour la liste complète. Cela vous donne le contrôle le plus strict, au prix d'une maintenance de règles plus importante pour chaque tenant.
* **Infrastructure Veeam mise à l'échelle.** À mesure que le volume de sauvegarde augmente, Veeam prend en charge le passage au-delà du serveur VBR tout-en-un — référentiels de sauvegarde dédiés, serveurs passerelles et workers supplémentaires. Ce dimensionnement relève d'une décision de conception côté Veeam ; voir le [Guide utilisateur Veeam Backup & Replication](https://helpcenter.veeam.com/docs/vbr/userguide/universal_hypervisors.html?ver=13). Le principe réseau de ce guide continue de s'appliquer : chaque worker doit pouvoir joindre directement les composants entre lesquels il déplace des données.
## Documentation associée
* [l'intégration de Veeam avec VergeOS](/automate-protect-and-extend/integrations-and-apis/veeam.md)
* [Configurer les réseaux de couche 2 du tenant](/run-the-platform/tenants/layer-2-networks.md)
* [Attribution d'adresses IP externes à un tenant](/run-the-platform/tenants/assign-ip-to-tenant.md)
* [Comment créer un réseau externe](/knowledge-base/fr/networking/create-external-network.md)
* [Création d'un réseau interne de couche 2](/run-the-platform/networking/internal-layer2.md)
* [Vue d'ensemble du tenant](/run-the-platform/tenants/overview.md)
* [Guide utilisateur Veeam Backup & Replication — Hyperviseurs universels](https://helpcenter.veeam.com/docs/vbr/userguide/universal_hypervisors.html?ver=13)
* [Guide utilisateur Veeam Backup & Replication — Considérations et limites](https://helpcenter.veeam.com/docs/vbr/userguide/uh_limitations.html?ver=13)
---
# 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/knowledge-base/fr/backup-dr/veeam-worker-networking.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.