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

Wer mehrere VPS oder Root-Server bei netcup betreibt, steht früher oder später vor der Frage: Wie lassen sich Datenbank und Applikationsserver sauber trennen, ohne dass der Datenbank-Port öffentlich erreichbar ist? Die Antwort ist das netcup Cloud VLAN Add-on. Es spannt einen privaten virtuellen Ethernet-Switch über alle deine Server am gleichen Standort – die interne Kommunikation bleibt vollständig im Rechenzentrum, ohne Umweg über das öffentliche Internet. Diese Anleitung zeigt dir, wie du das VLAN im CCP buchst, im SCP jedem Server zuweist und das neue Interface unter Debian, Ubuntu (netplan) und systemd-networkd konfigurierst.

Voraussetzungen

• Netcup-Account mit mindestens zwei VPS oder Root-Servern am gleichen Standort (z. B. beide in Nürnberg)
• Root- oder sudo-Zugang auf allen beteiligten Servern
• Cloud VLAN Add-on im CCP bestellt (auch die kostenlose „Free"-Variante muss explizit gebucht werden)
• Grundkenntnisse Linux-Netzwerkkonfiguration (ip-Befehl, netplan oder /etc/network/interfaces)
• Optional: keepalived für HA-Setup (apt install keepalived)

Schritt 1: Cloud VLAN im CCP buchen

Öffne das Customer Control Panel unter customercontrolpanel.de und navigiere zu Produkte → Server-Erweiterungen. Wähle dort das gewünschte Cloud VLAN-Tier aus und schließe die Bestellung ab. Die folgende Tabelle gibt dir einen Überblick über die verfügbaren Stufen:

Produkt	Preis/Monat (inkl. MwSt.)	Bandbreite	Empfehlung
Cloud vLAN Free	0,00 EUR	100 Mbit/s	Tests, kleine Setups
Cloud vLAN Starter	4,99 EUR	250 Mbit/s	Kleine Cluster, 2–3 VPS
Cloud vLAN Medium	7,98 EUR	500 Mbit/s	Mittlere Produktivumgebungen
Cloud vLAN Giga	12,98 EUR	1 Gbit/s	Größere Cluster, DB-Replikation
Cloud vLAN 2,5 Gbit/s	20,50 EUR	2,5 Gbit/s	High-Performance-Cluster

Das Free-Tier ist dauerhaft kostenlos und sofort nach der Bestellung verfügbar. Für eine einfache Frontend/Datenbank-Trennung mit zwei VPS ist es vollkommen ausreichend. Bei intensiver Datenbankreplikation oder großen Backup-Transfers lohnt sich der Wechsel auf Starter oder Medium.

Verifizieren: Nach der Bestellung erscheint das Cloud VLAN in deiner Produktübersicht im CCP. Notiere dir den Namen bzw. die ID des VLANs – du benötigst ihn im nächsten Schritt.

Schritt 2: VLAN im SCP jedem Server zuweisen

Dieser Schritt muss für jeden Server wiederholt werden, der am VLAN teilnehmen soll. Öffne das Server Control Panel unter servercontrolpanel.de, wähle den ersten Server aus und klicke in der linken Navigation auf Network.

1. Klicke auf den Button „Add Cloud VLAN Interface".
2. Wähle im Dropdown das soeben gebuchte Cloud VLAN aus.
3. Wähle als Treiber virtio (empfohlen für beste Performance und Kompatibilität).
4. Klicke auf „Add Interface".
5. Starte den Server neu. Bei ARM-Servern reicht ein einfacher Reboot manchmal nicht – führe in diesem Fall einen vollständigen Power-Zyklus (Ausschalten, dann Einschalten) durch.

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

Verifizieren: Nach dem Neustart siehst du im SCP unter „Network" das neue Interface in der Liste. Auf dem Server selbst kannst du mit ip a prüfen, ob das Interface erschienen ist.

Schritt 3: Interface-Namen im Betriebssystem ermitteln

Je nach Betriebssystem, Kernel-Version und Server-Generation trägt das neue Interface unterschiedliche Namen. Prüfe daher immer zuerst, wie es bei dir heißt:

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

Merke dir den exakten Interface-Namen und ersetze eth1 in allen folgenden Konfigurationsbeispielen entsprechend.

Schritt 4a: Netzwerkkonfiguration unter Debian (interfaces)

Auf Debian-Systemen, die noch /etc/network/interfaces verwenden, legst du 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 den Netzwerkdienst neu starten:

sudo systemctl restart networking

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

Schritt 4b: Netzwerkkonfiguration unter Ubuntu (netplan)

Ubuntu-Server nutzen netplan. Wichtig: Bearbeite niemals die Datei /etc/netplan/50-cloud-init.yaml direkt – Cloud-Init überschreibt sie bei jedem Systemstart. Lege stattdessen 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, deaktivierst du 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 netplan --debug try kannst du 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), testest du 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 MTU-Test mit -s 1472 prüft, ob Pakete der vollen Ethernet-Nutzdatengröße (1472 Byte Payload + 28 Byte IP/ICMP-Header = 1500 Byte) ohne Fragmentierung durchkommen. Wenn dieser Test funktioniert, ist das VLAN korrekt konfiguriert.

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

