UT-Netzwerk-FAQ

V0.25, März 2002

Autoren: ]RHD[-Zeitkind, ]RHD[-Vierheilig, ]RHD[-Ko-Dji

1. Allgemeines

Ziel dieses FAQ (frequently asked questions - häufig gestellte Fragen) ist es, einige immer wiederkehrende Probleme bei Netzwerken und Internetverbindungen zu beschreiben und eventuell Lösungsmöglichkeiten oder Erklärungen anzubieten.

Im wesentlichen behandelt werden Router, Proxies, NAT, Ports und Port-mapping, Firewalls und ähnliche Dinge, die immer wieder beim Umgang mit dem Internetprotokoll TCP/IP auftauchen. Obwohl als FAQ deklariert, wird das ganze wohl erst mal eine kleine Abhandlung. Spezielle Fragen mit Antworten machen wir, wenn wir grad Zeit und Lust haben, oder jemand anderes sich erbarmt zu helfen ;)

2. Begriffe

Grundbegriffe des Netzwerkes

Bei einem Netzwerk handeltes sich um eine wie auch immer geartete Verbindung zwischen zwei oder mehreren Rechnern. Ziel ist ein eindeutiger Datenaustausch.Damit dieser zustande kommt, ist es notwendig, dass beide Rechner "die gleiche Sprache sprechen" - also das gleiche Protokoll verstehen / sprechen. Am häufigsten findet man heute das"Internetprotokoll" TCP/IP (Transmission Control Protocol /Internet Protocol), andere noch verbreitete Protokolle sindAppleTalk, NetBUI/NetBIOS, IPX, DECnet und XNS. Prinzipiell kann man dabei die Protokolle in 2 Gruppen aufteilen: routing-fähige und nicht-routing-fähige. Was heißt das?

Auch wenn man das Internet gerne als "große Gemeinschaft" ansieht, so besteht das Internet streng genommen aus Millionen kleiner Netze, die jeweils miteinander verbunden sind. Die Knotenpunkte dieses Netzes werden als "Router" bezeichnet. Routingfähige Protokolle (TCP/IP, IPX,AppleTalk Phase2) können auch über diese Router in andere Netze geleitet werden, nicht-routingfähige bleiben im Router hängen (z.B. Netbios oder LAT)

Daten werden stets in Form von "Paketen" versendet, also immer eine (oft auch von der Größe festgelegte) Anzahl von Bytes, versehen mit Absender, Zieladresse und Nutzdaten (und oft auch noch weiteren Zusatzinformationen wie z.B. Prüfsummen). Will Rechner A ein Paket an Rechner B schicken, so könnte dieses Paket so aussehen:

Flags: 0x00

Status: 0x00

PacketLength: 64

Timestamp: 23:15:56.61415102/02/01

EthernetHeader

Destination: 00:05:02:f1:a4:a8

Source: 00:90:27:65:9f:f2

ProtocolType: 0x0800 IP

IP Header -Internet Protocol Datagram

Version: 4

HeaderLength: 5

Precedence: 0

Type of Service: %0000

Unused: %0

Total Length: 40

Identifier: 4096

Fragmentation Flags: %000

Fragment Offset: 0

Time To Live: 128

IPType: 0x06 TCP

HeaderChecksum: 0x1f2d

Source IP-Address: 192.168.69.13

Dest. IP-Address: 192.168.69.69

No Internet Datagram Options

TCP -Transport Control Protocol

SourcePort: 49706

DestinationPort: 23 TELNET

SequenceNumber: 0

AckNumber: 1574430894

Offset: 5

Reserved: %000000

Code: %010100

Ack is valid

Reset Connection

Window: 0

Checksum: 0x9b65

UrgentPointer: 0

No TCP Options

No More TELNET Data

Extra Bytes(Padding): ------ 00 00 00 00 00 00

Frame Check Sequence: 0x00000000

Hier handelt es sich um ein TCP/IP-Paket auf Ethernet - erkennbar am Ethernet-Rahmen (=verpackt für Ethernet mit MAC-Adresse etc.) Für uns interessant ist erst der 2. Teil:

IP Header- Internet Protocol Datagram

Version: 4

TCP/IP Version 4. Die fünfte gibt es nicht, die Ipv6 wird erst langsam implementiert, dazu später.

HeaderLength: 5

[...]

IP Type: 0x06 TCP

Protokolltyp (hier: TCP – also Transmission Control Protocol)

HeaderChecksum: 0x1f2d

Prüfsumme des Headers (=Kopf oder Beginn des Paketes)

Source IP-Address: 192.168.69.13

Absender hat die IP-Adresse 192.168.69.13

Dest. IP-Address: 192.168.69.69

Empfänger hat die IP-Adresse 192.168.69.69

SourcePort: 49706

Destination Port: 23 TELNET

Der Quell- und Zielport des Paketes, hier der Versuch, eine Telnet-Verbindung aufzubauen.

Fazit: In jedem Paket steht ein Absender, ein Empfänger und wozu das Paketdient, also z.B. ftp, telnet, http, smpt, snmp, finger, gopher usw. oder ob es Teil einer bereits bestehenden Datenverbindung ist (z.B.ftp-Verbindung), wobei dann eine Seriennummer mit übermittelt wird. Leider würde dieses Paket aber nie durch das Internet gelangen...warum?

