Wie Spieleserver über openVPN hosten?

[Drakrochma]

Hallo,

ich hoffe die Frage ist hier richtig aufgehoben, zur Not sehr gerne auch verschieben

Ich hab bei Strato einen V-Server mit Linux auf dem ich eigentlich meine dedicated server für einige Spiele laufen lassen wollte.
Leider gibt es für das ein oder andere Spiel keine serverdaten für Windows.
Daher hab ich auf dem Server einen openVPN-Server aufgesetzt und für jeden Rechner der Kumpels einen client-key generiert.
Ich hab hier einen Windowsrechner "übrig", der dann als eigentlicher Server laufen soll.
Dem hab ich genauso einen client-key generiert.
Wenn ich mich mit einem der Rechenr beim openVPN-server anmelde bekomme ich auch sauber eine IP zugewiesen.
Wenn ich dann versuche mit einem der Rechner aus den Spielen raus auf die IP des "Windowsserver" zuzugreifen, findet der aber nix.
Ich hab allen Rechnern die Firewall entsprechend konfiguriert um openVPN und die Spiele, bzw. auf dem Spieleserver die Serversoftware, durchzulassen.

• Könnt ihr mir weiter helfen was ich noch kontrollieren/berücksichten/machen sollte?
• Warum kann sich zwar jeder Rechner beim openVPN-server anmelden und bekommt ne IP, die Clients sehen sich aber untereinander scheinbar nicht?
• Kann ich irgendwo kontrollieren welche Clients aktuell verbunden sind?
• Muss ich noch irgendwas einstellen?
• muss ich was ganz anders machen?

Direkt verbinden auf den Spieleserver geht leider nicht, da ich Glasfaser und damit dann auch dSlite und daher keine offizielle ipV4 habe und Deutsche Glasfaser mir auch nix passendes zur Verfügung stellen will.
Andere Anbieter für ne öffentliche IPv4 haben wir versucht.
Die waren aber allesamt irgendwie nicht performat, instabil oder haben sosnt wie gesponnen.
Daher openVPN.

 

[kamanu]

Ich könnte mir vorstellen, dass es irgendwo eine Einstellung gibt die verhindert, dass VPN-Clients untereinander Zugriff haben.
Generell auch mal Wireguard für das Thema VPN anschauen. Ist wesentlich effizienter und fixer.

 

[HighTech-Freak]

Ja, client-to-client muss explizit gesetzt sein.

OK ich beschreib lieber beide Szenarien bzgl keep alive:

• Wenn der OpenVPN-Server auch der Game-Server ist: keine besonderen Settings notwending. VPN Verbindung wird ohnehin von den Clients initiert.
• Wenn der GameServer selbst VPN Client ist: Keep-Alive zwangsläufig notwendig, da uU sonst keine eingehenden Pakete vom OpenVPN-Server oder anderen VPN-Clients ankommen (der OpenVPN-Server kann sich ja nicht eigenständig zu einem Client verbinden). Würde 10s ansetzen für Keep-Alive Pakete.

 

[Renegade334]

Wie schon oben geschrieben ist Client zu Client normal nicht an, was auch der Sicherheit dient.

Direkt verbinden auf den Spieleserver geht leider nicht, da ich Glasfaser und damit dann auch dSlite und daher keine offizielle ipV4 habe und Deutsche Glasfaser mir auch nix passendes zur Verfügung stellen will.

Man kann inzwischen auch sehr viele Spiele über IPv6 hosten. Dank DynDNS muss man dann auch nicht die elend lange IP eingeben. Allerdings hatte ich bisher auch 2 Spiele technisch wirklich nur IPv4 konnten. Kommt da leider stark auf die Entwickler an.

 

[Raijin]

Neben der Einstellung client-to-client gibt es noch die Thematik mit der toplogy. Ist topology net30 konfiguriert (Standard für ältere OpenVPN-Versionen), bekommt jeder Client ein eigenes /30 Subnetz. Das heißt jeder Client befindet sich in einem eigenen Subnetz, in dem sich nur der VPN-Server und der VPN-Client selbst befinden, mehr nicht. Daher sollte stets toplology subnet verwendet werden damit alle Clients mit den anderen Clients und dem Server in ein und demselben Subnetz liegen.

Da ich mir aus dem Stegreif nicht sicher bin ob topology subnet default ist - früher war sie es nicht - kann es sein, dass man diese Option nicht mehr explizit setzen muss. Man sollte jedoch anhand der IPs+Subnetzmaske der VPN-Clients verifizieren, dass alle im selben Subnetz liegen. Falls nicht, die besagte Option in die OpenVPN-Konfiguration im Serve einbauen.

 