Schritt 6: Firewall auf OS-Ebene konfigurieren

Ein häufiges Missverständnis: Die SCP-Firewall von netcup greift nicht für VLAN-Traffic. Ein Server ohne OS-seitige Firewall-Regeln lässt alle VLAN-Teilnehmer ungehindert auf alle Ports – das ist besonders 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, speichere sie mit dem Paket iptables-persistent:

sudo apt install iptables-persistent
sudo netfilter-persistent save

Alternativ kannst du ufw mit Interface-Bindung nutzen oder nftables einsetzen. Die Anleitung VPS absichern und härten: UFW, SSH-Keys und Fail2Ban zeigt dir den vollständigen Prozess zur Server-Härtung.

Vergleich: öffentliche IP vs. Cloud VLAN

Eigenschaft	Öffentliche IP	Cloud VLAN (privat)
Erreichbarkeit	Weltweit	Nur verbundene Server (gleicher Standort)
IP-Vergabe	Von netcup zugeteilt	Manuell (RFC 1918)
SCP-Firewall greift	Ja	Nein
Kosten	Im Server-Tarif enthalten	Separates Add-on (ab 0 EUR)
Latenz	Standard	Minimal (internes Layer 2)
Typischer Einsatz	Web, SSH, APIs	DB, Cluster, Backend-Dienste

Exkurs: Keepalived HA-Cluster über das VLAN

Ein fortgeschrittener Anwendungsfall ist ein Hochverfügbarkeits-Setup mit zwei VPS und einer virtuellen IP (VIP). Server 1 hält die VIP aktiv; fällt er aus, übernimmt Server 2 automatisch. Die folgende Konfiguration zeigt das 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 geheimespasswort
    }
    virtual_ipaddress {
        10.0.0.100/24
    }
}

Auf Server 2 setzt du state BACKUP und priority 90. Die VIP 10.0.0.100 ist dann immer auf dem aktiven Master erreichbar. Die Anleitung Hochverfügbarkeit auf netcup: Zwei VPS mit Keepalived, Failover-IP und Cloud-vLAN beschreibt den vollständigen Aufbau inklusive Failover-IP.

Cloud vLAN Only – Server ganz ohne öffentliche IP

Ab Server-Generation 12 bietet netcup beim Server-Setup die Option „Cloud vLAN Only". Damit erhält der Server kein öffentliches Interface – er ist ausschließlich über das VLAN oder die VNC-Konsole im SCP erreichbar. Das macht Sinn für reine Datenbank-Server oder interne Micro-Services, die niemals von außen erreichbar sein sollen.

Wichtig: Diese Entscheidung ist irreversibel. Nachträglich kann keine öffentliche IPv4 oder IPv6 mehr hinzugefügt werden. Wähle diese Option also nur dann, wenn der Server wirklich dauerhaft rein intern bleiben soll.

Troubleshooting / Typische Fehler

Interface erscheint nicht nach dem Neustart

Bei ARM-Servern reicht ein normaler Reboot manchmal nicht aus. Führe einen vollständigen Power-Zyklus durch: Server im SCP ausschalten, kurz warten, dann einschalten. Erst danach erscheint das neue Interface im Betriebssystem.

ping zwischen den Servern schlägt fehl

Prüfe zuerst mit ip a, ob das Interface auf beiden Seiten konfiguriert ist und die richtigen IPs hat. Prüfe außerdem, ob beide Server wirklich am gleichen netcup-Standort sind – ein Server in Nürnberg und einer in Wien können nicht über dasselbe VLAN kommunizieren. Kontrolliere auch, ob iptables-Regeln den ICMP-Traffic blockieren.

