Um vom Internet aus zugänglich Serverdienste hinter dem Router anbieten zu können sind häufig mehr oder weniger aufwendige Konfigurationen im Routersetup erforderlich.
Häufig reicht es einzelne Ports freizugeben - manche Serverdienste lassen sich allerdings nur mit einigem Aufwand und etwas Trickserei dazu überreden, hinter einem Router zu laufen.
Grundsätzlich besteht gerade beim Austesten eines neuen Dienstes immer die Möglichkeit den Client-Rechner, auf dem der Serverdienst laufen soll, im Router in der sogenannten DMZ (Demilitarized Zone) zu konfigurieren.
In diesem Fall wird der Router "vor" jegliche Firewall-Filter gesetzt und bekommt vereinfacht gesagt die Ports auf Anforderung durch die Serveranwendug 1:1 per NAT durchgereicht. Der Client, der in die DMZ gesetzt wird, verhält sich somit (annähernd) so wie ein Rechner, der direkt z.B. per DFÜ-Netzwerk mit dem Internet verbunden ist.
Sollten Serveranwendungen auch in der DMZ nicht laufen, hat man relativ schlechte Aussichten die Anwendung ohne weitere Massnahmen hinter dem Router zum Laufen zu bekommen.
Einen WWW-Server hinter dem Router zu betreiben ist relativ einfach.
Für die Erreichbarkeit des Servers muss der Standard-WWW-Port geöffnet und auf den Rechner geleitet werden, auf dem der WWW-Server läuft.
Zu öffnende Ports (im NAT-Setup-Menü):
IN TCP 80 (in "Open Ports Setup" oder "Port Redirection")
Weitere Hinweise:
Der Server ist nun aus dem Internet über die WAN-IP des Routers zu erreichen.
Damit man immer unter einer festen Adresse zu erreichen ist (man bekommt ja üblicherweise von seinem Provider eine dynamische WAN-IP), sollte man einen der vielen Dynamic-IP-Services nutzen. Man erhält dann eine feste Adresse der Form: "user.dyndns.org", über die der Router vom Internet aus adressiert wird. Eingebaut in den Router ist der Support für http://www.dyndns.org. Es lassen sich aber auch andere Dienste nutzen, bei denen dann ein Programm die Überwachung und Aktualisierung der IP übernimmt - dies hat den Vorteil, dass man bestimmen kann, wann die IP mit dem Namen synchronisiert werden soll. Ein meiner Meinung sehr guter Dienst mit einem kostenlosen Clientprogramm ist z.B. http://www.no-ip.com
Sollte man das Mangement des Routers über das Internet freigeschaltet haben (Fernwartung in: > System Management > Management Setup > Management Access Control > Allow management from the Internet), dann muss man den Port 80 auf der gleichen Konfigurationsseite bei > Management Port Setup "umbiegen" z.B. auf 8080, da ansonsten 2 Webserver auf dem gleichen Port laufen würden (was nicht funktioniert). Das Vigor-Webinterface ist dann zu erreichen, indem man die IP mit Portangabe im Browser angibt (also z.B. http://192.168.1.1:8080).
Der Server kann nicht aus dem LAN direkt über die WAN-IP (oder eine eventuell eingerichtete Dynamic-IP-Adresse) des Routers erreicht werden
- Korrektur: Irgendwann in der Firmware-Geschichte wurde das Verhalten von NAT anscheinend verbessert. Seit der 2.0a scheint es jedenfalls zu funktionieren, auch seinen eigenen Server über die WAN-IP ansprechen zu können.
Hierbei handlet es sich aber um eine LoopBack im Router und es werden keine Datenpakete über das Internet geschickt, sondern die Daten verlassen nie das LAN!
Man kann über dieses LoopBack also weiterhin nicht die Erreichbarkeit seines eigenen Servers aus dem Internet testen!
- Ergänzung: Sollte trotz Weiterleitung des Ports 80 das Webinterface des Routers und nicht der eigene Webserver des LANs erscheinen, so solle man den Router-Zugriffsport (wie bei "aktivierter Fernwartung" weiter oben beschrieben) ändern. Nur so teilt man auch dem Router eindeutig seine "Absicht" mit, was man beim Zugriff auf die WAN-IP bzw. den DNS-Alias wirklich erreichen möchte: Den Webserver im LAN oder das Webinterface.
- Hinweis: Auch wenn eventuell das Webinterface bei Aufruf der WAN-IP oder des DNS-Alias erscheint, heisst das nicht, dass das Webinterface aus dem Internet heraus zu sehen ist. Das ist nur der Fall bei aktiverter Fernwartung!
Testen kann man den Server, indem man ihn über "localhost" oder die IP-Adresse im LAN anspricht. Alternativ kann man zum testen des Servers noch sogenannte "Anon-Proxys" verwenden, die die eigene IP maskieren - bespielsweise: http://@nonymouse.com/ oder https://www.safeweb.com/. Diese Anon-Proxys sind aber erfahrungsgemäß meist sehr langsam, haben aber den Vorteil, dass man ohne Netzpartner testen kann, ob die eigene Seite auch im Internet z.B. über den eingerichteten Dynamic-IP-Dienst angesprochen werden kann. Nur so lässt sich auch die Internet-Erreichbarkeit aus dem eigenen LAN heraus testen!
Der FTP-Transfer ist eines der ältesten Internet-Dienste.
Die meisten Browser bieten auch direkt die Möglichkeit einen FTP-Server anzusprechen; dies ist aber häufig nicht ohne Probleme, da gerade bei passwortgeschützten FTP-Servern häufiger Probleme auftreten und sich speziell der Internet-Explorer nicht in allen Bereichen sauber an die RFCs für FTP hält.
Es empfiehlt sich daher für reibungslosen Ablauf beim FTP-Transfer auf jeden Fall "echte" FTP-Clients zu nutzen. Es gibt hier eine grosse Auswahl an Freeware-Programmen.
Nun aber zum FTP-Serverdienst:
Ein FTP-Transfer kann auf zwei verschiedene Arten ausgehandelt werden bzw. ablaufen:
1. Aktive FTP
Für die meisten User, die einen FTP-Server (zeitweise) anbieten wollen, dürfte Aktive FTP die interessantere Variante sein.
Aktive FTP ist für die Firewall des SERVERS deutlich einfacher zu konfigurieren, da nur Port 21 von AUSSEN geöffnet sein muss (von aussen nach innen vom Server aus gesehen). Port 20 wird vom Server geöffnet (also von innen nach aussen). Daher muss dieser Port nicht für Verbindungsaufnahme (initial) von aussen geöffnet werden, sondern die Firewall muss nur einen Verbindungsaufbau durch den Server zulassen (also von innen nach aussen).
Wenn die Verbindung vom Server connected wurde, laufen die Daten dann bidirektional - mag sein, dass die Vigor-Router hier dann Eigenintelligenz entwickelt und das daher zulässt und bei anderen Firewalls hier der Port 20 eventuell restriktiver gehandhabt wird und auch explizit zu öffnen ist.
Zu öffnende Ports (im NAT-Setup-Menü):
IN TCP 21 (in "Open Ports Setup" oder "Port Redirection")
2. Passive FTP
Passive FTP ist für den Client (der eventuell hinter einer Firewall sitzt) günstiger, da der Client die Ports öffnet. Für die Firewall des Servers ist es aber so, dass in der Firewall viele Ports zu öffnen sind, damit sich die Clients von aussen initial damit connecten können. Der Server bestimmt hier zwar den Port für die Verbindung, aber der Client öffnet ihn!
Es sollten hier dann z.B. die ersten 256 Port oberhalb von 1024 geöffnet werden.
Der Server ist nun aus dem Internet über die WAN-IP des Routers zu erreichen.
Damit man immer unter einer festen Adresse zu erreichen ist (man bekommt ja üblicherweise von seinem Provider eine dynamische WAN-IP), sollte man einen der vielen Dynamic-IP-Services nutzen. Man erhält dann eine feste Adresse der Form: "user.dyndns.org", über die der Router vom Internet aus adressiert wird. Eingebaut in den Router ist der Support für http://www.dyndns.org. Es lassen sich aber auch andere Dienste nutzen, bei denen dann ein Programm die Überwachung und Aktualisierung der IP übernimmt - dies hat den Vorteil, dass man bestimmen kann, wann die IP mit dem Namen synchronisiert werden soll. Ein meiner Meinung sehr guter Dienst mit einem kostenlosen Clientprogramm ist z.B. http://www.no-ip.com
Der Server kann nicht aus dem LAN direkt über die WAN-IP (oder eine eventuell eingerichtete Dynamic-IP-Adresse) des Routers erreicht werden
- Korrektur: Irgendwann in der Firmware-Geschichte wurde das Verhalten von NAT anscheinend verbessert. Seit der 2.0a scheint es jedenfalls zu funktionieren, auch seinen eigenen Server über die WAN-IP ansprechen zu können.
Hierbei handlet es sich aber um eine LoopBack im Router und es werden keine Datenpakete über das Internet geschickt - die Daten verlassen nie das LAN!
Man kann über dieses LoopBack also weiterhin nicht die Erreichbarkeit seines eigenen Servers aus dem Internet testen!
- Ergänzung: Sollte trotz Weiterleitung des Ports 21 nicht der eigene FTP-Server des LANs erscheinen, so solle man den Router-Zugriffsport (wie bei "aktivierter Fernwartung" weiter oben beim www-Server beschrieben) ändern. Nur so teilt man auch dem Router eindeutig seine "Absicht" mit, was man beim Zugriff auf die WAN-IP bzw. den DNS-Alias wirklich erreichen möchte (s.a. Tipp zum Webserver)
Testen kann man den Server, indem man ihn über "localhost" oder die IP-Adresse im LAN anspricht. Alternativ kann man zum testen des Servers noch sogenannte "Anon-Proxys" verwenden, die die eigene IP maskieren - bespielsweise: http://@nonymouse.com/ oder https://www.safeweb.com/. Diese Anon-Proxys sind aber erfahrungsgemäß meist sehr langsam, haben aber den Vorteil, dass man ohne Netzpartner testen kann, ob die eigene Seite auch im Internet z.B. über den eingerichteten Dynamic-IP-Dienst angesprochen werden kann. Da der FTP-Server aber hier nicht über einen echten FTP-Client angesprochen werden kann, ist der Zugriff über diese browserbasierenden Proxys nicht unproblematisch bei Prüfung des eigenen FTP-Servers. Ein Netz-Kollege, der den Zugriff auf den eigenen FTP-Server gegencheckt, ist hier allemal besser geeignet.
Zu öffnende Ports (im NAT-Setup-Menü):
IN UDP 27005 (in "Open Ports Setup" oder "Port Redirection")
IN UDP 27015 (in "Open Ports Setup" oder "Port Redirection")
Weitere Hinweise:
Server aufsetzen unter Menüpunkt "Play Online" und dann "Create".
Der Server läuft auch, wenn man im Router über das DMZ-Menü alle Ports des Server-PCs freischaltet.
Man kann sich auch aus dem eigenen LAN einwählen, aber nur unter dem CS-Menü "Play on LAN". Es schlägt fehl, wenn man versucht, mit "Play Online" ins Internet zu gehen und von dort wieder zum Server ins eigene LAN! Grund: Die Quellen-IP und die Ziel-IP sind gleich. Das fängt wohl schon der Router ab.
Bandbreite: Man braucht *mindestens* ca. 32kbit/s pro Spieler im Uplink-Kanal. Also bei ISDN max. 2 Spieler und bei T-DSL maximal 4 Spieler. In den Clients kann man die Datenrate in einem Menü einstellen.
Wenn man Bots auf den Server gibt, kommen erfahrungsgemäß recht bald Spieler aus dem Internet auf den Server. Bei Podbot 2.5 gibt es aber einen Fehler. Im "Dedicated Server"-Modus muss man den Podbot-Kommandos einen Präfix voranstellen. Den Kommando-Präfix "bot" hat Count Floyd bei Version 2.5 in "pb" abgeändert (ohne Hochkommata). Er hat es aber an einer Stelle vergessen. "pb killbots" funktioniert daher z.B. nicht. Man muss in einem Hexeditor in Podbot.dll nach einem String "bot" suchen (mit schließender Maschinennull) und diesen dann durch "pb0" ersetzen, wobei 0 die *Maschinennull* ist und die Hochkommata wegzulassen sind. Dann funktionieren die Bot-Kommandos. In der nächsten Version wird der Fehler wohl behoben sein.
Wie bringt man den "Esel" (eDonkey) unter dem Vigor zum rennen?
Mit folgender Konfiguration bekommt er eine hohe ID und man kann die volle Userbandbreite ausnutzen.
In einem Netzwerk kann diese Einstellung aber nur von einem Computer aus genutzt werden.
Zu öffnende Ports (im NAT-Setup-Menü):
IN TCP 4661 auf 4661 (in "Port Redirection")
IN TCP 4662 auf 4662 (in "Port Redirection")
IN UDP 4665 auf 4665 (in "Port Redirection")
IN TCP 4661 bis 4662 (in "Open Ports Setup")
IN UDP 4665 bis 4665 (in "Open Ports Setup")
Neuerdings wird auch immer häufiger der Port 6662 verwendet, daher kann bzw. sollte man noch folgende Ports zusätzlich einstellen:
IN TCP 6662 auf 6662 (in "Port Redirection")
IN TCP 6662 bis 6662 (in "Open Ports Setup")
Weitere Hinweise:
Getestet wurden diese Einstellungen für den gleichzeigen Betrieb sowohl für den Server als auch für den Client.
Beim Server sind nicht mehr als etwa 165 gleichzeitige Connections bis Firmware 1.08 möglich. Ab der Firmware 2.00 ist diese Beschränkung offensichtlich nun gefallen. Bei 1200 gleichzeitigen Connections habe ich aufgehört zu testen. Auch andere Routerherstellern haben diese Begrenzung der Connections. Diese sind aber unterschiedlich und schwanken von 300 bis 500 maximal möglichen Connections. Für den Router ist diese Verwaltung Hochleistungsarbeit, denn er muss bei jeder Anfrage und Antwort die Portnummern umsetzen. Jeder kann sich vorstellen was dies bei 1200 Connections bedeutet.
Spieler kennen das Problem, dass eine aktive Sprachübertragung die Systemleistung teilweise erheblich einschränkt,
oder Abstriche an der Sprachqualität gemacht werden.
Nun gibt es die Möglichkeit, einen Rechner, der vielleicht bisher nur einen FTP Zugang ermöglicht hat, nebenher auch
als Voice-Server zu verwenden. Nebenbei erhält man so auch die Sicherheit, dass bei einem Absturz der
Spielermaschine nicht gleich die gesamte Kommunikation der teilnehmenden Spieler zusammenbricht.
Zusätzlich erhält man ebenfalls ein System, das auch im eigenen Netzwerk einen Voice-Service zu Verfügung stellt.
Das BattleCom Servermodul wird einfach auf dem Server installiert und mit minimalem Aufwand eingerichtet.
Sämtliche Einstellungen dienen nur dem Komfort der Teilnehmer, haben aber keinen Einfluss mehr auf die
Funktionalität im Netzwerk oder Internet.
Ist das Teil installiert, müssen nur noch die passenden Ports im Router eingerichtet werden.
Zu öffnende Ports (im NAT-Setup-Menü):
IN UDP 2300 bis 2400 (in "Open Ports Setup") ACHTUNG: DirctX-Port!
IN TCP 2300 bis 2400 (in "Open Ports Setup") ACHTUNG: DirctX-Port!
IN UDP 47624 (in "Open Ports Setup")
IN TDP 47624 (in "Open Ports Setup")
Weitere Hinweise:
Eine Umleitung der DirectX-Ports leitet auch das gesamte DX-Play vom Internet aus auf nur einen Rechner!
Der Server lässt sich von jedem Rechner im Netz über die LAN-IP erreichen. Über die WAN-IP des Routers können
nun auch Leute aus dem Internet an dem Chat teilnehmen, beide Teilnehmer-Sorten lassen sich auch bedenkenlos
mischen.
Selbstverständlich setzt diese Methode einen ziemlich dicke Leitung voraus, aber schließlich macht ein Router ja
auch bei DSL erst richtig Sinn, oder?!
BattleCom Server und Gamevoice Server laufen problemlos parallel nebeneinander.
Auch der Nachfolger von BattleCom, das MS Gamevoice besitzt ein Server Modul, das sich auf eine ganz ähnliche Art
wie der BattleCom Server nutzen lässt.
Hier wird ebenfalls ein ganz simples Modul auf dem Server installiert. Der Aufwand ist noch geringer als beim
BattleCom Server, da dem Gamevoice Server die Komfortfunktionen gänzlich fehlen.
Es gibt dem BattleCom Server gegenüber aber auch einen Vorteil: der Gamevoice Server kann auf einen bestimmten
Port hinter der Firewall eingestellt werden, die Gamevoice Site von Microsoft erteilt hier eine ganze Menge
Ratschläge zur Konfiguration.
MS Supportseite zu Gamevoice
getestet unter:
- DrayTek Vigor 2200X
- Firmware 2.00 (englisch)
- Gamevoice Server Version ???
Zu öffnende Ports (im NAT-Setup-Menü):
IN UDP 59110 bis 59119 (in "Open Ports Setup" und "Port Redirection")
(für 10 Chat Sessions!)
Weitere Hinweise:
Die Ports müssen zusätzlich zur Freigabe auf den ausführenden Computer redirectet (forwarded) werden, ansonsten funktioniert es nicht!
Die möglichen Chatsessions werden durch die Freigabe bestimmt - jeder freigegebene Port ermöglicht eine Session.
Wie beim BattleCom Server lässt sich der Server vom LAN über die interne IP und vom WAN über die Router IP erreichen.
BattleCom Server und Gamevoice Server, laufen problemlos parallel nebeneinander.
Anwendung: Unreal Tournament PC Version 4.36
Im Router zu öffnender Port-Bereich: IN UDP 7777-7781
Mehr ist nicht notwendig!
Infos zu den Ports:
Auf Practical Networking http://www.practicalnetworking.com/ steht:
IN UDP 7777 (default gameplay port)
IN UDP 7778 (server query port)
IN UDP 7779+ (UDP 7779+ are allocated dynamically for each helper UdpLink objects, including UdpServerUplink objects. Try starting with 7779-7781 and add ports if needed.)
Server-Start:
Menü: Multiplayer -> Start New Internet Game
Match-Karteikarte:
Ggf. "Auto Change Levels" aktivieren. Hier kann man auch die Map-Liste editieren, durch die zyklisch iteriert wird.
Server-Karteikarte:
Treffer-Statistik "ngWorldStat Logging" abstellen. Das spart Rechner-Resourcen.
"Server Name" sollte ausgefüllt sein.
"Advertise Server" abstellen. Anderenfalls müsste man noch einen Port öffnen.
"Optimize for LAN" abstellen. Wenn man das vergisst, sendet der Server zuviele Daten für einen ADSL-Uplink von 128kbit/sec. Siehe dazu auch weiter unten.
"WWW Remote Admin" abstellen, wenn man keinen "dedicated server" stellt. Sonst aktivieren. Man kann dann aus den LAN den Server über einen Web-Browser administrieren. Vom selben Klient-PC nimmt man den URL http://127.0.0.1/ServerAdmin von einem anderen Klienten http://IP/ServerAdmin, wobei IP die private IP des Server-Klienten ist. Wenn man den Wg-Interface-Port abgeändert hat, z.B. in 8080 muss man http://127.0.0.1:8080/ServerAdmin oder http://IP:8080/ServerAdmin wählen.
Datenrate einstellen:
Datei UT\System\UnrealTournament.ini suchen. UT steht fürs Unreal-Tournament-Verzeichnis. Die Datei lässt sich mit demm Notepad bearbeiten.
Die Sektion [IpDrv.TcpNetDriver] suchen. MaxClientRate gibt die Datenrate in Byte/sec an.
2600 = Modem-Qualität
5000 = ISDN-Qualität
20000 = Beste LAN-Qualität
Der ADSL-Uplink hat in Deutschland derzeit 16000 Byte/sec. Das ergibt:
16000 / 2600 = 6 Spieler mit Modem-Qualität
16000 / 5000 = 3 Spieler mit ISDN-Qualität
16000 / 8000 = 2 Spieler mit Etwas-Besser-Als-ISDN-Qualität
Bei 2600 spielt es sich nicht besonders gut.
5000 ist merklich besser und wird allgemein empfohlen.
Achtung: Wenn die Datenrate zu hoch gesetzt ist, erfahren alle Spieler einen stetig steigenden "ping".
Download der auf den Klienten fehlenden Dateien:
Das kann etwas nerven. Bei Testen kam es öfters vor, dass der Download kurz vor Ende abbrach. Dann gehts wieder von vorne los. Deshalb ist es sehr empfehlenswert, wenn alle Spieler die entsprechenden Bonuspacks und Erweiterungen voher selber installieren.
In der folgenden Sektion
[IpDrv.TcpNetDriver]
AllowDownloads=True
MaxDownloadSize=0
kann man das Downloadverhalten steuern:
AllowDownloads=True erlaubt Downloads.
AllowDownloads=False verbietet Downloads.
MaxDownloadSize=0 erlaubt jede Dateigröße.
MaxDownloadSize=100000 erlaubt es, Dateien bis 100000 Bytes herunterzuladen. Die Zahl kann man anpassen. 100000 wird empfohlen, damit sich kleinere Dateien übertragen lassen, der Server aber nicht durch ein sehr großes Download-Volumen gestört wird.
Server-Modus:
Bei "Dedicated" läuft der Server ohne Grafik. Hier reicht ein P500 locker aus. >128MB RAM sind empfehlenswert. Man kan am Klienten nicht am Spiel teilnehmen.
Bei "Start" kann man vom Server-Klienten aus am Spiel teilnehmen.
Empfehlenswert ist es, mindestens einen P800 mit Geforce2 einzusetzen. 16bit Farbtiefe hilft Resourcen einzusparen.
Start der Klienten:
Im Menü "Open Location" die IP oder den URL des Servers angeben.
Empfehlenswert: Den Router, in dessen LAN der Server läuft bei DynDNS registrieren. Dann gibt man z.B. ein: Name.dnsalias.org
Die Mac-Version scheint etwas heikel zu sein. Man brauch u.U. noch zusätzlich die Portangabe, also Name.dnsalias.org::7777
Die unüblichen zwei Doppelpunkte könnten eine Macke der Macintosh-Demo-Version sein.
Weitere Ports:
Man sollte eigentlich nur den oben angegebenen Portbereich benötigen.
In Netz kursieren allerdings noch viele weitere Angaben zu freizugebenden Ports, z.B.:
IN UDP 27900 (server query, if master server uplink is enabled. Some master servers use other ports, like 27500)
IN TCP 8080 (Port 8080 is for UT Server Admin. In the [UWeb.WebServer] section of the server.ini file, set the ListenPort to 8080 (to match the mapped port above) and ServerName to the IP assigned to the router from your ISP.)
Diese braucht man nicht freizugeben. Es wurde angenommen, dass "Advertise Server" aus ist und dass das Webinterface nur aus dem LAN benutzt wird, wenn überhaupt.
Bei UT macht es wenig Sinn, sich bei den Master-Servern zu registrieren, um den Server zu testen. Bots werden nicht als Spieler angezeigt (im Gegensatz zu Counterstrike), daher ist auf dem Server nichts los und kein Spieler kommt auf den Server. Die schmale Bandbreite erlaubt auch keine Sessions mit vielen Internet-Spielern bei einer ADSL-Anbindung.
Weiter findet man auch noch folgende angeblich freizugebende Ports:
TCP 28900
TCP 29900
TCP 29901
UDP 13139
nach oben