[Drakrochma]

Sorry, wahrscheinlich ne doofe, sicher aber ne peinliche Frage:
Wo finde ich die conf-datei für den Server?

in der /etc/openvpn/server/server.conf hab ich eine Zeile mit "client-to-client" aufgenommen, die Clients sehen sich aber immer noch nicht.

"topology subnet" war schon default in der Datei drin.

Hier der Inhalt der Conf:

local 1.2.3.4
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
server-ipv6 fddd:1194:1194:1194::/64
push "redirect-gateway def1 ipv6 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
client-to-client
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
verb 3
crl-verify crl.pem
explicit-exit-notify

Was mach ich falsch ?

 

[Raijin]

Was mach ich falsch ?

Vorher stellt sich die Frage was du konkret damit meinst:

die Clients sehen sich aber immer noch nicht.

Wie testest du das nun?

Machst du einen Ping?
Wenn ja, auf welche IP?
Funktioniert der Ping zum Server?

Oder schaust du in die "Netzwerkumgebung" und erwartest, dass da alle Clients auftauchen?

Oder versuchst du eine konkrete Verbindung herzustellen?
Wenn ja, was und wie verbindest du genau?

Oder startest du den Gameserver und suchst in den Gameclients nach einem aktiven Server?

Es gibt viele potentielle Probleme und noch mehr Ursachen dafür. Je präziser du dich ausdrückst, umso eher kann man Lösungen anbieten. "Sehen" kann ein PC nämlich maximal durch eine Webcam, und ich bezweifle irgendwie, dass du das damit sagen wolltest...

 

[Drakrochma]

@Raijin :
Danke für die Frage

zu den verwendeten IPs:

• Spieleserver hat 10.8.0.4.
• Client hat z.B. 10.8.0.3
• openVPN-Server hat seine öffentliche IP, die wir auch in TS verwenden. (offizielle IP)
  (Da das funktioniert, denk ich mal, dass die IP passen sollte )
• Zusätzlich hat der Server von openVPN die IP 10.8.0.1 bekommen (openVPN-IP)

jeweils gepingt per IP:
Ping vom "Spieleserver" auf die offizielle IP des openvpn-server: wird gefunden (21ms)
Ping vom "Spieleserver" auf die openVPN-IP des openvpn-server: wird gefunden (18ms)
Ping vom "Spieleserver" auf die clients: wird nicht gefunden (XXXX)

Ping vom "Client" auf den openvpn-server: wird gefunden (23ms)
Ping vom "Client" auf die openVPN-IP des openvpn-server: wird gefunden (22ms)
Ping vom "Client" auf den "Spieleserver": wird nicht gefunden (XXXXX)

Passend dazu finde ich in keinem Spiel die dedicated server auf dem "Spieleserver"


In der Netzwerkumgebung taucht nur der Spieleserver auf, da er im selben LAN wie meine Versuchsclients ist.


Zur Art der Verbindung:
Ich hab den openVPN auf dem Server aufgesetzt und dort dann für jeden Client einen generiert.
Auf den Clients ist die Client-software für openVPN installiert und da dann über den zuvor erstellten Key verbunden.
Das Verbinden zum Server funktioniert auch auf allen Clients super.
Nur untereinander geht nix.


Gibt es noch irgendwelche Infos, die ich zusammentragen/zur Verfügung stellen kann?
Bin leider wirklich etwas ratlos und bräuchte da eure Hilfe

 

[Raijin]

In Zukunft am besten Screenshots von ping und Co machen. Selbst formulierte Testergebnisse sind zu unpräzise, weil du ggfs unwissend wichtige Details weglässt.

zu den verwendeten IPs:

• Spieleserver hat 10.8.0.4.
• Client hat z.B. 10.8.0.3
• openVPN-Server hat seine öffentliche IP, die wir auch in TS verwenden. (offizielle IP)
  (Da das funktioniert, denk ich mal, dass die IP passen sollte )
• Zusätzlich hat der Server von openVPN die IP 10.8.0.1 bekommen (openVPN-IP)

Das sieht zunächst einmal gut aus.

In der Netzwerkumgebung taucht nur der Spieleserver auf, da er im selben LAN wie meine Versuchsclients ist.

Das wird tendenziell auch nicht passieren, weil die Netzwerkumgebung ein sehr unzuverlässiges Konstrukt ist, das nicht mal im lokalen Netzwerk - ganz ohne VPN - wirklich funktioniert.



