Velocity und Paper: Prüft den Direktzugriff auf eure Backends

Prüft vor der Freigabe eines Netzwerks mit Velocity und Paper zwei Dinge getrennt: Spieler erreichen die Spielserver über den Proxy mit der richtigen Identität, und aus einem nicht autorisierten Netz ist keine direkte Verbindung zu diesen Servern möglich. Modern Forwarding prüft zusätzlich die Herkunft weitergeleiteter Spielerdaten, ersetzt aber keine Firewall. Der Sicherheitsleitfaden von Velocity empfiehlt, diese Schutzmaßnahmen zu kombinieren.

Dieser Prüfplan richtet sich an Communitybetreiber, die ein Java-Netzwerk mit authentifizierten Konten vorbereiten. Als Backend bezeichnen wir einen Paper-Spielserver hinter dem Proxy, etwa Lobby oder Survival. Der Plan gilt für aktuelles Paper mit Velocity Modern Forwarding. Für ältere Clients, Floodgate oder modifizierte Server müssen zusätzlich Kompatibilität und Identitätszuordnung geprüft werden. Wir haben diese Tests nicht auf eurer Infrastruktur ausgeführt.

Haltet den vorgesehenen Verbindungsweg fest

Erstellt ein kurzes Betriebsblatt: öffentlicher Einstiegspunkt, Backends mit Ports, vom Proxy verwendete Zieladressen und Zuständigkeit für jede Netzwerkregel. Nehmt weitere öffentliche Adressen der Maschinen ebenfalls auf. Ein einprägsamer Hostname für Spieler belegt nicht, dass andere Zugänge geschlossen sind.

Als Beispiel dient ein Netzwerk mit einem Proxy, einer Lobby und einem Survival-Server. Vor der Freigabe müssen beide vorgesehenen Abläufe funktionieren: der Einstieg in die Lobby und der Wechsel zu Survival. Ein Eintrag in der Mehrspielerliste reicht dafür nicht aus.

Ergänzt im Betriebsblatt:

• Builds von Velocity und Paper sowie Versionen der Plugins für Zugang und Berechtigungen.
• Eine verantwortliche Person für den Test und eine für die Freigabe; beide Aufgaben dürfen bei derselben Person liegen.
• Ein Testkonto mit bekanntem Inventar und bekannten Rechten, ohne unnötige Administratorrechte.
• Das Vorgehen zur Wiederherstellung der vorherigen Konfiguration bei weiterhin geschlossenem öffentlichem Zugang.

Wenn ihr verwaltete Infrastruktur beauftragt, hilft dieses Blatt bei der Abstimmung: Welche Verbindungswege prüft das technische Team, und welche Nachweise übergibt es?

Wählt eine passende Netzwerkisolation

Velocity beschreibt die Bindung an 127.0.0.1, wenn Proxy und Backends auf einer vertrauenswürdigen Maschine laufen, sowie verschlüsselte Tunnel zwischen Maschinen. Bei verteilten Installationen müssen Netzwerkregeln zu den autorisierten Proxys passen. Lest die Möglichkeiten zur Isolation, bevor ihr eine Konfigurationsanleitung übernehmt.

Formuliert die gewählte Architektur als überprüfbare Bedingung: „Der Survival-Port nimmt Verbindungen nur über den autorisierten Weg an.“ Lasst dokumentieren, wie das umgesetzt wird, einschließlich Providerregeln und veröffentlichter Containerports. Derselbe physische Host macht eine localhost-Anleitung nicht automatisch für jede Architektur geeignet.

Öffnet einen Backend-Port zur Fehlersuche nicht vorübergehend für das gesamte Internet. Lasst die Beschränkung bestehen und prüft zunächst Adressen, Port, lauschende Schnittstelle und Verbindungsweg vom autorisierten Ursprung. Untersucht ausschließlich eigene Systeme oder solche, für deren Prüfung ihr eine Erlaubnis habt.

Verwechselt die drei Authentifizierungseinstellungen nicht

Im hier beschriebenen Aufbau authentifiziert der Proxy die Spieler mit online-mode = true in velocity.toml. Dort stehen außerdem player-info-forwarding-mode = "modern" und mit forwarding-secret-file der Verweis auf die Datei mit dem gemeinsamen Geheimnis. Die Velocity-Konfigurationsreferenz erläutert diese Optionen.

Für jedes Backend nennt die offizielle Anleitung zu Modern Forwarding online-mode=false in server.properties und settings.bungeecord: false in spigot.yml. Damit übernimmt der Proxy die Authentifizierung. Dieser Schritt gehört in den geschützten Gesamtaufbau, den ihr gerade prüft.

Kontrolliert in config/paper-global.yml die vorhandenen Schlüssel, statt die gesamte Datei zu ersetzen:

