Linux Netzwerke

Manueller Aufbau von Netzverbindungen

1 Voraussetzungen

TCP/IP ist im Unixbereich immer fester Bestandteil des Kernels. D.h., dass die zwei mittleren Schichten des TCP/IP Modells schon im Kernel implementiert sind. Die nötige Konfigurationsarbeit beschränkt sich daher auf die Netzzugriffsschicht. Natürlich muß dem System klargemacht werden, welche Netzschnittstellen vorhanden sind und welche Adressen ihnen jeweils zugeordnet werden.

Das IP-Protokoll definiert eine abstrakte Schnittstelle interface um auf verschiedene Hardware zugreifen zu können. Diese Schnittstellen bieten eine Reihe von standardisierten Operationen an, die alle mit Versand und Empfang von Daten zu tun haben. Durch das Laden von Gerätetreibern werden diese Schnittstellen mit physikalischen Geräten (Netzwerkkarten o.ä.) verbunden. Dadurch entstehen symbolische Schnittstellennamen wie eth0, eth1 für Ethernetkarten, tr0, tr1 für Token Ring Karten oder arc0, arc1 für Arcnet-Karten. Der lokale Loopback heißt lo. Selbst serielle Verbindungen ins Internet mit ppp oder slip haben dann Interfacenamen wie sl0, sl1 oder ppp0, ppp1.

Diese Zuweisung geschieht in der Regel schon beim Booten, es können bei einem modularen Kernelaufbau aber auch während der Laufzeit des Kernels noch Gerätetreiber geladen werden. Dann erfolgt natürlich auch die Zuweisung von symbolischen Namen erst während der Laufzeit.

2 Konfigurieren des Interfaces

Nachdem wir ein funktionsfähiges Interface haben, z.b. eth0 muß jetzt dafür gesorgt werden, dass dieser Schnittstelle eine Adresse zugewiesen wird. In der Regel geschieht das natürlich automatisch, aber um zu sehen was dort passiert, ist es wichtig, diese Schritte auch mal von Hand durchgeführt zu haben.

Zum Konfigurieren eines Interfaces gibt es das Programm ifconfig, das einem beliebigen Interface IP-Adresse, Netzmaske und Broadcast-Adresse zuweist. Die Anwendung ist erstmal simpel: 

 # ifconfig lo 127.0.0.1
 # ifconfig eth0 192.168.200.55
Damit haben wir dem Interface lo, also dem lokalen Loopback die ihm zustehende Adresse 127.0.0.1 zugewiesen, die Ethernetkarte eth0 bekommt 192.168.200.55. Besser wäre noch gewesen, gleich die Netmask und Broadcast-Adresse mit anzugeben, mit den Schlüsselwörtern netmask und broadcast ist das möglich: 
 # ifconfig eth0 192.168.200.55 broadcast 192.168.200.255 netmask 255.255.255.0
Somit wäre unser Interface jetzt komplett konfiguriert. Das Programm ifconfig kann aber noch mehr. Wird es ohne Optionen aufgerufen, so zeigt es Informationen zu allen bestehenden Netzschnittstellen an. Mit

ifconfig interface

werden Informationen zum jeweiligen interface angezeigt. Neben der Informationsausgabe kann das Programm ifconfig noch folgende Optionen verarbeiten:

down
Schaltet ein Interface schlagartig aus. Es ist danach für den Kernel nicht mehr erreichbar. Vorsicht, Routing Einträge werden nicht mitgelöscht, es können also noch Routen existieren, denen kein Interface zugeordnet ist.
up
Schaltet ein abgeschaltetes Interface wieder ein.
pointopoint ADRESSE
für SLIP und PPP, beides Protokolle für serielle Verbindungen. Hier ist das Interface etwas anders zu steuern, weil ja sozusagen nur ein Netz aus zwei Rechnern (Point to Point) besteht.
metric NUMMER
Nur für RIP. RIP summiert alle anfallenden metric Werte einer Verbindung um daraus die Kosten zu errechnen (heute selten benutzt) und damit Routenwahl auch hinsichtlich der Kosten zu optimieren.
mtu BYTES
Maximum Transmission Unit - Größte Übertragungseinheit des verwendeten Netzprotokolls. Bei Ethernet (802.3) 1500, bei SLIP 296.
promisc
Schaltet ein Interface in den promiscuos mode in dem alle Pakete des Netzwerks, egal ob an diesen oder einen anderen Rechner geschickt, empfangen werden. Brauchbar zur Analyse des Netzverkehrs, der Fehlersuche, aber auch zum Abhören von Netzleitungen.
Alle diese Optionen werden am Ende der Befehlszeile angehängt, z.B. 
  # ifconfig eth0 metric 2 mtu 1024
es folgen also die Optionen der Nennung des Interfacenamens.

3 Erstellen der Routen

