Sie sind hier

Behandlung eingehender Datenpakete durch einen Zugangsrouter

Erläutert am Beispiel des DrayTek Vigor 2200

Ich habe alle Tests zwar anhand des Vigor-Routers beschrieben, jedoch bieten viele andere Routermodelle auf dem Markt sehr ähnliche Leistungsmerkmale, so dass die hier gemachten Aussagen meist übertragbar sind. Jedoch verwenden die Hersteller oft verschiedene Begriffe für das gleiche Leistungsmerkmal. Auch die unten angegebenen Experimente kann man wohl meist analog übertragen.

Routing-Regeln

Es kommen Pakete aus dem Internet beim Router an. Der Router prüft dann anhand eines Satzes von Regeln, ob er die Pakete überhaupt weiterleiten soll und wenn ja wohin.

Es gibt 5 Klassen von Routing-Regeln. Der Router prüft nacheinander alle Klassen, inwieweit dort eine Regel passt. Eine Regel passt, wenn sie aussagt, dass das Paket zu verwerfen ist, oder wenn sie aussagt, wohin das Paket zu schicken ist. Wenn eine Regel passt, ist der Überprüfungsprozess abgeschlossen: Der Router verwirft oder verschickt das Paket sofort im lolalen Netz (LAN).

Es gibt folgende Routing-Regel-Klassen, die der Router nach Herstellerangabe in der hier aufgeführten Reihenfolge nacheinander untersucht:

  1. Paketfilter (Data Filter IN)
  2. NAT Active Sessions Table
  3. Port Redirection
  4. Open Ports
  5. DMZ

1. Paketfilter (Data Filter IN)

Dass das Paketfilter zuerst angelaufen werden sollte, erscheint selbstverständlich. Man kann sich dies aber durch zwei sehr einfache Experimente selber klar machen.

Experiment 1:

Man rufe das Vigor-Web-Interface auf und wähle:

  IP Filter/Firewall Setup -> Filter Set -> Filter Rule

Dort bitte angeben:

  Direction              : IN
  Protocol               : TCP/UDP
  Destination Start Port : 32000
  Destination End Port   : 40000

Anschließend ist die Filterregel aktivieren, indem man den Haken an die Regel setzt und auch OK drückt. Booten ist unnötig. Nachdem dies vollbracht ist, lassen sich jetzt keinerlei Web-Seiten mehr aufrufen lassen. Der Grund hierfür liegt darin, dass man das gesamte NAT-Verfahren (Network Address Translation) lahm gelegt hat, da die Pseudo-Ports, die der Router dafür verwendet, durch die Filterregel blockiert sind. Wenn der Router die NAT-Regeln vorher untersuchen würde, entginge ihm dass die Ports gesperrt sind, da er ja die Pakete schon weitergeleitet hätte, bevor er die Filterregeln untersuchte. Nun sollte man das Filter natürlich wieder entfernen, dann geht wieder alles.

Experiment 2:

Zunächst sollte man einen Computer im privaten Netz (LAN) als sog. DMZ (Demilitarized Zone) anmelden. Dazu rufe man auf:

 NAT Setup -> DMZ