Was du bei VPNs bedenken musst, ist, dass das für den VPN-Host eine separate Netzwerkschnittstelle ist. Unterm Strich ist es dasselbe wie wenn du in einen PC eine zweite Netzwerkkarte einbaust. Für das Betriebssystem ist diese Verbindung ein weiteres Netzwerk und dementsprechend werden für diese Verbindung auch eigene Sicherheitseinstellungen verwendet. Bei Windows ist dies Beispielsweise die Einstufung öffentlich, privat, domäne. Im öffentlichen Profil blockt Windows alles weg, was über diese Verbindung reinkommt, weil es also Bedrohung angesehen wird (öffentlich = Hotspot am Flughafen, im Hotel, etc). Um einen VPN-Client mit Windows also anzupingen, muss Windows die VPN-Verbindung als privat einstufen, ggfs umstellen.


Unter Linux läuft das ein wenig anders, aber bevor man da ins Details geht, kann man erstmal einen Test machen:

tcpdump -i tun0 icmp
tun0 ist dabei das Interface von OpenVPN, kann bei dir aber anders heißen. Mit diesem Befehl wird dir auf der Konsole jedes ein- und ausgehende ICMP-Paket angezeigt, also die Pings und deren Antworten. Diesen Befehl lässt du nun auf dem Linux-Game-Server laufen. Nun pingst du von einem VPN-Client die 10.8.0.4 an, den Game-Server. tcpdump müsste jetzt die eingehden Pings vom Client am Server zeigen - wenn sie denn ankommen. Ist das der Fall, aber der Server schickt keine auf den Ping, wird iptables/nftables den Ping blocken.

Ich weiß, das klingt alles etwas kompliziert, aber Netzwerk, VPN und Server sind eben komplexer als man es von der heimischen Fritzbox oder dem Speedport kennt. Netzwerke sind sehr komplex und es gibt etliche Stolperfallen, wenn man sich nicht damit auskennt - von verschiedenen Betriebssystemen ganz zu schweigen.

 

[Drakrochma]

Und noch mal vielen Dank

tun0 war richtig, bei tun1,2,... kam die Rückmeldung :no such device exists

So sieht das Pingergebnis aus, wenn ich den openVPN-Server anpinge:

So sieht das Pintergebnis aus, wenn ich den Spieleserver (10.8.0.4) anpinge:

So sieht das Pintergebnis aus, wenn ich eine nicht aktive IP (10.8.0.5) anpinge:

Falls es irgendwie hilft, das hier sagt ufw Status:

 

[Raijin]

Kann denn der Server die Clients inkl. Gameserver anpingen?

Der ufw-Status impliziert, dass alles andere als diese 4 Einträge geblockt wird. Dort steht sinngemäß, dass lediglich TCP 22 (das ist der Standardport für ssh) sowie UDP 51820 (inoffizieller Standardport für Wireguard) erlaubt sind. ICMP alias Ping sowie die Ports für das eigentliche Spiel fallen nicht darunter.

Zum Test kannst du die Firewall am Gameserver mal mit ufw disable abschalten. Funktioniert es dann, ist die Ursache für deine Probleme eine zu restriktive Firewall am Server, die blockiert.

Dann müsstest du entweder die Firewall am Server ausgeschaltet lassen - das würde ich bei Servern abgesehen von kurzen Tests grundsätzlich nie tun - oder ufw entsprechend konfigurieren damit es sowohl Pings als auch Gameclients zulässt.

Versuche dann mal folgendes:

Protokoll ICMP Echo Request

Per Default ist Ping nicht erlaubt. Wer es braucht, muss es aktivieren. Leider erlaubt UFW keinen Ausdruck, der direkt ICMP Echo Request (Ping!) erlaubt. Es gibt also keine Eingabe wie "ufw allow icmp" oder ähnliches. Dazu muss man in die Datei /etc/ufw/before.rules gehen und dort ein -A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT einfügen. Danach den Regelsatz von UFW neu laden mit: ufw reload

Quelle: Klick!

Wenn der Ping dann klappt, kannst du einen Schritt weitergehen und die nötigen Ports für deinen Gameserver in ufw freigeben. Das passiert einfach mit dem Kommando

ufw allow 12345/tcp

In diesem Fall gibt ufw den Zugriff auf Port TCP 12345 frei. Wenn's ein UDP-Port ist, dann eben statt tcp udp schreiben.

Welche Ports dein Gameserver benötigt, musst du der Dokumentation des Games entnehmen, im Internet recherchieren oder im Zweifelsfalle mittels netstat -tulpen nachsehen welche Ports der Gameserver tatsächlich öffnet. Minecraft nutzt soweit ich weiß TCP 25565, um nur mal ein Beispiel zu nennen.


