netcup Cloud VLAN einrichten: Private Server-Kommunikation ohne öffentliche IP

Mit mehreren VPS oder Root-Servern bei netcup stellt sich die Frage, wie Datenbank und Applikationsserver getrennt werden, ohne den Datenbank-Port öffentlich zu machen. Die Antwort ist das netcup Cloud VLAN Add-on: ein privater virtueller Ethernet-Switch über alle Ihre Server am gleichen Standort, der die interne Kommunikation im Rechenzentrum hält. Ein VLAN (Virtual LAN) ist ein logisch getrenntes Netzwerksegment, das sich wie ein eigener Switch verhält. Sie buchen das VLAN im Customer Control Panel (CCP), weisen es im Server Control Panel (SCP) jedem Server zu und konfigurieren das Interface unter Debian, Ubuntu (netplan) und systemd-networkd.

Voraussetzungen

1. netcup-Account mit mindestens zwei VPS oder Root-Servern (x86-64 oder ARM64) am gleichen Standort (z. B. beide in Nürnberg). Jede Servergröße genügt; CPU, RAM und Speicher richten sich nach den späteren Diensten
2. Root- oder sudo-Zugang auf allen beteiligten Servern
3. Cloud VLAN Add-on im CCP bestellt (auch die kostenlose „Free“-Variante muss explizit gebucht werden)
4. Grundkenntnisse Linux-Netzwerkkonfiguration (ip-Befehl, netplan oder /etc/network/interfaces)
5. Optional: keepalived für HA-Setup (apt install keepalived)

Schritt 1: Cloud VLAN im CCP buchen

Öffnen Sie customercontrolpanel.de, gehen Sie zu Produkte → Server-Erweiterungen, wählen Sie die Cloud-VLAN-Stufe und schließen Sie die Bestellung ab. Die Stufen nach Bandbreite:

Für Frontend und Datenbank auf zwei VPS reichen 100 Mbit/s meist; bei intensiver Replikation oder großen Backup-Transfers begrenzt die Bandbreite.

Verifizieren: Nach der Bestellung erscheint das Cloud VLAN in Ihrer Produktübersicht im CCP, und im SCP zeigt der Bereich Network den Button Add Cloud VLAN Interface. Notieren Sie den Namen bzw. die ID des VLANs, Sie benötigen ihn im nächsten Schritt.

Schritt 2: VLAN im SCP jedem Server zuweisen

Wiederholen Sie diesen Schritt für jeden Server im VLAN. Wählen Sie im Server Control Panel (servercontrolpanel.de) den Server und links Network.

1. Klicken Sie auf den Button „Add Cloud VLAN Interface“.
2. Wählen Sie im Dropdown das soeben gebuchte Cloud VLAN aus.
3. Wählen Sie als Treiber virtio (paravirtualisierter Treiber mit guter Leistung unter Linux).
4. Klicken Sie auf „Add Interface“.
5. Erscheint das Interface im Betriebssystem nicht (siehe Schritt 3), starten Sie den Server neu; bei ARM-Servern ist teils ein vollständiger Power-Zyklus (Aus, dann Ein) nötig.

Wiederholen Sie diese Schritte für alle weiteren Server, die in dasselbe VLAN eingebunden werden sollen.

Verifizieren: Im SCP steht unter „Network“ das neue Interface in der Liste. Auf dem Server selbst prüfen Sie mit ip a, ob das Interface erschienen ist.

Schritt 3: Interface-Namen im Betriebssystem ermitteln

Der Interface-Name hängt von Betriebssystem, Kernel und Server-Generation ab. Prüfen Sie ihn zuerst:

ip a
# Das neue Interface erscheint typischerweise als:
# eth1        – Debian mit älterer Nomenklatur
# ens6        – Ubuntu/Debian mit systemd predictable names
# enp2s1      – je nach PCI-Slot-Zuweisung

Merken Sie sich den exakten Interface-Namen und ersetzen Sie eth1 in allen folgenden Konfigurationsbeispielen entsprechend.

Verifizieren: ip a listet neben dem öffentlichen Interface ein zweites Interface mit eigener MAC-Adresse, aber noch ohne IP-Adresse.

Schritt 4a: Netzwerkkonfiguration unter Debian (interfaces)

Auf Debian-Systemen, die noch /etc/network/interfaces verwenden, legen Sie eine neue Konfigurationsdatei an:

# Datei anlegen: /etc/network/interfaces.d/vlan.cfg
auto eth1
iface eth1 inet static
    address 10.0.0.10
    netmask 255.255.255.0

Anschließend nur das neue Interface aktivieren. Ein Neustart des gesamten Netzwerkdienstes kann die laufende SSH-Verbindung unterbrechen:

sudo ifup eth1

Verifizieren: ip a show eth1 zeigt die konfigurierte IP-Adresse 10.0.0.10/24.

Schritt 4b: Netzwerkkonfiguration unter Ubuntu (netplan)

