Virtual OS/2 International Consumer Education
VOICE Homepage: http://de.os2voice.org
März 2002

[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]

editor@os2voice.org


TCP/IP-Portnummern verstehen

Von Peter Moylan © März 2002, Übersetzung: Thomas Klein

Ursprünglich schrieb ich diesen Artikel im Zusammenhang mit einem bestimmten Problem: Ist es möglich, einen FTP-Server an's Laufen zu bekommen, wenn sich dieser hinter einer Firewall befindet? Aus diesem Grund werden Sie hier zahlreiche Verweise auf FTP vorfinden. Dennoch sollte dies auch für diejenigen unter den Lesern interessant sein, die sich nicht unbedingt für FTP interessieren, aber dafür, wie Netzwerke funktionieren.

Ein paar Hinweise zum Fachchinesisch

Wenn Sie auf irgendeine Art vernetzt sind, arbeiten Sie höchstwahrscheinlich mit TCP/IP. Es ist aber nicht das einzig mögliche Netzwerkprotokoll. Um z.B. gemeinsamen Zugriff auf Dateien im Netzwerk zu ermöglichen, werden für gewöhnlich andere Protokolle wie NetBIOS eingesetzt. Im Allgemeinen aber dürfte wohl TCP/IP das am weitesten verbreitete Netzwerkprotokoll sein. Für die bekannten Anwendungen auf dem Gebiet der Client-Server-Verarbeitung wie FTP, HTTP, SMTP und so weiter ist TCP/IP die Voraussetzung.

Das Internet Protocol (IP) stellt die Grundfunktion zur Übertragung eines Datenpakets von einem Knoten zu einem anderen zur Verfügung. Jedes IP-Paket enthält Kopfdaten ("header"), die unter anderem Sender- und Empfängeradresse des Datenpakets enthalten. Diese Adressen sind bekannt unter der allgemeinen Bezeichnung IP-Adresse.

Innerhalb des mehrstufigen OSI-Referenzmodells für Netzwerkprotkolle ist das Terminal Control Protocol (TCP) eine übergeordnete Schicht zum IP. Es wird für weitergehende Funktionen verwendet, benötigt aber natürlich immer noch IP um die eigentliche Übertragung der Befehls- und Datenpakete zu gewährleisten. Mehr Informationen zu TCP und TCP/IP-Anwendungen erhalten Sie, wenn Sie auf der OS/2 Befehlszeile TCPhelp eingeben.

IP-Adressen

Jeder Knoten eines Netzwerks wird durch eine IP-Adresse identifiziert, die eine 32-Bit-Zahl darstellt. (Die IP-Version 6 arbeitet bereits mit 128-Bit-Zahlen, aber Version 6 wird vom OS/2-TCP/IP noch nicht unterstützt.) Im einfachsten Fall verfügt ein Computer über genau eine IP-Adresse, jedoch ist es möglich - und mittlerweile zunehmend gebräuchlicher - daß ein Rechner mehr als eine Netzwerkkarte besitzt und somit auch mehr als eine IP-Adresse.

Die IP-Adressen im Format

sind insofern Sonderfälle, als daß sie privat (nicht öffentlich) und auf das lokale Netzwerk beschränkt sind, in dem sie eingesetzt werden. In den meisten lokalen Netzwerken wird wohl die Class-C-Adresse am geeignetsten sein, jedoch sind die Adreßbereiche von Class A und Class B für sehr große LANs vorzuziehen. Der Vorteil dieser Adressen liegt darin, daß sie im LAN frei vergeben werden können und nicht der offiziellen Beantragung einer fest zugewiesenen Adresse unterliegen. Der Nachteil dieser Adressen ist, daß sie außerhalb des LANs faktisch "unsichtbar" sind; d.h. diese Netzwerkknoten (Rechner) können nicht mit dem Internet kommunizieren. Die Umgehungslösung hierfür ist, eine Firewall einzusetzen, die Network Address Translation (NAT; Netzwerk-Adreßübersetzung) verwendet. Zu NAT kommen wir später.

Irgendwann im Laufe des Betriebs hat ein Netzwerkknoten mehrere Verbindungen zu unterschiedlichen anderen Rechnern im Netzwerk aufgebaut. Wir brauchen jetzt also einen Weg, diese Verbindungen zu kennzeichnen, um sie auseinanderhalten zu können. Hierfür verwenden wir (an unserem Ende) Portnummern. Diese Portnummern haben aber nichts mit den Hardware-I/O-Ports zu tun. Es handelt sich lediglich um eine Nummerierungsmethode für die Verbindungen. Portnummern werden durch vorzeichenlose 16-Bit-Zahlen dargestellt. Je ein Ende einer Verbindung wird eindeutig identifiziert durch die Paarung von IP-Adresse + Portnummer.