Tja, dazu muss man etwas in die Geschichte des Internet zurück. Als man das Internet geplant hat, wollte man eigentlich nur ein paar Uni-Rechner und Forschungseinrichtungen miteinander verbinden. Damit man es einfach hatte, bekam der Host (=Rechner im Netz) eine eindeutige IP-Nummer zugeteilt, z.B. 3.4.7.54 oder 17.34.5.9.

Jede IP-Adresse besteht aus vier Zahlen, jeweils von 0-255. So ergeben sich 2 hoch 32 Adressen, also rund 4,2 Milliarden. Einige dieser Adressen sind jedoch bereits für "interne" Betriebssystemspezifische Dinge reserviert, so ist z.B. die 127.0.0.1 immer der Rechner selber (Test: ping 127.0.0.1 sollte immer eine Antwort bringen, sonst ist was faul), der Bereich oberhalb 224.0.0.0 - 255.255.255.0 wird ebenfalls von manchen Systemen für interen Dinge verwendet – Stichwort "multicast" (offiziell "not allocated" wie auch 217.0.0.0 - 223.255.255.0).

Zieht man diese Bereiche ab, dann blieben ja immer noch sehr viele Adressen übrig(2147483774) - nur leider trotzdem nicht genug für alle. Zum einen sind viele Adressen durch einige Firmen "blockiert" (so besitzen einige der "alten" IT-Unternehmen ganze Class-A-Netze- M$, Apple etc.), zum anderen gehen viele Addressen durch ungeschicktes oder notwendiges Aufspalten des Adressraums verloren. Version 4 des TCP/IP-Protokolls soll zwar fließend durch Version 6 abgelöst werden (womit dann rund 3 mal 10 hoch 38 Adressen zur Verfügung stehen werden), aber die vollständige Implementierung wird noch einige Zeit (also viele Jahre)dauern.

Um Engpässe zuvermeiden, hat man sehr früh bereits bestimmte Adressebereiche (so genannte Sub-Netze A,B oder C) für die "private" Nutzung reserviert (RFC1918):

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

10.0.0.0-10.255.255.255(10/8prefix)

172.16.0.0-172.31.255.255(172.16/12prefix)

192.168.0.0-192.168.255.255(192.168/16prefix)

We will refer to the first block as "24-bit block", the second as "20-bit block", and to the third as "16-bit" block. Note that (in pre-CIDR notation) the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and third block is a set of 256 contiguous class C network numbers.

So werden in vielen Firmen nicht "offizielle" IP-Adressen verwendet, sondern z.B. das 10er-Netz. Werden dann Pakete nach "außen", also ins Internet verschickt, dann werden alle Pakete, die als Empfänger eine private IP-Adresse tragen, vom nächsten Router, der nächsten Vermittlungsstelle geschluckt. Umgekehrt, wenn zwar der Empfänger stimmt, der Absender aber eine 10er Nummer hat, dann geht halt die Antwort verloren... :D

Aber weshalb kann man dann trotzdem vom Firmennetz aus surfen??

3. NAT contra Proxy

Damit man auch von solchen privaten Netzes aus auf das Internet zugreifen kann, gibt es zwei – nennen wir es mal "erweiterten" Router: den Proxy und den NAT-fähigen Router.

Ein Proxy ist eigentlich eine Art Daten-Puffer. Wenn Rechner A (privates Netz) auf den Webserver B (Internet) zugreifen will, dann fragt er nicht direkt B, sondern "bittet" den Proxy C dies für ihn zu tun und ihm die Daten dann weiterzureichen.

Vorteil: Nur ein Rechner -nämlichC - braucht eine offizielle IP-Adresse, alle anderen brauchen nur den Proxy zu kennen.

Das geht soweit auch ganz gut, hat nur einen entscheidenden Nachteil: Nicht alle Dienste können über einen Proxy funktionieren, in manchen Fällen ist eine direkte Kommunikation zwischen A und B notwendig. Funktioniert das ganze mit http noch ganz passabel, so scheitert es bei ftp oft schon. Bestimmte Dienste wie irc gehen gar nicht.

Ausflug: "Dienste und Ports"

Als Dienst bezeichnet man eine bestimmte Art der Kommunikation zwischen zwei Rechnern, vorgegeben durch die Programme. http, ftp, telnet, pop3, finger, smtp sind geläufige Dienste. Bei TCP/IP wird jedem Dienst ein bestimmter "port" zugeordnet, quasi eine Art Anschluss auf dem Rechner. Theoretisch verfügt jeder Rechner mit TCP/IP-Protokoll über 65536 solche Anschlüsse, wobei die Ports 0-1024 oft als "well known ports" bezeichnet werden, da ihre Portnummern durch internationale Vereinbarungen systemübergreifend festgelegt sind, z.B.:

Port# Abkürzung Servicename
1 TCPMUX TCPPort Service Multiplexer
5 RJE Remote Job Entry
7 ECHO ECHO
20 FTP-Data FTP-Data
21 FTP FTP-Control
23 Telnet Telnet
25 SMTP Simple Mail Transfer Protocol
37 Time Time
42 Nameserv Host Name Server
43 WhoIs WhoIs Server
49 Login Login Host Protocol
53 DNS Domain Name System
69 TFTP Trivial File Transfer Protocol
70 Gopher Gopher Services
79 Finger Finger
80 HTTP HyperText Transfer Protocol(WWW)
103 X400 X.400 Standard
108 SNA SNA Gateway Access Server
109 POP2 Post Office Protocol version 2
110 POP3 Post Office Protocol version 3
115 SFTP Simple File Transfer Protocol
118 SQLserver SQLserver
119 NNTP Newsgroup
137 NetBIOS-NS NetBIOS Name Service
139 NetBIOS-DG NetBIOS Datagram Service
143 IMAP Interim Mail Access Protocol
150 NetBIOS-SS NetBIOS Session Service
156 SQLSRV SQLServer

