[ Basics ]
[ HowTo ]
[ Linux ]
[ WIN ]
[ FAQ ]
[ Tools ]
CS-Server hinter einem Router bzw. einer Firewall
-
Grundsätzliches
-
Nicht immer ist der Gameserver direkt mit dem Internet verbunden. Manchmal befindet sich der Server
hinter einem Router oder einer Firewall
Aber auch dann ist es möglich, einen Internetserver zu betreiben. Dazu müssen wir lediglich dafür sorgen, dass die entsprechenden
Ports, die der Server benötigt, weitergeleitet werden bzw. geöffnet sind.
Bei dem Router bzw. der Firewall kann es sich sowohl um eine Hardwarelösung (z.B DSL-Router von T-Online) oder
eine Softwarelösung (z.B. das Windowseigene ICS) handeln.
Bei beiden Möglichkeiten ist das Prinzip jedoch gleich: den Gameserverport weiterleiten, die anderen öffnen.
-
Ports und Protokolle
-
Vorab und weil das sonst irgendwie jeder überliest:
Der Serverport (Standard ist UDP 27015) muss WEITERGELEITET werden! Freigeben alleine reicht NICHT aus!
Ein CS-Server (1.6 und CS: Source) nutzt bzw. benötigt diese Ports:
UDP 1200
TCP 27015
UDP 27020
UDP 27000 to 27015 inclusive
TCP 27030 to 27039 inclusive
UDP 27015 ist der Standardport für den Server.
ACHTUNG! Für CS:Source muss auch 27015 TCP geöffnet sein!
Gehen wir der Einfachheit halber davon aus, dass wir den Standardport des Servers nutzen (UDP 27015).
Dann müssen wir nur diesen Port von unserem Router auf den Rechner weiterleiten, auf dem der Server läuft. Ein freigeben des Serverports reicht NICHT!
Die anderen Ports müssen lediglich geöffnet sein, dass heisst, sie dürfen nicht z.B. durch eine Firewall geblockt werden.
Wie das weiterleiten des Ports bzw. das öffnen der Ports nun konkret geschieht, hängt vom Router bzw. der Software ab.
Für Hardwarerouter ist diese Seite ein guter Anlaufpunkt, da sich dort für die gängigsten Router Schritt-für-Schritt-Anleitungen befinden. Auch ist dort das Forwarding, Triggering etc. recht nett erklärt. Wer es unbedingt in Deutsch möchte, muss mit dieser Seite vorlieb nehmen.
Noch mal zur Verdeutlichung: Portforwarding bedeutet, dass alle Anfragen, die den Router auf Port 27015 UDP
erreichen nicht von ihm selber beantwortet werden sondern an den Rechner im LAN weitergeleitet werden, auf dem
der CS-Server läuft.
Das reine öffnen des Serverports reicht NICHT aus, ohne Forwarding ist der Server von aussen nicht zu erreichen!
-
Connecten
-
Wenn alles eingerichtet ist, sollten Clients aus dem Internet unter Angabe der ONLINE-IP des Routers
connecten können. Wenn ihr diese IP-Nummer nicht kennt, sollte euch ein Blick auf diese
Seite weiterhelfen.
-
Probleme und das STEAM-Mysterium
-
Meistens geht dass Connecten der Clients leider nur mit direkter Angabe der IP. Der Grund liegt in
der Arbeitsweise fast aller Router bzw. Firewalls.
Warum das so ist und mögliche Lösungsmöglichkeiten erklärt dieser sehr ausführliche Text von
mckenzie:
„Das Mysterium STEAM“ oder „Warum findet niemand meinen Server?“
Ihr habt ein LAN mit Router/Firewall? Ihr könnt wunderbar im Internet zocken? Auf Euren frisch
eingerichteten Server kommt Ihr ohne Probleme? Auf Eurem Router habt Ihr ein Forward für den Server-Port eingerichtet?
Und trotzdem ist das Ding irgendwie dauernd leer und Eure Freunde monieren, das Euer frisch gebackenes
Spieleparadies in diversen CS-Browser Listen (Ingame oder extra Proggies a là GameSpy) nicht zu finden ist...
Das deutet darauf hin, das irgendwie Euer Server nicht richtig in die STEAM-Liste eingetragen wird. Aber warum?
Beispielkonfiguration
Nehmen wir mal folgendes Setting an:
- Ihr habt ein LAN mit den Adressen
192.168.0.1 bis 192.168.0.254; auf allen Rechner ist die
Subnet-Mask 255.255.255.0 eingerichtet
- Euer (dedicated) CS-Server hat die IP-Adresse
192.168.0.20 und hlds läuft auf Port 27015
- Euer CS-Client hat die IP-Adresse
192.168.0.5
- Euer Internet-Router hat die IP-Adresse
192.168.0.254
- Eurem Internet-Router wurde von Eurem Provider (ISP) z.B. die IP-Adresse
213.100.100.100 zugewiesen.
Das ist die Adresse, unter der man vom Internet aus den Router erreichen würde.
In Deinem Fall kannst Du diese Adresse unter www.whatismyip.com erfahren –
hier wird Dir lediglich die Quelladresse Deiner versendeten IP-Pakete „vorgelesen“.
- Euer Router erlaubt beliebige Verbindungen von innen nach außen („outbound“ – ins Internet raus gehend)
und schickt Pakete, die vom Internet kommen („inbound“) und an UDP-Port
27015 gerichtet sind an Euren
Server weiter („forward“)
Wenn das alles passt, können sich Eure Freunde bereits mit dem Befehl connect
213.100.100.100:27015 (Port 27015 ist Standard, könnte hier auch weggelassen werden) auf
Eurem Server einloggen. Nicht vergessen: Das ist die Router-IP. Dieser gibt alle Pakete lediglich an Euren Server weiter. Falls der Login nicht
klappt, habt Ihr ein Problem - aber primär nicht mit STEAM, sondern ein tiefer gehendes. Seht Euch in dem Fall die anderen FAQs nochmal
genau an.
Sollte dieser manuelle Login von außen klappen, dann fehlt nur noch der richtige STEAM-Eintrag zum Spielerglück...
NB: Wenn im folgenden von Router die Rede ist, ist ein Router mit Firewall gemeint.
Signs of Life: Der Start des Servers
Nun kommt der Part mit dieser STEAM-Liste. Aber dazu ganz von vorne:
Euer Server wird gestartet und bringt ein paar Meldungen,
was für eine Version er ist, usw.. Irgendwo in diesem Buchstabenverhau kommen ein paar wichtige Zeilen:
Die erste wäre
STEAM Auth Server
Diese Meldung sagt Euch, das Euer Server Kontakt zu STEAM und damit zum Internet hat. Steht da nur STEAM Server, dann gab's ein
Problem mit der Internet-Verbindung.
Des weiteren kommen dann noch drei Meldung (die IP-Adressen können abweichen):
Adding master server 207.173.177.11:27010
Adding master server 68.142.72.250:27010
Und hier passiert es: Euer Server schickt an diese 2 Master-Server ein „Hallo-hier-bin-ich“ Paket. Jetzt wird's ein wenig komplizierter:
Dieses Begrüßungs-Paket hat von Eurem Server dessen IP-Adresse und seinen Port mit eingetragen bekommen, also
192.168.0.20:27015. Das Paket wird mit dem UDP-Protokoll verschickt. Der Server weiß, das er dieses Paket z.B. an
198.74.32.53 (den ersten der drei Master-Server) schicken soll, schaut in seiner Routing-Tabelle nach und merkt: das ist nicht
im lokalen Netzwerk (192.168.0.XXX) – ich muss dieses Paket an den Router schicken, der weiß schon, wohin damit.
Maskenball: Der Router
Das Paket kommt nun bei Eurem Router an und der tut, was eine „Masquerading Firewall“ nun mal so macht: er setzt Eurem Paket
eine Maske auf. Das heißt, er verändert die Quelladresse des Paketes so ab, als ob der Router als Absender dieses Paketes angesehen
würde und schickt es weiter ans Internet. Hierbei verändert er aber nicht nur die Adresse, sondern in der Regel auch den Port des Pakets.
Die neue Portnummer wird dabei mehr oder minder zufällig vergeben.
Nehmen wir an, das Paket, das von Eurem Server kam (Quelladresse
192.168.0.20:27015), erhält somit nun die Quelladresse 213.100.100.100 und den Quellport
12345. Nach dieser Veränderung schickt Euer Router das Paket ins Internet und merkt sich diese Änderung. Denn falls der
angesprochene Server eine Antwort zurückschicken will, müssen bei den Antwortpaketen die Änderungen vom Router
genau wieder rückgängig gemacht werden, damit die Pakete im LAN auch den CS-Server erreichen. Das macht der Router automatisch:
mit jedem Paket, das Ihr sendet (bewusst oder unbewusst), macht ihr sozusagen eine kleine Tür auf, durch die ausschließlich der
angesprochene Server antworten darf.
Die Master-List
Das Begrüßungs-Paket kommt nun nach einer kurzen Reise beim Master-Server an und dieser schaut in den IP-Header des Pakets,
woher es denn kommt (Quelladresse und -port) und schreibt diesen in seine Master-List, die eigentliche STEAM-Liste. Bei unserem Beispiel landet in
der STEAM-Liste die Info, dass es einen Server gibt, den man unter 213.100.100.100:12345 (die Adresse des Routers!) erreichen
kann.
Die Client-Anfrage und der verschwundene Server
Was passiert nun, wenn Ihr in Eurem Client auf „Update“ klickt? Der Client sendet eine Anfrage an STEAM und bekommt auch prompt von
einem der Server eine (vorgefilterte) Liste mit IP-Adressen und -Ports von Spiele-Servern zugesandt, die sich am Master-Server gemeldet haben, unter anderem in
unserem Beispiel die 213.100.100.100:12345. Es werden keinerlei Informationen wie z.B. über die Anzahl der Spieler oder den
eigentlichen Namen des Servers übermittelt – das versucht der Client selber vom CS-Server online zu bekommen. Dazu schickt er ein
UDP-Paket mit einer Anfrage nacheinander an jeden CS-Server aus der Liste. In unserem Beispiel geht es dann an die Adresse des Routers (
213.100.100.100:12345).
So, und nun kommt ein Feature des Routers zum tragen: Nur der ursprünglich angesprochene
Rechner (also der STEAM-Server, an den das Begrüßungs-Paket ging) darf über diesen Port (12345) antworten –
Pakete von allen anderen Quellen werden verworfen („dropped“). Dass Ihr mühevoll Port 27015 geforwardet habt, ist
hierbei nicht weiter wichtig – das ist für den Router eine vollkommen andere Sache. (Das Ganze soll Hackern vorbeugen, die irgendwie von
Eurem offenen Port Wind bekommen haben und über diesen nun bei Euch „rein“ wollen.)
Der Client erhält somit keine Antwort. Er vermutet, das der Server nicht mehr online ist und löscht diese IP aus seiner Liste und geht zur
nächsten über (merkt man an den Hängern beim Ingame-Browser, wenn er die Servernamen durchrattert). Der Server taucht nie auf.
Also ist Euer eigener Router daran Schuld, das STEAM nicht den Port 27015, sondern irgendeinen anderen speichert – unter dem aber, dank
Firewallreglement, wiederum für keinen Rechner, außer dem ursprünglich angesprochenen STEAM-Server selber, etwas zu erreichen ist.
Für dieses Problem gibt es nun 3 Ansatzpunkte:
Lösung A: Outbound NAT Preset
Ihr bringt Eurem Router bei, dass er, zumindest bei UDP-Paketen, die von Eurem Server und dessen Port 27015 kommen,
bitteschön nicht den Port verändern, sondern dort 27015 stehen lassen soll. Damit würde die Masterlist die Adresse
213.100.100.100:27015 speichern und die Client-Anfragen kämen dank eingerichtetem Forward auch am Server an und
würden beantwortet. Somit erfährt der Client u.a. den Namen Eures Servers und kann den in der Liste anzeigen, statt in sang- und klanglos
zu löschen.
Wie dies im einzelnen für Euren (Hardware-)Router geht, entnehmt Ihr dessen Beschreibung (RTFM
 ) oder nehmt Kontakt zu Eurem Händler oder zum Hersteller auf - die haben