Softwaretechnisch wird dieser Mechanismus durch sockets realisiert. Einen socket können Sie sich vorstellen als Datenstruktur, die stets beide IP-Adressen und beide Portnummern aufzeichnet, zusammen mit allen anderen für die Verbindung vielleicht benötigten Angaben (Datenpuffer, Bytezähler, etc.).

Beim erstmaligem Erzeugen eines sockets kennen wir nur die IP-Adresse und den Port an "unserem" Ende der Verbindung. Kommt nun eine Verbindung zustande, wird uns IP-Adresse und Portnummer der Gegenstelle mitgeteilt. Natürlich muß dabei eine der beiden Stellen der "Auslöser" der Verbindung sein. Der übliche Mechanismus hierfür ist, daß ein Server sich im Bereitschaftszustand befindet und auf Verbindungsanforderungen von Clients wartet, wobei das "clientseitige Ende" den eigentlichen Verbindungsaufbau übernimmt.

Die Portnummern im Bereich 0 bis 49151 sind für "server"-Ports reserviert. Genauer gesagt ist der Bereich von 0 bis 1023 sogar durch offizielle Standards definiert. Die Ports 1024 bis 49151 sind zwar nicht ganz so offiziell, jedoch zumindest "registrierte Ports", die von vorgegebenen Anwendungen verwendet werden. Eine Liste dieser reservierten Ports können Sie sich in der Datei \MPTN\ETC\SERVICES auf dem Systemlaufwerk anschauen.

Portnummern von 49152 bis 65535 bilden den Bereich der sogenannten "freien" Ports, die immer dann verwendet werden, wenn ein neuer Port benötigt wird. Ein solcher Port wird typischerweise für eine kurzzeitige Verbindung angefordert und nach Beendigung des Vorgangs wieder freigegeben.

In einem Client/Server-Protokoll muss der Client eine Möglichkeit haben, den Server zu finden. Aus diesem Grund warten Server grundsätzlich auf bekannten Ports ("well known ports"), die für diese Zwecke reserviert werden, auf Anforderungen durch die Clients. Das FTP-Protokoll verwendet beispielsweise zwei Kanäle - einen für Befehle und einen für Daten. Als Konsequenz daraus gibt es zwei "well known ports": Port 21 für die Befehle und Port 20 für die Daten. Das ist aber natürlich nur auf der Server-Seite so. Der Client kann für die Verbindung einen beliebigen Port verwenden und normalerweise wird hierfür dann ein Port aus der Menge der "freien Ports" angefordert.

Das FTP-Protokoll kennt zwei Arten der Datenübertragung. Im sogenannten "passiven" Modus wird der Datentransfer clientseitig initiiert. Im nicht-passiven FTP, auch bekannt als "port FTP", geschieht das durch den Server. In beiden Fällen wird für die Befehlsübertragung serverseitig Port 21 verwendet. Der Unterschied zwischen den beiden Modi liegt in der Art, wie der Datenport angefordert wird.

Passives FTP

Passives FTP wird dadurch gestartet, daß der Client den Befehl PASV sendet. (Die Auswirkungen sind aber auf einen Dateitransfer beschränkt; soll eine weitere Übertragung stattfinden, muß der Client erneut einen PASV Befehl senden.) Der Server antwortet auf diesen Befehl mit einer Zeile ähnlich...:
      227 Entering passive mode (127,0,0,1,203,197)

Die ersten vier Ziffern geben die IP-Adresse des Servers an. Die beiden übrigen Ziffern geben eine Portnummer an. Eigentlich sagt der Befehl PASV nichts anderes als "Bitte such Dir einen Datenport aus und sag' mir, welcher es ist". Der Server wählt den Port (normalerweise aus seinem Vorrat an freien Ports) und sendet dessen Nummer zurück an den Client. Dann wartet der Server auf dem angegebenen Port auf den Verbindungsaufbau durch den Client. Natürlich muß auch der Client auf seiner Seite einen Port auswählen - der Server erkennt diesen Port nachdem die Verbindung vom Client aufgebaut wurde.

Im passiven FTP verhalten sich der Port des Befehlskanals und des Datenkanals gleich: der Server wartet auf einem bekannten Port. Der Client kennt diesen Port und kann daher eine Verbindung dorthin aufbauen.

Port- (nicht-passives) FTP