In unserem IP-Paket weiter oben – wir erinnern uns – wurde eine Telnetverbindung versucht – also Port 23 auf Rechner B angesprochen. Damit das ganze aber kompliziert wird, werden die eigentlichen Verbindungen dann oft über andere höhere ports abgewickelt – der well-known-port dient dann quasi nur als erste Anlaufstelle. Die vollständige Liste der well-known-ports gibt es unter anderem hier.

Beispiel: Telnetverbindung von A nach B

Erste Anfrage von 192.168.69.13 (Rechner A) an 192.168.69.3 (Rechner B)

Source IP-Address: 192.168.69.13

Dest. IP-Address: 192.168.69.3

No Internet Datagram Options

SourcePort: 1029

Destination Port: 23 TELNET

SequenceNumber: 4746780

AckNumber: 0

Offset: 7

Reserved: %000000

Code: %000010

SynchSequence

Antwort von B:

Source IP-Address: 192.168.69.3

Dest. IP-Address: 192.168.69.13

No Internet Datagram Options

SourcePort: 23 TELNET

Destination Port: 1029

SequenceNumber: 103284754

AckNumber: 4746781

Offset: 7

Reserved: %000000

Code: %010010

Ack is valid

SynchSequence

Auffallend: Rechner A sendet an B auf Port 23, gibt aber als "Absender" den Port 1029 an. Entsprechend sendet B die Antwort auch nicht auf 23, sondern wie aufgefordert auf Port 1029. Es reicht also nicht aus, für Telnet immer nur Port 23 auf beiden Seiten durch zu lassen, sondern – wie in diesem Fall z.B. Port 1029 und viele andere x-beliebige Ports.

-------------

Das obige Beispiel verdeutlicht, dass Telnet über einen Proxy nur schwerlich zu realisieren ist. Die direkte Kommunikation über die Ports, Seriennummern der Pakete usw. sind ziemliche Hindernisse. Entsprechend kam man sehr schnell auf eine andere Idee:

NAT

Bei NAT geht es im Wesentlichen darum, die privaten IP-Adressen bei der Kommunikation zu verstecken. Der als NAT-Router dienende Rechner muss eine "echte" IP-Adresse besitzen, alle "Clients" dürfen private Adressen besitzen. Beim Verbindungsaufbau zwischen Rechner A im privaten Netz über den Router B mit NAT zum Rechner C im Internet wird bei jedem Paket die tatsächliche Absender-IP-Adresse(privat) durch den NAT-Router mit der offiziellen IP des Routers ausgetauscht. Rechner C geht also davon aus, dass er eigentlich mit Rechner B kommuniziert, selbiger reicht die Pakete aber – nach Wiedereinsetzen der privaten Adresse - in das private Netz zu Rechner A weiter:

AbsenderDatenEmpfänger
(AxxxxxxC)

A sendet (AxxxC) -> B, Austausch des Absenders (BxxxC) und weitersenden -> C

Antwort:

C sendet (CxxxB) -> B, Austausch des Empfängers (CxxxA) -> A

Der NAT-Router merkt sich hierbei – durch geschickte Algorithmen – alle Pakete, damit er Pakete unterschiedlicher Absender aus dem privaten Netz nicht durcheinander bringt. Der Rechenaufwand ist nicht allzu hoch, auch der Ping (betrachtet man den als Referenz für die Dauer der Paketsendungen) erhöht sich meist nicht.

Jetzt wird auch klar, was die Abkürzung bedeutet: Network Address Translation.

Ein typisches kleines Netzwerk würde dann z.B. so aussehen:

Der NAT-Router hat die 130.102.1.1 als offizielle IP-Adresse, nach innen hat er die 192.168.1.1. Alle Pakete aus dem Internet haben also nicht eine 192.168.1.x Adresse, sondern immer die 130.102.1.1 als Empfänger, der Router schickt diese dann "nach innen" weiter.

Cisco-Router (und ebenso Linux und andere leistungsfähige Router) können auch sog. dynamisches NAT. Hierbei wird nicht nur eine offizielle IP-Adresse verwendet, sondern ein ganzer Block solcher Adressen. Obwohl sich hier die Vorteile der NAT scheinbar aufheben, wird diese Variante oft als recht effektiver Schutz vor Eindringlingen verwendet, der NAT-Router dient quasi als Firewall:

Je nach Bedarf wird den internen Clients jeweils eine echte Adresse zugewiesen (im Bild oben die 130.102.1.1 und 130.102.1.2).

Dummerweise hat auch NAT so seine Tücken und stellt keineswegs ein Allheilmittel dar. Rechner C glaubt nämlich, dass er eigentlich mit Rechner B kommuniziert und sendet u.U. Pakete an andere Ports, die der NAT-Router nicht kennt, bzw. nicht zuordnen kann.

Beispiel IRC (Internet Relay Chat):

Der Empfang von Dateien geht, das Senden schlägt fehl. Warum?

Nun, normalerweise werden Dateien im IRC per DCC übertragen: /dcc send nickname file

