6
KVM-Qemu: Portweiterleitung - Bridge? CentOS
Hallo,
ich habe folgendes Problem:
OS: CentOS
1) Host-System mit öffentlicher IP --> Anbindung via Bridge (br0) über eth0
2) Virtuelle Maschine mit privater IP --> Anbindung via Bridge (br0)
3) "Internetverbindung" über eth0
Auf der VM habe ich ein Gameserver installiert. Dieser kann sich nach außen verbinden und lässt Verbundgen von außen zu. Das Spielen (online) ist somit möglich.
Das Spiel benutzt den Verbindungsport 2302. Darüber connected der Client sich.
Nun zur Frage.
Es gibt ein Tool, mit dem man den Gameserver administrieren kann. Wenn ich via virt-manager auf der VM bin und als Ziel-IP im Programm 127.0.0.1:2302 eingebe, kann ich mich verbinden. Wenn ich jetzt die öffentliche IP von meinem Rechner zu Hause eingebe mit dem Port, bekommt er keine Verbindung.
1) Gameserver funktioniert für alle Clients (über Port 2302).
2) Lokale Administration geht (über Port 2302).
3) Externe Administration geht nicht (über Port 2302).
Habt ihr eine Idee warum??? Bin für jede hilfreiche Antwort dankbar
MfG Clero
ich habe folgendes Problem:
OS: CentOS
1) Host-System mit öffentlicher IP --> Anbindung via Bridge (br0) über eth0
2) Virtuelle Maschine mit privater IP --> Anbindung via Bridge (br0)
3) "Internetverbindung" über eth0
Auf der VM habe ich ein Gameserver installiert. Dieser kann sich nach außen verbinden und lässt Verbundgen von außen zu. Das Spielen (online) ist somit möglich.
Das Spiel benutzt den Verbindungsport 2302. Darüber connected der Client sich.
Nun zur Frage.
Es gibt ein Tool, mit dem man den Gameserver administrieren kann. Wenn ich via virt-manager auf der VM bin und als Ziel-IP im Programm 127.0.0.1:2302 eingebe, kann ich mich verbinden. Wenn ich jetzt die öffentliche IP von meinem Rechner zu Hause eingebe mit dem Port, bekommt er keine Verbindung.
1) Gameserver funktioniert für alle Clients (über Port 2302).
2) Lokale Administration geht (über Port 2302).
3) Externe Administration geht nicht (über Port 2302).
Habt ihr eine Idee warum??? Bin für jede hilfreiche Antwort dankbar
MfG Clero
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 236140
Url: https://administrator.de/forum/kvm-qemu-portweiterleitung-bridge-centos-236140.html
Ausgedruckt am: 20.04.2025 um 15:04 Uhr
6 Kommentare
Neuester Kommentar
Servus,
das ist leider recht schwer zu beantworten, ohne die Software zu kennen.
- Welcher Gameserver läuft denn dort, und wo gibts die Doku dazu?
- Ist 2302 nur der Admin-Port für das Webinterface, oder läuft das Game auch über diesen Port?
Ich würde auf einen dieser beiden Punkte tippen:
1. Der Gameserver erlaubt den Zugriff auf das Admin-Interface nur vom Local-Host aus.
Ich kenne viele Programme, die man erst entsprechend aufmachen muss.
2. Die Firewall im Gameserver blockiert den Zugriff von aussen.
Grüße,
Daniel
das ist leider recht schwer zu beantworten, ohne die Software zu kennen.
- Welcher Gameserver läuft denn dort, und wo gibts die Doku dazu?
- Ist 2302 nur der Admin-Port für das Webinterface, oder läuft das Game auch über diesen Port?
Ich würde auf einen dieser beiden Punkte tippen:
1. Der Gameserver erlaubt den Zugriff auf das Admin-Interface nur vom Local-Host aus.
Ich kenne viele Programme, die man erst entsprechend aufmachen muss.
2. Die Firewall im Gameserver blockiert den Zugriff von aussen.
Grüße,
Daniel
Moin,
also es handelt sich um Arma3: Altis Life.
Es gibt noch weitere Ports fürs Game, die aber offen sind.
Und die Admin-SW ist diese hier: EPMRCon0.9.9.6
http://forums.bistudio.com/showthread.php?150547-EPM-RCon-Tool-%28Beta% ...
Damit soll eine externe Verbindung möglich sein.
zu 1.) Habe auch noch ein anderes Tools versucht, geht auch nicht.
zu 2.) Habe gerade mal die FW von der VM (Win7) deaktiviert, leider kein Erfolg. Die FW am Host-System habe ich auch schon verändert, aber immer kein Erfolg. Beim Hosts (CentOS) ist IPTables aktiv.
Und die Clients könn sich ja darüber connecten und spielen?! Das ist ja das merkwürdige.
also es handelt sich um Arma3: Altis Life.
Es gibt noch weitere Ports fürs Game, die aber offen sind.
Und die Admin-SW ist diese hier: EPMRCon0.9.9.6
http://forums.bistudio.com/showthread.php?150547-EPM-RCon-Tool-%28Beta% ...
Damit soll eine externe Verbindung möglich sein.
zu 1.) Habe auch noch ein anderes Tools versucht, geht auch nicht.
zu 2.) Habe gerade mal die FW von der VM (Win7) deaktiviert, leider kein Erfolg. Die FW am Host-System habe ich auch schon verändert, aber immer kein Erfolg. Beim Hosts (CentOS) ist IPTables aktiv.
Und die Clients könn sich ja darüber connecten und spielen?! Das ist ja das merkwürdige.
Servus,
https://community.bistudio.com/wiki/Arma_3_Dedicated_Server
http://forums.bistudio.com/showthread.php?147537-Tutorial-How-to-run-Ar ...
Laut dieser werden dafür die Ports UDP / 2300-2305 und noch einige andere verwendet.
Leider sind die Anleitungen... na ja, sagen wir mal ziemlich schade.
Was brauchbares habe ich leider nicht gefunden.
Jedenfalls steht bei Punkt 12:
-config=CONFIG_Vanilla.cfg
Es gibt also eine Config zu dem Server.
Schon mal reingeschaut?
Kann / muss / sollte man die evtl. anpassen?
Steht da evtl. bei einer Einstellung nur 127.0.0.1 oder localhost drin?
Stehen in der A3Master.log irgendwelche Meldungen, zu dem Zeitpunkt, wenn das Tool keine Verbindung herstellen kann?
Wenn nein, versuch mal das Debug-Log anzuschalten und schau da rein, ob dort was drin steht.
Kannst du denn im Game die Admin-Befehle ausführen?
Die Firewall müsste demnach offen sein, sonst würde gar nix gehen.
Grüße,
Daniel
also es handelt sich um Arma3: Altis Life.
Es gibt noch weitere Ports fürs Game, die aber offen sind.
Also ich hab da mal Anleitungen ausgegraben:Es gibt noch weitere Ports fürs Game, die aber offen sind.
https://community.bistudio.com/wiki/Arma_3_Dedicated_Server
http://forums.bistudio.com/showthread.php?147537-Tutorial-How-to-run-Ar ...
Laut dieser werden dafür die Ports UDP / 2300-2305 und noch einige andere verwendet.
Leider sind die Anleitungen... na ja, sagen wir mal ziemlich schade.
Was brauchbares habe ich leider nicht gefunden.
Jedenfalls steht bei Punkt 12:
-config=CONFIG_Vanilla.cfg
Es gibt also eine Config zu dem Server.
Schon mal reingeschaut?
Kann / muss / sollte man die evtl. anpassen?
Steht da evtl. bei einer Einstellung nur 127.0.0.1 oder localhost drin?
Stehen in der A3Master.log irgendwelche Meldungen, zu dem Zeitpunkt, wenn das Tool keine Verbindung herstellen kann?
Wenn nein, versuch mal das Debug-Log anzuschalten und schau da rein, ob dort was drin steht.
Und die Admin-SW ist diese hier: EPMRCon0.9.9.6
http://forums.bistudio.com/showthread.php?150547-EPM-RCon-Tool-%28Beta% ...
Das ist der Client Teil, nicht der Server.http://forums.bistudio.com/showthread.php?150547-EPM-RCon-Tool-%28Beta% ...
zu 1.) Habe auch noch ein anderes Tools versucht, geht auch nicht.
Wenn der Server das nicht erlaubt, kannst du noch 10 weitere Client-Tools probieren, die gehen alle nicht ;)Kannst du denn im Game die Admin-Befehle ausführen?
Und die Clients könn sich ja darüber connecten und spielen?! Das ist ja das merkwürdige.
Weil anscheinend alles über die gleichen Ports läuft. Spiel + AdminDie Firewall müsste demnach offen sein, sonst würde gar nix gehen.
Grüße,
Daniel
Also die Server Configs sehen alle gut aus. Und in den Logs steht nix.
Ich habe mal folgenden Befehl auf dem Host ausgeführt: cat /proc/net/nf_conntrack | grep 2302
ipv4 2 udp 17 21 src=77.225.61.201 dst=85.214.106.121 sport=50037 dport=2302 [UNREPLIED] src=85.214.106.121 dst=77.225.61.201 sport=2302 dport=50037 mark=0 secmark=0 use=2
ipv4 2 udp 17 163 src=192.168.100.5 dst=69.10.30.248 sport=2302 dport=27900 src=69.10.30.248 dst=85.214.106.121 sport=27900 dport=2302 [ASSURED] mark=0 secmark=0 use=2
ipv4 2 udp 17 14 src=77.47.120.36 dst=85.214.106.121 sport=51847 dport=2302 [UNREPLIED] src=85.214.106.121 dst=77.47.120.36 sport=2302 dport=51847 mark=0 secmark=0 use=2
Also kommt er gar nicht zur VM durch, oder?
Die 69.10.30.248 ist der Reporting Server, damit mein Server in der Serverliste ingame angezeigt wird.
Die Admin Befehle kann ich ausführen.
Ich habe mal folgenden Befehl auf dem Host ausgeführt: cat /proc/net/nf_conntrack | grep 2302
ipv4 2 udp 17 21 src=77.225.61.201 dst=85.214.106.121 sport=50037 dport=2302 [UNREPLIED] src=85.214.106.121 dst=77.225.61.201 sport=2302 dport=50037 mark=0 secmark=0 use=2
ipv4 2 udp 17 163 src=192.168.100.5 dst=69.10.30.248 sport=2302 dport=27900 src=69.10.30.248 dst=85.214.106.121 sport=27900 dport=2302 [ASSURED] mark=0 secmark=0 use=2
ipv4 2 udp 17 14 src=77.47.120.36 dst=85.214.106.121 sport=51847 dport=2302 [UNREPLIED] src=85.214.106.121 dst=77.47.120.36 sport=2302 dport=51847 mark=0 secmark=0 use=2
Also kommt er gar nicht zur VM durch, oder?
Die 69.10.30.248 ist der Reporting Server, damit mein Server in der Serverliste ingame angezeigt wird.
Die Admin Befehle kann ich ausführen.
Servus,
Es muss aber ja nicht umbedingt heißen, dass da eine Firewall im Weg ist.
Es kann auch sein, dass der Dienst einfach auf die Anfrage nicht antwortet.
Um das jetzt einzugrenzen, sollte man erst mal verstehen, welche UDP Ports wann genau erreichbar sind.
Dazu verwendet man üblicherweise die Tools nmap und nc.
Eine Anleitung gibts hier:
http://www.thelinuxwiki.in/2013/02/how-to-test-udp-connectivity.html
(Achtung, die Tools brauchen Parameter damit sie UDP und nicht TCP prüfen. Bei nmap ist das -sU und bei nc -u)
Mit diese Tools müsste man jetzt prüfen, welche Ports an folgenden Punkten offen sind:
1. Von der Windows VM aus Richtung localhost / 127.0.0.1
2. Von der Windows VM aus Richtung interne NAT IP
3. Vom Hypervisor aus Richtung Windows VM
4. Von außen, an der öffentlichen Hypervisor-IP
Irgendwo unterwegs müsste ja ein Port plötzlich nicht mehr antworten.
Und wenn man weiß wo, kann man das erst mal eingrenzen.
Grüße,
Daniel
Also kommt er gar nicht zur VM durch, oder?
Woher dieses "Unreplied" genau kommt, kann ich auch nicht sagen.Es muss aber ja nicht umbedingt heißen, dass da eine Firewall im Weg ist.
Es kann auch sein, dass der Dienst einfach auf die Anfrage nicht antwortet.
Um das jetzt einzugrenzen, sollte man erst mal verstehen, welche UDP Ports wann genau erreichbar sind.
Dazu verwendet man üblicherweise die Tools nmap und nc.
Eine Anleitung gibts hier:
http://www.thelinuxwiki.in/2013/02/how-to-test-udp-connectivity.html
(Achtung, die Tools brauchen Parameter damit sie UDP und nicht TCP prüfen. Bei nmap ist das -sU und bei nc -u)
Mit diese Tools müsste man jetzt prüfen, welche Ports an folgenden Punkten offen sind:
1. Von der Windows VM aus Richtung localhost / 127.0.0.1
2. Von der Windows VM aus Richtung interne NAT IP
3. Vom Hypervisor aus Richtung Windows VM
4. Von außen, an der öffentlichen Hypervisor-IP
Irgendwo unterwegs müsste ja ein Port plötzlich nicht mehr antworten.
Und wenn man weiß wo, kann man das erst mal eingrenzen.
Grüße,
Daniel
1
Nach langem ausprobieren lags doch an der Firewall des Hosts.
Hier die IPTables Config, die funktioniert (Auszug).
*
*nat
-A PREROUTING -p tcp -m tcp --dport 2302 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 2302 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 2303 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 2303 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 2305 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 2305 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 8766 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 8766 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 27016 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 27016 -j DNAT --to-destination 192.168.100.5
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -j MASQUERADE
*mangle
-A INPUT -p tcp -m tcp --dport 8766 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 27016 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2302 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2303 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2305 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A FORWARD -d 192.168.100.0/24 -o virbr1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -i virbr1 -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -j ACCEPT
-A FORWARD -i br0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o br0 -j ACCEPT
-A FORWARD -i vnet0 -o br0 -j ACCEPT
-A FORWARD -i br0 -o vnet0 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 2302 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 2302 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 2303 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 2303 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 2305 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 2305 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 8766 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 8766 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 27016 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 27016 -j ACCEPT
*
192.168.100.5 --> VM
192.168.100.0 --> virtuelles Netz
Danke für die Tipps Daniel Wer noch Verbesserungen weiß, kann diese gerne posten
MfG
Hier die IPTables Config, die funktioniert (Auszug).
*
*nat
-A PREROUTING -p tcp -m tcp --dport 2302 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 2302 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 2303 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 2303 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 2305 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 2305 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 8766 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 8766 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p tcp -m tcp --dport 27016 -j DNAT --to-destination 192.168.100.5
-A PREROUTING -p udp -m udp --dport 27016 -j DNAT --to-destination 192.168.100.5
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -j MASQUERADE
*mangle
-A INPUT -p tcp -m tcp --dport 8766 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 27016 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2302 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2303 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2305 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A FORWARD -d 192.168.100.0/24 -o virbr1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -i virbr1 -j ACCEPT
-A FORWARD -s 192.168.100.0/24 -j ACCEPT
-A FORWARD -i br0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o br0 -j ACCEPT
-A FORWARD -i vnet0 -o br0 -j ACCEPT
-A FORWARD -i br0 -o vnet0 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 2302 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 2302 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 2303 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 2303 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 2305 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 2305 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 8766 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 8766 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p tcp -m tcp --dport 27016 -j ACCEPT
-A FORWARD -d 192.168.100.5/32 -p udp -m udp --dport 27016 -j ACCEPT
*
192.168.100.5 --> VM
192.168.100.0 --> virtuelles Netz
Danke für die Tipps Daniel
Wer noch Verbesserungen weiß, kann diese gerne posten MfG
