Gameserver TCP/UDP-Portfreigabe

[Turrican-2]

Greetings,

ich habe bei einem der Ableger von United Gameserver einen einfachen 6-Slot Gameserver gemietet. Darauf soll u.a. "Shootmania Storm: Joust" laufen, dessen benötigte Ports können aus dem Wiki entnommen werden, siehe https://doc.maniaplanet.com/dedicated-server/getting-started#network-configuration

2350 TCP & UDP General
3450 TCP & UDP P2P
5000 TCP XML-RPC

Der Server lädt Server- und Matchkonfigurationen, erscheint in der Serverliste, es kann clientseitig jedoch nicht verbunden werden: "Could not connect: UDP initialization failed"

Frage bzw. TCP/UDP Portscan:

Der Support teilte mir mit, dass von ihrer Seite "nix blockiert" sei. Ich gehe davon aus, dass bei United Gameserver Fachkräfte sitzen. Aber mein Grundverständnis zu Netzwerktechnik besagt nach folgendem Portscan (http://www.ipfingerprints.com/portscan.php), dass UDP Ports auf der Gameserver-IP geschlossen sind:

PORT : STATE : SERVICE
2350/tcp : open : psbserver
2350/udp : open|filtered : psbserver

PORT : STATE : SERVICE
3450/tcp : open : castorproxy
3450/udp : closed : castorproxy

Ja/Nein/Vielleicht? Freue mich über jeden hilfreichen Hinweis :)

[Gast]

UDP kann man praktisch nicht wirklich scannen. Man kann UDP Pakete an den Server senden, aber ob der Antwortet liegt 100% an der Software, die den Port bearbeiten soll. Wenn die UDP Anfrage nicht von der Software verstanden wird, dann antworten die im Normalfall einfach garnicht.

Ich kenn mich jetzt nicht mit deinem Gameserver aus. Wenn du da eigene Programme laufen lassen kannst, kannst du ja mal Netcat oder so auf dem Port lausche lassen und dann nen Portscan starten. Dann müsste bei Netcat ein Paket eingehen (geantwortet wird dann dennoch nicht -> Der Port wird im Scan weiterhin als closed bezeichnet).

[Rechner-Tester]

offen|gefiltert

Nmap klassifiziert einen Port in diesen Zustand, wenn es nicht feststellen kann, ob der Port offen oder gefiltert ist. Das kommt bei Scan-Methoden vor, in denen offene Ports keine Antwort geben. Das Fehlen einer Antwort könnte auch bedeuten, dass ein Paketfilter das Testpaket verworfen hat oder dass keine Antwort provoziert werden konnte. Deswegen weiß Nmap nicht sicher, ob der Port offen ist oder gefiltert wird. Ports werden von den UDP-, IP-Protokoll-, FIN-, NULL- und Xmas-Scans auf diese Weise klassifiziert.
https://nmap.org/man/de/man-port-scanning-basics.html

Es ist also durchaus möglich das der Gameserver lediglich keine Antwort sendet, weil er mit dem Paket des Portscanners nichts anfangen kann.

[lumines]

UDP und Portscanner sind immer so eine Sache. Benutz einmal nmap und schränke den Scan auf deine jeweiligen Ports ein.

[sei laut]

Was soll den "open|filtered" sein. Entweder es antwortet etwas oder es gibt einen Timeout. Das eine wäre offen, das andere filtered (meint eine Firewall dazwischen, die keine Antwort sendet).

Aber lumines hat recht, UDP ist halt "Paket kann ankommen, muss aber nicht".
Telnet kann nur TCP, unter Linux kann man für UDP netcat nutzen mit -u und dann der Angabe des Ports.

[Turrican-2]

Danke für diese Hinweise. Die meisten Portscanner bieten lediglich TCP. Somit war ich mir nicht im Klaren, ob das UDP Ergebnis von http://www.ipfingerprints.com/portscan.php als Fakt ausgelegt werden kann.

[lumines]

Welche gibt es denn noch abseits von nmap? Ehrlich gesagt kenne ich nur den.

[Turrican-2]

Welche gibt es denn noch abseits von nmap? Ehrlich gesagt kenne ich nur den.

Ich habe verschiedene Webdienste getestet (https://goo.gl/2tYjfv). Teilweise wird auf Nmap verwiesen, teilweise gibt's keine Informationen zum Scan.

[Birdman]

Was soll den "open|filtered" sein. Entweder es antwortet etwas oder es gibt einen Timeout.
Nein, es kann eine Antwort kommen, es kann ein ICMP reject kommen oder eben gar nichts - was dann dem Timeout entspricht.

Gibt durchaus Szenarien, wo Rejects einem Drop vorzuziehen sind - ich persönlich z.B. nutze öfters Reject Rules um die mitunter ekligen Timeouts und Retransmits bei Drop Regeln zu vermeiden.