Betrachtet man das ganze von der mehr technischen Seite, so passiert folgendes:
Der IRC-Client holt sich die Dateiinformationen wie die Größe und sendet an den anderen seine IP-Adresse und die Port-Nummer, auf der er passiv auf das Abholen der Daten wartet. Der Abholer versucht nun eine Verbindung aufzubauen – aber wohin? Richtig, zu dem NAT-Router, denn die private IP-Adresse wurde ja ausgetauscht. Der NAT-Router weiß aber nichts von einer Datei und der Port – sagen wir mal 31337 – ist zu, schließlich läuft der IRC-Client ja auch auf dem Rechner im privaten Netz und nicht auf dem Router.

Darüber hinaus sendet der IRC-Client auch noch eine falsche IP-Adresse - nämlich seine private - und auf die kann der andere Client sowieso nicht antworten (Zumindest dieses Problem lässt sich aber umgehen, bei ircle heißt die Einstellung dazu "TIA/ADSL" – hier kann man die IP-Adresse des NAT-Routers angeben – bei mIRC muß "On connect always get IP Address" und "Lookup method Server" ausgewählt werden. Wie das IRC-Problem mit Hilfe von Linux als Router elegant gelöst werden kann, dazu kommen wir später.

Dieses Szenario ist leider sehr verbreitet – immer wenn passive Verbindungen zum privaten Netz aufgebaut werden sollen, muß NAT scheitern – so zum Beispiel auch bei unserem beliebten Battlecom. Muß das so sein, oder geht es auch anders?

Port-Mapping bei NAT

Wie wir gesehen haben, ist es nicht möglich, über NAT passive Verbindungen zu einem Rechner im privaten Netz aufzubauen. Sehr schnell kam aber der Wunsch auf, z.B. einen Webserver hinter einem NAT-Router zu betreiben. Die Lösung dafür ist das sogenannte Port-Mapping.

Ein normaler Webserver wartet auf Port 80 auf ankommende Anfragen. Steht der Webserver jedoch hinter einem NAT-Router, so landen alle Anfragen auf dessen Port 80 - also im Nirwana. Die Lösung dafür ist, dem NAT-Router eine neue Regel beizubringen: "Sende allen auf Port 80 ankommenden Datenverkehr direkt weiter zu 192.168.1.2" – mal angenommen, daß auf dem Rechner mit der IP 192.168.1.2 ein Webserver läuft.

Damit erreicht man, daß alle HTTP-Requests – also Anfragen an Port 80 – auf dem Webserver landen und dieser dann nach dem gewohnten Prinzip per NAT antworten kann. Ist die Verbindung erst einmal aufgenommen, dann funktioniert auch NAT – meistens.

Im Bild sieht man, dass die 192.168.1.2 als Webserver läuft (Port 80), auf der 192.168.1.3 ein Mailserver (Port 25 Simple Mail Tranfer Protocol, Port 110 Post Office Protocol Version 3). Entsprechend könnte man auf einem weiteren (z.B. 192.168.1.4) einen Telnet-Server aufsetzen und Port 23 dorthin umleiten.

Im obigen Beispiel mit IRC könnte man jetzt ähnliches versuchen, leider meist ohne Erfolg. Warum?

Nun, wie anfangs erwähnt sind nur die Port von 0 bis 1023 fest zugeordnet, alle oberhalb dürfen von allen Programmen beliebig verwendet werden. Davon machen viele Programme dann auch exzessiven Gebrauch und legen sich leider selten fest, welche Ports sie denn verwenden. Im Fall von IRC bieten allerdings viele Clients die Möglichkeit an, diese Ports auf einige wenige zu beschränken, so dass man nur wenige Ports mappen muß(z.B. 33000-33003). Ein bei IRC ebenfalls oft auftretendes Problem ist der "ident"-port 113, der ebenfalls durchgeschaltet werden muss. Video und Audio-Streams benutzen meist 9000 (Sender) und 9001 (Empfänger)

Viele Programme sind vollständig NAT-kompatibel (z.B. Unreal). Sie ereichen das, indem sie auf passive Verbindungen verzichten und so der NAT-Router immer weiß, was er zu tun hat. Andere Programme sind ähnlich kompliziert wie IRC, manche noch schlimmer: BattleCom verwendet beispielsweise gleich mehrere große Port-Bereiche, die alle gemappt werden müssen:

Das Problem hier ist, das der BC-Server den Port aussucht und dem Client sagt: "Ich versuche jetzt mit dir auf Port 2356 Kontakt aufzunehmen." Nur hat der Client keine Chance, diesen passiven Port dem NAT-Router bekannt zu machen, er öffnet diesen nur auf dem lokalen Rechner, Port 2356 auf dem NAT-Router jedoch ist tot. Fazit: Um einen BC-Client durch einen NAT-Router nutzen zu können, müssen die Ports 2300-2400/TCP+UDP auf den Rechner gemappt werden, auf dem der BC-Client laufen soll. Das sind immerhin 100 Ports (wenn man TCP und UDP einzeln zählt, sogar 200!), die in der Konfiguration des Routers angegeben werden müssen...

Leider bieten viele Hardware-NAT-Router (z.B. Elsa-Router) keine Möglichkeit, mehr als z.B. 10 Mappings anzulegen, geschweige denn ganze Bereiche zu mappen. Hier versagt NAT - oder anders gesehen, man sollte den BC-Entwickler mal kräftig in den Hintern treten oder Router von Elsa meiden. Da Battlecom inzwischen nicht mehr erhältlich ist – die Firma wurde von einem großen Betriebssystemehersteller gekauft – bleibt wohl nur die letzte Möglichkeit...

Bei einigen NAT-Routern gibt es jedoch noch eine andere Möglichkeit: exposed hosts oder DMZ-Hosts. Hier wird eine private IP-Adresse komplett "nach außen" gestellt, d.h. aller ankommender Datenverkehr, der nicht eindeutig zu einer anderen Session gehört, wird – egal welcher Port angesprochen ist – auf einen internen Rechner umgeleitet.

Im Schaubild gibt es jetzt 2 Mappings: Einen statischen Webserver (auf Port 80) auf der 192.168.1.20 und einen exposed Host auf der 192.168.1.10. Trotz dieses statischen Mappings kann 192.168.1.30 noch normal surfen, der NAT-Daemon (also das NAT-Programm) ist normalerweise intelligent genug, um diese Pakete alle auseinander zu halten.

Nachteil bei diesem Portmapping ist natürlich, dass nur ein einzelner Rechner hinter dem NAT-Router die jeweiligen gemappten Dienste dann nutzen kann, denn dessen private IP-Adresse steht zum Umleiten ja fest im NAT-Router drin (static port mapping). Selbst wenn man also BC komplett mappen kann - zwei Rechner mit BC im privaten Netz gehen nicht.

4. Fragen und Antworten

Allgemeine Fragen

Q: Ich habe X-DSL(ADSL, T-DSL usw.) oder ISDN und will Unreal von mehreren Rechnern aus spielen. Geht das?

A: Ja, alles was du brauchst, ist ein NAT-fähiger Router. Es gibt entweder die Möglichkeit, einen der Rechner zu einem Router zu machen – Software dazu gibt es viele. Wenn du einen älteren PC übrig hast, dann kannst auf diesem z.B. auch Linux einsetzen (z.B. fli4l, Frazierwall, Debian/GNU Linux), als netten Nebeneffekt kannst du gleich eine semi-professionelle Firewall daraus machen.

Eine weitere Möglichkeit ist, fertige Hardware-Router einzusetzen (Elsa, Netgear, Netopia, Cisco usw.) – Vorteil ist sicherlich eine einfachere Konfiguration. Allerdings gehen nicht mit allen diesen Routern beliebige Port-Mappings, ein Hardwarerouter hat meist weit weniger Features als eine Software à la Linux. Außerdem kosten solche Router z.T. mehr als 250€ aufwärts. Als Anfänger kann Linux zwar recht faszinierend und eine Herausforderung sein, die Frustration ist aber auch recht groß, wenn man auch nach Wochen keinen funktionierenden Router hinbekommen hat ;)

