netcup Cloud vLAN: Backend ohne öffentliche Adresse, Internet über ein Gateway

Eine Datenbank, ein interner Dienst oder ein Build-Server braucht keine öffentliche Adresse. Bei netcup hängen Sie solche Server in ein Cloud vLAN und lassen sie nur über einen zweiten Server ins Internet, der als Gateway arbeitet. Diese Anleitung zeigt den ganzen Weg: die vLAN-Schnittstelle per SCP-REST-API anhängen, das Gateway mit NAT einrichten, auch wenn dort Docker läuft, und das Backend so installieren, dass es vom ersten Start an nur im vLAN erreichbar ist. Dazu kommen gemessene Werte, die Sie bei der Planung kennen sollten.

Dies ist Teil 9 der Reihe „netcup Spezial“.

Zwei Wege zum Server ohne öffentliche Adresse

Ab Server-Generation 12 bietet netcup bei der Bestellung die Netzwerkoption „Cloud vLAN only“. Ein solcher Server hat gar keine öffentliche Schnittstelle, und das lässt sich laut netcup nachträglich nicht ändern. Die Optionen erklärt Teil 6.

Diese Anleitung geht den anderen Weg: Ein vorhandener Server mit öffentlicher Adresse wird neu installiert und nutzt diese Adresse danach nicht mehr. Das hat zwei Vorteile. Sie können einen bestehenden Server umwidmen, und Sie können ihn später wieder öffentlich machen. Der Preis: Bis das Startskript läuft, ist die öffentliche Schnittstelle kurz aktiv (Schritt 4).

Wie Sie das Cloud vLAN buchen und Netzwerkdateien für Debian, Ubuntu und systemd-networkd schreiben, steht in netcup Cloud VLAN einrichten. Hier geht es um das Gateway, die API und den reinen vLAN-Betrieb.

Voraussetzungen

• Zwei netcup-Server am selben Standort, im Beispiel mit Ubuntu 24.04. Der eine wird Gateway und behält seine öffentliche Adresse, der andere wird Backend.
• Ein gebuchtes Cloud vLAN am selben Standort. Im Test war es eines mit 100 MBit/s.
• Zugang zur SCP-REST-API mit einem Zugriffstoken, wie in Teil 19 beschrieben. Die Beispiele erwarten ihn in der Variablen TOKEN. Er gilt nur fünf Minuten, holen Sie vor jedem Schritt mit dem Refresh-Token ein neues.
• Ein SSH-Schlüssel, der im SCP hinterlegt ist, und ein Rechner mit curl und jq.

Die Neuinstallation in Schritt 4 löscht alle Daten auf dem Backend. Läuft auf dem Gateway Docker, wie in Docker und Docker Compose auf Linux installieren beschrieben, ist Schritt 3 besonders wichtig.

Schritt 1: vLAN und Benutzerkennung per API ermitteln

Alle Pfade beginnen mit https://www.servercontrolpanel.de/scp-core/api/v1. Die vLANs hängen an Ihrem Benutzerkonto. Dessen Kennung steht in jeder Aufgabe, die die API zurückgibt, unter executingUser.id:

API=https://www.servercontrolpanel.de/scp-core/api/v1
UID_SCP=$(curl -s -H "Authorization: Bearer $TOKEN" "$API/tasks?limit=1" | jq '.[0].executingUser.id')
curl -s -H "Authorization: Bearer $TOKEN" "$API/users/$UID_SCP/vlans" | jq '.[] | {vlanId, site: .site.city, bandwidthClass: .bandwidthClass.name}'

{
  "vlanId": 1234567,
  "site": "Nuremberg",
  "bandwidthClass": "100Mbit"
}

Die Antworten der SCP-API enthalten unter executingUser auch Vor- und Nachname, Firma, Mailadresse und als Benutzernamen die Kundennummer. Geben Sie die Ausgabe deshalb nicht ungefiltert in Tickets oder Foren weiter.

Schritt 2: Die vLAN-Schnittstelle anhängen und kalt starten

