> 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/de/backup-dr/veeam-worker-networking.md).

# Konfigurieren des Netzwerkzugriffs für Veeam Backup- & Replikation-Worker

## Überblick

Veeam Backup & Replication (VBR) stellt bereit **Worker** — zusätzliche Linux-basierte VMs, die Backup-Workloads verarbeiten und Backup-Daten übertragen — bei Bedarf. In diesem Leitfaden ist der **Anbieter** ist das Root-System — das oberste VergeOS-System (selbst der Root-Mandant), das Ihre Mandanten hostet und VBR ausführt. Der **VBR-Server** (`veeamHost`) ist eine einzelne VM, die beide Kernkomponenten von Veeam hostet: den **Backup-Server** (der Verwaltungskern der Backup-Infrastruktur) und ein **Backup-Repository** (der Speicherort, an dem die Backups abgelegt werden). Wenn VBR Workloads sowohl im Provider als auch innerhalb eines Mandanten schützt, müssen die Worker, die es auf beiden Seiten bereitstellt, einander direkt erreichen können — ebenso den VBR-Server, auf dem sich das Backup-Repository befindet — ohne durch das NAT des Mandanten blockiert oder über zusätzliche Hops geroutet zu werden.

Die Integration selbst — das VergeOS-oVirt-engine-Paket, das Systeme und Mandanten in Veeam als **VergeOS-Manager**, sowie die Versionsanforderungen — werden behandelt in [Veeam-Integration mit VergeOS](/automate-protect-and-extend/integrations-and-apis/veeam.md). Dieser Leitfaden behandelt nur die *Netzwerk* die die Worker benötigen: den **Datenpfad** gezeigt in der [Beispieltopologie](#example-topology) unten — das flache External-Netzwerk, das die Worker verwenden, um Backup-Verkehr zu übertragen, sobald sie bereitgestellt sind.

Das zugrunde liegende Modell ist einfach:

* **Nur Provider-Workloads:** Verbinden Sie sowohl den VBR-Server als auch seinen Worker direkt mit dem `Extern` Netzwerk des Providers. Das ist das gesamte Setup — alles teilt sich bereits eine Layer-2-Domäne, sodass sich VBR-Server und Worker direkt erreichen, ohne manuell erstellte Firewall-Regeln.
* **Mandanten-Workloads:** Erweitern Sie dasselbe `Extern` Netzwerk auf Layer 2 in jeden Mandanten, und stellen Sie dann innerhalb des Mandanten einen Worker im erweiterten Netzwerk bereit. Das ist der einfachste Weg zum Mandanten-Backup — er gibt jeder Komponente den Zugriff, den sie benötigt, ohne dass Firewall-Regeln manuell erstellt werden müssen.

Dieses flache Design mit gemeinsamem Layer 2 ist absichtlich der einfachste Weg, Veeam auf VergeOS zum Laufen zu bringen. Wenn Ihre Umgebung eine stärkere Mandantenisolierung oder ein dediziertes Backup-Netzwerk benötigt, siehe [Komplexere Bereitstellungen](#more-complex-deployments) am Ende dieses Leitfadens.

Dieser Leitfaden behandelt den vollständigen Mandantenfall, bei dem der VBR-Server des Providers und beide Worker auf demselben **Layer-2-Broadcast-Domain** liegen, während die Benutzeroberfläche des Mandanten weiterhin in diesem selben Netzwerk erreichbar bleibt. Er verwendet die [Tenant-Layer-2-Netzwerke](/run-the-platform/tenants/layer-2-networks.md) Funktion von VergeOS, einen Mandanten direkt auf das `Extern` Netzwerk des Providers zu brücken, anstatt den Mandantenverkehr über NAT zu routen. Für den reinen Provider-Fall siehe [Bereitstellung nur für den Provider](#provider-only-deployment-no-tenants) unten.

{% hint style="info" %}
**Wichtige Punkte**

* Des Providers `Extern` Netzwerk wird mittels eines Tenant-Layer-2-Netzwerks direkt an den Mandanten durchgereicht — keine VLAN-Kennzeichnung ist erforderlich, wenn Sie das primäre/flache External-Netzwerk durchreichen.
* Da sich jede Komponente in derselben External-Layer-2-Domäne befindet, **müssen keine Firewall-Regeln manuell erstellt werden** — das flache Netzwerk bietet dem VBR-Server und den Workern den Zugriff, den sie benötigen.
* VBR weist die IP-Adressen der Worker selbst zu, wenn es jeden Worker bereitstellt. Diese werden **nicht** von VergeOS-DHCP verwaltet — wählen Sie Adressen außerhalb des DHCP-Bereichs Ihres External-Netzwerks.
* Der Mandant erhält weiterhin seine eigene routbare UI-Adresse über eine **Virtuelle IP**, unabhängig vom Layer-2-Durchschleifen.
  {% endhint %}

## Bereitstellung nur für den Provider (keine Mandanten)

Wenn Sie nur Workloads im Provider (dem Root-System) schützen und keine Mandanten beteiligt sind, reduziert sich dies auf ein viel einfacheres Setup — lassen Sie einfach die Mandanten-Teile weg:

1. Verbinden Sie den **VBR-Server** zum `Extern` Netzwerk mit einer statischen IP (siehe [Schritt 1](#step-1-deploy-the-vbr-server-on-the-providers-external-network)).
2. Stellen Sie den **Provider-seitigen Worker** auf demselben `Extern` Netzwerk mit einer statischen IP außerhalb des DHCP-Bereichs (siehe [Schritt 5](#step-5-deploy-the-workers)).

Das ist alles. Schritte 2–4 existieren nur, um das External-Netzwerk in einen Mandanten zu erweitern, daher können Sie sie vollständig überspringen. Alles teilt sich bereits die Layer-2-Domäne des External-Netzwerks, sodass VBR-Server und Worker direkt miteinander kommunizieren können, ohne manuell erstellte Firewall-Regeln.

Wenn später Mandanten hinzukommen, erweitern Sie dasselbe `Extern` Netzwerk in jeden von ihnen mit einem Tenant-Layer-2-Netzwerk und stellen Sie dort einen Worker bereit — das ist der Mandanten-Workflow, der im Rest dieses Leitfadens dokumentiert ist.

## Beispieltopologie

| Rolle                    | Ort                      | Netzwerk                                        | Beispiel-IP                                |
| ------------------------ | ------------------------ | ----------------------------------------------- | ------------------------------------------ |
| VBR-Server (`veeamHost`) | Provider                 | `Extern`                                        | `10.1.2.214` (statisch)                    |
| Mandanten-UI             | Vom Provider zugewiesen  | `Extern` (Virtuelle IP im Besitz des Mandanten) | `10.1.2.10`                                |
| Provider-seitiger Worker | Provider                 | `Extern`                                        | `10.1.2.30` (statisch, von VBR festgelegt) |
| Mandantenseitiger Worker | Mandant (`VeeamTenant1`) | `ExternalL2`                                    | `10.1.2.13` (statisch, von VBR festgelegt) |

```mermaid
graph TB
    subgraph Provider["Provider (Rootsystem) — External 10.1.2.0/24"]
        VBR["veeamHost — VBR-Server<br/>10.1.2.214"]
        PWorker["Provider-seitiger Worker<br/>10.1.2.30"]
    end
    subgraph Tenant["Mandant: VeeamTenant1"]
        PhysExt["Physical - External<br/>(automatisch erstellt durch Tenant-Layer-2-Netzwerk)"]
        ExtL2["ExternalL2<br/>External-Netzwerk, ungetaggt, IP-Adress-Typ: None"]
        TWorker["Mandantenseitiger Worker<br/>10.1.2.13"]
        PhysExt --> ExtL2
        ExtL2 --> TWorker
    end

    VBR ---|"Tenant-Layer-2-Netzwerk<br/>(gleiche L2-Broadcast-Domäne)"| PhysExt
    VBR <-.->|"direkt, kein NAT"| PWorker
    PWorker <-.->|"direkt, kein NAT"| TWorker
    VBR <-.->|"direkt, kein NAT"| TWorker
    TenantUIVIP["Mandanten-UI<br/>Virtuelle IP 10.1.2.10<br/>(im Besitz von VeeamTenant1)"]
    Provider --- TenantUIVIP

    style Provider fill:#e8f5e9,stroke:#2e7d32
    style Tenant fill:#fff3e0,stroke:#e65100
```

Da sich alles im selben Subnetz befindet, können der VBR-Server und beide Worker direkt miteinander kommunizieren, und die Admin-UI des Mandanten bleibt unter ihrer eigenen IP in diesem selben Netzwerk erreichbar — keine Portweiterleitung oder zusätzlichen Routen, die gepflegt werden müssen.

## Anforderungen

**Immer:**

* Der [Veeam-Integration mit VergeOS](/automate-protect-and-extend/integrations-and-apis/veeam.md) vorhanden — Versionsanforderungen erfüllt, das oVirt-engine-Paket aktiviert und das System dem Veeam-Bestand als ein **VergeOS-Manager**
* Cluster-Admin-Zugriff auf Provider-Ebene
* Des Providers `Extern` Netzwerk bereits konfiguriert und läuft
* Veeam Backup & Replication als VM im Provider bereitgestellt — in diesem Leitfaden eine einzelne **VBR-Server** die sowohl den Backup-Server als auch ein Backup-Repository hostet
* Lesen Sie Veeams [Überlegungen und Einschränkungen](https://helpcenter.veeam.com/docs/vbr/userguide/uh_limitations.html?ver=13) dazu, was die Integration unterstützt und nicht unterstützt, bevor Sie Ihre Bereitstellung planen

**Nur Mandantenpfad:**

* Ein vorhandener Mandant (dieser Leitfaden verwendet `VeeamTenant1` als Beispiel), der in Veeam als eigener VergeOS-Manager hinzugefügt wurde

## Schritt 1: Den VBR-Server im External-Netzwerk des Providers bereitstellen

Stellen Sie Ihren Veeam Backup & Replication-Server als VM mit einer NIC bereit, die direkt mit dem `Extern` Netzwerk verbunden ist, und geben Sie ihm eine statische IP in diesem Subnetz (z. B. `10.1.2.214`).

{% hint style="info" %}
Diese VM ist eine standardmäßige VergeOS-VM-Konfiguration — hier ist kein spezielles Networking erforderlich. Sie muss lediglich im selben `Extern` Netzwerk sitzen, das Sie in den nächsten Schritten auf den Mandanten brücken werden.
{% endhint %}

## Schritt 2: Dem Mandanten eine UI-Virtual-IP im External-Netzwerk zuweisen

Dadurch bleibt die Admin-UI des Mandanten im selben Netzwerk wie der VBR-Server erreichbar, unabhängig vom später konfigurierten Layer-2-Durchschleifen.

1. Navigieren Sie zum **Extern** Netzwerk-Dashboard des Providers.
2. Klicken Sie **IP-Adressen** im linken Menü und dann **Neu**.
3. **Typ**: `Virtuelle IP`
4. **IP-Adresse**: die Adresse, die die Mandanten-UI verwenden soll (z. B. `10.1.2.10`)
5. **Besitzer-Typ**: `Mandant`
6. **Besitzer**: wählen Sie Ihren Mandanten aus (z. B. `VeeamTenant1`)
7. Klicken Sie **Absenden**.
8. Von der **Extern** Netzwerk-Dashboard auf **Regeln anwenden**.
9. Navigieren Sie zum Netzwerk-Dashboard des Mandanten (**Netzwerke** > **Dashboard** > **Mandanten** > doppelklicken Sie auf den Mandanten) und klicken Sie auf **Regeln anwenden** auch dort.

Vollständige Details: [Zuweisen externer IP-Adressen zu einem Mandanten](/run-the-platform/tenants/assign-ip-to-tenant.md).

## Schritt 3: Die Tenant-Layer-2-Netzwerkverbindung erstellen

Dadurch wird der Mandant direkt auf das `Extern` Netzwerk des Providers auf Layer 2 gebrückt.

1. Navigieren Sie im oberen Menü zu **Mandanten** > **Liste**.
2. Klicken Sie auf den Mandantennamen (z. B. `VeeamTenant1`) um das Mandanten-Dashboard zu öffnen.
3. Erweitern Sie in der linken Navigation **Netzwerk** und klicken Sie auf **Layer2-Netzwerke**.
4. Klicken Sie **Neu**.
5. **Netzwerk**: wählen Sie das `Extern` Netzwerk des Providers aus.
6. Schalten Sie **Aktiviert** auf EIN (blau).
7. Klicken Sie **Absenden**.

VergeOS stellt automatisch eine NIC auf dem Knoten des Mandanten bereit, die mit `Extern`, plus ein **Physical - External** Netzwerk innerhalb des Mandanten, das daran angeschlossen wird.

{% hint style="warning" %}
**Das automatisch erstellte Netzwerk nicht taggen**

Wenn VergeOS innerhalb des Mandanten automatisch ein passendes External-Netzwerk erstellt, lassen Sie es ungetaggt — die Schnittstelle befindet sich bereits im richtigen Netzwerk. Siehe [Tenant-Layer-2-Netzwerke konfigurieren](/run-the-platform/tenants/layer-2-networks.md) für die vollständige Erklärung der automatisch erstellten Komponenten.
{% endhint %}

Vollständige Details und Schritte zum Entfernen/Aufräumen: [Tenant-Layer-2-Netzwerke konfigurieren](/run-the-platform/tenants/layer-2-networks.md).

## Schritt 4: Das mandantenseitige External-Netzwerk für den Worker-Anschluss erstellen

Wenn Ihr Mandant bereits über ein eigenes Standardnetzwerk mit dem Namen `Extern` (wird für normalen ausgehenden/NAT-Zugriff verwendet), erstellt VergeOS kein zweites Netzwerk mit demselben Namen — daher fügen Sie manuell eines zusätzlich zu dem automatisch erstellten `Physical - External` Backend-Netzwerk unter einem anderen Namen hinzu (dieses Beispiel verwendet `ExternalL2`).

1. Melden Sie sich beim **Tenant-UI**.
2. Navigieren Sie zu **Netzwerke** > **Neues externes**.
3. **Name**: `ExternalL2`
4. **Layer-2-Typ**: `Keine` (dies ist ein reines Durchschleifen — die VLAN-/Tag-Kennzeichnung, falls vorhanden, wird bereits von der Schnittstelle Physical - External gehandhabt)
5. **Interface-Netzwerk**: `Physical - External`
6. **IP-Adressart**: `Keine`

{% hint style="info" %}
**Warum IP-Adress-Typ: None**

Veeam weist die IP-Adresse des Workers selbst zu und verwaltet sie, wenn es die Worker-VM bereitstellt. Wenn IP Address Type auf `Keine` bleibt VergeOS aus dieser Adressierung heraus — es ist ein reines Layer-2-Durchschleifen, ähnlich wie [interne Layer-2-Netzwerke](/run-the-platform/networking/internal-layer2.md) funktionieren, wenn ein Dritter die IP-Adressierung verwaltet.
{% endhint %}

7. Klicken Sie **Absenden**, dann **Einschalten** das Netzwerk.

Die vollständige Feldreferenz zur Erstellung externer Netzwerke (VLAN-Optionen, statische IP, Routing-Regeln) finden Sie in [So erstellen Sie ein externes Netzwerk](/knowledge-base/de/networking/create-external-network.md).

## Schritt 5: Die Worker bereitstellen

Stellen Sie die Worker innerhalb von Veeam mithilfe der VergeOS-Integration bereit — VergeOS benötigt hier keine zusätzliche Konfiguration über die oben erstellten Netzwerke hinaus. Siehe [die Dokumentation von Veeam](https://helpcenter.veeam.com/docs/vbr/userguide/uh_workers_add.html?ver=13) für die genauen Schritte zur Worker-Bereitstellung für Ihre Veeam-Version.

* **Provider-seitiger Worker**: an das Netzwerk des Providers anschließen `Extern` Netzwerk verbinden. Geben Sie ihm eine statische IP außerhalb des DHCP-Bereichs Ihres External-Netzwerks (in diesem Beispiel vergibt das External-Netzwerk `10.1.2.200`–`10.1.2.201` per DHCP, daher `10.1.2.30` ist eine sichere statische Wahl).
* **Mandantenseitiger Worker**: an das Netzwerk des Mandanten anschließen `ExternalL2` Netzwerk. Verwenden Sie erneut eine statische IP außerhalb des DHCP-Bereichs des Providers (z. B. `10.1.2.13`).

{% hint style="warning" %}
**DHCP-Bereichskonflikte vermeiden**

Da es sich um statische Adressen handelt, die im Veeam-Worker festgelegt werden (nicht von VergeOS-DHCP angefordert), prüfen Sie sorgfältig, dass sie nicht mit dem DHCP-Bereich des External-Netzwerks oder anderen statisch zugewiesenen Adressen in diesem Subnetz kollidieren.
{% endhint %}

Sobald beide Worker laufen, sollten sie und der VBR-Server sich alle direkt auf `10.1.2.0/24`, und die Mandanten-UI bleibt unter ihrer virtuellen IP erreichbar (`10.1.2.10`) im selben Netzwerk.

## Verifizierung

* Bestätigen Sie vom VBR-Server aus, dass beide Worker in der Veeam-Konsole als erreichbar/gesund angezeigt werden.
* Bestätigen Sie von jedem Worker aus, dass er den VBR-Server und den anderen Worker direkt erreichen kann (z. B. `ping`) ohne eine Route über das NAT-Gateway des Mandanten zu benötigen.
* Bestätigen Sie, dass die Admin-UI des Mandanten unter ihrer virtuellen IP aus demselben Netzwerk wie der VBR-Server erreichbar ist.
* In der Mandanten-UI, unter **Netzwerke** > **Liste**, bestätigen Sie `Physical - External` und `ExternalL2` sind beide vorhanden und laufen.

## Fehlerbehebung

{% hint style="warning" %}
**Häufige Probleme**

* **Worker kann den VBR-Server oder den anderen Worker nicht erreichen**: bestätigen Sie `ExternalL2` (mandantenseitig) eingeschaltet ist und sein **Interface-Netzwerk** ist `Physical - External`, nicht das eigene Standard- `Extern` Netzwerk des Providers aus.
* **Mandanten-UI unter ihrer virtuellen IP nicht erreichbar**: bestätigen Sie **Regeln anwenden** wurde sowohl im Netzwerk des Providers als auch im `Extern` Netzwerk-Dashboard des Mandanten ausgeführt, nachdem die virtuelle IP zugewiesen wurde.
* **Namenskonflikt beim Erstellen des Layer-2-Netzwerks**: Wenn VergeOS anscheinend kein passendes `Extern` Netzwerk innerhalb des Mandanten erstellt, liegt das wahrscheinlich daran, dass der Mandant bereits ein Standardnetzwerk mit diesem Namen hat. Erstellen Sie das dem Worker zugewandte Netzwerk manuell (Schritt 4) unter einem anderen Namen, unter Verwendung von `Physical - External` als Schnittstelle.
* **Worker-IP-Konflikte**: überprüfen Sie, dass die im Veeam-Worker festgelegte statische IP nicht in den DHCP-Bereich des External-Netzwerks fällt und nicht mit einer anderen bereits in diesem Subnetz verwendeten statischen/virtuellen IP kollidiert.
  {% endhint %}

## Komplexere Bereitstellungen

Die Topologie in diesem Leitfaden soll Veeam schnell zum Laufen bringen — eine flache Layer-2-Domäne, keine Firewall-Regeln — und eignet sich gut für Labore, Proofs of Concept und kleinere Produktionsumgebungen. Größere oder sicherheitskritischere Umgebungen können Folgendes erfordern:

* **Ein dediziertes Backup-Netzwerk.** Anstatt das primäre `Extern` Netzwerk zu erweitern, erstellen Sie ein separates VLAN für den Backup-Verkehr und reichen Sie es in jeden Mandanten als VLAN-getaggtes [Tenant-Layer-2-Netzwerk](/run-the-platform/tenants/layer-2-networks.md). Dadurch bleibt der Backup-Datenverkehr aus Ihrem Produktionsnetzwerk heraus, und Sie können diesen Verkehr unabhängig formen oder begrenzen.
* **Gerouteter Zugriff mit expliziten Firewall-Regeln.** Wenn das Erweitern einer gemeinsamen Layer-2-Domäne in Mandanten nicht akzeptabel ist — zum Beispiel bei strengen Anforderungen an die Mandantenisolierung — halten Sie jeden Mandanten hinter seinen eigenen gerouteten/NAT-geschützten Netzwerken und erstellen Sie Firewall-Regeln für die spezifischen Ports, die Veeam zwischen VBR-Server, Workern und Repositories benötigt. Siehe [Ports](https://helpcenter.veeam.com/docs/vbr/userguide/uh_used_ports.html?ver=13) in der Veeam-Benutzeranleitung für die vollständige Liste. Dies gibt Ihnen die strengste Kontrolle auf Kosten eines höheren Wartungsaufwands für Regeln pro Mandant.
* **Skalierte Veeam-Infrastruktur.** Wenn das Backup-Volumen wächst, unterstützt Veeam den Übergang über den All-in-One-VBR-Server hinaus — dedizierte Backup-Repositories, Gateway-Server und zusätzliche Worker. Diese Dimensionierung ist eine Designentscheidung auf Veeam-Seite; siehe die [Veeam Backup & Replication-Benutzerhandbuch](https://helpcenter.veeam.com/docs/vbr/userguide/universal_hypervisors.html?ver=13). Das in diesem Leitfaden beschriebene Netzwerkprinzip gilt weiterhin: Jeder Worker benötigt direkte Erreichbarkeit zu den Komponenten, zwischen denen er Daten überträgt.

## Verwandte Dokumentation

* [Veeam-Integration mit VergeOS](/automate-protect-and-extend/integrations-and-apis/veeam.md)
* [Tenant-Layer-2-Netzwerke konfigurieren](/run-the-platform/tenants/layer-2-networks.md)
* [Zuweisen externer IP-Adressen zu einem Mandanten](/run-the-platform/tenants/assign-ip-to-tenant.md)
* [So erstellen Sie ein externes Netzwerk](/knowledge-base/de/networking/create-external-network.md)
* [Erstellen eines internen Layer-2-Netzwerks](/run-the-platform/networking/internal-layer2.md)
* [Mandantenübersicht](/run-the-platform/tenants/overview.md)
* [Veeam Backup & Replication-Benutzerhandbuch — Universelle Hypervisoren](https://helpcenter.veeam.com/docs/vbr/userguide/universal_hypervisors.html?ver=13)
* [Veeam Backup & Replication-Benutzerhandbuch — Überlegungen und Einschränkungen](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/de/backup-dr/veeam-worker-networking.md?ask=<question>&goal=<endgoal>
```

`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.