Die ersten Entwürfe zum FTP-Standard sahen gar kein passives FTP vor. Der "normale" Weg, Daten zu übertragen (und selbst heute noch der übliche) war, den Datenkanal vom Server aus aufzubauen. (Ausnahme: Die meisten Webbrowser, im Gegensatz zu reinen FTP-Clients, scheinen ausschließlich passives FTP zu verwenden. Die reinen FTP-Clientprogramme überlassen dem Anwender die Auswahl.) Damit nicht-passives FTP funktioniert, muß der Server den Port kennen, auf dem der Client auf eine Verbindung wartet.

Das wird durch den PORT Befehl erreicht, den der Client sendet. Beispiel:

       PORT 127,0,0,1,203,201

Der Client sendet hierdurch seine IP-Adresse und den Port, den er für die Datenübertragung gerne verwenden möchte. Das bedeutet also, daß der Client eine Portnummer auswählt und auf diesem Port auf eine Verbindung wartet, die durch den Server aufgebaut wird. Sowohl in diesem Beispiel als auch für den obigen PASV Befehl war die IP-Adresse 127.0.0.1. Das kommt daher, daß ich in beiden Fällen das loopback device meines Rechners zur Erzeugung der Beispiele verwendet habe. Falls Sie das selbst ausprobieren, werden die IP-Adressen natürlich ganz anders aussehen, in Abhängigkeit davon, was bei Ihnen eingestellt ist.

Natürlich muß der Server nun auch noch eine Portnummer auf seiner Seite auswählen. Standardmäßig wird das fast immer Port 20 sein.

Beachten Sie, daß der Client grundsätzlich entweder den Befehl PASV oder PORT senden muß, bevor ein upload oder download gestartet wird. Die Auswahl des verwendeten Befehls bestimmt, ob passive oder nicht-passive Übertragung eingesetzt wird.

Die Auswirkungen einer Firewall

Eine Firewall kann die NAT-Option beinhalten oder auch nicht. Für den folgenden Abschnitt spielt das erst einmal keine Rolle, dazu kommen wir gleich noch.

Sinn und Zweck einer Firewall ist es, bestimmte Datenpakete passieren zu lassen und andere eben nicht. Dies wird durch Regeln erreicht, die der Systemadministrator festlegt. Hierfür muß dieser entscheiden, welche Arten des Datenverkehrs zulässig sind.

Ich habe nicht gerade viel Erfahrung mit Firewalls und kann Ihnen daher keine erschöpfende Auskunft darüber geben, was da so abläuft. Ich glaube aber, daß diese Regeln (auch) auf Portnummern basieren. Datentransfer von/zu bestimmten Ports wird unterbunden. Normalerweise sollten diese Regeln insofern asymmetrisch sein, als daß die Regeln bezüglich abgehenden Paketen sich ziemlich von denen unterscheiden, die die eingehenden Pakete betreffen.

Betrachten wir einmal den Fall, wo sich ein FTP-Client hinter einer Firewall befindet und mit einem Server kommunizieren will, der sich nicht hinter einer Firewall befindet. Typische Firewallregeln würden nicht-passives FTP verbieten, denn dafür wäre es notwendig, daß der Server - also der Rechner "außerhalb" der Firewall - die Verbindung einleitet. Firewalls sind häufig so konfiguriert, daß es außenstehenden Rechnern nicht gestattet ist, eine Verbindung in die geschützte Zone aufzubauen. Tatsächlich ist dieses Problem einer der Hauptgründe dafür, daß passives FTP in den FTP-Standard aufgenommen wurde. Wenn sich der Client hinter einer Firewall befindet, sollte er eigentlich ausschließlich den passiven Modus verwenden.

Im umgekehrten Fall, wo sich der Server hinter einer Firewall befindet und der Client nicht, ist es sehr wahrscheinlich, daß passives FTP nicht funktioniert und Port-FTP der einzig gangbare Weg ist.

Wenn sich aber nun der Client hinter einer Firewall befindet und der Server hinter einer anderen, steht uns Ärger ins Haus. Das Konzept der Firewall wurde nicht vor dem Hintergrund einer solchen Konstellation entworfen. Server dürften eigentlich nicht hinter einer Firewall stehen, es sei denn natürlich, daß sie für das private LAN gedacht sind. Wenn Sie also zum Schutz ihres LANs eine Firewall einsetzen, sollten Sie die öffentlichen Serveranwendungen auf dem Rechner laufen lassen, der auch die Firewallsoftware betreibt. Dadurch befindet sich der Server technisch gesehen außerhalb der Firewall.