Ubuntu nutzt netplan. Bearbeiten Sie nie /etc/netplan/50-cloud-init.yaml, Cloud-Init überschreibt sie bei jedem Start. Legen Sie eine neue YAML-Datei mit höherem Präfix an:

# Datei anlegen: /etc/netplan/60-vlan.yaml
network:
  version: 2
  ethernets:
    eth1:
      dhcp4: false
      addresses:
        - 10.0.0.10/24

Damit Cloud-Init die Konfiguration nicht beim nächsten Reboot überschreibt, deaktivieren Sie die netzwerkbezogene Cloud-Init-Konfiguration einmalig:

echo 'network: {config: disabled}' | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Danach die Konfiguration anwenden:

sudo netplan apply

Verifizieren: ip a show eth1 zeigt 10.0.0.10/24. Mit sudo netplan try können Sie die Konfiguration vorab testen, bevor sie dauerhaft aktiviert wird.

Schritt 4c: Netzwerkkonfiguration mit systemd-networkd

Wer systemd-networkd als Netzwerkmanager nutzt, erstellt eine .network-Datei:

# Datei anlegen: /etc/systemd/network/10-vlan.network
[Match]
Name=eth1

[Network]
Address=10.0.0.10/24

Dienst neu starten:

sudo systemctl restart systemd-networkd

Verifizieren: networkctl status eth1 zeigt den Status „configured“ und die zugewiesene Adresse.

Schritt 5: Konnektivität zwischen den Servern testen

Sobald alle beteiligten Server eine VLAN-IP haben (im Beispiel Server 1 mit 10.0.0.10, Server 2 mit 10.0.0.20), testen Sie die Verbindung:

# Von Server 1 zu Server 2
ping 10.0.0.20

# MTU-Test (Standard 1500 Byte, kein Jumbo Frame nötig)
ping -M do -s 1472 10.0.0.20

Der Test mit -s 1472 prüft, ob Pakete voller Ethernet-Größe (1472 Byte Payload + 28 Byte IP/ICMP-Header = 1500 Byte) ohne Fragmentierung durchkommen; dann ist das VLAN korrekt konfiguriert.

Verifizieren: Sie sehen Ping-Antworten mit einer Latenz im einstelligen Millisekunden-Bereich – deutlich niedriger als über das öffentliche Internet.

Schritt 6: Firewall auf OS-Ebene konfigurieren

Die SCP-Firewall von netcup greift nicht für VLAN-Traffic. Ohne OS-seitige Firewall erreichen alle VLAN-Teilnehmer alle Ports, bei Datenbank-Servern ein ernstes Sicherheitsrisiko.

Das folgende iptables-Beispiel erlaubt MySQL nur über das VLAN-Interface und sperrt es auf allen anderen Interfaces:

# Nur VLAN-Interface auf Port 3306 (MySQL) erlauben
sudo iptables -A INPUT -i eth1 -p tcp --dport 3306 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3306 -j DROP

# Für PostgreSQL entsprechend Port 5432, für Redis Port 6379

Damit die Regeln einen Neustart überleben, speichern Sie sie mit dem Paket iptables-persistent:

sudo apt install iptables-persistent
sudo netfilter-persistent save

Alternativ nutzen Sie ufw mit Interface-Bindung oder nftables. Die vollständige Server-Härtung zeigt VPS absichern und härten: UFW, SSH-Keys und Fail2Ban.

Verifizieren: sudo iptables -L INPUT -v -n zeigt die ACCEPT-Regel für eth1 vor der DROP-Regel. Ein Verbindungsversuch auf Port 3306 über die öffentliche IP läuft ins Leere, über die VLAN-IP funktioniert er.

Vergleich: öffentliche IP vs. Cloud VLAN

Exkurs: Keepalived HA-Cluster über das VLAN

Fortgeschritten: Hochverfügbarkeit mit zwei VPS und einer virtuellen IP (VIP). Server 1 hält die VIP; fällt er aus, übernimmt Server 2. Grundprinzip:

# /etc/keepalived/keepalived.conf (Server 1 – MASTER)
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass GEHEIM01
    }
    virtual_ipaddress {
        10.0.0.100/24
    }
}

Auf Server 2 setzen Sie state BACKUP und priority 90. Bei auth_type PASS wertet keepalived nur die ersten 8 Zeichen von auth_pass aus; ersetzen Sie GEHEIM01 auf beiden Servern durch dasselbe eigene Kennwort. Die VIP 10.0.0.100 liegt dann immer auf dem aktiven Master. Den vollständigen Aufbau mit Failover-IP zeigt Hochverfügbarkeit auf netcup: Zwei VPS mit Keepalived, Failover-IP und Cloud-vLAN.

Cloud vLAN Only – Server ganz ohne öffentliche IP