In der Weboberfläche des SCP fanden wir in der Version 2026.1103 keinen Knopf zum Anhängen. Unter Server und Netzwerk standen nur die vorhandenen Schnittstellen. Die REST-API kann es. Die Beispiele zeigen das Backend mit der ID 100002. Wiederholen Sie jeden Befehl dieses Schritts für das Gateway (im Beispiel 100001). Das Gateway ist beim Kaltstart rund eine halbe Minute nicht erreichbar, auch seine Dienste nicht.

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"vlanId": 1234567, "networkDriver": "VIRTIO"}' "$API/servers/100002/interfaces" | jq '{name, state, uuid}'

Die Aufgabe heißt ServerInterfaceVxLanAdditionTask und war im Test nach höchstens 3 Sekunden fertig. Im laufenden System ist die neue Karte dann aber noch nicht da. Auch ein systemctl reboot auf dem Server änderte daran nichts. Erst nachdem wir den Server über die API aus- und wieder eingeschaltet hatten, war sie zu sehen. Das dauerte 17 bis 26 Sekunden:

for z in OFF ON; do
  T=$(curl -s -X PATCH -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/merge-patch+json" \
    -d "{\"state\": \"$z\"}" "$API/servers/100002" | jq -r .uuid)
  until [ "$(curl -s -H "Authorization: Bearer $TOKEN" "$API/tasks/$T" | jq -r .state)" = FINISHED ]; do sleep 3; done
  echo "$z fertig"
done

Das Ausschalten fährt den Server sauber herunter, wie in Teil 17 beschrieben. Die Schleife wartet jeweils, bis die Aufgabe FINISHED meldet.

curl -s -H "Authorization: Bearer $TOKEN" "$API/servers/100002/interfaces" | jq -r '.[] | select((.ipv4Addresses | length) == 0) | .mac'

Schritt 3: Das Gateway einrichten

Das Gateway bekommt im vLAN die Adresse 10.90.0.1. Legen Sie /etc/netplan/60-vlan.yaml an, mit der MAC-Adresse Ihrer neuen Karte:

network:
  version: 2
  ethernets:
    eth1:
      match:
        macaddress: "0a:00:5e:00:53:02"
      set-name: eth1
      addresses:
      - "10.90.0.1/24"

chmod 600 /etc/netplan/60-vlan.yaml && netplan apply
sysctl -w net.ipv4.ip_forward=1
echo net.ipv4.ip_forward=1 > /etc/sysctl.d/90-vlan-gateway.conf

Auf unserem Gateway stand die Weiterleitung schon auf 1, weil Docker sie einschaltet. Ohne Docker brauchen Sie die beiden sysctl-Zeilen.

Die NAT-Regel kommt in eine eigene nftables-Tabelle. So bleiben eine vorhandene Firewall und die Regeln von Docker unberührt. Datei /etc/vlan-gateway.nft:

#!/usr/sbin/nft -f
table inet vlan_gw
delete table inet vlan_gw
table inet vlan_gw {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.90.0.0/24 oifname "eth0" masquerade
  }
}

Läuft auf dem Gateway Docker, fehlt noch ein Schritt. Docker setzt die Weiterleitung in iptables auf DROP und lässt nur seine eigenen Netze durch. Eigene Ausnahmen gehören in die Kette DOCKER-USER. Skript /usr/local/sbin/vlan-gateway-docker-user.sh:

#!/bin/sh
iptables -C DOCKER-USER -i eth1 -o eth0 -s 10.90.0.0/24 -j ACCEPT 2>/dev/null || iptables -I DOCKER-USER 1 -i eth1 -o eth0 -s 10.90.0.0/24 -j ACCEPT
iptables -C DOCKER-USER -i eth0 -o eth1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2>/dev/null || iptables -I DOCKER-USER 2 -i eth0 -o eth1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Beides lädt ein systemd-Dienst nach Docker, Datei /etc/systemd/system/vlan-gateway.service. Ohne Docker lassen Sie die zweite ExecStart-Zeile weg. Nutzen Sie ufw, verwirft es weitergeleiteten Verkehr standardmäßig ebenfalls und braucht eine eigene Freigabe:

