Gameserver mit Starlink hosten: über ein kostenloses VPS-Relay

Wie Spieler einen Server zu Hause ohne Portfreigabe erreichen

Hat dein Router keine öffentliche IPv4-Adresse, kommen die Verbindungen der Spieler aus dem Internet zuerst am NAT deines Anbieters an, und eine Portfreigabe auf deinem eigenen Router bekommt sie nur, wenn auch dieses NAT den Port weiterleitet. Die Anleitung zum Selbsthosten ohne öffentliche IPv4-Adresse zeigt, wie das an einem Starlink-Anschluss zu Hause aussieht.

Starlinks Hilfeseite What IP address does Starlink provide? sagt, dass seine Standardkonfiguration für IPv4 Carrier-Grade NAT (CGNAT) nutzt und dass diese Richtlinie „default“ „does not allow inbound traffic“, also keinen eingehenden Datenverkehr zulässt (abgerufen im Oktober 2026). Eine öffentliche IPv4-Adresse am Anschluss selbst ist eine Option der Priority-Tarife, sagt Starlinks Hilfeseite zum Einstellen einer öffentlichen IP.

Ein Relay dreht die Verbindung um. Der Weg hat vier Schritte:

1. Das Spiel eines Spielers verbindet sich mit der öffentlichen IPv4-Adresse einer Cloud-VM, der Relay-VM, auf dem Port des Spiels.
2. Ein Relay-Programm auf der VM nimmt die Verbindung an und öffnet eine eigene Verbindung zur Adresse des Gameservers in einem Tailnet, dem privaten Netz, dem deine Rechner mit Tailscales Client beitreten.
3. Das Tailnet trägt diese Verbindung nach Hause, direkt zwischen den beiden Rechnern oder über einen DERP-Relay-Server. Tailscales Seite zu Verbindungsarten sagt, dass jede Verbindung zuerst über DERP weitergeleitet wird und direkt wird, wo es geht, und dass manche Netze, die sie Hard NAT nennt, den direkten Weg verhindern (abgerufen im Oktober 2026).
4. Der Gameserver antwortet auf demselben Weg zurück.

Spieler verbinden sich nur mit der öffentlichen Adresse der Relay-VM, und das Relay, nicht der Spieler, öffnet die Verbindung zu dir nach Hause.

Minecraft Java beantwortete 30 von 30 Serverlisten-Pings über das Relay

Ich hoste so einen Server für Minecraft Java Edition, in Docker zu Hause an einem Starlink-Anschluss. Spieler verbinden sich mit einer kostenlosen Cloud-VM mit öffentlicher IPv4-Adresse, auf der socat jede TCP-Verbindung auf Port 25565 über mein Headscale-Tailnet, das auf WireGuard läuft, an den Gameserver weiterreicht. Die Richtlinie des Tailnets habe ich so eingestellt, dass die Relay-VM zu Hause diesen einen Port erreicht und sonst nichts.

Eine Abfrage auf dem Gameserver im Oktober 2026 fand das Image itzg/minecraft-server mit online-mode, Whitelist und enforce-whitelist, alle eingeschaltet. Docker veröffentlicht TCP 25565 dorthin, nicht UDP.

Der Test lief im Oktober 2026 von einem per Kabel angeschlossenen Computer im Heimnetz, in drei Durchgängen mit je 10 Runden, alle an einem Tag, jede Abfrage mindestens 2 s nach der vorigen. Jede Runde baute eine bloße TCP-Verbindung zur öffentlichen Adresse der Relay-VM auf Port 25565 auf, dann einen Serverlisten-Ping durch das Relay: die Statusanfrage, die ein Minecraft-Client sendet, um einen Server in seiner Liste anzuzeigen, gefolgt von Ping und Pong auf derselben Verbindung. Der Test meldet sich nie an. Vor jedem Durchgang wurde die Route zur Adresse der VM geprüft, und sie ging über die Standardroute des Anschlusses zu Hause hinaus, nicht über das Tailnet. In jedem Durchgang stimmte die Statusantwort durch das Relay mit der überein, die direkt vom Gameserver über das Tailnet gelesen wurde, das Relay führte also zu diesem Server.

