Hallo zusammen!
Ich habe meinen Beitrag von damals nochmal ausgegraben, aber da sich am Spiel nichts geändert hat, dürfte er immer noch gültig sein. Mal abgesehen von einigen Links.
Im Folgenden möchte ich Informationen und Hilfen zu Siedler3 in Kombination mit einem Router präsentieren. Die Informationen stammen aus Forenbeiträgen, anderen Quellen im Netz, persönlichen Gesprächen oder Try&Error-Prozeduren.
Alle Angaben sind ohne Gewähr, der Autor haftet nicht für Fehlfunktionen oder Schäden an Router/Rechner oder sonstigem. Auch nicht für eingedellte oder angenagte Tischplatten.
Viel Spaß beim Lesen wünscht Knight Jim
In letzter Zeit haben immer mehr Leute das Problem, daß sie Siedler 3 hinter einem Router (genauer: NAT-Router) spielen möchten und dies ohne besondere Einstellungen erstmal nicht funktioniert.
Dabei ist es egal, ob es nun ein Hardware-Router (DSL-Router sind ja grad sehr beliebt) oder eine Software-Lösung ist
(ich persönlich habe eine Linux/Netfilter/iptables Kombination ).
Bei einigen Software Lösungen soll es allerdings ohne besondere Einstellungen gehen, z.B. mit dem Windowseigenen ICS, die kennen scheinbar ihr eigenes proprietäres Protokoll ganz gut und haben dafür einen entsprechenden Proxy eingebaut.
Gambler hat dazu eine Anleitung geschrieben: http://settlers4.net/forum/thread.php?threadid=6442
Falls jemand ICS benutzen will, braucht er den ganzen Rest hier wohl eher nicht zu lesen.
Das grundlegende Problem, an dem alle zu knabbern haben, ist NAT (network address translation) in Kombination mit eingehenden Verbindungen. Die (zumindest bei vielen Routern) Lösung bzw. Umgehung des Problems ist portforwarding bzw. portmapping.
Was ist NAT?
Da ich das Rad nicht zweimal erfinden will:
Vielleicht das ganze nochmal laienhaft zusammengefaßt:
Um sich im Internet bewegen zu können, benötigt man eine öffentliche IP, die gibts vom Provider. Leider meist nur eine, obwohl man eventuell mit mehreren Rechnern online sein möchte. Um das Problem zu umgehen, ersetzt der Router als Absenderadresse bei jeder Anfrage aus dem eigenen Netz die private IP durch die (einzige) öffentliche IP und merkt sich zusätzlich, von welchem Rechner die Anfrage kam. So kann er eintreffende Antworten entsprechend zuordnen und an den richtigen internen Rechner weiterleiten.
Das funktioniert wunderbar für alle die Dienste/Protokolle, bei denen die Verbindung vom client (dem Rechner im eigenen Netz) initiiert wird, und bei dem die Antwortdaten nur über diese Verbindung gehen. Darunter fallen z.B. www, email, telnet/ssh und noch viele mehr.
Leider gehört Siedler 3 nicht zu dieser Kategorie.
Es gibt nämlich auch Protokolle, bei denen zwar ein client eine Verbindung zum server aufbaut, als Reaktion aber u.a. auch eine neue Verbindung vom Server zum client aufgebaut wird. Bekanntester Vertreter ist dabei wohl (active-)ftp mit seinem ftp-data Kanal.
Normalerweise ist dieses Verhalten auch kein Problem, im Zusammenhang mit NAT allerdings schon. Diese neue Verbindung baut der Server natürlich zur Ursprungsadresse seiner eingegangen Anfrage auf, und das ist die öffentliche IP des Routers (was anderes sieht der Server ja nicht). Folglich bekommt der Router eine eingehende Verbindung auf einem (beliebigen) Port. Da es eine neue Verbindung ist, ist sie für den Router erstmal keinem internen Rechner zugehörig, und da er mit eingehenden Verbindungen im Normalfall nichts anzufangen weiß, wird er sie wahrscheinlich verwerfen. Der interne client wartet seinerseits aber verzweifelt auf diese Verbindung, bis er irgendwann auf ein timeout läuft und die versuchte Verbindung abbricht.
Also muß man dem Router irgendwie beibringen, daß er die neue Verbindung doch bitte schön an den client weiterleiten soll, der die ursprüngliche Anfrage gestellt hatte. Teilweise klappt das sogar
So sollte heutzutage jeder NAT-Router auch mit ftp klarkommen, da es ein Standardprotokoll und enorm verbreitet ist. Durch das Wissen über das spezielle Protokoll kann der Router entsprechende Antwortverbindungen dem richtigen internen Rechner zuordnen.
Nun steht hier schon soviel Blabla und noch immer nichts zu Siedler 3, wann kommt der Typ endlich mal zur Sache? Jetzt (vielleicht)
Siedler 3 benutzt zur Kommunikation zwei unterschiedliche Protokolle:
Für den Lobbychat wird eine Eigenentwicklung von BB benutzt,
für den Mini-chat vor dem Spiel und für das eigentliche Spiel wird das direct-play Protokoll von Microsoft benutzt.
Protokolle sind oft an spezifische Port geknüpft, so auch hier, BB hat sie sogar in seiner FAQ vermerkt:
http://www.siedler3.de/faq/faq3.htm#3-002-1
Leider wird es wohl kaum einen Router geben, der diese (unbekannten) Protokolle von Haus aus unterstützt (im Gegensatz zum oben angesprochenen Protokoll ftp)
Ein paar Worte zum direct-play-Protokoll, ohne Gewähr:
Wenn ein host ein neues Spiel öffnet, so wartet er auf port 47624 (tcp und udp) auf eingehende Anfragen.
Möchte sich ein Spieler einklinken, so verbindet er sich zu dem port und es werden diverse Informationen ausgetauscht.
Unter anderem wählen host und client jeweils zufällig einen port aus dem Bereich 2300 bis 2400.
Daraufhin baut der client zum zufälligen port des hosts eine Verbindung auf, anschließend der host eine andere Verbindung zum zufälligen port des clients. Dies geschieht jeweils einmal für tcp und einmal für udp.
Und genau dieser gegenseitige Verbindungsaufbau führt mit NAT zu den weiter oben angesprochenen Problemen, da der Router mit der eingehenden Verbindungsanfrage nichts anzufangen weiß, er kann sie nicht zuordnen, da er kein Wissen über dieses Protokoll hat.
Wenn dieser Verbindungsaufbau nicht vollständig zu stande kommt, erhält man das bekannte
"Status: verbinde" und nach einem timeout irgendwann "Status: nicht verbunden".
Genereller Lösungsvorschlag in bezug auf NAT:
ports 2300-2400 und 47624, jeweils TCP und UDP forwarden.
Das Lobbyprotokoll basiert komplett auf udp. Im Normalfall verbindet der client von port 3343 auf den lobbyserver mit Zielport 3344 und 3345 (ist zumindest meine Beobachtung).
Betritt man einen chatraum, so übermittelt der lobbyserver scheinbar ip und source-port der aktuellen teilnehmer, denn wenn man selber eine Nachricht schreibt, geht die nicht etwa an den Server und von da an die Teilnehmer, nein, sie wird direkt an jeden Teilnehmer einzeln geschickt. So ballert man also durch einen Satz bei 60 Teilnehmern gleich mal 60 Pakete raus, find ich schon irgendwie lustig
Da udp ein unzuverlässiges Protokoll ist, ist das vielleicht auch der Grund, warum die lobby ab und zu Nachrichten schluckt (obwohl sie effektiv damit gar nichts zu tun hat).
Genereller Lösungsvorschlag in bezug auf NAT:
die eigentliche Verbindung zum Lobbyserver(sofern man bei udp von Verbindung reden kann) wird mit den Standard NAT-Einstellungen gehandhabt, das ist also kein Problem.
Anders sieht es mit dem chatten aus.
Wie oben erwähnt wird der Text an den source-port der jeweiligen client-lobbyserver Verbindung geschickt. Das udp-Protokoll erlaubt sowas. Andereseits kann dieses auch als eine Sicherheitslücke angesehen werden:
http://www.kb.cert.org/vuls/id/24140
Je nach Router kann die lobby daher ohne gesonderte Einstellung gleich funktionieren, oder man muß zusätzlich ein
portforwarding für udp port 3343 einrichten (oder bei linux mit 2.2er kernel den dloose Schalter aktivieren).
Sollte der port 3343 auf dem siedlerrechner eventuell einmal durch eine andere Anwendung belegt sein, so nimmt Siedler den nächsthöheren, freien Port als Ausgang, in dem Fall müßte man nicht nur 3343, sondern auch noch 3444, 3345 usw. forwarden, um damit keine Probleme zu haben.
Ich habe meinen Beitrag von damals nochmal ausgegraben, aber da sich am Spiel nichts geändert hat, dürfte er immer noch gültig sein. Mal abgesehen von einigen Links.
Im Folgenden möchte ich Informationen und Hilfen zu Siedler3 in Kombination mit einem Router präsentieren. Die Informationen stammen aus Forenbeiträgen, anderen Quellen im Netz, persönlichen Gesprächen oder Try&Error-Prozeduren.
Alle Angaben sind ohne Gewähr, der Autor haftet nicht für Fehlfunktionen oder Schäden an Router/Rechner oder sonstigem. Auch nicht für eingedellte oder angenagte Tischplatten.
Viel Spaß beim Lesen wünscht Knight Jim
In letzter Zeit haben immer mehr Leute das Problem, daß sie Siedler 3 hinter einem Router (genauer: NAT-Router) spielen möchten und dies ohne besondere Einstellungen erstmal nicht funktioniert.
Dabei ist es egal, ob es nun ein Hardware-Router (DSL-Router sind ja grad sehr beliebt) oder eine Software-Lösung ist
(ich persönlich habe eine Linux/Netfilter/iptables Kombination
).
Bei einigen Software Lösungen soll es allerdings ohne besondere Einstellungen gehen, z.B. mit dem Windowseigenen ICS, die kennen scheinbar ihr eigenes proprietäres Protokoll ganz gut und haben dafür einen entsprechenden Proxy eingebaut.
Gambler hat dazu eine Anleitung geschrieben: http://settlers4.net/forum/thread.php?threadid=6442
Falls jemand ICS benutzen will, braucht er den ganzen Rest hier wohl eher nicht zu lesen.
Das grundlegende Problem, an dem alle zu knabbern haben, ist NAT (network address translation) in Kombination mit eingehenden Verbindungen. Die (zumindest bei vielen Routern) Lösung bzw. Umgehung des Problems ist portforwarding bzw. portmapping.
Was ist NAT?
Da ich das Rad nicht zweimal erfinden will:
Zitat
Original von http://www.belwue.de/support/ulm/faq/nat.htm
Im Internet hat i.d.R. jeder einzelne Rechner eine weltweit eindeutige Nummer, die IP-Adresse genannt wird. Diese IP-Adressen bestehen aus 4 Zahlengruppen (Oktette genannt), die durch Punkte getrennt sind. Zugeteilt werden diese IP-Adressen vom jeweiligen Provider, der seinerseits wiederum von einer übergeordneten Organistion einen mehr weniger grossen Block von Adressen erworben hat.
Die Adressen reichen von 0.0.0.0 bis 255.255.255.255. Der grösste Wert den ein Oktett annehmen kann, ist die grösste durch 8-Bit darstellbare Zahl, also 255 oder FF in hexadezimaler Schreibweise.
Es ist vereinbart, dass Nachrichten für folgende IP-Adressen im Internet nicht weitergeleitet (geroutet) werden, wobei eine alleinstehende Null jeden Wert von Null bis 255 annehmen kann:
10.0.0.0
127.0.0.0 [ local host ]
172.16.0.0
192.168.0.0
Diese Adressbereiche sind für sog. private Adressierung reserviert. Privat deshalb, weil diese Adressen eben nur innerhalb eines LANs Gültigkeit haben.
Damit aber Rechner dieser Adressbereiche auch am weltweiten Datenverkehr teilnehmen können, gibt es Programme (Protokolle genannt), die diese Datenpakete von Rechnern mit "privater" IP-Adresse quasi in einen neuen Briefumschlag stecken und diesen mit der eigenen weltweit eindeutigen Absender-Adresse versehen und über den Gateway hinaus ins Internet befördern.
Treffen aus dem Internet Antwort-Datenpakete ein, wird der Umschlag entfernt und am inliegenden Umschlag kann das Protokoll erkennen, welchem Rechner im LAN das Datenpaket zugestellt werden soll. Dieser Vorgang wird Adressumsetzung genannt.
Auf diese Weise ist es möglich, über eine einzige weltweit eindeutige IP-Adresse u.U. Tausende von Rechnern eines "privaten" LANs mit dem Internet zu verbinden, wobei dazu noch die Rechner des LANs von aussen her betrachtet transparent sind und auf die folglich auch von aussen her nicht unmittelbar zugegriffen werden kann.
Im Internet hat i.d.R. jeder einzelne Rechner eine weltweit eindeutige Nummer, die IP-Adresse genannt wird. Diese IP-Adressen bestehen aus 4 Zahlengruppen (Oktette genannt), die durch Punkte getrennt sind. Zugeteilt werden diese IP-Adressen vom jeweiligen Provider, der seinerseits wiederum von einer übergeordneten Organistion einen mehr weniger grossen Block von Adressen erworben hat.
Die Adressen reichen von 0.0.0.0 bis 255.255.255.255. Der grösste Wert den ein Oktett annehmen kann, ist die grösste durch 8-Bit darstellbare Zahl, also 255 oder FF in hexadezimaler Schreibweise.
Es ist vereinbart, dass Nachrichten für folgende IP-Adressen im Internet nicht weitergeleitet (geroutet) werden, wobei eine alleinstehende Null jeden Wert von Null bis 255 annehmen kann:
10.0.0.0
127.0.0.0 [ local host ]
172.16.0.0
192.168.0.0
Diese Adressbereiche sind für sog. private Adressierung reserviert. Privat deshalb, weil diese Adressen eben nur innerhalb eines LANs Gültigkeit haben.
Damit aber Rechner dieser Adressbereiche auch am weltweiten Datenverkehr teilnehmen können, gibt es Programme (Protokolle genannt), die diese Datenpakete von Rechnern mit "privater" IP-Adresse quasi in einen neuen Briefumschlag stecken und diesen mit der eigenen weltweit eindeutigen Absender-Adresse versehen und über den Gateway hinaus ins Internet befördern.
Treffen aus dem Internet Antwort-Datenpakete ein, wird der Umschlag entfernt und am inliegenden Umschlag kann das Protokoll erkennen, welchem Rechner im LAN das Datenpaket zugestellt werden soll. Dieser Vorgang wird Adressumsetzung genannt.
Auf diese Weise ist es möglich, über eine einzige weltweit eindeutige IP-Adresse u.U. Tausende von Rechnern eines "privaten" LANs mit dem Internet zu verbinden, wobei dazu noch die Rechner des LANs von aussen her betrachtet transparent sind und auf die folglich auch von aussen her nicht unmittelbar zugegriffen werden kann.
Vielleicht das ganze nochmal laienhaft zusammengefaßt:
Um sich im Internet bewegen zu können, benötigt man eine öffentliche IP, die gibts vom Provider. Leider meist nur eine, obwohl man eventuell mit mehreren Rechnern online sein möchte. Um das Problem zu umgehen, ersetzt der Router als Absenderadresse bei jeder Anfrage aus dem eigenen Netz die private IP durch die (einzige) öffentliche IP und merkt sich zusätzlich, von welchem Rechner die Anfrage kam. So kann er eintreffende Antworten entsprechend zuordnen und an den richtigen internen Rechner weiterleiten.
Das funktioniert wunderbar für alle die Dienste/Protokolle, bei denen die Verbindung vom client (dem Rechner im eigenen Netz) initiiert wird, und bei dem die Antwortdaten nur über diese Verbindung gehen. Darunter fallen z.B. www, email, telnet/ssh und noch viele mehr.
Leider gehört Siedler 3 nicht zu dieser Kategorie.
Es gibt nämlich auch Protokolle, bei denen zwar ein client eine Verbindung zum server aufbaut, als Reaktion aber u.a. auch eine neue Verbindung vom Server zum client aufgebaut wird. Bekanntester Vertreter ist dabei wohl (active-)ftp mit seinem ftp-data Kanal.
Normalerweise ist dieses Verhalten auch kein Problem, im Zusammenhang mit NAT allerdings schon. Diese neue Verbindung baut der Server natürlich zur Ursprungsadresse seiner eingegangen Anfrage auf, und das ist die öffentliche IP des Routers (was anderes sieht der Server ja nicht). Folglich bekommt der Router eine eingehende Verbindung auf einem (beliebigen) Port. Da es eine neue Verbindung ist, ist sie für den Router erstmal keinem internen Rechner zugehörig, und da er mit eingehenden Verbindungen im Normalfall nichts anzufangen weiß, wird er sie wahrscheinlich verwerfen. Der interne client wartet seinerseits aber verzweifelt auf diese Verbindung, bis er irgendwann auf ein timeout läuft und die versuchte Verbindung abbricht.
Also muß man dem Router irgendwie beibringen, daß er die neue Verbindung doch bitte schön an den client weiterleiten soll, der die ursprüngliche Anfrage gestellt hatte. Teilweise klappt das sogar
So sollte heutzutage jeder NAT-Router auch mit ftp klarkommen, da es ein Standardprotokoll und enorm verbreitet ist. Durch das Wissen über das spezielle Protokoll kann der Router entsprechende Antwortverbindungen dem richtigen internen Rechner zuordnen.
Nun steht hier schon soviel Blabla und noch immer nichts zu Siedler 3, wann kommt der Typ endlich mal zur Sache? Jetzt (vielleicht)
Siedler 3 benutzt zur Kommunikation zwei unterschiedliche Protokolle:
Für den Lobbychat wird eine Eigenentwicklung von BB benutzt,
für den Mini-chat vor dem Spiel und für das eigentliche Spiel wird das direct-play Protokoll von Microsoft benutzt.
Protokolle sind oft an spezifische Port geknüpft, so auch hier, BB hat sie sogar in seiner FAQ vermerkt:
http://www.siedler3.de/faq/faq3.htm#3-002-1
Leider wird es wohl kaum einen Router geben, der diese (unbekannten) Protokolle von Haus aus unterstützt (im Gegensatz zum oben angesprochenen Protokoll ftp)
Ein paar Worte zum direct-play-Protokoll, ohne Gewähr:
Wenn ein host ein neues Spiel öffnet, so wartet er auf port 47624 (tcp und udp) auf eingehende Anfragen.
Möchte sich ein Spieler einklinken, so verbindet er sich zu dem port und es werden diverse Informationen ausgetauscht.
Unter anderem wählen host und client jeweils zufällig einen port aus dem Bereich 2300 bis 2400.
Daraufhin baut der client zum zufälligen port des hosts eine Verbindung auf, anschließend der host eine andere Verbindung zum zufälligen port des clients. Dies geschieht jeweils einmal für tcp und einmal für udp.
Und genau dieser gegenseitige Verbindungsaufbau führt mit NAT zu den weiter oben angesprochenen Problemen, da der Router mit der eingehenden Verbindungsanfrage nichts anzufangen weiß, er kann sie nicht zuordnen, da er kein Wissen über dieses Protokoll hat.
Wenn dieser Verbindungsaufbau nicht vollständig zu stande kommt, erhält man das bekannte
"Status: verbinde" und nach einem timeout irgendwann "Status: nicht verbunden".
Genereller Lösungsvorschlag in bezug auf NAT:
ports 2300-2400 und 47624, jeweils TCP und UDP forwarden.
Das Lobbyprotokoll basiert komplett auf udp. Im Normalfall verbindet der client von port 3343 auf den lobbyserver mit Zielport 3344 und 3345 (ist zumindest meine Beobachtung).
Betritt man einen chatraum, so übermittelt der lobbyserver scheinbar ip und source-port der aktuellen teilnehmer, denn wenn man selber eine Nachricht schreibt, geht die nicht etwa an den Server und von da an die Teilnehmer, nein, sie wird direkt an jeden Teilnehmer einzeln geschickt. So ballert man also durch einen Satz bei 60 Teilnehmern gleich mal 60 Pakete raus, find ich schon irgendwie lustig
Da udp ein unzuverlässiges Protokoll ist, ist das vielleicht auch der Grund, warum die lobby ab und zu Nachrichten schluckt (obwohl sie effektiv damit gar nichts zu tun hat).
Genereller Lösungsvorschlag in bezug auf NAT:
die eigentliche Verbindung zum Lobbyserver(sofern man bei udp von Verbindung reden kann) wird mit den Standard NAT-Einstellungen gehandhabt, das ist also kein Problem.
Anders sieht es mit dem chatten aus.
Wie oben erwähnt wird der Text an den source-port der jeweiligen client-lobbyserver Verbindung geschickt. Das udp-Protokoll erlaubt sowas. Andereseits kann dieses auch als eine Sicherheitslücke angesehen werden:
http://www.kb.cert.org/vuls/id/24140
Je nach Router kann die lobby daher ohne gesonderte Einstellung gleich funktionieren, oder man muß zusätzlich ein
portforwarding für udp port 3343 einrichten (oder bei linux mit 2.2er kernel den dloose Schalter aktivieren).
Sollte der port 3343 auf dem siedlerrechner eventuell einmal durch eine andere Anwendung belegt sein, so nimmt Siedler den nächsthöheren, freien Port als Ausgang, in dem Fall müßte man nicht nur 3343, sondern auch noch 3444, 3345 usw. forwarden, um damit keine Probleme zu haben.
Hinweis
Nach Klick auf "OK" wird eine Verbindung zu Facebook oder twitter hergestellt. Dadurch werden ggfs. Daten an diese Plattformen übermittelt.