Schlüssel	Bedingung für diesen Aufbau
proxies.velocity.enabled	true
proxies.velocity.online-mode	true, passend zum Proxy
proxies.velocity.secret	Stimmt mit dem in Velocity konfigurierten Geheimnis überein

Die globale Paper-Konfigurationsreferenz beschreibt den Zusammenhang mit Spielerdaten und UUIDs. Prüft neben dem sichtbaren Namen auch die UUID, also die Kennung des Spielers. proxies.velocity.online-mode und online-mode in server.properties haben in diesem Aufbau bewusst unterschiedliche Werte und Aufgaben.

Vergleicht die Geheimnisse über einen privaten Administrationskanal. Im Prüfbericht steht nur „stimmt überein“ oder „stimmt nicht überein“, niemals der Wert. Er gehört weder in Screenshots noch in Tickets oder Repositorys. Startet die betroffenen Komponenten im Wartungsfenster neu und prüft anschließend die tatsächlich angewendete Konfiguration.

Arbeitet eine kleine Abnahmematrix ab

Bereitet zwei Prüfstandorte vor: einen außerhalb der autorisierten Netze und einen entlang des erlaubten Proxy-Verbindungswegs. Notiert Zeitpunkt, Ursprung, Ziel und beobachtetes Ergebnis. Die Tabelle enthält Soll-Ergebnisse, keine bereits durchgeführten Messungen.

Prüfung	Voraussetzung zum Fortfahren
Reguläre Verbindung über den Proxy	Das Konto erreicht die Lobby und anschließend Survival
Identitätsprüfung auf jedem Backend	UUID, Inventar und Rechte entsprechen der Erwartung für Konto und Server
Direkte TCP-Verbindung von außen zu jedem Backend-Port	Es kommt keine Verbindung zustande
Zugriff über den autorisierten Weg	Der Proxy erreicht alle vorgesehenen Backends
Neustart und Wiederholung	Erlaubte Wege funktionieren weiterhin, gesperrte bleiben gesperrt

Der negative Netzwerktest verlangt mehr als „Minecraft hat mich getrennt“. Wenn TCP eine Verbindung aufbaut und das Spiel den Client anschließend ablehnt, wurde eine Ablehnung auf Anwendungsebene beobachtet. Die vereinbarte Netzwerkisolation ist damit noch nicht belegt. Umgekehrt ist ein einzelner Timeout kein vollständiger Nachweis: Bestätigt das Ziel und prüft mit dem zugehörigen positiven Test, dass das Backend funktioniert.

In einer isolierten Testumgebung könnt ihr die Prüfung des gemeinsamen Geheimnisses ergänzen. Verwendet einen autorisierten Testproxy mit einem absichtlich abweichenden Geheimnis, prüft die Ablehnung und wiederholt den Versuch mit dem richtigen Wert. Ändert dafür weder das Produktionsgeheimnis noch die öffentlichen Freigaben der Produktionsserver. Protokolliert nur das Ergebnis.

Leitet aus Fehlern eine Freigabeentscheidung ab

Funktioniert die Lobby, aber Survival nicht, vergleicht beide Verbindungswege und Konfigurationen. Das grenzt die Untersuchung ein, beweist jedoch noch keine konkrete Ursache. Bei leerem Inventar oder unerwartetem Rang bleibt die Freigabe ausgesetzt. Untersucht zuerst Identität und zugeordnete Daten, bevor ihr neue Profile anlegt oder Spielerdateien verschiebt.

Ein weiterhin offener Direktzugang bleibt ein ungelöster Punkt, selbst wenn Modern Forwarding die Anmeldung ablehnt. Ändert sich das Verhalten nach einem Neustart, prüft die tatsächlich geladene Konfiguration und die Zuständigkeit für dauerhaft gespeicherte Netzwerkregeln. Bewahrt den vorherigen Bericht auf, wiederholt betroffene Tests und prüft zusätzlich den vollständigen regulären Verbindungsablauf.

Zur Übergabe gehören die ausgefüllte Matrix, Softwareversionen, Zuständigkeiten, offene Probleme und Anlässe für erneute Prüfungen. Ein neues Backend, ein Hostingwechsel oder eine geänderte Authentifizierung erfordern eine erneute Kontrolle des Verbindungswegs. Dieser Test bescheinigt weder Kapazität noch DDoS-Schutz oder Fehlerfreiheit sämtlicher Plugins.

Bei eigenem Code für Zugang, Berechtigungen oder Identität gehören diese Prüfungen auch in den Umfang der Minecraft-Entwicklung. Mineando übernimmt bezahlte Projekte mit individuell vereinbartem Umfang. Laufender Support wird gesondert vereinbart.