Q: Wenn ich so einen NAT-Router einsetze, können dann auch alle BC oder IRC benutzen?

A: Jein. BC verlangt umfangreiches Portmapping, hier kann jeweils nur ein Rechner verwendet werden. Bei IRC ist das ein bisschen anders. Hier können alle Rechner ins IRC-Netz, bestimmte Dienste (z.B.dcc-send) funktionieren jedoch nicht unbedingt von allen Rechnern. Allerdings kann man mit viel Mühe für alle IRC-Clients unterschiedliche Ports definieren. Nur ident (Port 113) geht nur mit einem (was aber reicht), Audio/Videostreaming (Ports 9000,9001) ebenfalls.

Mit einer aktuellen Linux-Distribution (sprich: einem 2.2er- oder 2.4er Kernel) läßt es sich allerdings einrichten, daß alle Rechner im lokalen Netz problemlos ins IRC-Netz kommen können und auch die Dienste wie z.B. DCC-Send nutzen können, ohne ein spezielles Portmapping einrichten zu müssen.

Q: Kann ich hinter einem NAT-Router auf zwei unterschiedlichen Rechnern einen UT-Server, Webserver oder Ftp-Server betreiben?

A: Da man beim UT-Server die Ports festlegen kann (z.B. 7777 + 7778), geht das ohne Probleme. Jeder Server kommt einen anderen Port zugewiesen.

Bei HTTP und FTP ist es etwas komplizierter. Tippt man in einem Browser www.rhd-clan.de ein, dann sieht die Anfrage eigentlich so aus:

http://www.rhd-clan.de:80

Das "http://" und den Port "80" fügen die Browser heute automatisch ein. Laufen jetzt auf 2 Rechnern Webserver, so können aber nicht beide auf Port 80 liegen. Es spricht nichts dagegen, einen Webserver auf Port 45302 laufen zu lassen, jedoch muss dann der Surfer diesen Port kennen, sonst probiert er automatisch Port 80. Für FTP gilt das gleiche, und in beiden Fällen muss der Server auf andere Ports konfigurierbar sein.

Beispiel

Webserver1: 80, Webserver2: 8080

FtpServer1: 21, FtpServer2: 2121

Q: Ich habe die Möglichkeit, sowohl mit ISDN als auch mit DSL ins Internet zugehen. Was sollte ich hinsichtlich optimalem Onlinegaming wählen?

A: Solange T-Online als Hauptanbieter für DSL in Deutschland kein Fastpath erlaubt, muss man sich darüber im klaren sein, dass DSL einen gegenüber ISDN um etwa 20 bis 30 ms schlechteren Ping haben kann. Die Verhältnisse in Deutschland sind aber nicht überall gleich. In manchen Gegenden ist DSL fast so "schnell"(Ping-Antwort-Zeiten) wie ISDN, in manchen Gegenden wiederum ist DSL wesentlich schlechter. Onlinespiele, die mit der Bandbreite einer ISDN-Leitung auskommen, oder die entsprechend konfiguriert wurden (Netspeed maximal 8000), laufen per ISDN in der Regel etwas flüssiger als mit T-DSL, da es bei ISDN keine vorgeschaltete Fehlerkorrektur gibt.(siehe nächsten Abschnitt)