Wenn Sie Ihren Server aus irgendeinem Grund unbedingt hinter einer Firewall betreiben müssen, sollten Sie über etwas Fachwissen in Bezug auf die Definition der Firewallregeln verfügen. Lesen Sie die vorherigen Abschnitte sorgfältig um sicherzustellen, daß Ihre Regeln die richtigen Portnummern beinhalten. Dieser Teil ist noch relativ einfach. Schwieriger ist es, das ganze so zu machen, daß der FTP Server funktioniert, ohne die Sicherheit Ihres LANs dafür zu opfern. Wenn Sie die Regeln zu lasch setzen, können Sie sich die Firewall auch direkt sparen.

Firewalls mit NAT

Der beste Firewalltyp ist der, der NAT (Network Address Translation, "Netzwerk Adreßübersetzung") unterstützt. Der NAT-Mechanismus erlaubt es den Rechnern in Ihrem LAN, eigene IP-Adressen zu haben, außerhalb des LANs aber unter einer anderen IP-Adresse zu arbeiten. Im günstigsten Fall können alle Rechner Ihres LANs die selbe "externe" IP-Adresse verwenden.

Ein IP-Datenpaket besitzt einen Header, der unter anderem die IP-Adressen von Sender und Empfänger beinhaltet - also wo das Paket herkommt und wo es hingeht. Mit aktiviertem NAT wird die Firewall dazu veranlasst, die Sender-IP-Adresse im Header des Datenpakets zu ändern, wodurch der Eindruck entsteht, es stamme von einer anderen Adresse. Soviel zum Ausgangsdatenstrom; beim eingehenden Verkehr fängt die Firewall die Pakete ab, die jetzt für die "vorgetäuschte" IP-Adresse bestimmt sind und sendet sie stattdessen an den eigentlichen Empfänger indem die Zieladresse im Header entsprechend geändert wird.

Betrachten wir nun wieder den Fall, wo sich der FTP-Client hinter der Firewall befindet und der Server außerhalb. Wenn der Client die Verbindung zum Server aufbaut, sieht dieser dann nicht die echte IP-Adresse des Clients, sondern die der Firewall. Der Server hat natürlich keine Ahnung, daß die Firewall überhaupt existiert. Er arbeitet ganz simpel mit der erhaltenen Adresse, so, wie er es auch mit jedem anderen Client macht. Aus Sicht des Servers ist der Client einfach die Firewall. Diese allerdings gibt die vom Server kommenden Pakete einfach weiter an den echten Client.

Im Umkehrschluß denken alle Clients außerhalb einer Firewall, daß es sich bei dieser um den FTP-Server handelt, der in Wirklichkeit hinter der Firewall steht. Die Firewall verändert die IP-Adressen der Clients und gibt die geänderten Pakete an den Server weiter.

Das klappt eigentlich alles sehr gut, bis auf zwei kleine Details: Wie wir aus vorangegangenen Beispielen wissen, senden die Befehle PASV und PORT in ihren Daten auch IP-Aressen. Da die Firewall (bzw. die NAT-Software) aber nur die IP-Adressen in den Headern der Pakete ändert, werden also dummerweise immer noch die echten IP-Adressen übermittelt, was dazu führen kann, daß die Pakete an die falsche Adresse gesendet werden oder schlicht verlorengehen.

Als logische Konsequenz wäre die Lösung für dieses Dilemma, die NAT-Software so einzustellen, daß sie die Befehle PASV und PORT ebenfalls abfängt um die damit übermittelten IP-Adressen entsprechend abzuändern. Einige Firewallsysteme sind pfiffig genug, um dies zu erkennen. Leider verfügen aber viele andere Systeme nicht über diese Option.

In der Vergangenheit dachte aber normalerweise niemand daran, einen FTP-Server hinter eine Firewall zu setzen. Jetzt, wo Kabelmodems, ADSL und diverse andere Hochgeschwindigkeitsverbindungen immer selbstverständlicher werden, hat sich das geändert. Um mit diesem Problem umgehen zu können, müßte der FTP-Server in der Lage sein, in seiner Antwort auf den PASV-Befehl die IP-Adresse der Firewall anstelle seiner eigenen anzugeben.

Genauso sollte ein FTP-Client, der sich hinter einer Firewall befindet, die Parameter seines PORT-Befehls entsprechend auf die Firewall anpassen. (Im Fall des PORT-Befehls muß das Problem auf der Seite des Client gelöst werden.) In Wirklichkeit habe ich aber noch nie von einem FTP-Client gehört, der sich so verhält. Das bedeutet also, daß ein FTP-Client hinter einer Firewall grundsätzlich passives FTP verwenden muß.

Quellenverzeichnis:

Peter Moylans Website - http://eepjm.newcastle.edu.au


[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org