🛡️ Trooper.AI anpassbare Netzwerk-Ebene-Firewall

Trafficfluss

Ihr GPU-Server wird hinter unserer NAT-Infrastruktur und Netzwerksicherheitsschicht betrieben, was bedeutet, dass der gesamte Datenverkehr immer durch das Trooper.AI-Netzwerkfirewall geleitet wird, bevor er den Server erreicht.

UDP-Verkehr ist standardmäßig gesperrt, kann aber über die Firewall-Einstellungen aktiviert werden, falls erforderlich.

Diese Architektur ermöglicht Ihnen die zentrale Verwaltung der Netzwerksicherheit, während Sie sich vollständig auf den Aufbau und die Ausführung Ihrer KI-Workloads konzentrieren können.

So verwenden Sie die integrierte Netzwerk-Firewall

Die Trooper.AI-Firewall-Schnittstelle bietet eine natürliche Firewall direkt vor Ihrem GPU-Server. Dies ermöglicht Ihnen die Steuerung des Netzwerkverkehrs bevor Pakete das Betriebssystem des GPU-Servers erreichen. Sie können zudem den ausgehenden Verkehr beschränken, falls gewünscht – sei es aus Sicherheitsgründen oder zur Leistungsoptimierung.

Diese Sicherheitsebene ist vollständig in die Trooper.AI-Infrastruktur integriert und kann über Actions > „Firewall-Regeln“ aufgerufen werden.

Die Oberfläche funktioniert wie folgt:

• (1) Regel-Tabelle – Zeigt alle konfigurierten Firewall-Regeln an. Regeln können sortiert, bearbeitet oder gelöscht werden.
• (2) Standardrouten – Legt das Standardverhalten für Traffic fest, der keine Regel trifft.
• (3) Regel-Editor – Neue Regeln basierend auf Portbereichen, IP-Bereichen sowie der Aktion (Erlauben / Verweigern) erstellen.

Diese Lösung ermöglicht es Ihnen, die Netzwerkexposition Ihres GPU-Servers zu steuern ohne die Konfiguration des Betriebssystems zu ändern.

Ausgehende Firewall

Die Trooper.AI-Firewall auf Netzwerkebene sorgt für eine feingranulare Steuerung des ausgehenden Netzwerkverkehrs von Ihrem GPU-Server Blib. Diese Funktion ermöglicht es Organisationen, strenge regulatorische Compliance-Maßnahmen umzusetzen, die Bandbreitennutzung zu optimieren sowie die betriebliche Sicherheit zu erhöhen.

Hinweis: Ausgehende Regeln können Paket- und Modell-Downloads (apt, pip, Hugging Face) blockieren oder drosseln. Sollten Verbindungsprobleme auftreten, überprüfen Sie bitte zunächst Ihre Firewall-Regeln.

Die Oberfläche funktioniert wie folgt:

• (1) Regel-Tabelle – Zeigt alle konfigurierten ausgehenden Firewall-Regeln an. Regeln können sortiert, bearbeitet oder gelöscht werden.
• (2) Standardrouten – Ausgehender Verkehr ist standardmäßig immer erlaubt.
• (3) Regel-Editor – Neue Regeln basierend auf Portbereichen, IP-Bereichen sowie Aktion (Erlauben / Verweigern) erstellen. Bei einer Erlaubnisregel können Sie eine Geschwindigkeitsbegrenzung bis zu einem Maximum von 50 MBit/s festlegen.

Die Firewall-Implementierung hält eine vollständige Trennung zwischen der Durchsetzung von Richtlinien und den Serverausführungsumgebungen aufrecht:

• Die gesamte Filterung erfolgt auf der Ebene der Netzwerkinfrastruktur vor dem Paketversand.
• Anwendungsprozesse haben keine Einsicht oder Änderungsmöglichkeiten bezüglich der Firewall-Konfigurationen.
• Schutz vor potenzieller Kompromittierung von serverseitigen Komponenten, die versuchen, Beschränkungen zu umgehen

Empfohlene Firewall-Voreinstellungen

