oder: Behandlung eingehender Pakete durch den DrayTek Vigor
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, ob 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 Router fertig: Er verwirft oder verschickt das Paket sofort im LAN.
Es gibt folgende Routing-Regel-Klassen, die der Router 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 zu aktivieren, indem man den Haken an die Regel setzt und auch OK drückt. Booten ist unnötig.
Nach dem dies vollbracht ist, lassen sich jetzt keinerlei Web-Seiten mehr aufrufen lassen. Der Grund liegt darin, dass man die gesamte NAT/PAT 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.
So, nun sollte man den Filter natürlich wieder entfernen, dann geht wieder alles.
Experiment 2:
Einen Klienten-PC im privaten Netz im Router als DMZ anmelden:
NAT Setup -> DMZ
Dort die private IP-Adresse des DMZ-Klienten angeben. Der DMZ-Klient muss hochgefahren sein.
Anschließend auf der Gibson Research Web-Seite anwählen:
Der Port-Test von "NanoProbe" ergibt nun z.B. bei einem DMZ-Klienten, der unter Win98 ohne Firewallsoftware läuft überall geschlossene oder offene Ports.
Achtung: Die Scan-Ergebnisse sind nur vom Verhalten des DMZ-Klienten abhängig. D.h., wenn der Klient-PC auf die Scans nicht antwortet, ist alles "stealth". Das ist abhängig vom Betriebssystem und von der geladenen Software.
Jetzt beim Vigor 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
Dann nochmal den Port-Test von "NanoProbe" bei Gibson Research durchführen und man wird feststellen können, dass jetzt alles als "stealth" klassifiziert ist - außer dem IDENT_Port 113 (bei der Standard-Konfiguration).
D.h. die DMZ-Regel wird nach dem Paketfilter untersucht. Zum Betrachten der DMZ-Regel kommt es aber nicht, da der Rouer die Pakete des Portscanners vorher verwirft.
=============================
2. NAT Active Sessions Table
3. Port Redirection
4. Open Ports
5. DMZ
=============================
Anders würde das auch überhaupt keinen Sinn machen, denn wenn DMZ höher priorisiert wäre als "Open Ports", würde "Open Ports" von der DMZ-Regel immer komplett maskiert, wenn sie denn aktiv ist. In Open Ports kann man ganze Portbereiche routen, während Port Redirection nur einzelne Ports betrifft.
2. NAT Active Sessions Table
Hier wird geschaut, ob Paktete die gleiche Quellen-"Peer-Ip" und den gleichen Ziel-"Pseudo-Port" haben, wie in einem Tabelleneintrag. Dies entspricht eine Verbindung, die aus dem privaten Netz heraus aufgebaut wurde. Wenn dies zutrifft, wird das Paket zum Klienten geschickt, der im Tabelleneintrag vermerkt ist.
Die Tabelle sieht aus wie folgt:
Durch folgendes Experiment kann man sich klar machen, dass der Router die NAT-Tabelle tatsächlich vor den Port-Mapping-Regeln untersucht:
Experiment 3:
a) Eine Verbindung dach draußen aufbauen, bei der beständig Daten ausgetauscht werden, z.B. ICQ.
b) 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.) 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 mit angegeben wird, sonst speichert der Vigor die Port-Umlengungsregel nicht. Neu booten ist wieder unnötig (wurde mehrfach ausgetestet).
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 Experimant kann man zeigen, dass der Router bei der NAT-Tabelle nicht nur den Pseudo-Port der eintreffenden Pakete sondern auch deren Peer-IP auswertet.
Wie im vorigen Experiment besteht wieder eine ICQ-Verbindung. Der NAT-Pseudo-Port sei wieder 34333.
Einen anderen Klienten meldet man in der DMZ des Routers an. Dort startet man lokal einen beliebigen Server, der auf Port 34333 Pakete erwartet.
Obacht! Das ist der geiche Port wie im NAT-Eintrag zur ICQ-Verbindung!
Nun braucht man eine Person im Internet, am besten den ICQ-Chat-Partner, die auf den Server zugreift.
Ich habe einen Unreal-Tournamemt-Server gestartet und die Server-Admin-Webseite benutzt. Mein ICQ-Partner hat diese Seite dann einfach im Browser aufgerufen. (Statt Unreal gehen aber auch andere Server-Dienste. Was gerade verfügbar ist, und den Port frei konfigurierbar hält)
Und siehe da es klappt. Der ICQ-Partner kann die Seite aufrufen und der ICQ-Botschftenaustausch geht auch weiter - Auf dem gleichen Port! Der Router kann die Pakete jedoch anhand der Quelladresse auseinanderhalten. Die Pakete mit der NAT-Peer-IP schickt der zum PC mit ICQ und alle anderen Pakete zum DMZ-Klienten, auf dem der Server läuft.
Ohne Auswertung der Peer-IP könnte das in dieser Situation nicht reibungslos klappen.
Hinweis:
Ohne Port-Mapping werden nur eingehende Pakete geroutet, die zu einer "Verbindung" gehören, was einem NAT-Tabelleneintrag entspricht. Bei allen anderen Paketen weiß der Router ja ohne Port-Mapping nicht wohin damit und er verwirft sie.
Das ist eine Standardfunktionalität von NAT-Routern. Viele Leute bezeichnen dies bereits als "Firewall". Andere Leute bezeichnen das vorgeschaltete Paketfilter als "Firewall".
Andere lassen nur"stateful inspection" als vollwertige "Firewall"-Funktionalität gelten.
So lässt es sich trefflich aneinander vorbei reden.
3. Port Redirection
Die Tabelle enthält eine Liste von Ziel-Portnummern und den Protokolltyp von eingehenden Paketen sowie der zugehörigen Klienten-Sockel, zu denen diese Pakete geschickt werden sollen.
Wenn 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
Wie Regel 3 nur, dass für die ankommende Pakete ganze Portbereiche spezifiziert werden können. Im Gegensatz zu Port Redirection bleiben die Zielports immer wie sie sind.
5. DMZ
Alle Pakete, die hier noch ankommen, werden ohne Veränderung zum angegebenen Klienten geschickt. Der Begriff "demilitarized zone" ist eigentlich grottenfalsch. Besser wäre z.B. "default port forwarding".
Achtung: Dieser Klient ist allen Paketen, die nicht schon vorher herausgefischt wurden, ausgesetzt!