Der eine direkte Ping, der fehlschlug, und zwei, die erst verbunden waren, nachdem ihr erstes Paket erneut gesendet wurde, liefen über den direkten Tailnet-Weg innerhalb des Heimnetzes. Das Relay antwortete in denselben Runden normal. Warum der direkte Weg hängen blieb, wurde nicht untersucht, da er nur eine Kontrolle war.

Die Pings des Tests hinterließen keine Zeile im Log des Gameservers. Die vorhandenen Spielerzeilen im Log, von früheren Anmeldungen, tragen alle dieselbe private Adresse aus dem Netz, das Docker auf diesem Rechner eingerichtet hat: nie die Tailnet-Adresse der Relay-VM und nie die eigene Adresse eines Spielers. Das Log zeigt nicht, auf welchem Weg diese Spieler hereinkamen.

Die Relay-Strecke, von der VM zum Gameserver und zurück, lag bei etwa 20 ms (eine Schätzung)

Eine Umlaufzeit (Round-Trip-Time, RTT) durch das Relay umfasst die Strecke vom Spieler zur Relay-VM und die Relay-Strecke: von der VM über das Tailnet zum Gameserver und zurück, samt der Weiterleitung durch das Relay selbst. Die Relay-Strecke lag bei etwa 20 ms, als Schätzung. Das ist der Median von 27 Runden, und die Mediane der drei Durchgänge reichten von 17,9 bis 23,6 ms. Der Satelliten-Internet-Vergleich stellt diese Schätzung neben die minimale Umlaufzeit über einen geostationären Satelliten.

Für jede Runde nimmt die Schätzung die Zeit von Ping bis Pong durch das Relay, abzüglich der Umlaufzeit derselben Verbindung zur VM, kurz zuvor gemessen, und abzüglich der eigenen Antwortzeit des Gameservers, direkt über das Tailnet gemessen. Die Teile wurden nicht im selben Moment gemessen, und die Umlaufzeit des Anschlusses zu Hause ändert sich von Sekunde zu Sekunde, wie die Anleitung zu Ping-Spitzen zeigt. Drei Runden blieben außen vor, weil ihre direkte Verbindung, auf die sich die Schätzung stützt, fehlschlug oder ein Paket erneut senden musste.

Testcomputer und Gameserver teilen sich den Anschluss zu Hause, also verließ jede Abfrage durch das Relay das Haus über Starlink zur VM und kam über Starlink innerhalb des Tailnets zurück. Bei einem Spieler anderswo tritt seine eigene Strecke zur VM an die Stelle der des Testcomputers, und die Relay-Strecke bleibt.

Ein TCP-Relay transportiert TCP-Spiele; UDP-Spiele brauchen ein UDP-Relay

Ein TCP-Relay transportiert nur TCP. Die eigene Dokumentation oder das Wiki jedes Spiels sagt, welches Protokoll sein Server nutzt (abgerufen im Oktober 2026):

Die Zeilen stammen aus den Seiten des Minecraft Wiki zu server.properties und Bedrock Dedicated Server, einem Community-Wiki; der Seite Server im Official Terraria Wiki; der Seite Multiplayer im Factorio Wiki, die sagt „Factorio uses UDP only“, Factorio nutzt also nur UDP; der Seite Requirements in Pocketpairs Palworld Server Guide; der Seite Dedicated server setup im ARK Official Community Wiki; und der Seite Dedicated servers im Official Satisfactory Wiki. Bei jedem lässt sich der Standard-Port ändern. Die Terraria-Seite sagt, der Server „runs on TCP port 7777 by default“, laufe standardmäßig also auf TCP-Port 7777, und ihr Hinweis für Cloud-Anbieter sagt, 7777 für TCP und UDP zu öffnen. Die Satisfactory-Seite sagt „Port redirection is not supported at the moment for the standard port“, eine Umleitung des Standard-Ports wird derzeit also nicht unterstützt, deshalb behält ein Relay dort die Nummer dieses Ports, standardmäßig 7777, auf beiden Seiten bei. Der Port für zuverlässige Nachrichten, standardmäßig TCP 8888, „can be remapped“, lässt sich also mit dem Kommandozeilenparameter -ExternalReliablePort= umlegen, sagt dieselbe Seite.

An der Adresse des getesteten Relays bekam ein UDP-Paket, der Discovery-Ping, mit dem ein Bedrock-Client Server sucht, auf Port 25565 innerhalb von 5 s keine Antwort. Dasselbe Paket an Port 25566, auf dem nichts läuft, bekam dieselbe Stille, während ein Serverlisten-Ping über TCP auf 25565 in derselben Minute antwortete. Auf dem Gameserver veröffentlicht Docker 25565 nur für TCP.

