Der Kernel 2.2 hat die Routing-Fähigkeiten von Linux wesentlich verbessert. Unglücklicherweise gibt es fast keine Dokumentation zur Nutzung der neuen Fähigkeiten und wenn vorhanden ist sie schwer zu finden.
Ich habe einige Zeit darin investiert und bereits einige Dinge erreicht. Mit der Zeit und mit wachsendem Verständnis werde ich diese Dokumentation erweitern.
Bis Kernel 2.0 nutzte Linux das Standardkommando route zum
Erstellen von Routingregeln in einer einzigen Routingtabelle. Diese konnte
mit
netstat -rn
Mit neueren Kerneln (ab 2.1) gibt es eine weitere regelbasierte Möglichkeit, die es erlaubt, mehrere Routingtabellen zu führen. Die neuen Regeln sind viel flexibler bei der Entscheidung, wie ein Paket gehandhabt wird. Es sind nun Regeln möglich, die nicht mehr nur auf der Zieladresse, sondern auch auf der Quelladresse, dem TOS (Type of Service) Feld des Paketes oder der Schnittstelle auf der das Paket ankam, basieren können.
Die Routingtabelle kann so angezeigt werden:
ip route
Auf meinem Rechner ergibt sich folgende Ausgabe:
207.149.43.62 dev eth0 scope link
207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62
default via 207.149.43.1 dev eth0
Die erste Zeile »207.149.43.62 dev eth0 scope link« ist dabei die Routingregel für die Schnittstelle.
Die zweite Zeile »207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62« ist eine Regel, die aussagt: alles nach 207.149.43.0 muß über 207.149.43.62 versandt werden.
Die dritte Zeile »default via 207.149.43.1 dev eth0« ist die Regel für die Defaultroute.
Jetzt nachdem wir uns eine einfache Routingtabelle angesehen haben, ist es Zeit, mit ihr zu arbeiten. Dazu sollte man zuerst die englischsprachige Dokumentation zum Policy Based Routing lesen, die von folgender Adresse bezogen werden kann:
http://www.compendium.com.ar/policy-routing.txt
Im letzten Abschnitt haben wir das Anzeigen und die Bedeutung der Ausgabe der Routingtabelle besprochen. Glücklicherweise ähnelt die Ausgabe der Tabelle der Syntax zu ihrer Erzeugung:
ip route add 207.149.43.62 dev eth0 scope link
ip route add 207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62
ip route add 127.0.0.0/8 dev lo scope link
ip route add default via 207.149.43.1 dev eth0
Wie Sie sehen, sind Ausgabe und Kommandos fast identisch, wenn man
mal von dem ip route add vor jeder Zeile absieht.
Die IP Network Address Translation Funktionalität ist so ziemlich der standardisierte »Big Brother« des Linux IP Masquerading. NAT ist in gewisser Hinsicht im RFC 1631 spezifiziert. Es bietet Möglichkeiten, die das IP-Masquerading nicht bietet. Damit ist es eher für die Nutzung für Firmen Firewall-Router und noch größere Installationen geeignet.
Eine Alpha Implementierung von NAT für den Linux 2.0.29 Kernel wurde
von Michael Hasenstein
(Michael.Hasenstein@informatik.tu-chemnitz.de) entwickelt.
Michaels Dokumentation und Implementierung sind verfügbar unter:
http://www.suse.de/~mha/HyperNews/get/linux-ip-nat.htmlDer wesentlich verbesserte TCP/IP Stack des 2.2er Linux Kernel enthält bereits die NAT-Funktionalität. Diese Möglichkeit macht eine Zusatzlösung wie von Michael Hasenstein unnötig.
Um sie zu aktivieren, müssen folgende Kerneloptionen gewählt werden:
CONFIG_IP_ADVANCED_ROUTER,
CONFIG_IP_MULTIPLE_TABLES (auch bekannt als Policy Routing)
CONFIG_IP_ROUTE_NAT (auch bekannt als Fast NAT)
Benötigen sie granularere NAT Regeln, dann möchten Sie ebenfalls die Firewallfunktionalität aktivieren:
CONFIG_IP_FIREWALL
CONFIG_IP_ROUTE_FWMARK.
Um diese Kernelfunktionalität auch nutzen zu können, benötigt
man das ip Programm von Alexey Kuznyetsov, welches
von folgendem Server bezogen werden kann:
ftp.inr.ac.ru:/ip-routing
Ist der Kernel richtig konfiguriert und sind alle Tools installiert, kann man mit folgendem Kommando die Adressübersetzung für Pakete einrichten.
ip route add nat <ext-addr>[/<masklen>] via <int-addr>
Diese Regel wird in allen eingehenden Paketen mit der Zieladresse »ext-addr« (also die Adresse, die von außen z.B. vom Internet sichtbar ist) die Zieladresse nach »int-addr« umändern (das ist eine Adresse im internen Netzwerk, hinter dem Gateway bzw. der Firewall). Das Paket wird dann gemäß der lokalen Routing Regeln weitergeleitet. Es ist möglich, entweder einzelne oder ganze Bereiche von Hostadressen zu verändern.
Beispiele:
ip route add nat 195.113.148.34 via 192.168.0.2
ip route add nat 195.113.148.32/27 via 192.168.0.0
Das erste Kommando macht die interne Adresse 192.168.0.2 nach außen hin als 195.113.148.34 zugänglich. Das zweite Beispiel zeigt das Abbilden des Adreßbereiches 192.168.0.0-31 auf den Bereich 195.113.148.32-63.
Haben Sie das Paket iproute2 installiert, kann durch den
einfachen Aufruf von ip die grundlegende Syntax angezeigt
werden.
ip
Usage: ip [ OPTIONS ] OBJECT [ COMMAND [ ARGUMENTS ]]
where OBJECT := { link | addr | route | rule | neigh | tunnel |
maddr | mroute | monitor }
OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] |
-f[amily] { inet | inet6 | dnet | link } | -o[neline] }
»OBJECT« spezifiert das Objekt, für das Informationen ermittelt oder mit dem anderen Kommandos durchgeführt werden sollen. Die von der aktuellen Implementation unterstützten Typen sind:
eine Netzwerkschnittstelle z.B. eth0 oder ppp0
die IP (IPv4 oder IPv6) Adresse der Schnittstelle
ein ARP oder NDISC Cache Eintrag
ein Eintrag der Routingtabelle
eine Regel in der Routing Policy Datenbank
eine Multicast Adresse
ein Multicast Routing Cache Eintrag
Objekt, um zu entscheiden, ob IP Tunneling verwendet wird
Der Umfang an möglichen Optionen jedes Objekttypes hängt vom Typ der durchzuführenden Aktion ab. Ganz grundlegend ist es für jedes Objekt möglich, ein »add«, »delete« oder ein »show« durchzuführen. Nicht alle Objekte bieten weitere Kommandos. Natürlich ist für alle Objekte das Kommando »help« möglich. Dieses gibt die Syntax für das jeweilige Objekt aus.
Wird kein Kommando angegeben, wird das Standardkommando ausgeführt. Das ist typischerweise »show«. Können keine Informationen zum abgefragten Objekt ausgegeben werden, wird nur die Hilfe ausgegeben.
»ARGUMENTS« ist eine Liste von Argumenten, die kommando- und objektspezifisch sind. Es gibt zwei Typen für Argumente:
»Flags« diese bestehen aus einem Schlüsselwort gefolgt von einem Wert. Für die einfachere Benutzung sind für Kommandoargumente oft Standardwerte vorgesehen. So ist der Parameter »dev>« standardmäßig auf »ip link« gesetzt.
Zeigt die Versionsnummer des benutzten ip
Programmes an.
Diese Option führt dazu, daß zusätzliche Informationen ausgegeben werden. Wird die Option mehrfach angegeben, erfolgen noch mehr Ausgaben.
Ermöglicht das Angeben der zu verwendenden Protokollfamilie.
IPv4 (der aktuelle Internetstandard)
IPv6 (der kommende IPv4 Nachfolger)
steht für eine physische Verbindung
Wird diese Option nicht angegeben, versucht das Programm die Protokollfamilie selbst zu bestimmen. Sind dafür nicht genug Informationen gegeben, werden die Standardeinstellungen verwendet.
Bei der Ausgabe wird pro Datensatz nur eine Zeile verwendet.
Mit dieser Option nutzt das Programm den lokalen Auflösungsdienst (z.B. DNS) um Namen statt IP Adressen auszugeben.
Alle Operationen des ip Kommandos sind dynamisch.
Ist die angegebene Syntax fehlerhaft, wird die Systemkonfiguration
nicht verändert. Es gibt nur eine Ausnahme: das »ip link«
Kommando, das zum Ändern der Schnittstelleneigenschaften
genutzt wird.
Es ist schwierig, alle Fehlermeldungen anzugeben (speziell die bei Syntaxfehlern). Typischerweise sollte die Bedeutung einer Fehlermeldung im Kontext des Objektes klar sein.
Typische Fehler sind:
Cannot open netlink socket: Invalid value
Cannot talk to rtnetlink: Connection refused
Cannot send dump request: Connection refused
ip rule fehl. Beispiel:
ip rule list RTNETLINK
error: Invalid argument
dump terminated