Nachdem die Interfaces konfiguriert worden sind, müssen noch die Routing-Tables (Routen-Tabellen) erstellt werden. Das geschieht mit dem Programm route. Die Tabelle existiert nicht als Datei, sondern wird im Kernelspeicher verwaltet. Das heißt, der Aufruf von route muß also bei jedem Start erfolgen.

Das Programm route hat eine einfache Aufrufform:

Wird es ohne Parameter (oder mit -n) aufgerufen, so zeigt es den aktuellen Routing-Table an. (-n zeigt Adressen immer nummerisch, auch wenn Hostnamen bekannt sind)

Ansonsten muß route immer entweder mit dem Schlüsselwort add oder del versehen werden.add steht für Hinzufügen einer Route, del für Löschen einer Route. 

  route add [-net | -host] XXXX [gw GGGG] 
            [metric MMMM] [netmask NNNN] [dev DDDD]
oder 
  route del XXXX
Dabei stehen XXXX für die Route (Netz- oder Hostadresse), GGGG für die Adresse eines Gateway, MMMM für einen numerischen Wert, der als metric-Wert benutzt werden soll, NNNN für eine Netzmaskierung und DDDD für ein TCP/IP Interface wie etwa eth0.

Für einen einfachen Rechner in einem lokalen Netz würde also der folgende Eintrag genügen: 

  # route add -net 192.168.200.0
Damit wäre eine Route definiert, die alle Pakete, die ans Netz 192.169.200.0 gerichtet sind an die Ethernetkarte schickt. Das weiß das System, weil die Ethernetkarte ja die Nummer 192.168.200.55 hat, also die gleiche Netzadresse.

Nehmen wir an, in unserem Netz ist ein Gateway (z.B. 192.168.200.77)ans Internet angeschlossen. Wir brauchen jetzt also zwei Routen, eine ins lokale Netz und einen an den Gateway. An diesen schicken wir alle Pakete, die nicht fürs lokale Netz gedacht sind. 

  # route add -net 192.168.200.0
  # route add default gw 192.168.200.77
Alle Pakete, die wir losschicken und die NICHT für das lokale Netz bestimmt sind, werden jetzt direkt an den Gateway 192.168.200.77 geschickt. Das Schlüsselwort default kann auch mit 0.0.0.0 ausgetauscht werden, der default route.

Jetzt bleibt nur noch die Frage, wie die Routing-Tables eines Gateways konfiguriert werden müssen. Nehmen wir an, der Gateway 192.168.200.77 hat eine FDDI-Karte und hängt direkt am Rechner des Providers. Der Provider hat eine eigene Netzadresse für sein FDDI-Netz. Nehmen wir an, die Provider-Netzadresse ist 192.100.200.0 Der Rechner des Providers (192.100.200.1) leitet alle Pakete ans eigentliche Internet weiter. Das heißt, er dient als nächster Gateway ins Internet. Unser Gateway hat eine FDDI-Karte (Interface fddi0) mit der Adresse 192.100.200.7.

Also müssen wir in unserem Gateway drei Routen konfigurieren. Eine ins lokale Netz, eine ins FDDI-Netz und eine Default-Route zum Providergateway. Selbstverständlich müssen hier auch beide Interfaces richtig konfiguriert sein: 

  # ifconfig eth0 192.168.200.77 broadcast 192.168.200.255 netmask 255.255.255.0
  # ifconfig fddi0 192.100.200.7 broadcast 192.100.200.255 netmask 255.255.255.0
  # route add -net 192.168.200.0
  # route add -net 192.100.200.0
  # route add default 192.100.200.1
Der Gateway hat jetzt also zwei statische Routen in die jeweiligen Netze, die er verbindet (das geht selbstverständlich auch mit zwei Ethernetkarten) und eine Default Route, die wiederum auf den Gateway des Providers verweist. Wenn jetzt ein beliebiger Rechner in unserem lokalen Netz ein Paket an eine gänzlich unbekannte Adresse schickt (etwa 123.45.67.89) dann wird sie (weil es keine feste Route dorthin gibt) über die Default-Route geschickt. Diese ist mit unserem Gateway verbunden. Der hat auch keine feste Route zu 123.45.67.89, schickt das Paket wiederum auf seine Default Route, die mit dem Gateway des Providers verbunden ist. Der gibt das Paket seinerseits ans Internet weiter.

4 Das Programm netstat

Dieses Programm gibt Informationen über den Status bestimmter Netzverbindungen zurück. Interessant sind folgende Möglichkeiten:

netstat -r oder -rn Wie route oder route -n Die angezeigten Flags haben folgende Bedeutung:

netstat -i Gibt die Statistik der Interfaces an, Flags haben folgende Bedeutung: netstat -t, -u, -w, -x, -a zeigt die aktiven Sockets für TCP, UDP, RawIP, Unix oder Alle.

 

[ Kurs Hauptseite ] [ Linux-Kurse ] [ Startseite Linux-Praxis ]

© 1999, 2000, 2001 by F. Kalhammer