Kostenlose Cloud-VMs haben Bedingungen, die du zuerst prüfen solltest

Das Relay braucht eine VM mit öffentlicher IPv4-Adresse, die läuft, solange gespielt wird. Mehrere Cloud-Anbieter veröffentlichen kostenlose Angebote: das AWS Free Tier, Azures kostenlose Dienste, Google Clouds kostenlose Funktionen und das Oracle Cloud Free Tier (Seiten abgerufen im Oktober 2026). Kostenlose Angebote ändern sich, also lies die aktuelle Seite des Anbieters, bevor du auf einem aufbaust. Achte darauf:

• ob die VM ohne Enddatum kostenlos bleibt oder nur für eine Testphase;
• ob die kostenlose VM eine öffentliche IPv4-Adresse enthält und ob diese Adresse getrennt berechnet wird;
• wie viel ausgehender Datenverkehr pro Monat kostenlos ist;
• ob der Anbieter eine VM zurückfordern kann, die er für ungenutzt hält;
• was die Anmeldung voraussetzt, etwa eine Zahlungskarte.

Ein Relay schickt den Datenverkehr jedes Spielers durch die VM, also wächst ihr ausgehender Datenverkehr mit Spielern und Spielzeit.

Aufbau mit einem offenen Port, einer Tailnet-Regel und der eigenen Anmeldung des Spiels

Diese Schritte nutzen Minecraft Java Edition. Für ein anderes TCP-Spiel nimm seinen Port aus der Tabelle oben.

1. Starte zu Hause den Gameserver in Docker, mit den eigenen Anmeldeprüfungen des Spiels eingeschaltet. Das Image itzg/minecraft-server nimmt seine Einstellungen als Umgebungsvariablen, laut seiner Dokumentation (abgerufen im Oktober 2026):

   docker run -d -it --name mc -p 25565:25565 \
     -e EULA=TRUE -e ONLINE_MODE=TRUE \
     -e WHITELIST=your-friend-1,your-friend-2 \
     -e ENFORCE_WHITELIST=true \
     -v "$PWD/data:/data" itzg/minecraft-server

   • -p 25565:25565 veröffentlicht den Port für TCP. Dockers Seite zum Veröffentlichen von Ports ordnet einen Port TCP zu, wenn er nicht auf /udp endet (abgerufen im Oktober 2026).
   • EULA=TRUE akzeptiert die Endbenutzer-Lizenzvereinbarung von Minecraft; die Dokumentation des Images sagt, diese Variable „always include“, also immer mitzugeben.
   • ONLINE_MODE=TRUE lässt online-mode eingeschaltet, was das Minecraft Wiki als „Whether to only allow players verified with the Minecraft account database to join“ beschreibt, also ob nur Spieler beitreten dürfen, die über die Minecraft-Kontodatenbank geprüft sind. Standardmäßig ist es eingeschaltet.
   • WHITELIST schaltet die Whitelist ein und listet, wer beitreten darf. Setze die Profilnamen deiner Spieler aus der Java Edition anstelle von your-friend-1,your-friend-2 ein; die Dokumentation des Images sagt, diese zu verwenden, „not Xbox gamertags“, also keine Xbox-Gamertags.
   • ENFORCE_WHITELIST=true setzt enforce-whitelist. Ist es eingeschaltet, gilt laut Minecraft Wiki: „players not present on the whitelist get kicked from the server after the server reloads the whitelist file“, Spieler, die nicht auf der Whitelist stehen, fliegen also vom Server, sobald dieser die Whitelist-Datei neu lädt.
   • -v "$PWD/data:/data" behält die Welt in einem Ordner data dort, wo du den Befehl ausführst, denn das Image speichert die Daten des Servers im Container unter /data.

   Andere Spiele haben eigene Prüfungen beim Beitreten, etwa das Serverpasswort im Startbefehl von ARK, auf derselben Wiki-Seite wie seine Ports.

2. Besorge dir eine Cloud-VM mit öffentlicher IPv4-Adresse (was du bei einem kostenlosen Angebot prüfen solltest). Das Relay braucht darauf nur Tailscales Client und socat.