Andere DSL-Anbieter in Deutschland haben Fastpath standardmäßig aktiviert (z.B. Arcor) oder setzen (wie z.B. QSC) auf eine andere Technik, die ebenfalls gegenüber einem TDSL-Anschluß und sogar gegenüber ISDN deutlich bessere "Pings" ermöglicht.

Q: Was ist Fastpath bei DSL und was bringt mir das?

A: Beim Fastpath wird lediglich die vorgeschaltete Fehlerkorrektur der übertragenen Datenpakete bei einem ADSL Standardanschluss abgeschaltet. Zwar beeinflusst diese Fehlerkorrektur die Geschwindigkeit der Datenübertragung nicht, allerdings entsteht durch diese Fehlerkorrektur der im Vergleich mit ISDN höhere Ping, welcher für Online-Gamer enorm wichtig ist. Bisher konnte der Anwender diese Funktion von der Telekom abstellen und somit Fastpath aktivieren lassen, was jetzt wohl nicht mehr der Fall ist. Als Begründung nannte ein Telekom-Mitarbeiter, dass meist mehrere Personen einen Anschluss nutzen und dass diese Methode dazu dient die Performance der anderen User nicht zu beeinflussen. Wer's glaubt...

Manche Anbieter von DSL werben sogar damit, daß es keine Fehlerkorrektur gibt. Ob das nun der Weisheit letzter Schluß ist, mag ich aber auch zu bezweifeln.

Q: Welche DSL- oder ISDN-Router funktionieren mit BattleCom?

A: Nun, eine Liste kann ich nicht anbieten. Durch so manche Gespräche und Hilfen zeichnet sich aber ein bestimmtes Bild ab.

Sämtliche Elsa-Produkte(ISDN und DSL) können nicht verwendet werden, ebenso einige sehr alte ISDN-Router von ZyXEL, Ascend und Netopia (Farallon). Die von der Telekom angebotenen ISDN-Router sind meist OEM-Versionen von neueren ZyXEL-Routern und funktionieren über den Umweg exposed host, wie auch alle aktuellen ZyXEL Geräte (die ich kenne!). SMC DSL-Router bieten z.Z. die intelligenteste Methode(trigger-ports) und funktionieren problemlos (SMC Barricade Broadband Router). Bei einigen BinTec-Routern war ich erfolgreich, bei anderen nicht, hier sollte man vorher besser nochmals nachhaken.

Wenn ihr weitere Info's habt: Bitte im #rhd/Quakenet melden und durchgeben.

Q: Ich nutze einen Windows-Rechner mit DSL-Anschluß für Onlinegaming. Gibt es irgendwelche "geheimen" Einstellungen, mit denen ich die Performance im Internet steigern kann?

A: Die gibt es tatsächlich. Grundsätzlich sollte man sich zwischen zwei Arten der DSL-Anbindung entscheiden:

Grundsätzlich ist die zweite Methode vorzuziehen, denn sie entlastet den PC, da der Router alle Verwaltungsarbeit für die Kommunikation mit der DSL-Gegenstelle übernimmt. Dies wird jedoch dadurch relativiert, dass durch die indirekte Verbindung wiederrum ein etwas höherer Ping (ca. 1ms :D) entsteht, denn zwischen PC und ADSL-Modem hängt ja der Router und unter Umständen ein Netzwerk-Hub, was ja auch wieder zusätzliche Antwortzeiten verursacht.

Da jedoch ALLE PPPoE-Treiber für Windows-Rechner eine im Vergleich zu einem Hardware-Router wesentlich schlechtere Performance haben, sollte man sich im Hinblick auf Stabilität und CPU-Auslastung für eine Anbindung mittels Hardware-Router – oder ersatzweise Linux-Router – entscheiden.

Warnung: Manipulationen an der Registry stellen ein erhebliches Risiko dar und sollten nur von versierten Anwendern nach einem kompletten Backup des Rechners durchgeführt werden. Die Autoren übernehmen keinerlei Verantwortung für etwaige Schäden, die durch die Manipulation entstehen können.

Um Windows auf die wesentlich höhere Performance eines DSL-Anschlusses zu konfigurieren, hilft ein kleiner Registry-Eintrag.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpWindowSize"=dword:00007fff

Dadurch wird die Framesize der TCP-Pakete erhöht, was eine deutliche Performancesteigerung bedeuten kann.

Eine wesentlich größere Manipulation kann man über dieses Script erreichen:

Für Windows NT/2000/XP:
; MaxTweak.inf
; January 18, 2002
;
; Written by Ken Frazier - email:wecoyote@technologist.com
;
; Compiled from my NetTweak file, andvarious registry tweaks to optimize and run more secure.
; 
[Version]
Signature = "$Windows NT$"

[DefaultInstall]
DelReg=Delete_keys
AddReg=Mod_keys
[Delete_keys]
HKLM,Software\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\{D6277990-4C6A-11CF-8D87-00AA0060F5BF}
HKLM,Software\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\DelegateFolders\{59031a47-3f72-44a7-89c5-5595fe6b30ee}
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,TcpWindowSize
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,GlobalMaxTcpWindowSize
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,GlobalMaxRcvWin
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,DefaultTTL
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,Tcp1323Opts
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,SackOpts
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,MaxDupAcks
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,TcpMaxDupAcks
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,EnablePMTUDiscovery
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,EnablePMTUBHDetect
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,EnableICMPRedirect