die Kohle von Euch, sollen sie also auch was dafür tun. WIR WISSEN NICHT, WIE EUER ROUTER SPEZIELL EINGESTELLT WERDEN MUSS
– also fragt auch bitte erst gar nicht per Mail oder ICQ. Benutzt bei totalem Versagen der erwähnten Quellen bitte
Google, das ServerOp-Forum oder im IRC den Channel
#serverop
Lösung B: „Loose UDP Patch“ für Linux-Router
Normalerweise darf durch einen Port, den der Router einem Paket zugeordnet hat, nur der Rechner antworten, an den das ursprüngliche Paket
gerichtet war. Die Quick‘n‘Dirty Lösung ist nun: Ihr sagt Eurem Router, er soll genau diese Überprüfung abschalten.
D.h. durch den von unserem Begrüßungs-Paket geöffneten UDP-Port 12345 werden alle Pakete an den CS-Server
weitergeleitet, egal von welchem Rechner im Internet aus sie gesendet wurden. Man könnte dieses Feature auch „Auto-Forwarding“
nennen – es werden automatische Forwards eingerichtet.
Da dies eine Schwächung der Firewall ist, sollte in hoch kritischen und hackanfälligen Umgebungen (wichtige Webserver, etc.) von diesem
Patch abgesehen werden – für Euer Heim-LAN sollte dies jedoch keine große Gefahr darstellen. Mit diesem Patch benötigt Ihr
auch nicht mehr unbedingt den 27015er-Forward – er wird schlichtweg nicht mehr gebraucht, da alle Clients über den via
STEAM veröffentlichten Port 12345 anfragen.
Das ganze ging bei 2.0er und 2.2er Kernel. Wie‘s bei anderen Versionen aussieht weiss ich nicht. Genaue Installationsanweisungen entnehmt
Ihr dem Web, siehe bei Google oder, weiter unten, den Links.
Wunschtraum-Lösung C: Valve ändert das Begrüßungs-Paket
Die für die Serveradministratoren wohl einfachste Variante wäre, das Valve in dem Begrüßungs-Paket die tatsächliche
Portnummer des Servers mitschickt. Das müsste der Admin dann noch nicht mal irgendwie aktivieren – hlds macht‘s einfach
automatisch. Diese Port-Nummer könnte der STEAM-Masterserver dann lediglich übernehmen, alle Clients wüssten wohin und der
geforwardete Port wird genutzt.
Somit müsste man keinerlei Outbound Forwards einstellen – was auf manchen billigeren Hardware Routern auch gar nicht geht –
oder mit Tricks einige Regeln des Routers abschwächen. Das Inbound Forward müsste man aber nach wie vor einstellen.
Hoffentlich liest das Valve auch...
GameSpy, All-Seeing-Eye, Gametiger, etc.
Die externen Game-Browser von GameSpy, Gametiger/CSTiger
und All-Seeing-Eye holen sich Ihre Daten vom STEAM, soweit bekannt, selbständig – das
heißt Ihr müsst dazu nichts besonderes tun, außer ein wenig warten (evtl. ein bis zwei Mapchanges solltet Ihr Euch und STEAM
schon Zeit lassen).
Rösselsprung: Der Test des STEAM-Eintrags
Nun habt Ihr vielleicht gerade an Euren Netzwerkeinstellungen rumgebastelt, aber wie sollt Ihr deren Erfolg nun testen? Euren eigenen Ingame-Browser
könnt Ihr hierzu in der Regel nicht benutzen, da Euer Client (192.168.0.5) Anfragen an die externe Adresse Eures Routers
(213.100.100.100) schicken würde, die der Router zurück ins LAN zum CS-Server (192.168.0.20) schicken
müsste. Dieses „loopback“ unterstützen manche Router, aber manche eben nicht. Ihr müsstet es irgendwie
schaffen, vom Internet aus eine Anfrage zu starten. Sicher, Ihr könnt Eure Freunde anrufen und fragen, ob die Euern Server finden. Oder Ihr
könntet Euch, falls eine extra Modem/ISDN-Karte vorhanden ist, mit Eurem Rechner schnell mal bei einem anderen ISP anmelden und dann
eine Anfrage starten.
Der einfachste Weg geht jedoch über Gametiger/CSTiger. Dort tippt Ihr in der Server-Suche einfach
einen Teil Eures Servernamens ein. Dieser Dienst findet Euren Server relativ schnell und listet ein paar Daten darüber auf. Falls es doch mal
nicht klappt, einfach 5 Minuten warten. Wenn Ihr den Server hier gefunden habt, findet ihn jeder.
Dynamische IP
Der Eintrag in die STEAM-Masterlisten wird nach einiger Zeit automatisch aktualisiert. D.h. sollte sich Eure IP ändern (z.B. durch Neuanwahl des
Internets) wird die neue IP automatisch bei STEAM eingetragen. Ein Neustart des CS-Server kann aber die Eintragung beschleunigen. Dynamische DNS
Dienste wie DynDNS oder DNS2Go sind also nicht unbedingt erforderlich.
Häufige Fehler und Irrtümer
- Ihr könnt Euch in der Regel nicht aus dem LAN an Euren eigenen CS-Server über die externe Adresse anmelden (
213.100.100.100:27015). Zum connect aus dem eigenen LAN verwendet Ihr am Besten nach wie vor einfach die interne IP (
192.168.0.20) eures Servers. Kopiert Euch doch mal die Verknüpfung zum CS-Client ab und hängt dort in die
Kommandozeile mit rein: +connect 192.168.0.20:27015
- Der Parameter
+ip des hlds nimmt nur Adressen, die Euer CS-Server auch wirklich selber besitzt – in unserem
Beispiel 192.168.0.100. Würdet ihr +ip 213.100.100.100 angeben, also die IP, die der Router
extern zugewiesen bekommen hat, würde er sofort maulen, dass er diese Adresse nicht belegen kann – er „besitzt“
sie schlichtweg nicht.
Außnahme: Der hlds läuft auf dem Router - dann "besitzt" der Rechner die IP und hlds kann sie
„binden“.
- Fehlermeldungen a là
NET_SendPacket Error: (...) und ähnlicher Couleur: Ihr habt ein Problem mit Euren
TCP/IP-Einstellungen. Entweder ist die Adresse und/oder Subnetmask vom Server und/oder Router falsch, oder das Standard-Gateway oder
der DNS-Server für den Server wurde nicht richtig eingestellt (hierfür ist beides mal in der Regel Euer Router einzutragen).
Auch mehrere, evtl. falsch eingestellte, Netzwerkinterfaces im selben Rechner könne zur Verirrung der Pakete und zu diesen Fehlermeldungen
führen. Überprüft nochmal alle TCP/IP-Einstellungen von Router und Server. Ping muss vom Server in alle Richtungen klappen,
bitte auch mit DNS-Resolve testen, also z.B. ping www.counter-strike.de. Bei weiterem Versagen: ServerOp-Forum oder
IRC unter #serverop
Glossar (alphabetisch)
- Bachstubenverdeher und Dreckfuhler : immer wieder kehrendes
Phänomen längerer Texte. Bei Auftreten einfach mit Email an uns bekämpfen.
- Firewall: engl. „Brandmauer“, schützt vor Zugriffen aus dem Internet (vereinfacht ausgedrückt). Läuft als
Software auf (manchen) Routern.
- Forward: siehe Port Forwarding
- Inbound Traffic: Datenverkehr vom Internet ins LAN
- ISP (Internet Service Provider): Die Firma, die Euch den Internetzugang zur Verfügung stellt.
- IP Masquerading: siehe NAT
- LAN (Local Area Network): lokales (d.h. räumlich nicht sehr weit ausgedehntes) Netzwerk
- Masquerading: siehe NAT
- NAT (Network Address Translation): Auch „IP Masquerading“ genannt. Firewalltechnik, um viele IP-Adressen eines lokalen
Netzwerks hinter einer einzigen öffentlichen IP-Adresse zu „verstecken“ (vereinfacht ausgedrückt).
- Outbound Traffic: Datenverkehr vom LAN ins Internet
- Port: „Unteradresse“ eines Rechners für TCP und UDP-Pakete. Ein Rechner kann auf bis zu 65535 Ports auf Anfragen
„horchen“. Eine Liste, welche Ports auf Eurem Rechner „offen“ sind, erhaltet Ihr unter Windows und Linux jeweils mit
netstat -an
- Port Forwarding: Normalerweise werden alle unangeforderten Pakete vom Internet – also solche, die nicht als Antwort auf eine Eigenes
ankommen – verworfen. Mit einem „Port Forward“ wird eine Firewall angewiesen, bestimmte Pakete mit einem gewissen
Zielport vom Internet trotzdem an einen bestimmten Rechner innerhalb des LANs weiterzuleiten. Der Router verhält sich damit von
außen (Internet) gesehen so, wie wenn er diesen Dienst selbst anbieten würde.
- Router: Netzwerkgerät, das zwei oder mehr Netzwerke miteinander verbindet und Pakete zwischen diesen hin- und her schickt. Als
Router kommen sowohl reine Hardware-Geräte, als auch ganz „normale“ Rechner mit Linux oder Windows zum Einsatz.
Mit spezieller Konfiguration bzw. Software kann aus einem solchen Rechner eine Firewall werden.
- Routing Table: Tabelle, die einem Netzwerkgerät sagt, wohin mit welchem IP-Paket.
- UDP (User Datagram Protocol): Eines der Datenübertragungsprotokolle der TCP/IP-Protokollfamilie. Arbeitet im Gegensatz zu TCP
(Transmission Control Protocol) verbindungslos. D.h. es entfallen z.B. manche Sicherheits-Checks, ob das Paket auch wirklich
angekommen ist. Hat dadurch gegenüber TCP u.a. Geschwindigkeitsvorteile bzgl. der Latenz („Reisedauer“ des Pakets).
- Verbesserungsvorschläge und Updates: Wenn sie sachlich und angemessen sind, dann gerne per Email an uns (aber bitte keine
Beschreibung von Router XYZ der Firma ABC – ab ins Forum damit).
(c) 09/2002-11/2002 by mckenzie
(c) 2002 - 2007 by jwm
BITTE KEINE SUPPORTANFRAGEN, DAFÜR SIND DAS
SERVEROP-FORUM UND DER #SERVEROP-CHANNEL DA!
[ Basics ]
[ HowTo ]
[ Linux ]
[ WIN ]
[ FAQ ]
[ Commands ]
[ Tools ]
|