Ab Server-Generation 12 bietet netcup beim Setup „Cloud vLAN Only“: Der Server erhält kein öffentliches Interface und ist nur über das VLAN oder die VNC-Konsole im SCP erreichbar, sinnvoll für reine Datenbank-Server oder interne Micro-Services.

Wichtig: Diese Entscheidung ist irreversibel; eine öffentliche IPv4 oder IPv6 lässt sich nicht nachträglich hinzufügen.

Troubleshooting / Typische Fehler

Interface erscheint nicht nach dem Neustart

Führen Sie einen vollständigen Power-Zyklus durch: Server im SCP ausschalten, kurz warten, einschalten. Ein normaler Reboot reicht bei ARM-Servern manchmal nicht.

ping zwischen den Servern schlägt fehl

Prüfen Sie mit ip a, ob das Interface auf beiden Seiten mit den richtigen IPs konfiguriert ist, ob beide Server am gleichen Standort stehen (Nürnberg und Wien teilen kein VLAN) und ob iptables-Regeln ICMP blockieren.

Ubuntu: Netzwerkkonfiguration wird nach Neustart überschrieben

Cloud-Init überschreibt /etc/netplan/50-cloud-init.yaml bei jedem Start. Nutzen Sie eine Datei mit höherem Präfix (z. B. 60-vlan.yaml) und deaktivieren Sie die Netzwerk-Konfiguration von Cloud-Init wie in Schritt 4b.

Interface-Name weicht von eth1 ab

Predictable network interface names von systemd richten sich nach dem PCI-Slot (ens6, enp2s1). Ein falscher Name in der Konfiguration lässt das Interface ohne Fehlermeldung unkonfiguriert; prüfen Sie ihn vorher mit ip a.

Bandbreite reicht nicht aus

Das Free-Tier ist auf 100 Mbit/s begrenzt; bei Replikation, großen Backups oder Docker-Layer-Pulls wählen Sie eine höhere Stufe (Tabelle in Schritt 1).

Häufige Fragen

Gibt es eine kostenfreie Cloud-VLAN-Variante?

„Cloud vLAN Free“ mit 100 Mbit/s ist kostenfrei, muss aber explizit im CCP bestellt werden.

Wie viele Server kann ich in ein VLAN einbinden?

Eine offizielle Obergrenze ist nicht dokumentiert. Jeder Server am Standort braucht eine eigene, manuell vergebene IP im Subnetz.

Kann ich einen Server in mehreren VLANs gleichzeitig betreiben?

Ja. Im SCP fügen Sie mehrere VLAN-Interfaces hinzu (z. B. eth1 für VLAN-A, eth2 für VLAN-B), etwa für getrennte Backup- und Applikationsnetze.

Wie sichere ich die Kommunikation im VLAN ab?

Das VLAN ist vom öffentlichen Internet isoliert. Ergänzend empfehlen sich iptables-Regeln für sensible Ports (MySQL 3306, PostgreSQL 5432, Redis 6379), fail2ban und bei kritischen Daten Verschlüsselung (TLS auch intern oder ein WireGuard-Overlay), siehe WireGuard-VPN für Homeoffice und Standortvernetzung einrichten.

Was passiert, wenn ich das VLAN-Add-on kündige?

Das Interface wird aus dem SCP entfernt, Dienste auf privaten VLAN-IPs verlieren die Verbindung. Passen Sie Datenbankverbindungen, Firewall-Regeln und Applikationskonfigurationen vor der Kündigung an.

Funktioniert das Cloud VLAN auch zwischen verschiedenen Standorten?

Nein, nur am exakt gleichen Standort. Standortübergreifend brauchen Sie ein VPN-Overlay wie WireGuard.

Fazit

Das netcup Cloud VLAN hält Backend-Dienste mehrerer Server am gleichen Standort vom öffentlichen Internet fern. Die Einrichtung dauert rund 20 Minuten: VLAN im CCP buchen, im SCP je Server ein Interface hinzufügen, ggf. neu starten, IP im Betriebssystem setzen. Der einzige echte Stolperstein ist die für VLAN-Traffic wirkungslose SCP-Firewall; ohne OS-Firewall ist die Datenbank für alle VLAN-Teilnehmer offen. Die iptables-Regeln aus Schritt 6 beheben das.

Weiterführende Anleitungen und Quellen

1. Das netcup Server Control Panel (SCP) erklärt: Alle Funktionen im Überblick
2. Hochverfügbarkeit auf netcup: Zwei VPS mit Keepalived, Failover-IP und Cloud-vLAN
3. netcup SCP-Firewall einrichten: Policies, Regeln und Zusammenspiel mit ufw
4. VPS absichern und härten: Anleitung mit UFW, SSH-Keys und Fail2Ban
5. VLANs verstehen und auf einem Managed Switch einrichten
6. Quelle: netcup Helpcenter: Assigning Cloud VLAN
7. Quelle: netcup Helpcenter: Selecting Network Configuration
8. Quelle: netcup Community: High Availability Cluster with Keepalived