Network

Erstellung und Verwaltung von Security Groups

In der SPARCI-Cloud ist die Erstellung und Verwaltung von Security Groups ein besonders relevanter Bereich der Netzwerkfunktionen. Obwohl Apache CloudStack mehrere Funktionen wie die Erstellung von Virtual Private Computing (VPC) bietet, sind diese Funktionen in dieser Installation nicht verfügbar. Darüber hinaus wird SPARCI als rein private Cloud betrieben, Funktionen wie Public IP-Adressen und VPN-Kunden-Gateways sind eher für eine Public Cloud-Installation relevant.

Allgemeine CloudStack-Hintergründe finden Sie in der offiziellen Dokumentation zu Security Groups und zur Netzwerk-Konfiguration. Die folgenden Abschnitte beschreiben die in SPARCI relevanten Regeln und Einschränkungen.

Bei der Erstellung von VMs in der SPARCI-Cloud wird automatisch eine IP-Adresse aus dem gemeinsam genutzten Adressbereich 141.26.156.0/23 für alle VMs zugewiesen. Darüber hinaus müssen Benutzer:innen eine Security Group auswählen, die zuvor definierte Regeln für den Zugriff auf VMs über Protokoll- und Portfreigaben enthält.

Die Erstellung und Verwaltung von Security Groups finden Sie links im Menü unter Network → Security Groups. Standardmäßig wird jedem neuen Account eine "default" Security Group zugewiesen. Nach dem Klick auf eine Security Group wird folgende Ansicht angezeigt:

Hier können eingehende (Ingress Rules) und ausgehende Regeln (Egress Rules) definiert werden. Alle Egress Rules werden nach dem Blacklisting-Verfahren gesteuert, was bedeutet:

• Alle ausgehenden Verbindungen sind standardmäßig erlaubt.
• Individuelle Ports, Protokolle und Netzwerkbereiche können über die Benutzeroberfläche definiert werden, um diese Verbindungen zu blockieren.
• Wenn keine Egress Rules definiert sind, werden alle ausgehenden Kommunikationen von der VM zugelassen.

Wenn ausgehende Verbindungen trotz dieser Grundeinstellung fehlschlagen, sollten die Egress Rules der tatsächlich verwendeten Security Group geprüft werden. Je nach Konfiguration können fehlende oder geänderte Egress-Regeln dazu führen, dass bestimmte ausgehende Ports nicht erreichbar sind.

Im Gegensatz dazu werden alle Ingress Rules nach dem Whitelisting-Verfahren gesteuert, was bedeutet:

• Benutzer:innen müssen eingehende Regeln für die Security Group definieren, um den Zugriff auf die VMs zu ermöglichen.
• Normalerweise werden der SSH-Port sowie die Ports für HTTP (80, 8080) und HTTPS (443, 8443) freigegeben, zum Beispiel:

Im Feld "CIDR" kann der Netzwerkbereich angegeben werden, über den der Zugriff erlaubt werden soll. Für den SSH-Port kann beispielsweise der öffentlich registrierte IPv4-Bereich der Universität Koblenz 141.26.0.0/16 verwendet werden. Wenn ein engerer ZIMT- oder VPN-Adressbereich bekannt ist, sollte dieser bevorzugt werden. Für Webserver-Ports soll der Zugriff von überall erlaubt werden, hier kann der Netzwerkbereich 0.0.0.0/0 verwendet werden.

Alternativ können alle eingehenden Regeln für eine Security Group erlaubt werden, indem im Feld "Protocol" die Option "ALL" ausgewählt wird. Im Feld "CIDR" wird der Wert 0.0.0.0/0 eingetragen.

Nachdem die Security Groups erstellt und angepasst wurden, können sie bei der Erstellung neuer VMs ausgewählt werden.

Fehlersuche bei ausgehenden Verbindungen

Wenn Paketinstallationen, Updates oder Build-Jobs innerhalb einer VM fehlschlagen, obwohl DNS funktioniert und HTTPS-Seiten erreichbar sind, sollten neben der Betriebssystemkonfiguration auch die Security-Group-Regeln geprüft werden.

Ein typisches Fehlerbild sind fehlgeschlagene APT-Updates mit HTTP-basierten Paketquellen, zum Beispiel:

Failed to fetch http://deb.debian.org/debian/dists/trixie/InRelease

oder vergleichbare Fehler mit http://archive.ubuntu.com. In diesem Fall kann es helfen, die APT-Sources der VM auf HTTPS umzustellen. Das löst aber nicht immer alle Probleme: Docker-Container, die in GitLab-CI-Jobs gestartet werden, verwenden häufig eigene Paketquellen innerhalb des Container-Images. Diese können weiterhin HTTP verwenden, auch wenn die VM selbst bereits auf HTTPS umgestellt wurde.