Ubuntu: Netzwerkkonfiguration wird nach Neustart überschrieben

Cloud-Init überschreibt /etc/netplan/50-cloud-init.yaml bei jedem Systemstart. Lege deine Konfiguration zwingend in einer Datei mit höherem Nummern-Präfix ab (z. B. 60-vlan.yaml) und deaktiviere die netzwerkbezogene Cloud-Init-Konfiguration wie in Schritt 4b gezeigt.

Interface-Name weicht von eth1 ab

Systemd predictable network interface names vergeben Namen wie ens6 oder enp2s1 basierend auf dem PCI-Slot. Prüfe mit ip a den tatsächlichen Namen, bevor du Konfigurationsdateien anlegst. Ein Fehler im Interface-Namen führt dazu, dass das Interface nicht konfiguriert wird – ohne Fehlermeldung.

Bandbreite reicht nicht aus

Das Free-Tier ist auf 100 Mbit/s begrenzt. Bei Datenbankreplikation, großen Backup-Transfers oder Docker-Layer-Pulls kann das zum Engpass werden. In diesem Fall lohnt sich das Upgrade auf Cloud vLAN Starter (250 Mbit/s) oder höher.

Häufige Fragen

Ist das Cloud VLAN wirklich dauerhaft kostenlos?

Ja, „Cloud vLAN Free" mit 100 Mbit/s ist ohne Laufzeitbegrenzung kostenlos. Du musst es jedoch explizit im CCP bestellen – es ist nicht automatisch für jeden Account aktiv.

Wie viele Server kann ich in ein VLAN einbinden?

Es gibt keine offiziell dokumentierte Obergrenze. Praktisch kannst du beliebig viele Server am gleichen Standort demselben VLAN hinzufügen. Jeder Server benötigt eine eigene, manuell vergebene IP-Adresse im gewählten Subnetz.

Kann ich einen Server in mehreren VLANs gleichzeitig betreiben?

Ja. Im SCP kannst du einem Server mehrere VLAN-Interfaces hinzufügen (z. B. eth1 für VLAN-A und eth2 für VLAN-B). Das ist sinnvoll, wenn du etwa ein separates Backup-VLAN und ein Applikations-VLAN betreiben möchtest.

Wie sichere ich die Kommunikation im VLAN ab?

Das VLAN ist physisch vom öffentlichen Internet isoliert – das ist bereits eine starke Schutzschicht. Zusätzlich empfehlen sich: iptables-Regeln auf sensiblen Ports (MySQL 3306, PostgreSQL 5432, Redis 6379), fail2ban sowie bei besonders kritischen Daten eine Verschlüsselung der Verbindung (TLS auch im privaten Netz oder ein WireGuard-Overlay). Lies dazu auch die Anleitung 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. Alle Dienste, die auf private VLAN-IPs angewiesen sind, verlieren ihre Verbindung. Passe alle abhängigen Konfigurationen (Datenbankverbindungsstrings, Firewall-Regeln, Applikationskonfigurationen) an, bevor du das Add-on kündigst.

Funktioniert das Cloud VLAN auch zwischen verschiedenen Standorten?

Nein. Server und VLAN müssen sich am exakt gleichen netcup-Standort befinden. Ein VLAN in Nürnberg kann nicht mit einem VPS in Wien kommunizieren. Für standortübergreifende private Kommunikation brauchst du ein VPN-Overlay wie WireGuard.

Fazit

Das netcup Cloud VLAN ist eine elegante und kostengünstige Lösung für jeden, der mehrere Server am gleichen Standort betreibt und Backend-Dienste vom öffentlichen Internet fernhalten möchte. Die Einrichtung ist in rund 20 Minuten erledigt: VLAN im CCP buchen, im SCP pro Server ein Interface hinzufügen, neu starten und die IP-Adresse im Betriebssystem setzen. Der einzige echte Stolperstein ist die SCP-Firewall, die für VLAN-Traffic nicht greift – wer das vergisst und keine OS-Firewall konfiguriert, hat de facto ein offenes Datenbank-Interface für alle VLAN-Teilnehmer. Mit den iptables-Regeln aus Schritt 6 ist auch das schnell behoben.

Weiterführende Anleitungen und Quellen

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