[Unit]
Description=Cloud vLAN Gateway (NAT und Forward)
After=network-online.target docker.service
Wants=network-online.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/nft -f /etc/vlan-gateway.nft
ExecStart=/usr/local/sbin/vlan-gateway-docker-user.sh
ExecStop=/usr/sbin/nft delete table inet vlan_gw
[Install]
WantedBy=multi-user.target

chmod 755 /usr/local/sbin/vlan-gateway-docker-user.sh
systemctl daemon-reload && systemctl enable --now vlan-gateway.service

Eingehende Verbindungen aus dem vLAN zum Gateway selbst brauchen keine Freigabe: Der SSH-Sprung in Schritt 5 geht vom Gateway hinaus ins vLAN. Die übrige Absicherung des Gateways beschreibt Linux-Server absichern mit ufw und Fail2ban.

Schritt 4: Das Backend nur im vLAN installieren

Die Neuinstallation per POST /servers/{id}/image nimmt im Feld customScript ein Skript an, das beim ersten Start läuft. Unser Startskript schaltet die Netzwerkkonfiguration von cloud-init ab, damit sie eth0 nicht bei einem späteren Start wiederherstellt. Es schreibt die vLAN-Adresse mit dem Gateway als Standardroute und legt eth0 still. Speichern Sie es als startskript.sh und tragen Sie die MAC-Adresse der vLAN-Karte des Backends ein:

#!/bin/bash
# Erster Start: Server nur im Cloud vLAN, Internet über das Gateway 10.90.0.1
echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
rm -f /etc/netplan/50-cloud-init.yaml
cat > /etc/netplan/60-vlan.yaml <<'NP'
network:
  version: 2
  ethernets:
    eth1:
      match:
        macaddress: "0a:00:5e:00:53:12"
      set-name: eth1
      addresses:
      - "10.90.0.2/24"
      routes:
      - to: default
        via: 10.90.0.1
      nameservers:
        addresses: [9.9.9.9, 149.112.112.112]
NP
chmod 600 /etc/netplan/60-vlan.yaml
ip addr flush dev eth0
ip link set eth0 down
netplan apply
echo "startskript fertig $(date -Is)" > /root/startskript.log

Die passende Kennung des Images liefert GET /servers/100002/imageflavours. Im Test war es Ubuntu 24.04.5 UEFI minimal. Den Namen der Festplatte (vda) zeigt GET /servers/100002. Mit jq wird das Skript sauber in das JSON eingebettet:

jq -n --rawfile s startskript.sh '{imageFlavourId: 116, diskName: "vda", rootPartitionFullDiskSize: true,
  hostname: "backend", locale: "de_DE.UTF-8", timezone: "Europe/Berlin", sshKeyIds: [11111],
  sshPasswordAuthentication: false, emailToExecutingUser: false, customScript: $s}' |
curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d @- \
  "$API/servers/100002/image" | jq '{name, state, uuid}'

Die Kennung Ihres SSH-Schlüssels liefert GET /users/$UID_SCP/ssh-keys. Die Antworten zur Aufgabe enthalten unter result ein Feld rootPassword für das Root-Passwort. Speichern Sie die Antworten deshalb nicht ungefiltert in Logs.

Im Test lief die Installation 5 Minuten und 20 Sekunden, das Startskript meldete sich eine halbe Minute vor dem Ende. Während der Installation haben wir alle drei bis fünf Sekunden geprüft, ob SSH auf der öffentlichen Adresse antwortet. Rund zwei Minuten lang tat es das, für Adressen, die die SCP-Firewall des Servers zuließ. Weisen Sie dem Backend deshalb vorher in der SCP-Firewall eine Policy zu, die eingehend nichts erlaubt. SSH lässt durch sshPasswordAuthentication: false ohnehin nur Ihren Schlüssel zu.

Schritt 5: Über das Gateway anmelden

Das Backend erreichen Sie nur noch über das Gateway. SSH springt mit ProxyJump automatisch weiter, Ihr Schlüssel bleibt auf Ihrem Rechner. Eintrag in ~/.ssh/config:

Host gateway
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/id_ed25519
Host backend
    HostName 10.90.0.2
    User root
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump gateway

Läuft SSH auf dem Gateway auf einem anderen Port, ergänzen Sie dort eine Zeile Port. Nach jeder Neuinstallation hat das Backend einen neuen Hostschlüssel, den alten entfernen Sie mit ssh-keygen -R 10.90.0.2.

ssh backend 'ip -br addr; ip route'

lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             DOWN
eth1             UP             10.90.0.2/24 fe80::800:5eff:fe00:5312/64
default via 10.90.0.1 dev eth1 proto static
10.90.0.0/24 dev eth1 proto kernel scope link src 10.90.0.2

Schritt 6: Testen, was das Backend kann

ssh backend 'apt-get update | tail -1; curl -s -4 https://ipv4.icanhazip.com; curl -s -m8 -6 https://ipv6.icanhazip.com || echo "kein IPv6"'

Updates liefen im Test ohne Probleme. Als Absender sah die Gegenstelle die öffentliche Adresse des Gateways. IPv6 gibt es nach außen nicht, weil das NAT nur IPv4 umsetzt. Die Spiegel von Ubuntu und die meisten Registries sind über IPv4 erreichbar.

Wir haben dazu gemessen. Ping im vLAN: 0,5 bis 0,7 Millisekunden. Pakete mit 1500 Byte gingen ohne Fragmentierung durch, Sie müssen die MTU also nicht senken. iperf3 zwischen Gateway und Backend kam in beide Richtungen auf rund 95 Mbit/s, mit einigen Hundert Wiederholungen in zehn Sekunden. Ein großer Download auf dem Backend erreichte über das Gateway 11,9 MB/s, also genau die Grenze des vLAN. Das Gateway selbst lud dieselbe Datei mit 288 MB/s.

Für Updates reicht das. Ziehen Sie auf dem Backend aber große Docker-Images oder sichern Sie viele Daten über das Gateway, setzt das vLAN die Grenze. Dann lohnt eine schnellere vLAN-Stufe, oder Sie sichern direkt im vLAN auf einen anderen Server.

Typische Fehler

Häufige Fragen

Brauche ich für das Gateway einen eigenen Server?

Nein. Im Test lief das Gateway auf einem Server mit, auf dem in Docker auch ein Webserver und ein Mailserver liefen. Wichtig ist nur die Freigabe in DOCKER-USER.

Was passiert, wenn das Gateway ausfällt?

Das Backend kommt dann nicht mehr ins Internet. Per SSH erreichen Sie es nur noch von einem anderen Server im vLAN aus oder über die Konsole im SCP. Halten Sie deshalb den Neustart des Gateways kurz und planen Sie Updates beider Server zusammen.

Wie mache ich das Backend wieder öffentlich?

Die öffentliche Schnittstelle bleibt im SCP erhalten, nur das System nutzt sie nicht. Bei unserer ersten Installation ohne Startskript war sie sofort aktiv, damals noch ohne vLAN-Karte. Bei der Neuinstallation mit Startskript blieb die vLAN-Karte angehängt.

Fazit

Ein Backend ohne öffentliche Adresse ist bei netcup mit wenigen API-Aufrufen, je einem Kaltstart und einem Startskript eingerichtet. Die meiste Arbeit liegt beim Gateway, besonders wenn dort Docker läuft. Rechnen Sie bei der Planung mit der Geschwindigkeit des vLAN, denn sie gilt auch für alles, was das Backend aus dem Internet holt.

Weiterführende Anleitungen und Quellen

• netcup Cloud VLAN einrichten: Private Server-Kommunikation ohne öffentliche IP
• Teil 6: Netzwerkkonfiguration bei der Bestellung
• Teil 17: Snapshots per SCP-REST-API
• Teil 19: netcup-Traffic im Blick, mit Einrichtung des API-Zugangs
• Docker und Docker Compose auf Linux installieren
• netcup: REST-API im SCP
• SCP-REST-API: OpenAPI-Beschreibung
• Docker: Packet filtering and firewalls