Um die Absicherung des ausgehenden Verkehrs so einfach wie möglich zu gestalten, bietet Trooper.AI zwei vorgefertigte Voreinstellungen an, die wir für den allgemeinen Gebrauch empfehlen. Sie können eine davon automatisch bei der Bestellung eines neuen GPU-Servers Blib aktivieren lassen – wählen Sie sie einfach im Bestelldialog aus, und sie ist sofort eingerichtet, sobald Ihr Server hochfährt; dabei sind keine manuellen Regelanpassungen nötig. Möchten Sie sich später entscheiden? Dann bestellen Sie mit „Keine Voreinstellung“ und können anschließend jederzeit über das Dashboard eine der beiden Voreinstellungen selbst neu aufbauen.

Beide Vorlagen steuern ausschließlich ausgehenden Verkehr (Ihr Server → Internet). Ihr öffentlicher eingehender Portbereich sowie SSH bleiben standardmäßig offen, und Regeln werden von oben nach unten ausgewertet – die erste passende Regel gilt.

• 🟢 Ausgewogen — unsere Standardempfehlung für fast alle Nutzer: bleibt vollständig offen für normale KI-Arbeiten, während bekannte Spam-/Wurm-/Botnet-Aktivitäten stumm blockiert werden.
• 🔴 Streng — eine strikt eingeschränkte Erlaubnisliste für reine Inferenz-Systeme, die ausschließlich die Grundfunktionen benötigen.

Wird bei der Bestellung angewendet oder kann später selbst neu aufgebaut werden: Wählen Sie eine Vorlage im Bestelldialog aus, um sie automatisch zu aktivieren, oder erstellen Sie diese jederzeit unter Verwaltung → Ihr Server → 🛡️ Firewall → Ausgehend mithilfe der Tabellen unten.

Immer aktive Schutzmaßnahmen (für alle Voreinstellungen, einschließlich „Keine Voreinstellung“): mehrstufige DDoS-Abwehr, pro-IP-Verbindungs-/Flutbegrenzungen, Mieterisolierung sowie Egress-Schutz für Privatnetzwerke (RFC1918) werden automatisch aktiviert und können nicht deaktiviert werden.

🔴 Ausgewogen (Empfohlen)

Alles bleibt für normale KI-Arbeiten offen – apt, pip/uv, Hugging Face, Docker, Datenbanken sowie Ihre eigenen APIs –, während eine Reihe branchenübliche Sicherheitsvorkehrungen Spam-, Wurm- und Botnetz-Missbrauch verhindert. Ausgehender UDP-Verkehr ist standardmäßig deaktiviert, außer für DNS und Zeitabgleich.

Nettoeffekt: Alle ausgehenden TCP-Verbindungen bleiben offen, außer zu den aufgelisteten Missbrauchsports; ausgehender UDP ist auf DNS (53) und NTP (123) beschränkt. QUIC/HTTP-3 wechselt automatisch zurück zu TCP 443, sodass Downloads unbeeinträchtigt bleiben. ICMP (Ping-/Path-MTU-Erkennung) bleibt erlaubt.

🔴 Streng (Erweitert)

Nur das Wesentliche geht hinaus – ideal für reine Inferenz-/KI-Systeme. Alles nicht auf der Erlaubnisliste ist blockiert (Standard-Sperre).

Nettoeffekt: apt, pip/uv, git (über HTTPS & SSH), Hugging Face sowie Docker-Pulls funktionieren alle; alles auf nicht-standardmäßigen Ports wird blockiert. ICMP bleibt erlaubt. Ideal, wenn Ihre Anwendungen nur Standardports nutzen.

🔒 SSH-IP-Sperre (optional)

Falls dies bei der Bestellung aktiviert wird, werden zwei eingehende Regeln hinzugefügt, sodass nur Ihre IP-Adresse auf SSH zugreifen kann, während Ihre öffentlichen App-Ports für alle offen bleiben:

Falls sich Ihre IP ändert, aktualisieren Sie bitte die Quelle unter Verwaltung → Firewall → Eingehend.

Wie prüfen oder neu aufbauen?

• Überprüfen: öffnen Sie Verwaltung → Ihr Server → 🛡️ Firewall → Ausgehend. Die Zählmarke auf der Registerkarte zeigt an, wie viele Regeln aktiv sind; vergleichen Sie diese mit der Tabelle oben.
• Neubau auf einer bestehenden Maschine: im Tab Ausgehend, fügen Sie pro Zeile eine Regel hinzu – in derselben Reihenfolge (oben = höchste Priorität) –, dann klicken Sie auf Jetzt anwenden.
• Später machen: Sie können mit Keine Voreinstellung beginnen und diese Regeln jederzeit hinzufügen – Änderungen wirken nach einem Klick auf Jetzt anwenden