3. Lass den Rechner des Gameservers und die Relay-VM demselben Tailnet beitreten. Mit Headscale, das diese Seite nicht einrichtet, führt jeder Rechner tailscale up --login-server mit der Adresse deines Headscale-Servers aus, und du bestätigst ihn auf dem Headscale-Server (Headscales Registrierungsmethoden, abgerufen im Oktober 2026). Die Anleitung zum Wechsel weg vom Festnetz behandelt, was ein Tailnet allein erreicht.

4. Erlaube der Relay-VM, den Spielport zu erreichen, und sonst nichts. Headscales Seite zu Richtlinien sagt, dass standardmäßig „no policy is loaded which means that Headscale allows all traffic between nodes“, also keine Richtlinie geladen ist und Headscale allen Verkehr zwischen Knoten erlaubt, dass Headscale die Datei liest, die die Einstellung policy.path seiner Konfiguration nennt, und dass es „needs to be reloaded to pick up changes“, also neu geladen werden muss, um Änderungen zu übernehmen (abgerufen im Oktober 2026). Diese Richtliniendatei erlaubt eine Sache: dass die Relay-VM TCP-Verbindungen zu Port 25565 auf dem Gameserver öffnet. Unter Headscale 0.29.7 ließ sich diese Richtlinie im Oktober 2026 laden, headscale nodes tag setzte beide Tags und lehnte einen Tag ab, den die Richtlinie nicht definiert, und die Regeln, die Headscale daraus baute, erlaubten nur TCP zu Port 25565 auf dem Gameserver, vom Relay aus; für diese Prüfung war kein Client verbunden.

   {
     "tagOwners": {
       "tag:game-relay": [],
       "tag:game-server": []
     },
     "acls": [
       {
         "action": "accept",
         "src": ["tag:game-relay"],
         "proto": "tcp",
         "dst": ["tag:game-server:25565"]
       }
     ]
   }

   Tailscales Syntaxreferenz für Richtlinien, deren Dateiformat Headscale nutzt, sagt, Zugriffsregeln „deny access by default“, verweigern den Zugriff also standardmäßig. Sobald diese Richtlinie geladen ist, wird deshalb alles blockiert, was sie nicht erlaubt: Wenn andere Geräte in deinem Tailnet einander erreichen müssen, füge Regeln für sie hinzu. Ohne "proto": "tcp" gilt laut derselben Referenz: Eine Regel „applies to all TCP and UDP traffic“, gilt also für allen TCP- und UDP-Verkehr. In Tailscales Syntax ist eine leere Liste unter tagOwners eine Kurzform für die Admins des Tailnets; unter Headscale setzt der Administrator Tags mit dem Befehl headscale nodes tag im nächsten Schritt. Headscales Seite zu Richtlinien empfiehlt Grants, Tailscales neuere Regelsyntax, und unterstützt auch Regeln wie diese.

5. Versieh die beiden Rechner auf dem Headscale-Server mit Tags, mit den IDs, die headscale nodes list für sie zeigt, anstelle von 1 und 2, wie Headscales Seite zu Tags es beschreibt (abgerufen im Oktober 2026):

   headscale nodes list
   headscale nodes tag -i 1 -t tag:game-server
   headscale nodes tag -i 2 -t tag:game-relay

6. Starte auf der Relay-VM das Relay. game-server steht für den Namen oder die Adresse des Gameservers im Tailnet:

   socat TCP4-LISTEN:25565,fork,reuseaddr \
     TCP4:game-server:25565

   socats Handbuch nennt eine TCP4-LISTEN-Adresse mit einer TCP4-Adresse „a simple TCP port forwarder“, eine einfache TCP-Portweiterleitung. Mit fork gilt für jede Verbindung, dass socat „handles its channel in a child process“, seinen Kanal also in einem Kindprozess bearbeitet, sodass sich mehrere Spieler gleichzeitig verbinden können. reuseaddr „Allows other sockets to bind to an address even if parts of it (e.g. the local port) are already in use by socat“, erlaubt also anderen Sockets, sich an eine Adresse zu binden, auch wenn Teile davon, etwa der lokale Port, schon von socat genutzt werden (abgerufen im Oktober 2026). Starte den Befehl unter dem Dienstmanager der VM, damit er nach einem Neustart wieder startet.