[Mod_keys]
HKLM,System\CurrentControlSet\Control\Session Manager\Environment,DEVMGR_SHOW_NONPRESENT_DEVICES,0,"1"
HKLM,System\CurrentControlSet\Control\Session Manager\MemoryManagement,DisablePagingExecutive,0x10001,"1"
HKLM,System\CurrentControlSet\Control\Session Manager\MemoryManagement,IoPageLockLimit,0x10001,"8388608"
HKLM,System\CurrentControlSet\Control\Session Manager\MemoryManagement,LargeSystemCache,0x10001,"0"
HKLM,System\CurrentControlSet\Control\Session Manager\MemoryManagement\PrefetchParameters,EnablePrefetcher,0x10001,"3"
HKLM,System\CurrentControlSet\Control\PriorityControl,IRQ8Priority,0x10001,"1"
HKLM,System\CurrentControlSet\Services\LanmanServer\Parameters,Hidden,0x10001,"0"
HKLM,System\CurrentControlSet\Services\LanmanServer\Parameters,AutoShareWks,0x10001,"0"
HKLM,System\CurrentControlSet\Services\LanmanServer\Parameters,AutoShareServer,0x10001,"0"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,TcpWindowSize,0x10001,"23360"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,DefaultTTL,0x10001,"128"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,Tcp1323Opts,0x10001,"0"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,SackOpts,0x10001,"1"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,MaxDupAcks,0x10001,"2"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,TcpMaxDupAcks,0x10001,"2"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,EnablePMTUDiscovery,0x10001,"0"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,EnablePMTUBHDetect,0x10001,"0"
HKLM,System\CurrentControlSet\Services\Tcpip\Parameters,EnableICMPRedirect,0x10001,"0"
;HKLM,Software\Microsoft\Windows\CurrentVersion\Explorer\MyComputer\NameSpace\DelegateFolders\{59031a47-3f72-44a7-89c5-5595fe6b30ee},,
HKLM,Software\Microsoft\Windows\CurrentVersion\Explorer,AlwaysUnloadDLL,0x10001,"1"
HKCU,ControlPanel\Desktop,MenuShowDelay,0,"150"
HKCU,ControlPanel\Desktop,AutoEndTasks,0,"1"
;
; The following is the only way to disableSuperCookies. For this to protect you,
; you must keep the Media Player UniqueIdentifier enabled.
HKCU,Software\Microsoft\MediaPlayer\Preferences,SendUserGUID,0x1001,"1"
HKCU,Software\Microsoft\WindowsMedia\WMSDK\General,UniqueID,0,"{00000000-0000-0000-0000-000000000000}"
HKCU,Software\Microsoft\MediaPlayer\Player\Settings,ClientID,0,"{00000000-0000-0000-0000-000000000000}"
HKU,.Default\Software\Microsoft\WindowsMedia\WMSDK\General,UniqueID,0,"{00000000-0000-0000-0000-000000000000}"
HKU,.Default\Software\Microsoft\MediaPlayer\Player\Settings,ClientID,0,"{00000000-0000-0000-0000-000000000000}"

Warnung: Manipulationen an der Registry stellen ein erhebliches Risiko dar und sollten nur von versierten Anwendern nach einem kompletten Backup des Rechners durchgeführt werden. Die Autoren übernehmen keinerlei Verantwortung für etwaige Schäden, die durch die Manipulation entstehen können.

Für Windows 95/98/ME:
;
; NetDefault.inf
;
; September 8, 2001
;
; NetDefault_9x.inf is for Windows 95/98/ME- Not for Windows NT/2000/XP
;
; by Ken Frazier - email:wecoyote@technologist.com
;
; Save this file as NetDefault_9x.inf. Right click on the file, and choose Install.
; Reboot your system, and you will be back to defaults
;
; NOTE: Use at your own Risk
;

[Version]
signature=$CHICAGO$
[DefaultInstall]
DelReg=Delete_Old_Tweaks
AddReg=Reset_Registry
[Delete_Old_Tweaks]
HKLM,System\CurrentControlSet\Services\VxD\MSTCP,DefaultRcvWindow
HKLM,System\CurrentControlSet\Services\VxD\MSTCP,DefaultTTL
HKLM,System\CurrentControlSet\Services\VxD\MSTCP,PMTUDiscovery
HKLM,System\CurrentControlSet\Services\VxD\MSTCP,PMTUBlackHoleDetect
HKLM,System\CurrentControlSet\Services\VxD\MSTCP,Tcp1323Opts
HKLM,System\CurrentControlSet\Services\VxD\MSTCP,SackOpts
HKLM,System\CurrentControlSet\Services\VxD\MSTCP\Parameters,MaxDupAcks
HKLM,System\CurrentControlSet\Services\VxD\MSTCP\Parameters,GlobalMaxTcpWindoSize
HKLM,System\CurrentControlSet\Services\VxD\MSTCP\Parameters,GlobalMaxTcpWindowSize
HKLM,System\CurrentControlSet\Services\VxD\MSTCP\Parameters,GlobalMaxRcvWin
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0000,MaxMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0000,MTUSize
HKLM,System\CurrentControlSet\Services\Class\Net\0000,IPMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0000,PerformRouterDiscovery
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0001,MaxMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0001,MTUSize
HKLM,System\CurrentControlSet\Services\Class\Net\0001,IPMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0001,PerformRouterDiscovery
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0002,MaxMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0002,MTUSize
HKLM,System\CurrentControlSet\Services\Class\Net\0002,IPMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0002,PerformRouterDiscovery
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0003,MaxMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0003,MTUSize
HKLM,System\CurrentControlSet\Services\Class\Net\0003,IPMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0003,PerformRouterDiscovery
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0004,MaxMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0004,MTUSize
HKLM,System\CurrentControlSet\Services\Class\Net\0004,IPMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0004,PerformRouterDiscovery
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0005,MaxMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0005,MTUSize
HKLM,System\CurrentControlSet\Services\Class\Net\0005,IPMTU
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0005,PerformRouterDiscovery
HKLM,System\CurrentControlSet\Services\ICSharing\Settings\General,InternetMTU