Regeln werden von oben nach unten abgearbeitet – das erste Trefferergebnis hat Vorrang. Halten Sie die beiden Erlauben-Regeln für DNS/NTP über jeder generellen Verweigern-Regel, sonst fallen Namensauflösung und Zeitabgleich aus.

Fehlerbehebung

Prüfen Sie diese Schritte, falls Sie nach einer Änderung an der Firewall oder dem Network Stack nicht mehr auf Ihre Dienste auf Ihrem GPU-Server zugreifen können. Falls Sie Ihr System weiterhin nicht erreichen können, prüfen Sie bitte zunächst Ihre Firewall-Einstellungen und wenden Sie sich dann an uns: Support Kontakte

WICHTIG: Deaktivieren Sie eine möglicherweise versehentlich aktivierte lokale Firewall.

Falls eine lokale Firewall wie z. B. UFW auf dem Server aktiviert wurde und zu Verbindungsproblemen führt, kann diese mit folgendem Befehl deaktiviert werden:

sudo ufw disable

Ausgabe:

Firewall stopped and disabled on system startup

Deaktivieren Sie dann den Dienst:

sudo systemctl disable ufw

Ausgabe:

Synchronizing state of ufw.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ufw
Removed /etc/systemd/system/multi-user.target.wants/ufw.service.

Sie sollten unbedingt jede lokale Firewall auf Ihrem GPU-Server entfernen. Das wird Ihnen die Arbeit erleichtern!

Fehlerbehebung: Warum funktionieren meine Firewall-Regeln nicht wie erwartet?

von oben nach unten

Die erste Regel, auf die der Traffic zutrifft, wird angewendet. Es werden keine weiteren Regeln überprüft.

Beispiel für eine falsche Reihenfolge:

1  Deny  0.0.0.0/0      Port 14141
2  Allow 78.168.0.0/16  Port 14141

In diesem Fall blockiert Regel 1 den gesamten SSH-Traffic, bevor Regel 2 erreicht wird.

Korrekte Reihenfolge:

1  Allow 78.168.0.0/16  Port 14141
2  Deny  0.0.0.0/0      Port 14141

Platzieren Sie immer spezifischere Erlaubnisregeln über allgemeine Sperrregeln.

Fehlerbehebung: Warum trifft meine Firewall-Regel nicht auf meine IP-Adresse zu?

Firewall-Regeln verwenden CIDR-Bereiche, um erlaubte oder blockierte IP-Adressen zu definieren.

Stellen Sie sicher, dass der Bereich Ihre IP-Adresse tatsächlich enthält.

Beispiele:

Wenn der CIDR-Bereich falsch ist, stimmt die Firewallregel niemals mit Ihrer Verbindung überein.

Fehlerbehebung: Warum ist mein Port noch blockiert?

Stellen Sie sicher, dass der richtige Port im Firewall freigegeben ist. Die korrekten Ports finden Sie im Manage-Dashboard Ihrer Blib. Falls ein falscher Port im Firewall freigegeben wurde, wird der Traffic niemals Ihre GPU-Server erreichen.

Fehlerbehebung: Verständnis der Steuerung des ausgehenden Datenverkehrs oder Warum funktioniert eine ausgehende Verbindung weiterhin?

Ausgehender Verkehr in der Firewall von Trooper.AI bezieht sich ausschließlich auf Aktiv gestartete Netzwerkverbindungen Ihres GPU-Server-Blib. Diese Unterscheidung verdeutlicht, dass:

• „Ausgehend“ = Verbindungen, bei denen Ihr Server als Client auftritt (Kommunikation initiiert).
• „Rückverkehr“ = Antworten auf zuvor etablierte eingehende Verbindungen (wobei externe Systeme als Clients agieren).
• Sie können ausgehenden SSH-Verkehr einschränken, während der eingehende SSH-Zugriff für Remoteverbindungen aufrechterhalten bleibt.
• Ausgehende Verkehrsregeln gelten gleichmäßig für alle Protokolle – einschließlich HTTP. Selbst wenn Sie alle ausgehenden Ports auf VERWEIGERN konfigurieren, werden HTTP-basierte Dienste wie WebProxy, Jupyter und OpenWebUI weiterhin funktionieren, da deren Verbindungen extern initiiert werden und sie somit von eingehendem Verkehr abhängen.