Prüfen Sie bei solchen Fehlern die Egress Rules der Security Group, die der VM zugeordnet ist:

• ausgehender TCP-Traffic auf Port 80 muss erlaubt sein
• ausgehender TCP-Traffic auf Port 443 sollte ebenfalls erlaubt sein
• die Regel muss für den benötigten Zielbereich gelten, im Zweifel für 0.0.0.0/0
• nach Änderungen an der Security Group sollte der fehlgeschlagene GitLab-CI-Job erneut gestartet werden

Die Erreichbarkeit kann innerhalb der VM mit folgenden Befehlen geprüft werden:

curl -I http://deb.debian.org
curl -I https://deb.debian.org

Wenn HTTPS funktioniert, HTTP aber fehlschlägt, deutet das auf ein Problem mit ausgehendem TCP-Traffic auf Port 80 hin. Prüfen Sie dann insbesondere die Egress Rules der Security Group.

Fehlersuche bei neuen VMs ohne SSH oder Internet

Wenn eine neu erstellte VM weder per SSH erreichbar ist noch ausgehend ins Internet kommt, prüfen Sie zuerst die VM-Erstellung und die Security Group, bevor Sie die VM löschen und neu erstellen:

• Ist die VM im Status "Running" und hat sie eine IP-Adresse aus dem SPARCI-Adressbereich?
• Wurde bei Ubuntu-Templates der richtige Benutzername verwendet, typischerweise ubuntu?
• Ist der passende SSH-Public-Key beziehungsweise Benutzer per Cloud-Init in der VM hinterlegt?
• Erlaubt die zugewiesene Security Group eingehenden TCP-Traffic auf Port 22 aus Ihrem Quellnetz?
• Blockieren Egress Rules versehentlich ausgehenden Traffic, zum Beispiel DNS, HTTP oder HTTPS?
• Funktioniert die Web-Konsole, sodass Sie innerhalb der VM ip addr, ip route, systemctl status ssh und einfache ping- oder curl-Tests ausführen können?

Wenn SSH und Internet gleichzeitig nicht funktionieren, kann die Ursache trotzdem unterschiedlich sein: SSH hängt meist an Ingress-Regeln, Benutzername, Keys oder dem SSH-Dienst in der VM; fehlende Internetverbindung hängt eher an Routing, DNS, Egress-Regeln oder Paketquellen. Wenn auch die Web-Konsole hängt oder mehrere VMs betroffen sind, kann ein Infrastrukturproblem vorliegen.

VM erhält keine IP-Adresse

Wenn eine VM keine IP-Adresse erhält, prüfen Sie zuerst über die Web-Konsole, ob innerhalb der VM überhaupt eine Netzwerkschnittstelle sichtbar ist:

ip a
ip route

Bei DHCP-Problemen helfen häufig ein kontrollierter Neustart über die CloudStack-Oberfläche oder eine DHCP-Erneuerung innerhalb der VM, zum Beispiel:

sudo dhclient -r
sudo dhclient -v

Wenn mehrere VMs gleichzeitig keine IP-Adresse erhalten oder eine VM auch nach Neustart und DHCP-Erneuerung keine Adresse bekommt, melden Sie VM-Namen, betroffene IPs falls sichtbar, Zeitpunkt und die Ausgabe von ip a an die Cloud-Administration. In solchen Fällen kann ein Host-, Cloud-Netzwerk- oder Campus-Netzwerkproblem vorliegen.

SSH-Zugriff aus dem Uni-Netz

Für SSH-Zugriff auf SPARCI-VMs müssen normalerweise zwei Bedingungen erfüllt sein:

• Sie befinden sich im Universitätsnetz oder sind per VPN verbunden.
• Die zugewiesene Security Group erlaubt eingehenden TCP-Traffic auf Port 22 aus Ihrem Quellnetz.

Wenn SSH nicht funktioniert, prüfen Sie daher zuerst VPN/Netzstandort, Security Group, Ziel-IP, Benutzername, SSH-Key und ob der SSH-Dienst in der VM läuft. Ohne passende Ingress-Regel kann eine VM trotz korrektem Benutzer und Key nicht erreicht werden.

DNS-Konfiguration in VMs

VMs im Universitätsnetz sollten die vorgesehenen DNS-Resolver der Universität beziehungsweise die per DHCP bereitgestellte DNS-Konfiguration verwenden. Manuell gesetzte öffentliche Resolver wie 8.8.8.8 können in diesem Netz zu Problemen führen oder durch Security Groups beziehungsweise vorgelagerte Netze blockiert sein.