[Reset_Registry]
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0000,PerformRouterDiscovery,0x10001,"1"
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0001,PerformRouterDiscovery,0x10001,"1"
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0002,PerformRouterDiscovery,0x10001,"1"
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0003,PerformRouterDiscovery,0x10001,"1"
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0004,PerformRouterDiscovery,0x10001,"1"
HKLM,System\CurrentControlSet\Services\Class\NetTrans\0005,PerformRouterDiscovery,0x10001,"1"

Hierbei werden wesentlich mehr Veränderungen vorgenommen als bei dem kleinen manuellen Eingriff weiter oben.

Warnung: Manipulationen an der Registry stellen ein erhebliches Risiko dar und sollten nur von versierten Anwendern nach einem kompletten Backup des Rechners durchgeführt werden. Die Autoren übernehmen keinerlei Verantwortung für etwaige Schäden, die durch die Manipulation entstehen können.

Q: Ich benutze eine Software-Firewall (ATGuard, Norton Personal Firewall etc...). Kann die irgendwelche Probleme mit Onlinespielen verursachen?

A: Ja, und zwar in zweierlei Hinsicht:

Zuerst muss die Firewall dahingehend konfiguriert sein, die Datenpakete von und zum Computer nicht zu blockieren. Die meisten Software-Firewalls sind vorkonfiguriert, um das Onlinespielen mit bekannten Spielen (UT, Quake, HL...) zu ermöglichen. Bei einigen Lösungen sind jedoch zuerst sogenannte "Firewall-Regeln" zu erstellen. Einzelheiten sind hierzu in den Hilfedateien der entsprechenden Software-Firewall zu finden.

Zweitens – und wesentlich wichtiger – ist die Tatsache, dass eine Software-Firewall eine erhebliche Performancebremse für Onlinespiele bedeutet, auch wenn sie bereits für das Onlinegame konfiguriert wurde. Jedes Datenpaket, das während einer Onlinegame-Session vom und zum Computer gesendet wird, muss untersucht und mit den internen Firewall-Regeln abgeglichen werden. Erst dann wird entschieden, ob das Datenpaket blockiert wird oder nicht. Da bei einem Onlinespiel eine ganze Wagenladung voller Datenpakete gesendet und empfangen wird, kommen die wenigstens Software-Firewalls mit dieser Datenflut zurecht. Die Konsequenz: Der Ping zum Online-Server steigt, und unter Umständen treten Paketverluste auf.

Aber: Eine Firewall macht auf Windows-Rechnern durchaus Sinn, die Anzahl der Trojaner und diverser anderer Unannähmlichkeiten steigt täglich. Wer seine Firewall abschaltet, sollte wissen, was er da tut! Als Grundregel sollte man alle unnötigen Bindungen auf der Internet-Seite des Netzwerkes abschalten. Anleitungen dazu finden sich in vielen Heften regelmäßig wieder, eine Liste von Antivirenprogrammen gibt es z.B. bei der c't.

Q: Hm.. ich weiß nun, eine Software-Firewall kann meine Online-Game Performance beeinträchtigen. Aber was soll ich tun? Ich will ja nicht ungeschützt sein.

A: Linux ;)

Q: Wieso habe ich auf einige Server so bescheidene Pings, obwohl die in Deutschland stehen? Andere haben doch auch keine Probleme...

A: Das kann mehrere Ursachen haben. Wie oben schon geschildert, ist das Internet in viele kleine Unternetze unterteilt. Jeder Provider hat i.d.R. sein eigenes "kleines" Netz und hat nur bestimmte "Verbindungspunkte" in die Netze anderer Provider. Die auch Peering-Points (Austauschpunkte) genannten Übergänge sind aber je nach Anbieter unterschiedlich. Mit etwas Pech nehmen so die Pakete erhebliche Umwege und werden beispielsweise über New York zum (in Wirklichkeit) 200km entfernten Server geschickt.

Softwarespezifische Fragen

Q: Ich benutzeKEN! von AVM. Wieso sehe ich keine Server beim UT?

A: KEN! ist kein NAT-Router, sondern ein Proxy! Hier geht mit UT/IRC/BC gar nichts.

Q: Kann ich trotzdem damit spielen?

A: Ja, allerdings darfst du nicht einfach den KEN!-Server als Router/Gateway benutzen. KEN!bietet – wie auch die professionelle Network Distributed Capi NDC – eine Netz-Capi an. Auf diesem Weg gaukelt man dem lokalen Rechner vor, er habe eine ISDN-Karte und kann sich selbst über das DFÜ-Netzwerk einwählen. Nachteil dabei ist natürlich, dass ich 1. einen Kanal der Karte für alle anderen blockiere und 2. ich eine eigene Internetverbindung aufmachen muss. Direkt den KEN!-Server als Router verwenden geht leider nicht.

So, weiter bin ich noch nicht, schreibt mal Kommentare - ähh... produktive wenn's geht...:D