Wichtiger Hinweis: Eine explizit erlaubte eingehende Verbindung kann legitimen Rückverkehr generieren, um die Sitzungsverbindung aufrechtzuerhalten – dies bleibt von ausgehenden Regeln unbeeinflusst, sofern nicht ausdrücklich eingeschränkt.

Alle ausgehenden Richtlinien gelten ausschließlich für Verbindungen, die von Ihrer GPU-Server-Instanz intern initiiert werden.

Fehlerbehebung: Warum funktioniert APT/PIP oder eine andere Systemaufgabe nicht mehr?

🚨 Stellen Sie sicher, dass Ihre ausgehenden Firewall-Regeln den notwendigen Netzwerkzugriff für Paketmanager (pip, apt-get) sowie Systemaktualisierungstools erlauben, um kritische Patches und Betriebssystem-Updates sicher abzurufen. Überprüfen Sie bitte, ob Standard-Repositories und Update-Server freigegeben sind, damit Abhängigkeiten reibungslos aufgelöst werden können und Wartungsvorgänge durchgeführt werden.

Fehlerbehebung: Warum ist meine Weboberfläche blockiert?

Die Firewall von Trooper.AI steuert alle eingehenden und ausgehenden Ports, einschließlich der für Web-Oberflächen verwendeten.

Wenn der von Diensten wie verwendeten Port:

• OpenWebUI
• Jupyter Notebook
• interne Dashboards
• benutzerdefinierte KI-Tools

Die Web-Oberfläche ist ebenfalls nicht erreichbar, wenn der Zugriff über das Firewall blockiert wird.

Eine gängige sichere Konfiguration besteht darin, den Zugriff auf Ihren Unternehmens-IP-Bereich einzuschränken.

Beispiel:

Allow 203.0.113.0/24  Port 14511
Deny  0.0.0.0/0       Port 14511

Dies erlaubt nur Benutzern Ihrer Organisation den Zugriff auf die sichere Weboberfläche.

Fehlerbehebung: Warum ist SSH nicht erreichbar?

Überprüfen Sie im Falle eines fehlgeschlagenen SSH-Zugriffs Folgendes:

1. Installieren Sie keine lokale UFW (Firewall), die Ihren internen SSH-Port 22 blockiert.
2. Ihre IP-Adresse muss innerhalb des erlaubten CIDR-Bereichs liegen
3. Die Erlaubnisregel für den öffentlichen SSH-Port (z. B. 14511 – nicht 22, das ist der interne Port) muss über allen Sperrregeln stehen.

Zusätzlich prüfen Sie bitte die SSH-Zulassungseinstellung am unteren Ende der Firewall-Konfigurationstabelle.

Wenn SSH am unteren Ende der Firewall-Einstellungen deaktiviert ist, akzeptiert der Server nur SSH-Verbindungen von IP-Adressen, die durch die oben genannten Regeln erlaubt sind.

Fehlerbehebung: Warum wird der Datenverkehr weiterhin blockiert, obwohl ich eine Regel hinzugefügt habe?

Verkehr, der keine Regel trifft, folgt den im Firewall-Einstellungen definierten Standardrouten.

Falls eine Regel nicht exakt übereinstimmt (falscher IP-Bereich, falsche Portnummer oder falsche Reihenfolge), kann der Traffic auf die Standard-Sperrregel („deny“) durchgereicht werden.

Immer überprüfen:

• Regelreihenfolge – die erste Übereinstimmung gewinnt (von oben nach unten)
• CIDR-Bereich – siehe Beispiele
• Portnummer – im Manage-Dashboard sichtbar
• Standardrouteverhalten

Letzter Test: Probieren Sie "ALLE ERLAUBEN" zu aktivieren und prüfen Sie, ob das funktioniert. Falls ja, liegt es daran, dass eine Regel darüber nicht korrekt passt.