7. Öffne einen Port. Erlaube in der Firewall des Anbieters für die VM, und in der eigenen Firewall der VM, falls sie eine hat, TCP 25565 von überall. Halte jeden anderen Port geschlossen, außer dem, über den du dich auf der VM anmeldest, wenn du das über das Internet tust.

8. Gib den Spielern die öffentliche IPv4-Adresse der Relay-VM, wie 203.0.113.10 in den Beispielen dieser Seite, oder einen DNS-Namen, den du darauf zeigen lässt, etwa mc.example.com.

Drei Wege, ein UDP-Spiel weiterzuleiten, laut ihrer Dokumentation

UDP hat keine Verbindung, die ein Relay annehmen könnte. socats Handbuch sagt, dass bei UDP „no real connection is established; data has to arrive from the peer first“, also keine echte Verbindung aufgebaut wird und zuerst Daten von der Gegenseite kommen müssen, und dass „no end-of-file condition is specified in UDP“, UDP also kein Dateiende kennt. Ein UDP-Relay merkt sich daher jeden Spieler und muss ihn nach einer Zeit ohne Daten verwerfen.

Bei jeder Methode unten veröffentlicht der Gameserver seinen Port für UDP (-p 34197:34197/udp in Docker), und die Richtlinienregel bekommt "proto": "udp" und den Port des Spiels. Der Port von Factorio, 34197, dient als Beispiel.

socat im UDP-Modus

Auf der Relay-VM:

socat -T 60 UDP4-LISTEN:34197,fork,reuseaddr \
  UDP4:game-server:34197

-T ist socats „Total inactivity timeout“, ein Timeout bei völliger Inaktivität, den das Handbuch „Useful with protocols like UDP that cannot transfer EOF“ nennt, also nützlich bei Protokollen wie UDP, die kein Dateiende übertragen können. Hier beendet er den Kindprozess eines Spielers nach 60 Sekunden ohne Daten. Bis socat 1.8.0.0 hieß -T 0 kein Timeout; seit 1.8.0.1 heißt es 0, sagt das Handbuch, also gib eine Zahl an.

Destination NAT im Kernel der VM

Die NAT-Seite im nftables-Wiki zeigt die beiden Regeln, die das braucht: eine Regel dnat to in einer Prerouting-Kette vom Typ nat, die die Pakete des Spielports an die Tailnet-Adresse des Gameservers weiterschickt, und masquerade in einer Postrouting-Kette, wobei „the source address is automagically set to the address of the output interface“, die Quelladresse also automatisch auf die Adresse der ausgehenden Schnittstelle gesetzt wird, hier die Tailnet-Adresse der VM, sodass der Gameserver der VM antwortet. Der Kernel muss auch Pakete zwischen seinen Schnittstellen weiterleiten, das ist die Einstellung net.ipv4.ip_forward: „Forward Packets between interfaces“, in der Dokumentation des Kernels.

Das Stream-Modul von nginx

Im Stream-Core-Modul von nginx öffnet listen 34197 udp reuseport; in einem server-Block einen Socket „for working with datagrams“, für die Arbeit mit Datagrammen; die Seite sagt, reuseport „should also be specified“, solle also ebenfalls angegeben werden, damit Pakete von einer Adresse und einem Port in einer Sitzung bleiben. Das Stream-Proxy-Modul reicht sie mit proxy_pass an den Gameserver weiter, und proxy_timeout, standardmäßig 10 Minuten, schließt eine Sitzung, wenn „no data is transmitted within this time“, in dieser Zeit also keine Daten übertragen werden. Die Seite des Core-Moduls sagt, es „is not built by default“, werde also standardmäßig nicht mitgebaut, und brauche die Build-Option --with-stream, also prüfe, ob dein nginx sie hat.

Bedrock Edition kann mehr als einen Port brauchen. Die Kopie der Datei server.properties im Minecraft Wiki, die mit Bedrock Dedicated Server 1.26.60.6 ausgeliefert wird, setzt transport=nethernet und server-udp-ports=19132, eine Einstellung, die „Configures UDP client transport ports“, also die UDP-Ports für den Transport der Clients festlegt: Das ist ein „Single UDP port shared by all clients“, ein einziger UDP-Port, den alle Clients teilen. Ist sie nicht gesetzt, sagt die Datei, „UDP ports are allocated from the operating system's ephemeral port range“, die UDP-Ports kommen also aus dem Bereich kurzlebiger Ports des Betriebssystems, und ein Relay müsste auch diese Ports transportieren. Mit diesem Transport wird die IPv6-Port-Einstellung der Datei ignoriert, und IPv6 nutzt ebenfalls 19132. Diese Seite hat Bedrock nicht über ein Relay ausprobiert.

