Nachdem jetzt alle Netzwerk-Devices konfiguriert sind, muß man sich Gedanken darüber machen, auf welchen Wegen der Computer die Datagramme weiterleitet. Ist überhaupt nur ein einziges Device vorhanden ist diese Frage sehr leicht zu beantworten: Alle Datagramme, die nicht an den eigenen Rechner adressiert sind, müssen über diese Schnittstelle transferiert werden. Bei mehr als einer Schnittstelle wird es aber komplizierter. Hier muß man bei jedem Datagramm nachsehen, über welche Schnittstelle der Rechner, an den das Datagramm adressiert ist, angeschlossen ist. Dieses `Routing' ist im Prinzip aber recht einfach, auch wenn es manchem auf den ersten Blick nicht so erscheinen mag.
Den Inhalt der momentanen Routing-Tabelle kann man sich ansehen, indem
man das route
-Kommando ohne Parameter aufruft.
Unter Unix gibt es vier unterschiedliche Routing- Mechanismen, auf die im folgenden kurz eingegangen werden soll.
Wie der Name bereits andeutet handelt es sich dabei um ein quasi `fest verdrahtetes' Routing. Das bedeutet, daß der angegebene Weg unter allen Umständen benutzt wird, auch wenn zu einem späteren Zeitpunkt eine bessere Verbindung zur Verfügung stehen würde, oder wenn die angegebene Verbindung zusammenbricht. Auch wenn noch eine alternative Verbindung bestehen würde, sie würde bei statischem Routing nicht benutzt. Aus diesem Grunde werden sie normalerweise nur für sehr einfache Netze verwandt, wenn es sowieso keine weitere Verbindungsmöglichkeit zum anderen Rechner gibt.
Unter Linux wird dieses statische Routing insbesondere für SLIP- und
PLIP-Verbindungen angelegt, wenn der Befehl ifconfig
mit dem
Parameter pointopoint
verwendet wird. Der entsprechende
route
-Befehl, um eine solche statische Verbindung in die
Routing-Tabelle einzutragen, lautet:
%/sbin/route add IPR.IPR.IPR.IPR
ist dabei die Adresse des Rechners am anderen Ende der Leitung.
Für die meisten Rechner, die als Benutzer-Workstations im Netzwerk angeschlossen sind und keine speziellen Aufgaben in diesem Netzwerk wahrnehmen ist die Deklaration einer Default Route das Standardvorgehen. Eine solche Route ist eine besondere Art von statischer Route, die für alle Adressen angewandt wird, für die nicht explizit eine andere Route angegeben ist.
Wer also nur über eine einzige Netzwerk-Schnittstelle verfügt, sei es nun eine SLIP-Verbindung oder eine Ethernet-Karte, der sollte seine Default Route auf dieses Device einrichten. Dazu ist weiterhin eine Adresse notwendig, diejenige des Routers. Dies läßt sich am besten am Beispiel eines (lokalen) Ethernet-Netzwerkes sehen: Soll ein Datagramm an einen Rechner innerhalb des lokalen Netzes gesandt werden, so kann dies der Kernel selständig erkennen (er macht dies anhand der bereits erläuterten Netzwerk-Maske). Soll das Datagramm aber an einen Rechner außerhalb dieses Netzes gehen, so benötigt der Kernel die Adresse eines anderen Rechners, an den er das datagramm weiterreichen kann, und der dann die weitere Zustellung übernimmt. Einen solchen Rechner bezeichnet man als Router oder Gateway. Im Falle eines Internet-Zuganges über SLIP übernimmt der SLIP Server diese Aufgabe, seine IP-Adresse muß dann als Router eingetragen werden. In lokalen Ethernet-Netzen erfährt man die Adresse des Routers vom Systemadministrator.
Um nun die Default Route festzulegen, müssen die folgenden Zeilen in der
Datei rc.inet1
nach der Konfiguration sämtlicher
Netzwerk-Devices eingefügt werden:
# # Add a default route. # /sbin/route add default gw RGA.RGA.RGA.RGA #
ist die Router/Gateway Adresse.
Diese Methode ist unschön, birgt einige Gefahren und sollte nur unter besonderer Vorsicht verwendet werden. Da aber manche darauf schwören, soll es hier nicht unerwähnt bleiben.
Bei weitem das größte Bedürfnis für Proxy ARP besteht bei all denjenigen, die einen Linux-Rechner als SLIP-Server konfigurieren wollen. Soll hingegen ein PPP-Server aufgebaut werden, so übernimmt der PPP-Dämon die meisten Aufgaben, dadurch wird PPP viel einfacher und sicherer.
Will ein anderer Rechner im TCP/IP-Netzwerk mit einem anderen Rechner kommunizieren, so kennt er zwar dessen IP-Adresse, nicht jedoch (im Falle eines Ethernet) die Hardware-Adresse, an die die Datagramme gesandt werden müssen. Der ARP-Mechanismus führt nun genau diese Übersetzung von Netzwerk- und Hardware-Adressen durch. Zu diesem Zweck wird ein spezielles Datagramm, welches die Adresse desjenigen Rechners enthält, dessen Hardware-Adresse gesucht ist, an die Broadcast-Adresse gesandt. Damit `hören' alle Rechner im Netz diesen Aufruf, und derjenige, dessen Adresse gesucht ist, reagiert darauf, indem er seine Hardware-Adresse zurücksendet. Damit kennt nun der Rechner, der die ARP-Anfrage gestartet hatte, die Hardware-Adresse und kann seine Datagramme weiterleiten.
Ist ein Rechner nun als Server für weitere Rechner konfiguriert, so muß
er auch auf alle ARP-Anfragen reagieren, die an diese Klienten gerichtet
sind, da sie ja nicht physikalisch im Ethernet-Netzwerk eingebunden
sind. Dies erläutert sich am besten an einem praktischen Beispiel: Ein
Rechner hat in seinem lokalen Netzwerk einige IP-Adressen, die er für
SLIP-Verbindungen über Modem zur Verfügung stellt. Dies seien die
Adressen 128.253.154.120-124
. Dieser Rechner ist weiter über
eine Ethernet-Karte mit der Hadrware-Adresse 00:00:C0:AD:37:1C
mit dem lokalen Netz verbunden (die Hardware-Adresse kann man mit dem
ifconfig
-Befehl herausfinden). Um diesem Linux-Server nun
mitzuteilen, daß er auch die ARP-Anfragen für die SLIP-Adressen
beantworten soll, müssen die folgenden Zeilen an die Datei
rc.inet1
angefügt werden:
# # Proxy ARP for those dialin users who will be using this # machine as a server: # /sbin/arp -s 128.263.154.120 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.121 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.122 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.123 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.124 00:00:C0:AD:37:1C pub # # End proxy arps.
Der Parameter pub
steht für publish (öffentlich
machen). Dies ist der Befehl für den lokalen Rechner, auch die Anfragen
für die angegebene Adresse zu beantworten, obwohl es nicht die eigene
ist. Dabei wird mit der angegebenen Hardware-Adresse geantwortet,
welches natürlich wiederum die eigene ist.
Selbstverständlich ist es außerdem notwendig, daß auf dem Linux-Server auch Routes zu diesen Adressen konfiguriert sind, die auf die jeweiligen SLIP-Devices zeigen.
Bei der Benutzung von PPP braucht man sich nicht darum kümmern, diese
ARP-Tabelle manuell auf dem laufenden zu halten, denn dies wird von
pppd
automatisch durchgeführt, wenn die Option
proxyarp
angegeben wurde. Voraussetzung dabei ist, daß die
IP-Adresse von Server und Klient zum selben Netzwerk gehören. Aus
diesem Grund muß man auf dem Server beim Start des pppd
die
Netzwerk-Maske in der Kommandozeile mitangeben.
Anstelle von Proxy ARP hätte man im vorangegangenen Beispiel
auch gated
verwenden können. Dessen Hauptaufgabe liegt aber
darin, einen Linux-Rechner als intelligenten IP Router in einem
Netzwerk zu konfigurieren. gated
bietet Unterstützung für eine
ganze Reihe an Routing-Protokollen: RIP, BGP, EGP, HELLO, OSPF und ein
paar mehr. Insbesondere in kleineren Netzen ist RIP das
verbreitetste. RIP steht dabei für Routing Information
Protocol. Ein Linux-Rechner, auf dem gated
für RIP
konfiguriert ist, verbreitet in regelmäßigen Abständen seine eigene
Routing-Tabelle in einem besonderen Format über die Broadcast-Adresse.
Auf diese Weise sind alle Rechner im Netz stets darüber informiert,
welche Adressen über diesen Rechner erreicht werden können.
Wenn auf allen Rechnern in einem Netzwerk entweder gated
oder
routed
läuft, kann Proxy ARP durch gated
ersetzt werden. In einem gemischen Netzwerk, welches sowohl statische
als auch dynamische Routes verwendet, sollten sämtliche statischen
Routes als passiv
erklärt werden um sicherzustellen, daß sie
von gated
nicht gelöscht werden, weil er für sie keine
wiederholten Gltigkeitsmeldungen bekommt. Statische Routes deklariert
man bei der Verwendung von gated
am besten durch einen
static
-Eintrag in der Datei /etc/gated.conf
. Dies
wird weiter unten beschrieben.
Wie es sich für einen Netzwerk-Dämon gehört, wird gated
für
gewöhnlich in der rc-Datei rc.inet2
gestartet. Eventuell wird
man feststellen, daß bereits ein Dämon namens routed
läuft. Da
gated
weit flexibler ist als routed
sollte man dessen
Verwendung vorziehen und den routed
-Prozess nicht weiter
verwenden.
gated
kann per Anonymous FTP bezogen werden von:
sunsite.unc.edu:/pub/Linux/system/Network/daemons/gated11_bin.tgz
Die binäre Paket von gated
besteht aus drei Programmen und zwei
beispielhaften Konfigurationsdateien. Diese sind:
der eigentliche gated
Dämon.
die (optionale) Benutzerschnittstelle zu gated
.
Mittels gdc kann man den gated
-Dämon anhalten, neu
straten, Statusabfragen durchführen usw.
Ein Diagnoseprogramm, mit dem man die bekannten Routes entweder durch eine `rip query' oder ein `rip poll' abfragen kann.
Die Konfigurations-Dateien sind:
dies ist die zentrale Konfigurations-Datei für den
gated
-Dämon. Hier kann das gesamte Verhalten von
gated
festgelegt werden, es können die verschiedenen Protokolle
aktiviert und deaktiviert werden und die aktiven Protokolle können in
ihrem Verhalten beeinflußt werden.
eine kleine Text-Datei, die die Versionsnummer des
gated
-Dämons enthält.
Unerfreulicherweise werden die verschiedenen Dateien von der Binär-Distribution nicht an die richtigen Stellen installiert. Da es aber nur wenige sind, kann man das sehr einfach beheben.
Um sie zunächst temporär zu entpacken und dann an die richtigen Stellen zu installieren dienen die folgenden Befehle:
% cd /tmp
% gzip -dc .../gated.linux.bin.tgz | tar xvf -
% install -m 500 bin/gated /usr/sbin
% install -m 444 bin/gated.conf bin/gated.version /etc
% install -m 555 bin/ripquery bin/gdc /sbin
% rm -rf /tmp/bin
/usr/sbin
ist dabei der übliche Platz für Netzwerk-Dämonen.
Wer sie auf seinem System in einem anderen Verzeichnis hat, muß das
Script natürlich entsprechend abändern. Die mitgelieferte
Beispielkonfiguration setzt gated
so auf, daß das Verhalten des
älteren routed
-Dämons emuliert wird. In den meisten Fällen
wird dies funktionieren. Die Datei /etc/gated.conf
sieht dafür
folgendermassen aus:
# # This configuration emulates routed. It runs RIP and only sends # updates if there are more than one interfaces up and IP forwarding is # enabled in the kernel. # # NOTE that RIP *will not* run if UDP checksums are disabled in # the kernel. # rip yes ; traceoptions all; #
Gibt es im Netz irgendwelche statischen Routes, sollten diese ebenfalls in diese Datei eingetragen werden. Dies geschieht, indem ein solcher Eintrag hinzugefügt wird:
# static { 37.0.0.0 mask 255.0.0.0 gateway 44.136.8.97 ; host 44.136.8.100 gateway 44.136.8.97 ; } ; #
In diesem Beispiel wird eine statische Route zu einem Class-A Netzwerk
37.0.0.0
über den Gateway 44.136.8.97
angelegt sowie
eine weitere zu dem Rechner mit der Adresse 44.136.8.100
ebenfalls über den Gateway 44.136.8.97
.
Will man auch die Dateien der Online-Hilfe für gated
installieren, geht man wie folgt vor:
% cd /tmp
% gzip -dc .../gated.linux.man.tgz | tar xvf -
% install -m 444 man/*.8 /usr/man/man8
% install -m 444 man/*.5 /usr/man/man5
% rm -rf /tmp/man
Diese man
Dateien enthalten sehr präzise und ausführliche
Hinweise zur Benutzung von gated
.
Informationen zur Konfiguration erhält insbesondere das
gated-config
Manual.