Wenn Namensauflösung fehlschlägt, prüfen Sie innerhalb der VM:

resolvectl status
cat /etc/resolv.conf

Vergleichen Sie die DNS-Konfiguration bei Bedarf mit einer funktionierenden VM aus demselben Account oder Projekt. Setzen Sie manuelle Änderungen zurück, wenn sie von der Standardkonfiguration abweichen.

Netzwerkdurchsatz und Rate Limits

CloudStack-Netzwerke oder Network Offerings können eine Netzwerkbegrenzung enthalten. Ein Wert wie networkrate: 200 bedeutet typischerweise 200 Mbit/s. Das entspricht grob 25 MB/s, weil 8 Bit einem Byte entsprechen und zusätzlich Protokoll-Overhead anfällt.

Wenn mehrere Tests dauerhaft bei ungefähr derselben Transferrate enden, kann ein solches Limit die Ursache sein. Änderungen an Network Offerings oder Netzwerkprofilen können nur administrativ erfolgen. Nach einer Änderung kann ein Neustart der betroffenen VM notwendig sein, bevor die neue Rate wirksam wird.

DNS-Namen und IP-Adressen

CloudStack weist IP-Adressen aus dem VM-Adresspool zu. Eine durch CloudStack bereits vergebene IP-Adresse kann in externen DNS- oder Verwaltungswerkzeugen trotzdem anders erscheinen, zum Beispiel weil alte Einträge noch nicht bereinigt wurden oder weil ein Tool nur freie Adressen anzeigt. Wenn CloudStack eine IP-Adresse aktiv einer VM zuweist, ist diese Adresse aus Sicht der Cloud nicht frei.

Für DNS-Namen verwenden Sie die von CloudStack zugewiesene VM-IP-Adresse und beantragen beziehungsweise pflegen den DNS-Eintrag über den dafür vorgesehenen DNS-Prozess. Eine account-spezifische Zuweisung eigener Subnetze wird in der aktuellen SPARCI-Cloud nicht unterstützt; verwenden Sie stattdessen eine Adresse aus dem gemeinsamen VM-Pool und einen passenden DNS-Namen.

Externer SSH-Zugriff

SSH auf Port 22 ist von außerhalb des Universitätsnetzes beziehungsweise ohne VPN in der Regel durch vorgelagerte Firewall-Regeln gesperrt. Diese Freigabe erfolgt nicht direkt durch die Cloud-Administration, sondern über das zuständige Rechenzentrum beziehungsweise ZIMT.

Wenn externe Kooperationspartner Zugriff auf eine VM benötigen, gehen Sie typischerweise so vor:

1. Konfigurieren Sie die VM so, dass SSH-Login per Passwort deaktiviert ist und ausschließlich SSH-Key-Authentifizierung erlaubt wird.
2. Legen Sie für jede Person einen eigenen Linux-Benutzer oder zumindest einen eigenen SSH-Key an. Vermeiden Sie geteilte Accounts und geteilte Private Keys.
3. Öffnen Sie in der CloudStack Security Group den eingehenden SSH-Zugriff nur für die benötigten Quellnetze, sofern diese bekannt sind.
4. Kontaktieren Sie das Rechenzentrum beziehungsweise ZIMT und nennen Sie die Serveradresse sowie den benötigten SSH-Zugriff.

Nach bisherigen Erfahrungen wird eine externe SSH-Freigabe nur für Systeme erteilt, bei denen Passwort-Login deaktiviert ist und Key-only-SSH verwendet wird.

Änderungen an Security Groups

Änderungen an Security Groups wirken nicht immer sofort sichtbar in laufenden Tests. Nach Änderungen an Ingress- oder Egress-Regeln sollten Sie einige Minuten warten und den Test erneut ausführen. In manchen Fällen ist zusätzlich ein Neustart der VM hilfreich, damit alle Änderungen zuverlässig greifen.

Bei Verbindungsproblemen prüfen Sie beide Richtungen:

• Ingress Rules steuern, welche eingehenden Verbindungen zur VM erlaubt sind, zum Beispiel SSH auf Port 22.
• Egress Rules können ausgehende Verbindungen aus der VM beeinflussen, zum Beispiel Paketquellen, Docker-Downloads oder externe APIs.

Ein versehentlich restriktiver Egress-Eintrag kann dazu führen, dass eingehende Regeln korrekt aussehen, die VM aber trotzdem nicht wie erwartet kommuniziert.