Übrigens: Ich hoffe, dass dein gemieteter VPN-Server bei Strato entsprechend gesichert ist. Bisher habe ich den Eindruck, dass du maximal rudimentäre Kenntnisse hast (no offense). Prüfe daher bitte unbedingt ob die Firewall deines VPN-Servers so eingestellt ist, dass sie ausschließlich den VPN-Port erlaubt sowie ssh. Letzteres sollte idealerweise nicht mit Passwordauthentifizierung laufen, sondern mit key-basiertem Login.

Warum ich das explizit erwähne? Du hast sicher schon mal davon gehört oder gelesen, dass Hackergruppen mit groß angelegten Angriffen Systeme wie das Playstation Network, Xbox Live oder andere Dienste lahmlegen. Das tun sie mit Hilfe von Botnetzen, die sich zu einem großen Teil aus auf der Welt verteilten Servern zusammensetzen und aufgrund von schlechten Sicherheitsmaßnahmen gehackt wurden - nicht selten weil der Admin des Servers keinen blassen Schimmer davon hat was er da eigentlich tut....

 

[Drakrochma]

Vielen Dank noch mal
Es geht zwr noch nicht, aber gefühlt hab ich heute wieder mal einiges gelernt

ja, ich hab maximal rudimentäre Kenntnisse von Linux/Servern.
Aber deswegen bin ich ja hier um da mehr zu lernen.
Und nur trocken aus Büchern lernen bringt mir nix, da bleibt bei mir nix hängen.
Deswegen der Server zum basteln/ausprobieren, hinfliegen und klüger aufstehen

Ich kontrolliere eigentlich mindestens ein mal die Woche welche Prozesse grade alle auf dem Server laufen und schaue, ob da irgendwas auffälliges dabei ist.
Falls ja, wird der Server platt gemacht und neu aufgesetzt.
Kam bisher ein mal vor.


Zu den Portfreigaben:
Da hat es scheinbar gestern beim update des servers oder beim installieren von Wireguard was zerschossen/die Freigaben durcheinander gebracht.
Die Freigaben kamen mir beim Bild machen schon komisch vor.
Mittlweile hab ich die Freigabe für Wireguard raus genommen und die fehlenden für TS wieder aufgenommen.

Kann denn der Server die Clients inkl. Gameserver anpingen?

Nein, der Server kann die Clients nicht anpingen.
Auch nach dem Deaktivieren der Firewall geht es nicht.
UFW ist auch wieder reaktiviert

Versuche dann mal folgendes:...

ich hab die Datei geöffnet und hab da genau die Zeile (-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT)schon drin:

# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

Da ich ja nix geändert hab, hab ich zwar keine Hoffnung gehabt, aber zur Sicherheit nochmal mein Glück versucht:
Ping 10.8.0.4:
Ergebnis:

Die ports hab ich mir zumindest mal für 2 Testspiele raus gesucht und die Freigaben aufgenommen.
Brachte aber leider auch nix.


Scheinbar geht aus dem Server nix raus.
Was mich allerdings etwas wundert, denn TS läuft einwandfrei und braucht ja auch die ein oder andere Portfreigabe.
Außerdem hatten wir auf dem Server schon einige Spieleserver installiert und direkt von dort laufen lassen.
Das ging auch ... meistens

 

[HighTech-Freak]

2 Einwürfe:

• client-to-client geht nicht über firewall vom OpenVPN Server, da die Pakete am Server innerhalb des OpenVPN Servers weitergeleitet werden und nicht durch die OS Firewall gehen. Jegliche Firewall Settings am Server sollten lediglich den Traffic an/vom Server betreffen, nicht jedoch traffic von clients an clients.
• Wenn die Clients Windows sind liegt am OpenVPN Interface 99% sicher das Öffentliche Firewall Profil an. Spätestens damit geht Windows ziemlich in einen "Stealth" mode was das Netzwerk betrifft. Selbst wenn nicht, ist das aktuelle Default Setting, dass ICMP ECHO nicht beantwortet wird. Die entsprechenden Regeln müssen erst aktiviert werden.
  

Die klassische Netzwerkerkennung funktioniert auch nur im Privaten Firewall Profil sofern nicht explizit die Regeln unterhalb aktiviert werden:

EDIT: Noch ein Tipp am Rande: SoftPerfect Network Scanner in der letzten Freeware Version laden! Spart viel Zeit bei Netzwerk Diagnose. In den Optionen auch gleich die Ports von den jeweiligen Spielen eintragen und ggf. "Always analyse device (even if ping failed)" setzen. (Letzere Option verlangsamt den Scan erheblich, also nicht unbedingt standardmäßig nutzen)
EDIT2: Wie von kamanu oben schon erwähnt: wenn man mit TUN devices arbeitet, ist WireGuard eigentlich die goto option. Es gibt nur noch sehr wenige Gründe/Szenarien auf OpenVPN zu setzen mit TUN.

 