Dort ist num die private IP-Adresse (LAN-Adresse) des DMZ-Klienten anzugeben. Der DMZ-Klient muss eingeschaltet sein. Anschließend benötigt man einen Portscanner im Internet. Man kann hierzu z.B. die Gibson Research Web-Seite (http://grc.com) aufrufen und auf die Seite der Anwendung ShieldsUp! gehen.

Der Port-Test ergibt nun z.B. bei einem DMZ-Klienten, der z.B. unter Windows 98 ohne Firewallsoftware läuft überall geschlossene oder offene Ports. Achtung: Die Scan-Ergebnisse sind nur vom Verhalten des DMZ-Klienten (d.h. des PCs) abhängig. Wenn der Klient-PC auf die Scans nicht antwortet, werden diese Ports als im Zustand "stealth" gewertet. Dieses Verhalten ist abhängig vom Betriebssystem und von der geladenen Software. Nun sollte man beim Vigor-Router aufrufen:

  IP Filter/Firewall Setup -> Filter Set -> Filter Rule

Dort bitte angeben:

  Direction              : IN
  Protocol               : TCP/UDP
  Destination Start Port : 21
  Destination End Port   : 1024

Diese Regel blockiert alle eingehenden Pakete, die Portnummern zwischen 21 und 1024 haben. Nachdem man nun nochmal den Port-Test im Internet aufgerufen hat, wird man bei dem obigen Routermodell bei der Standard-Konfiguration feststellen können, dass jetzt alles als "stealth" klassifiziert ist - außer dem IDENT-Port 113, der als geschlossen bewertet wird. Hieraus folgt, dass die DMZ-Regel nach dem Paketfilter untersucht wird. Zum Betrachten der DMZ-Regel kommt es aber nicht, da der Router die Pakete des Portscanners vorher verwirft.

2. NAT Active Sessions Table

Hier wird geprüft, ob die Quellenadresse ("Peer-IP") und der Ziel-"Pseudo-Port" in einer Tabelle ("NAT Active Sessions Table") gefunden werden kann. Alle Einträge in dieser Tabelle entsprechen Verbindungen, die aus dem privaten Netz heraus aufgebaut wurden. Wenn der Router einen passenden Eintrag findet, wird das Paket zum Klienten geschickt, der im Tabelleneintrag vermerkt ist. Die Tabelle sieht aus wie folgt:

------------------------------------------------------------------
 Private IP :Port #Pseudo Port         Peer IP :Port  Ifno  Status
------------------------------------------------------------------
192.168.1.5  3026        34333     64.12.25.24  5190     3  1
192.168.1.5  2209        33381  205.188.248.89    80     3  1
192.168.1.2  2197        34595  195.37.192.164   443     3  3
192.168.1.5  2214        33378  205.188.248.89    80     3  1
192.168.1.5  4484        34001  63.251.143.213 27010     3  0
192.168.1.2  1216        33174  205.188.248.89    80     3  1

Durch folgendes Experiment kann man sich klar machen, dass der Router die NAT-Tabelle tatsächlich vor den Port-Mapping-Regeln untersucht:

Experiment 3:

  1. Eine Verbindung dach draußen aufbauen, bei der beständig Daten ausgetauscht werden, z.B. ICQ.
  2. Den Port dieser Verbindung in
    Diagnostic Tools -> NAT Active Sessions Table
    suchen, das könnte z.B. 34333 sein. Den ICQ-Eintrag kann man an dem Port 5190 erkennen.
  3. Jetzt unter
    NAT Setup -> Port Redirection
    den gefundenen Port (hier 34333) auf einen anderen Klienten im Netz umleiten, nur nicht auf den Klienten, auf dem man gerade mit ICQ Botschaften austauscht. Die Port-Umlenkung mit OK bestätigen. Es ist wichtig, dass das Protokoll (TCP oder UDP) mit angegeben wird, sonst speichert der Vigor die Port-Umlengungsregel nicht. Den Router neu zu booten ist wieder unnötig.

Man sollte feststellen können, dass die Port-Umlenkung ICQ nicht stört, da der Router die "NAT Active Sessions Table" vorher auswertet und er alle Pakete aus dem Internet mit dem Port 34333 bereits zum ICQ-Klienten-PC geroutet hat, bevor er zur "Port Redirection"-Regel kommen kann.

Experiment 4:

Durch dieses Experiment kann man prüfen, ob der Router bei der NAT-Tabelle nicht nur den Pseudo-Port der eintreffenden Pakete sondern auch deren Peer-IP-Adresse auswertet.

Wie im vorigen Experiment bestehe z.B. wieder eine ICQ-Verbindung. Der NAT-Pseudo-Port dieser Verbindung sei wieder 34333. Einen anderen lokalen Klienten meldet man in der DMZ des Routers an. Dort startet man lokal einen beliebigen Serverdienst (z.B. den Apache-Webserver), dessen Portnummer sich einstellen lässt (bei Apache in httpd.conf durch die Listen-Option). Man konfiguriert den Dienst nun so, dass er ebenfalls auf Port 34333 Pakete erwartet (bei Apache: Listen 34333). Obacht! Das muss der gleiche Port sein wie im NAT-Eintrag der ICQ-Verbindung.

Nun braucht man eine dritte Person im Internet, die auf diesen lokalen Server zuzugreifen versucht. Im Falle des Apache-Servers ist also eine Webseite mit der aktuellen IP-Adresse des Routers unter dem Port 34333 im Internet aufzurufen (z.B. "http://100.101.102.103:34333"). Wenn dies klappt, d.h. sowohl die ICQ-Kommunikation als auch der Apache-Server funktionieren, bedeutet es, dass der Router die Quelladresse einkommender Pakete auswertet, d.h. die Pakete mit der NAT-Peer-IP zum PC mit der ICQ-Verbindung schickt und alle anderen Pakete zum DMZ-Computer, auf dem der Server läuft.

Hinweis

Ohne "Port-Mapping" werden nur eingehende Pakete geroutet, die zu einer Pseudo-Verbindung gehören, die einem NAT-Tabelleneintrag entspricht. Die Vorsilbe "Pseudo" soll andeuten, dass dies auch für das verbindungslose Protokoll UDP gilt. Bei allen anderen Paketen weiß der Router ja ohne Port-Mapping nicht, wohin er sie schicken soll und verwirft sie daher.

Das ist eine Standardfunktionalität von NAT-Routern ("IP masquerading"). Viele Leute bezeichnen dies bereits als "Firewall", womit gemeint ist, dass nicht beliebige Pakete aus dem Internet in das lokale Netz geroutet werden. Andere Personen bezeichnen das vorgeschaltete Paketfilter als "Firewall". Andere wiederum lassen lediglich "stateful inspection" als vollwertige "Firewall"-Funktionalität gelten.

So lässt es sich natürlich auch trefflich aneinander vorbei reden, was im Usenet in der Tat auch geschieht.

3. Port Redirection

Die Tabelle des Leistungsmerkmals "Port Redirection" enthält eine Liste von Ziel-Portnummern, den Protokolltyp von eingehenden Paketen sowie der zugehörigen Klienten-Sockel (IP-Adresse mit Portnummer), zu denen diese Pakete geschickt werden sollen. Wenn eingehende Pakete im Zielport und dem Protokolltyp übereinstimmen, werden sie zu den eingetragenen Klienten geschickt, wobei der Zielport u.U. durch den angegebenen ausgetauscht werden kann.

4. Open Ports

Dies entspricht im wesentlichen der Regel 3, mit dem Unterschied, dass für die ankommende Pakete ganze Portbereiche spezifiziert werden können. Im Gegensatz zu "Port Redirection" bleiben die Zielports im lokalen Netz immer wie sie sind.

Experiment 5:

Man konfiguriere einen Klienten als DMZ und starte dort einen Server. Man teste, ob sich der Sever aus dem Internet erreichen lässt. Nun öffne man den Port auf dem dieser Dienst angeboten wird mittels "Open Ports" für einen anderen Klienten im lokalen Nett. Nun sollte der Dienst nicht mehr erreichbar sein, da die anfordernden Pakte aus dem Internet zu einem anderen Klienten geleitet werden. Damit ist gezeigt, dass "Open Ports" eine höhere Priorität hat als DMZ.

5. DMZ

Alle Pakete, die hier noch ankommen, werden ohne Veränderung zum angegebenen Klienten geschickt. Der Begriff "DeMilitarized Zone" ist eigentlich unangebracht. Besser wäre die Routingregel etwa durch "Default Port Forwarding" bezeichnet. Vorsicht: Dieser Klient im lokalen Netz ist allen Paketen ausgesetzt, die der Router nicht schon vorher herausgefischte!