Verwaltete Tunnel sparen die VM, laut ihren eigenen Seiten

Keiner davon wurde hier getestet. Jeder betreibt das öffentliche Ende für dich, also gibt es keine VM einzurichten oder zu patchen; dafür transportiert ihr Netz den Datenverkehr deiner Spieler. Alle Seiten wurden im Oktober 2026 abgerufen.

playit.gg nennt sich „a global proxy that lets you host a server without port forwarding“, einen weltweiten Proxy, mit dem du einen Server ohne Portfreigabe hosten kannst, mit einem Agenten auf deinem Rechner: „Only you run the agent, your players just connect.“ Nur du betreibst den Agenten, deine Spieler verbinden sich einfach. Die Startseite nennt ein kostenloses Angebot und einen kostenpflichtigen Premium-Tarif; die Spieleliste dort führt Minecraft Java und Bedrock, Palworld, Terraria, Factorio und einen einfachen Eintrag „UDP“ unter „Free“, und einfache Einträge „TCP“ und „TCP+UDP“, mit einigen anderen Spielen, unter „Requires Playit Premium“.

ngroks Preisseite sagt, dass im Free-Tarif „TCP endpoints also need a verified credit card, and ngrok doesn't charge it“, TCP-Endpunkte also zusätzlich eine bestätigte Kreditkarte brauchen, die ngrok nicht belastet.

Tailscale Funnel „can only listen on ports 443, 8443, and 10000“, kann also nur auf den Ports 443, 8443 und 10000 lauschen, und „only works over TLS-encrypted connections“, funktioniert also nur über TLS-verschlüsselte Verbindungen. Der Standard-Port von Minecraft Java Edition, TCP 25565, ist keiner dieser Ports. Auf Headscales Seite zu Funktionen ist Funnel einer der Punkte ohne Häkchen.

Cloudflare Tunnel braucht für alles außer einem Webdienst Cloudflares Client auf dem Rechner jedes Spielers, wie die Anleitung zum Wechsel weg vom Festnetz zitiert. Die Seite zu Cloudflare Spectrum sagt: „Custom TCP/UDP applications require an Enterprise plan with Spectrum as a paid add-on“, eigene TCP- und UDP-Anwendungen brauchen also einen Enterprise-Tarif mit Spectrum als kostenpflichtiger Erweiterung (zuletzt aktualisiert im April 2026). Die Tabelle protocols per plan (zuletzt aktualisiert im August 2026) führt Minecraft, eine einzelne App, auch für die Tarife Pro und Business, in denen Spectrum eine kostenpflichtige Erweiterung ist.

Ein Mesh-VPN, dem jeder Spieler beitritt, braucht gar kein Relay, aber jeder Spieler installiert den Client und tritt deinem Tailnet bei (was ein Mesh-VPN erreicht).

Hier noch nicht getestet

• Ein Spieler in einem anderen Netz. Jede Abfrage lief vom selben Anschluss zu Hause, den auch der Gameserver nutzt.
• Echtes Spielen. Keine Abfrage meldete sich an oder spielte, also sind die Umlaufzeit, die das Spiel anzeigt, mehrere Spieler gleichzeitig und eine ganze Sitzung ungetestet.
• UDP über irgendein Relay, Bedrock Edition und jedes Spiel außer Minecraft Java Edition.
• Die Seite der Relay-VM. Ob ihr Weg nach Hause direkt oder über einen DERP-Relay-Server lief, ihre Last, ihre Firewall-Einstellungen und ob die Tailnet-Richtlinie sie davon abhält, sonst etwas zu Hause zu erreichen, wurden von der VM aus nicht geprüft.
• Was der Gameserver für einen Spieler protokolliert, der über das Relay kam. Die Spielerzeilen im Log stammen von früheren Anmeldungen, deren Weg nicht bekannt ist.
• Eine VM in einer anderen Region, andere Tage und Uhrzeiten, die verwalteten Tunnel und das Spiel auf der VM selbst zu betreiben.

Wie die Tests zu Hause für ein Homelab zusammenpassen, steht im Homelab-Urteil.