[Drakrochma]

@HighTech-Freak
Danke für die Info.

Nur um sicher zu gehen:
Die Einstellungen der Firewall auf dem Server sind also sehr wahrscheinlich nicht das Problem sondern die Firewall-Einstellungen auf den Windows-Clients?

Dann muss ich mir das nochmal ansehen.
Dachte, ich hatte openvpn probehalber Freigaben für beide Profile eingetragen.
Teste ich aber nochmal.


Wireguard hatte mir die Firewall-Einstellungen auf dem Server komplett zerlegt.
Deswegen hatte ich mich davon wieder getrennt.
Aber war vielleicht auch mein Fehler bei der Installation.


Ich will doch nur eine schnellere und kostenlose Alternative zu hamachi, einfach ein LAN um den Server mit den Kumpels teilen zu können.
Aber immerhin schon einiges gelernt bei der Aktion

 

[redjack1000]

Ich will doch nur eine schnellere und kostenlose Alternative zu hamachi

Dann schau Dir mal www.zerotier.com an.

CU
redjack

 

[HighTech-Freak]

WireGuard sollte eigentlich nicht an der Firewall rumfummeln...
In deinem Szenario sollte für WireGuard (wie auch für OpenVPN) auch nur die Regel für die wireguard-instanz selbst nötig sein (also der UDP Port für Wireguard selbst) + natürlich fürs Game wo die pakete am WireGuard Interface ankommen.

 

[Drakrochma]

Bin mir mittlerweile auch nicht ganz sicher, ob nicht vielleicht irgendwas von Strato direkt da mit rein pfuscht.

Hab an den clients die Ausnahmen für die Firewall aufgenommen für beides, Verbindung in Richtung Server läuft super, die clients sehen sich aber immer noch nicht und Ping läuft weiterhin ins Leere.

Bin schon am überlegen auf der fritte die Laborversion mit wireguard zu installieren und Strato komplett abzuschaffen...

 

[Raijin]

client-to-client geht nicht über firewall vom OpenVPN Server, da die Pakete am Server innerhalb des OpenVPN Servers weitergeleitet werden und nicht durch die OS Firewall gehen. Jegliche Firewall Settings am Server sollten lediglich den Traffic an/vom Server betreffen, nicht jedoch traffic von clients an clients.

Davon hat nach meinem Dafürhalten auch niemand geredet. Es sind im vorliegenden Fall aber 2 Server im Spiel, der VPN-Server als VPS bei Strato und ein Gameserver im Heimnetzwerk, der mit dem VPN als Client verbunden ist - wie die Gameclients ebenfalls.

Die Einstellungen der Firewall auf dem Server sind also sehr wahrscheinlich nicht das Problem sondern die Firewall-Einstellungen auf den Windows-Clients?

Nochmal: Du musst präzise sein, sowohl in deinen Aussagen als auch im Verständnis des Geschriebenen. "Den Server" gibt es nicht, weil es zwei verschiedene sind. Entweder musst du spezifizieren ob du vom VPN- oder vom Gameserver sprichst oder es muss sich aus dem Kontext ergeben.

@HighTech-Freak hat natürlich Recht, dass die Firewall am VPN-Server nachrangig ist. Die Einstellung client-to-client ist für die VPN-spezifische Erreichbarkeit verantwortlich, that's it. Aber: Wenn das VPN mittels client-to-client eben von VPN-Client zu VPN-Client durchreicht, ist das nur die Infrastruktur. Entscheidend ist danach, dass eben der jeweilige VPN-Client auch auf die eeingehene Anfrage reagiert, sei es ein Ping oder eine Verbindungsanfrage für ein Game. Genau das liegt in der Verantwortung der lokalen Firewall am VPN-Client.

Irgendwie habe ich mittlerweile ein mulmiges Gefühl dabei, dass du ohne nennenswerte Kenntnisse einen Server bei Strato betreibst. Nimm mir das nicht übel, aber nur weil ein VPS heutzutage nur wenige Euro kostet und spottbillig ist, heißt das nicht, dass dafür kein KnowHow nötig ist.
Prüfe bitte unbedingt ob die Firewall am VPN-Server alles eingehende blockt außer OpenVPN (Standard: UDP 1194) und zB TCP 22 für SSH. Letzteres zudem nur mittels Key-Authorization oder ansonsten mit fail2ban oder denyhosts absichern. Ein öffentlicher Server bedeutet nämlich auch Verantwortung.