Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Projektpraktikum VNUML SS06
COW-Dateisystem und Softwareinstallation
Einrichtung von DHCP, DNS und Routing in VNUML
Uli Eckstein, Rufus Linke, Martin Pätzold
Inhaltsverzeichnis
1 Einleitung........................................................................................................................3
2 Softwareinstallation in den virtuellen Maschinen..........................................................3
2.1 Das COW-Dateisystem in VNUML.......................................................................3
2.2 Vergrößerung des Dateisystems und Umstellung auf ext3.....................................4
2.3 Softwareinstallationen mit apt-get..........................................................................5
3 Entwurf einer Netzstruktur.............................................................................................6
3.1 Übersicht.................................................................................................................6
3.2 Implementation der Netzwerke in VNUML...........................................................7
4 Einrichtung von DHCP...................................................................................................9
4.1 Server......................................................................................................................9
4.2 Client.....................................................................................................................10
4.3 Ablauf einer DHCP-Anfrage................................................................................11
4.4 Aufgaben...............................................................................................................12
5 Einrichtung von DNS...................................................................................................15
5.1 Installation des DNS-Servers BIND.....................................................................15
5.2 Entworfene DNS-Hierarchie.................................................................................15
5.3 Konfiguration der DNS-Server.............................................................................15
5.4 DNS-Anfragen......................................................................................................19
5.5 Aufgaben...............................................................................................................21
6 Routing.........................................................................................................................26
6.1 Installation und Konfiguration von Zebra.............................................................26
6.2 Aufbau der Routingtabellen..................................................................................27
6.3 Aufgabe.................................................................................................................28
7 Literaturverzeichnis......................................................................................................30
2
1 Einleitung
Ziel des Projektpraktikums „Simulationen mit User Mode Linux“ im Sommersemester
2006 war, mit VNUML ein komplexes virtuelles Netzwerk zu erstellen und darin die
üblichen Dienste zu implementieren und zu administrieren.
Unsere Aufgabe bestand darin, zunächst eine Basis zur Softwareinstallation in den
virtuellen Maschinen zu schaffen. Im weiteren Verlauf nutzten wir diese, um
anschließend die Netzwerkdienste DHCP und DNS einzurichten. Schließlich
unterteilten wir das Netzwerk in drei separate Netze, um so sinnvoll Routingaufgaben
mittels RIP zu demonstrieren.
Alle folgenden Angaben beziehen sich auf VNUML Version 1.5.
2 Softwareinstallation in den virtuellen Maschinen
2.1 Das COW-Dateisystem in VNUML
Normalerweise wird in VNUML, vor allem um Speicherplatz zu sparen, nicht für jeden
virtuellen Rechner ein eigenes Dateisystem angelegt, sondern ein Root-Dateisystem
verwendet, an welchem die virtuellen Maschinen selbst keine Änderungen vornehmen
können. Sämtliche simulierten Rechner booten von diesem Image und haben zunächst
alle denselben Datenbestand. Falls ein Rechner im Netzwerk Veränderungen am
Dateisystem vornimmt, werden diese nicht in das ursprüngliche Image geschrieben,
sondern in einer separaten Datei, der sogenannten COW-Datei (Copy On Write)
abgelegt. Diese befindet sich im Dateisystem des Hostrechners unter:
/var/vnuml/<Name_des_Szenarios>
Findet ein Zugriff auf ein COW-Dateisystem statt, wird zunächst geprüft, ob in der
COW-Datei eine Änderung vorliegt. Trifft dies zu, so werden die Daten aus der COW-
Datei gelesen. Andernfalls referenziert die COW-Datei auf das ursprüngliche Root-
Dateisystem. So wird mit einem minimalem Mehrbedarf an Speicherplatz ermöglicht,
verschiedene Dateisystemkonfigurationen zu nutzen. Dabei ist natürlich zu beachten,
dass bei Löschung der COW-Dateien sämtliche Änderungen an den Dateisystemen der
virtuellen Maschinen verloren gehen.
Außerdem ist zu beachten, dass die COW-Dateien neu angelegt werden müssen, sobald
das Ursprungsdateisystem verändert wird, da sie auf dieses referenzieren und durch
diese Änderung die Verweise ungültig werden. Sind keine COW-Dateien vorhanden, so
3
werden diese beim Starten von VNUML automatisch neu angelegt.
Möchte man die in einer virtuellen Maschine vorgenommenen Änderungen in das
Originalimage zurückschreiben, und damit für sämtliche Rechner, die auf dieses
zugreifen, übernehmen, so bietet sich das Tool „uml_moo“ an. Die Anwendung
gestaltet sich folgendermaßen:
Entweder man schreibt alle Änderungen direkt in die vorherige Root-Imagedatei und
überschreibt sie damit
rechnet1:~# uml_moo d <cow_file>
oder erstellt ein neues Image auf Basis des Originals mit den Änderungen der COW-
Datei.
rechnet1:~# uml_moo <cow_file> <new_image_file>
Anschließend ist nun daran zu denken, die COW-Dateien aller virtuellen Rechner, die
auf dieses Image zugreifen, zu löschen (s.o.).
2.2 Vergrößerung des Dateisystems und Umstellung auf ext3
Das mit UML mitgelieferte Dateisystem „root_fs_tutorial“, auf dem wir in dieser Arbeit
aufbauen, bietet nicht genügend freien Speicherplatz. Daher vergrößern wir es, um
weitere Softwareinstallationen zu ermöglichen. Zunächst sollte man das Dateisystem
mit Hilfe von e2fsck auf Fehler überprüfen:
rechnet1:~# e2fsck f <Imagedatei>
Danach kann man es folgendermaßen vergrößern:
rechnet1:~# dd if=/dev/zero of=<Imagedatei> bs=1 count=1 \ seek=<neue_Größe> conv=notrunc
rechnet1:~# resize2fs p <Imagedatei>
Es kann aufgrund von Filesystemchecks beim Starten größerer Szenarien zu langen
Wartezeiten kommen. Um dieses Problem zu umgehen, haben wir uns entschlossen,
das Dateisystem auf ext3 umzustellen. Ext3 bietet im Gegensatz zu ext2 die Funktion
des Journaling, wodurch Filesystemchecks nach Abstürzen signifikant beschleunigt
werden. Dazu dient das Programm tune2fs:
rechnet1:~# tune2fs j <Imagedatei>
Zu beachten ist, dass der Kernel nun ext3 unterstützen muss.
4
2.3 Softwareinstallationen mit apt-get
Da das ursprüngliche Dateisystem auf Debian basiert, ist die einfachste Möglichkeit zur
Installation zusätzlicher Software die Paketverwaltung „apt-get“, die die benötigten
Pakete über das Internet bezieht und gleichzeitig eventuelle Abhängigkeiten auflöst.
Dazu benötigen die virtuellen Maschinen jedoch Internetzugriff über den Host. Hierzu
muss der Host IP-Forwarding und NAT unterstützen und auf den virtuellen Rechnern
als Standardgateway eingetragen werden.
Aktivieren von IP-Forwarding auf dem Host:
rechnet1:~# echo "1" > /proc/sys/net/ipv4/ip_forward
Aktivieren von NAT auf dem Host:
rechnet1:~# iptables t nat A POSTROUTING o eth0 j \
MASQUERADE
Desweiteren muss auf den virtuellen Rechnern in die Datei /etc/resolv.conf ein
erreichbarer Internetnameserver eingetragen werden (beispielsweise Uni Koblenz:
141.26.64.1).
Die Standardgröße des Arbeitsspeichers von 32 MB in VNUML reicht für die
Benutzung von apt-get nicht aus. Daher haben wir sie mit Hilfe des <mem>-Tags in der
XML-Szenariospezifikation auf 100 MB erweitert.
Apt-get bezieht seine Paketquellen aus der Datei /etc/apt/sources.list. Im vorhandenen
Dateisystem root_fs_tutorial sind einige der in dieser Datei stehenden Server nicht mehr
ansprechbar, daher ersetzen wir sie durch folgende Quellen:
# Debian GNU/Linux "Stable":
deb http://ftp2.de.debian.org/debian/ stable main nonfree contrib
debsrc http://ftp2.de.debian.org/debian/ stable main nonfree contrib
deb http://nonus.debian.org/debiannonUS stable/nonUS main contrib nonfree
debsrc http://nonus.debian.org/debiannonUS stable/nonUS main contrib nonfree
deb http://security.debian.org/ stable/updates main contrib nonfree
Nun sind alle Voraussetzungen geschaffen um apt-get auszuführen. Dabei stellen wir
hier nur die wichtigsten Befehle vor. Eine komplette Übersicht erhält man mit man
aptget.
Paketdatenbank aktualisieren:
dns1:~# aptget update
5
Installieren von Paketen:
dns1:~# aptget install <Paketname>
Löschen von Paketen:
dns1:~# aptget remove <Paketname>
Da das vorhandene Dateisystem veraltet ist, haben wir die ganze Debian-Distribution
mittels
dns1:~# aptget distupgrade
auf die aktuelle Stable-Version (3.1) gebracht.
3 Entwurf einer Netzstruktur
3.1 Übersicht
Folgende Netzstruktur wurde im Verlauf des Praktikums entworfen:
Es existieren drei Netze, die über drei Router paarweise verbunden sind. Die Bezeichner
an den roten Verbindungen zu den Netzen geben die IP-Adresse des angeschlossenen
Rechners an. So hat zum Beispiel der Rechner router0 in Net1 die Adresse 10.0.1.10
6
und in Net0 die Adresse 10.0.0.10. Die blauen Bezeichner geben an, dass die IP-
Adresse komplett dynamisch über DHCP vergeben wird, während die grünen Namen
eine statische Adressvergabe anzeigen. Die DHCP-Server müssen bereits vor allen
anderen Rechnern über die XML-Spezifikation eine feste IP-Adresse erhalten, dies wird
über ein * in der Grafik angezeigt. Zwischen vpn und host2 existiert ein virtuelles
privates Netzwerk, welches in einer anderen Projektgruppe bearbeitet wurde. Auf die
weiteren Dienste (www-ftp, nis-nfs), die hier bereits eingezeichnet sind, wird ebenfalls
in den anderen Arbeitsgruppen weiter eingegangen. Die Rechner host0 bis host2 stellen
Beispielclients dar und übernehmen keine weiteren Aufgaben im Netzwerk.
3.2 Implementation der Netzwerke in VNUML
In VNUML wird eine virtuelle Netzwerkumgebung über eine XML-Datei erstellt. Die
komplette XML-Datei unserer Simulation findet sich auf der Homepage des
Projektpraktikums. Zur Erklärung stellen wir hier die Besonderheiten vor.
Innerhalb von <global>:
<automac offset="1"/>
Zur Vergabe der statischen IP-Adressen über DHCP definieren wir in der XML-Datei
feste MAC-Adressen. Die automatisch von VNUML vergebenen MAC-Adressen haben
folgende Form: fe:fd:0:Z:X:Y. Die Variable X bezeichnet die Nummer des
virtuellen Rechners und Y die Netzwerkschnittstelle. Über Z kann man optional einen
Offsetwert angeben, bei dem die Vergabe anfangen soll. Unsere selbstvergebenen
Hardwareadressen benutzen hier den Wert 0. Um Konflikte zu vermeiden, setzen wir
den Offsetwert für automatische Vergabe auf 1.
<default_filesystem type="cow">
/usr/local/share/vnuml/filesystems/root_fs_pp06
</default_filesystem>
<default_kernel>
/usr/local/share/vnuml/kernels/linux2.6.101mv2
</default_kernel>
<basedir>/usr/local/share/vnuml/examples</basedir>
Mit den beiden <default>-Tags legen wir das Dateisystem und den Kernel für alle
virtuellen Maschinen fest. Da wir häufig das <filetree>-Tag benutzen, setzen wir
7
mit <basedir> den Standardpfad zu den darin benutzten Dateien.
Im Folgenden werden wir anhand eines Beispielrechners die Konfiguration der
simulierten Rechner erklären.
<vm name="dns1">
<mem>50M</mem>
<if id="1" net="Net0">
<ipv4>10.0.0.1</ipv4>
</if>
<filetree root="/etc/bind" when="always">
vnuml_pp06/dns1/bind
</filetree>
<filetree root="/root/config" when="always">
vnuml_pp06/dns1/config
</filetree>
<exec seq="config" type="verbatim">
/root/config/dns1_config
</exec>
</vm>
Um Speicherengpässen vorzubeugen wird der Arbeitsspeicher mittels <mem> vom
Standardwert 32 MB auf 50 MB erhöht. Dieser Rechner fungiert als DHCP-Server und
muss daher die IP-Adresse im Voraus fest zugeteilt bekommen.
In unserer Simulation benutzen alle virtuellen Maschinen das gleiche Dateisystem,
benötigen jedoch zum Starten unterschiedlicher Dienste eigene Startkonfigurationen.
Diese Konfigurationen haben wir in ein für jeden Rechner eigens angelegtes
Verzeichnis gespeichert (basedir/vnuml_pp06/Rechnername). Diese werden
über das <filetree>-Tag beim Starten der Simulation in die entsprechenden Ordner
der virtuellen Rechner kopiert. Die einzelnen Dienste werden über das
Rechnername_config-Skript gestartet, welches über <filetree> ins
Verzeichnis /root/config jedes virtuellen Rechners kopiert wird. Es wird
anschließend mit Hilfe der <exec>-Sequenz „config“ ausgeführt.
Grundlegend sind alle Rechner auf diese Weise spezifiziert. Auf Abweichungen davon
gehen wir nun ein.
Auszug aus der Konfiguration von dns4:
<if id="1" net="Net1">
<mac>fe:fd:00:00:00:04</mac>
</if>
8
Dieser Rechner erhält eine statische IP-Adresse über DHCP und benötigt daher eine
feste MAC-Adresse, die über das <mac>-Tag gesetzt wird. Die Rechner, welche
dynamische IP-Adressen vom DHCP-Server beziehen, benötigen aufgrund von
<automac> keinerlei Angaben im <if>-Tag.
Auszug aus der Konfiguration von router0:
<forwarding type="ipv4"/>
Um die Funktionalität der Router zu gewährleisten, wird bei ihnen das Forwarding für
IPv4 aktiviert.
Nach dem Starten der Simulation lassen sich nun alle benötigten Dienste mit dem
Befehl
rechnet1:~# vnumlparser.pl x config@vnuml_pp06.xml
aktivieren, so dass das Netzwerk einsatzbereit ist.
4 Einrichtung von DHCP
4.1 Server
Die DHCP-Server Software muss zunächst installiert werden.
dns1:~# aptget install dhcp
Die Konfiguration des Servers erfolgt über die Datei /etc/dhcpd.conf. Die Einträge
defaultleasetime 100000;
maxleasetime 120000;
geben in Sekunden an, wie lange vergebene IP-Adressen gültig bleiben sollen, bis
Clients eine neue Adresse anfordern müssen. defaultleasetime bezeichnet
dabei die Dauer der Vergabe, falls der Client keine bestimmte lease-time anfordert.
maxleasetime gibt die maximal mögliche Vergabedauer an.
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.200;
option domainnameservers 10.0.0.1;
host router0 {
hardware ethernet fe:fd:00:00:00:10;
fixedaddress 10.0.0.10;
option domainnameservers 10.0.0.1;
}
}
9
Über subnet wird ein Subnetz angegeben, für welches der DHCP-Server IP-Adressen
vergibt. Das obige Beispiel ist ein Auszug aus der Konfiguration von dns1, er verwaltet
die IP-Adressen im Netz 10.0.0.0/24 (Net0). range definiert den Bereich der
dynamisch zu vergebenen Adressen, dns1 teilt dynamischen Clients also IP-Adressen
von 10.0.0.100 bis 10.0.0.200 zu. Die option domainnameservers gibt an,
dass der Server allen dynamischen Clients den folgenden DNS-Server (hier dns1 selbst)
mitteilen soll. Clients mit statischer IP-Adresse werden über das host-Statement
konfiguriert. Dabei gibt man zunächst die Hardwareadresse des Clients, anschließend
mittels fixedaddress die zuzuweisende IP-Adresse an. Dieser Client erhält dann
bei jeder Adressanfrage diese Adresse. Auch hier kann man die option domain
nameservers angeben. Weitere Konfigurationsmöglichkeiten bieten die Manpages
zu dhcpd.conf.
Standardmäßig nimmt der Server Anfragen auf eth0 an. Dieses Interface ist jedoch bei
VNUML immer als Managementinterface reserviert. Daher lassen wir den DHCP-
Server an eth1 laufen. Das Startskript /etc/init.d/dhcp bezieht seine Optionen
aus der Datei /etc/default/dhcp, deshalb ändern wir dort den Eintrag
INTERFACES.
INTERFACES="eth1"
Durch apt-get wird der Server so konfiguriert, dass er beim booten automatisch
hochfährt. In unserem Dateisystem startet der dhcpd jedoch nicht automatisch, sondern
wird auf den entsprechenden Rechnern über das <exec>-Tag „config“ gestartet.
Manuell lässt sich der Server mit
dns1:~# /etc/init.d/dhcp start
dns1:~# /etc/init.d/dhcp restart
starten bzw. neustarten.
4.2 Client
Wie der Server muss der DHCP-Client zunächst installiert werden:
host0:~# aptget install dhcpcd
Zur Konfiguration dient die Datei /etc/dhcpc/config. Auch hier wird das Interface auf
eth1 gesetzt
case ${INTERFACE} in
eth1)
10
Damit die Clients den vom Server zugeteilten DNS-Server in ihre
/etc/resolv.conf eintragen, entfernen wir den Kommentar in der Zeile
# SET_DNS='yes'
Jetzt kann man den Client mit
host0:~# dhcpcd eth1
starten.
4.3 Ablauf einer DHCP-Anfrage
Möchte ein Client eine IP-Adresse beziehen, so schickt er ein DHCP-Broadcastpaket
mit der Absenderadresse 0.0.0.0 (da er noch keine IP-Adresse besitzt) an alle Rechner
im Netzwerk (255.255.255.255) auf den Port 67. Der Server lauscht am angegebenen
Interface auf eingehende IP-Pakete. Empfängt er ein solches Paket, antwortet er anhand
seiner dhcpd.conf mit einem die IP-Adresse beinhaltenden Ethernetpaket an den Client
(Port 68). Von nun an kann der Client mit dieser Adresse auch über IP kommunizieren.
Um dies zu demonstrieren, zunächst der Zustand des Clients dns4 vor der IP-Vergabe:
dns4:~# ifconfig
eth1 Link encap:Ethernet HWaddr FE:FD:00:00:00:04
inet6 addr: fe80::fcfd:ff:fe00:4/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:17 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:968 (968.0 b) TX bytes:378 (378.0 b)
Interrupt:5
Wie man sieht, besitzt dns4 noch keine IPv4-Adresse für das Device eth1. Nun werden
der Server- sowie der Clientdaemon gestartet. Verfolgen kann man den Vorgang mit
tcpdump:
IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from fe:fd:00:00:00:04, length: 548
IP 10.0.1.1.bootps > 10.0.1.4.bootpc: BOOTP/DHCP, Reply, length: 300
In der ersten Zeile sieht man, wie der Client mit der MAC-Adresse
fe:fd:00:00:00:04 eine IPv4-Adresse anfordert. Anschließend teilt der DHCP-
Server 10.0.1.1 dem Client seine neue IPv4-Adresse 10.0.1.4 mit. Ifconfig zeigt
nun, dass das Device eine Adresse erhalten hat.
11
dns4:~# ifconfig
eth1 Link encap:Ethernet HWaddr FE:FD:00:00:00:04
inet addr:10.0.1.4 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::fcfd:ff:fe00:4/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:20 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1918 (1.8 KiB) TX bytes:1028 (1.0 KiB)
Interrupt:5
Einen Überblick über die dynamisch vergebenen Adressen findet man auf dem Server in
der Datei /var/lib/dhcp/dhcpd.leases:
lease 10.0.1.100 {
starts 3 2006/08/16 15:40:43;
ends 3 2006/08/16 15:40:42;
hardware ethernet fe:fd:00:01:14:01;
uid 01:fe:fd:00:01:14:01;
clienthostname "host1";
}
An diesem Eintrag kann man beispielsweise ablesen, an welche MAC-Adresse die IP-
Adresse 10.0.1.100 vergeben wurde und wie lange sie gültig bleibt. Der Client findet
Informationen über die ihm zugeteilte Adresse in der Datei
/var/lib/dhcpc/dhcpcdeth1.info.
4.4 Aufgaben
Ins bestehende Netzwerk soll ein neuer DNS-Server eingebunden werden.
a) Erweitern Sie dazu die Simulation so, dass ein weiterer Rechner mit dem Namen
dns8 im Netzwerk Net2 gestartet wird. Da dieser Rechner als Server eine feste IP-
Adresse benötigt, denken Sie daran, ihm eine feste (eindeutige) MAC-Adresse
zuzuweisen.
b) Fügen Sie diesen neu erstellten Rechner in die DHCP-Konfiguration des Servers
dns3 ein und weisen Sie ihm damit eine IP-Adresse zu.
12
c) Ändern Sie die dhcpd.conf des Servers so ab, dass die Clients nach kurzer Zeit
eine neue IP-Adresse anfordern müssen. Verfolgen Sie den Vorgang mit tcpdump oder
ähnlichen Tools.
Lösungen:
a) Erweiterung der Datei vnuml_pp06.xml um:
<vm name="dns8">
<mem>50M</mem>
<if id="1" net="Net2">
<mac>fe:fd:00:00:00:08</mac>
</if>
</vm>
b) Nach dem Starten der Simulation und des <exec>-Tags „config“
(vnumlparser.pl x config@vnuml_pp06.xml) fügt man in der Datei
/etc/dhcpd.conf auf dns3 folgenden Eintrag im subnet 10.0.2.0 hinzu:
host dns8 {
hardware ethernet fe:fd:00:00:00:08;
fixedaddress 10.0.2.8;
option domainnameservers 10.0.2.8;
}
Um die neue Konfiguration zu lesen, muss man den DHCP-Serverdaemon neustarten.
dns3:~# /etc/init.d/dhcp restart
Startet man nun auf dem Client den DHCP-Clientdaemon mittels
dns8:~# dhcpcd eth1
bezieht der neu eingerichtete Rechner die ihm zugeteilte Adresse.
c) In der dhcpd.conf auf dns3 wird die default-lease-time auf 10 Sekunden
heruntergesetzt:
defaultleasetime 10;
Der DHCP-Server muss daraufhin wieder neugestartet werden
dns3:~# /etc/init.d/dhcp restart
Damit der Client sein lease auch erneuert, muss auch hier der Daemon neugestartet
werden. Dazu zunächst den Clientdaemon beenden:
13
dns8:~# killall dhcpcdbin
Dann kann er neugestartet werden:
dns8:~# dhcpcd eth1
In der Datei /var/lib/dhcpc/dhcpcdeth1.info kann man nun die neue
lease-time sehen:
dns8:~# cat /var/lib/dhcpc/dhcpcdeth1.info
(...)
LEASETIME=10
RENEWALTIME=5
(...)
Nach Ablauf der RENEWALTIME fordert der Client eine neue Adresse an. Tcpdump
macht dies ersichtlich:
16:41:05.604618 IP 10.0.2.8.bootpc > 10.0.2.1.bootps: BOOTP/DHCP, Request from fe:fd:00:00:00:08, length: 548
16:41:05.607089 IP 10.0.2.1.bootps > 10.0.2.8.bootpc: BOOTP/DHCP, Reply, length: 300
16:41:10.604654 IP 10.0.2.8.bootpc > 10.0.2.1.bootps: BOOTP/DHCP, Request from fe:fd:00:00:00:08, length: 548
16:41:10.607086 IP 10.0.2.1.bootps > 10.0.2.8.bootpc: BOOTP/DHCP, Reply, length: 300
16:41:15.604854 IP 10.0.2.8.bootpc > 10.0.2.1.bootps: BOOTP/DHCP, Request from fe:fd:00:00:00:08, length: 548
16:41:15.605872 IP 10.0.2.1.bootps > 10.0.2.8.bootpc: BOOTP/DHCP, Reply, length: 300
Anmerkungen:
Die Simulation ist auf drei physikalisch getrennte Netze verteilt, zwischen denen über
Router vermittelt wird. Damit der neu erstellte Rechner auch mit den anderen beiden
Netzen kommunizieren kann, muss seine Routingtabelle angepasst werden. Der
folgende Befehl setzt als Standardgateway den Router2:
dns8:~# route add default gw 10.0.2.20 eth1
Außerdem muss die Option rp_filter abgeschaltet werden:
dns8:~# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo \
0 > $f; done
Mehr dazu in Abschnitt 6 Routing.
14
5 Einrichtung von DNS
5.1 Installation des DNS-Servers BIND
Im benutzten Dateisystem war der DNS-Server BIND bereits installiert. Dieser war in
UML aufgrund eines Segmentation Faults nicht lauffähig, daher haben wir ihn durch die
vom Quellcode kompilierte Version 9.3.2 ersetzt.
5.2 Entworfene DNS-Hierarchie
Der Root-Nameserver der Hierarchie ist dns1, er verwaltet die Domain vnuml. Alle
Rechner auf dieser Ebene des Baumes liegen im IP-Netz 10.0.0.0/24. Darunter befinden
sich zwei Subdomains site1., verwaltet von dns2, und site2., verwaltet von dns3 mit den
IP-Netzen 10.0.1.0/24 beziehungsweise 10.0.2.0/24. Unter diesen beiden gibt es jeweils
noch zwei weitere Subdomains dept11. (dns4) und dept12. (dns5), sowie dept21. (dns6)
und dept22. (dns7), die jedoch keine eigenen IP-Netze besitzen.
5.3 Konfiguration der DNS-Server
Die Konfigurationsdateien des DNS-Servers BIND liegen im Verzeichnis
/etc/bind. Die einzelnen Zonen, die der Nameserver verwalten soll, werden in
sogenannten Zonendateien abgelegt. Sie werden in Debian nach der Konvention
db.zonenname benannt. Zur Erklärung des Aufbaus dieser Dateien folgen als
Beispiel Ausschnitte aus der Zonendatei db.vnuml des Nameservers dns1.
15
; Domain .vnuml
$TTL 300
vnuml. IN SOA dns1.vnuml. root.dns1.vnuml. (
1 ; serial
3600 ; refresh (1hour)
1800 ; retry (30 min)
604800 ; expire (7 days)
3600 ; minimum (1 hour)
)
vnuml. IN NS dns1.vnuml.
dns1.vnuml. IN A 10.0.0.1
Mit einem Semikolon gekennzeichnete Zeilen bezeichnen Kommentare. Die Direktive
$TTL gibt die standardmäßige Time-To-Live für alle folgenden Einträge in Sekunden
an. Darauf folgt der erste Zoneneintrag. IN gibt an, dass das Internetprotokoll verwendet
wird. Für die Zone vnuml. ist dns1.vnuml der primary nameserver, dies wird durch die
Angabe von SOA (Start Of Authority) festgelegt. Außerdem wird hier die Email-
Adresse des zuständigen Administrators angegeben. Diese ist hier [email protected],
der erste Punkt ist folglich durch ein @ zu ersetzen. In der Klammer steht hier zunächst
die Seriennummer der Zonendatei, gefolgt von den verschiedenen TTLs. Im nächsten
Eintrag gibt man nun alle autoritativen Nameserver (NS) der Zone an, in unserem
Beispiel lediglich dns1.vnuml. Damit der Name dns1.vnuml bereits aufgelöst werden
kann, muss hier eine Adresszuordnung stattfinden, welche über den A-Resource Record
geschieht. Der Name dns1.vnuml wird also in die IP-Adresse 10.0.0.1 übersetzt.
; Host entries
wwwftp.vnuml. IN A 10.0.0.2
www.vnuml. IN CNAME wwwftp
ftp.vnuml. IN CNAME wwwftp
nisnfs.vnuml. IN A 10.0.0.3
nis.vnuml. IN CNAME nisnfs
nfs.vnuml. IN CNAME nisnfs
Nun folgen die Einträge für die Umsetzung der Hostnamen der Zone in IP-Adressen.
Beispielsweise erhält www-ftp.vnuml die IP-Adresse 10.0.0.2. Außerdem werden für
www-ftp.vnuml die Aliasnamen www.vnuml und ftp.vnuml mit Hilfe des Resource
Records CNAME eingerichtet.
; Delegation of zone site1
site1.vnuml. IN NS dns2.site1.vnuml.
16
dns2.site1.vnuml. IN A 10.0.1.1
; Delegation of zone site2
site2.vnuml. IN NS dns3.site2.vnuml.
dns3.site2.vnuml. IN A 10.0.2.1
Anfragen an Subdomains site1.vnuml und site2.vnuml werden hier an die
entsprechenden Server delegiert. So leitet dieser Server zum Beispiel alle Anfragen an
die Domain site1.vnuml an den Nameserver dns2.site1.vnuml weiter. Natürlich muss
hier auch die IP-Adresse von dns2.site1.vnuml angegeben werden, weil sein Name sonst
nicht bekannt ist.
Eingebunden werden diese zonefiles über die Datei /etc/bind/named.conf.
Unter Debian stehen in dieser Datei einige Standardeinträge, Ergänzungen sollten in die
Datei /etc/bind/named.conf.local geschrieben werden, welche in
named.conf eingebunden wird. named.conf.local von dns1:
zone "vnuml." {
type master;
file "/etc/bind/db.vnuml";
};
zone "10.inaddr.arpa." {
type master;
file "/etc/bind/db.10";
};
Wie man sieht wird zunächst die Zone angegeben, anschließend der Typ des Servers für
diese Zone (master oder slave) und die Datei, in der die Zone spezifiziert wird. Die
untere Zone 10.in-addr.arpa wird benötigt für den Reverse Lookup, also die
Übersetzung von IP-Adressen in DNS-Namen.
Damit der Nameserver nicht auf dem Managementinterface von VNUML (eth0) auf
Anfragen wartet, müssen in der /etc/bind/named.conf.options noch die
Devices angegeben werden, auf denen der Server auf Anfragen reagieren soll.
options {
(...)
listenon { 10.0.0.1; 127.0.0.1; };
listenonv6 { none; };
(...)
};
17
Um das Programm rndc zur Verwaltung des Nameserver-Daemons named verwenden
zu können, muss man es konfigurieren. Dazu wird die Datei
/etc/bind/rndc.conf mit folgendem Inhalt erstellt:
key "rndckey" {
algorithm hmacmd5;
secret "99XD4Hi7WX7GTwE7kfRTJw==";
};
options {
defaultserver localhost;
defaultkey "rndckey";
};
Die Datei /etc/bind/rndc.key sollte standardmäßig im Dateisystem vorhanden
sein, falls nicht, muss sie für dieses Beispiel folgendes enthalten:
key "rndckey" {
algorithm hmacmd5;
secret "99XD4Hi7WX7GTwE7kfRTJw==";
};
Weiterhin bedarf die Datei named.conf.options dieser Ergänzung:
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
include "/etc/bind/rndc.key";
Jetzt sollte sich rndc mit
dns1:~# rndc c /etc/bind/rndc.conf Befehl
benutzen lassen. Eine Übersicht der Befehle erhält man durch Starten von rndc ohne
weitere Parameter. Ausgaben, wie beispielsweise ein Cachedump, werden in
/var/cache/bind (wie in named.conf.options über directory definiert)
abgelegt.
Zum Starten des Servers muss zunächst noch in der Datei /etc/default/bind9
folgende Option eingetragen werden:
OPTIONS="u bind c /etc/bind/named.conf"
Dann lässt sich der Server durch
dns1:~# /etc/init.d/bind9 start
starten.
18
Auf Clientseite genügt es zur Konfiguration von DNS, in die Datei
/etc/resolv.conf einen erreichbaren Nameserver einzutragen. Diese Aufgabe
wird jedoch in unserem Szenario bereits vom DHCP-Server übernommen.
5.4 DNS-Anfragen
Zur Auflösung der DNS-Namen von Hand, dient das Tool dig. Um zum Beispiel auf
Server dns4 den Namen dns6.dept21.site2.vnuml aufzulösen, startet man einfach dig
mit
dns4:~# dig dns6.dept21.site2.vnuml
Als Antwort erhält man:
; <<>> DiG 9.3.2 <<>> dns6.dept21.site2.vnuml
;; global options: printcmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 2828
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;dns6.dept21.site2.vnuml. IN A
;; ANSWER SECTION:
dns6.dept21.site2.vnuml. 300 IN A 10.0.2.6
;; AUTHORITY SECTION:
dept21.site2.vnuml. 300 IN NS dns6.dept21.site2.vnuml.
;; Query time: 95 msec
;; SERVER: 10.0.1.4#53(10.0.1.4)
;; WHEN: Thu Aug 17 17:13:04 2006
;; MSG SIZE rcvd: 71
In der Question Section wird zunächst unsere Anfrage wiederholt. In der Answer
Section erhält man dann die gesuchte IP-Adresse. Weiterhin schickt der Server noch
zusätzliche Angaben über zuständige Nameserver mit, damit diese beim nächsten Mal
direkt befragt werden können.
Den ganzen Vorgang der rekursiven Namensauflösung kann man mit tcpdump
beobachten:
19
17:13:04.223969 IP 10.0.1.4.1024 > 10.0.0.1.53: 14235 [1au] A? dns6.dept21.site2.vnuml. (52)
17:13:04.225192 IP 10.0.0.1.53 > 10.0.1.4.1024: 14235 0/1/2(87)
Als erstes sieht man hier, dass der Server dns4 den Root-Nameserver dns1 (10.0.0.1)
befragt, da er über die gesuchte Zone dept21.site2.vnuml keine Informationen besitzt. In
der Antwort teilt dns1 dem anfragenden Server dns4 dann mit, dass er selbst auch keine
Informationen zu dem gesuchten Host besitzt, aber Auskunft über die Zone site2.vnuml
geben kann. Für diese Zone ist der Server dns3 (10.0.2.1) autoritativ, demnach befragt
dns4 diesen als nächstes:
17:13:04.244626 IP 10.0.1.4.1024 > 10.0.2.1.53: 62416 [1au] A? dns6.dept21.site2.vnuml. (52)
17:13:04.266820 IP 10.0.2.1.53 > 10.0.1.4.1024: 62416 0/1/2(82)
Als Antwort erhält dns4 wiederum einen Verweis auf dns6 (10.0.2.6), der für die Zone
dept21.site2.vnuml verantwortlich ist. Schließlich kann dns4 diesen befragen und erhält
die gesuchte IP-Adresse von dns6:
17:13:04.278545 IP 10.0.1.4.1024 > 10.0.2.6.53: 31208 [1au] A? dns6.dept21.site2.vnuml. (52)
17:13:04.280183 IP 10.0.2.6.53 > 10.0.1.4.1024: 31208* 1/1/1 A[|domain]
Auch Reverse Lookups lassen sich mit dig durchführen:
dns4:~# dig x 10.0.1.1
Die Antwort darauf lautet:
; <<>> DiG 9.3.2 <<>> x 10.0.1.1
;; global options: printcmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 58099
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;1.1.0.10.inaddr.arpa. IN PTR
;; ANSWER SECTION:
1.1.0.10.inaddr.arpa. 3600 IN PTR dns2.site1.vnuml.
;; AUTHORITY SECTION:
1.0.10.inaddr.arpa. 3600 IN NS dns2.site1.vnuml.
20
;; ADDITIONAL SECTION:
dns2.site1.vnuml. 300 IN A 10.0.1.1
;; Query time: 45 msec
;; SERVER: 10.0.1.4#53(10.0.1.4)
;; WHEN: Thu Aug 17 17:24:06 2006
;; MSG SIZE rcvd: 99
5.5 Aufgaben
Die folgenden Aufgaben bauen auf die Lösungen aus 4.4 auf. Der neu eingerichtete
Server dns8 soll hier DNS-Aufgaben übernehmen (notfalls können die Aufgaben auch
auf dns6 oder dns7 bearbeitet werden).
a) Dns8 soll die neue Zone dept23.site2.vnuml verwalten. Dazu muss zunächst named
entsprechend konfiguriert werden (bei Verwendung von dns6 und dns7 bereits erfolgt).
Folgende Dateien können beispielsweise von dns3 übernommen werden, da sie
Standardeinstellungen beinhalten:
db.0
db.127
db.255
db.empty
db.local
db.root
named.conf
rndc.conf
rndc.key
Die Datei named.conf.options kann auch übernommen werden, jedoch muss hier
die IP-Adresse im Eintrag listenon an die entsprechende von dns8 angepasst
werden.
Erstellen Sie die Zonendatei db.dept23.site2.vnuml für die Zone
dept23.site2.vnuml mit dns8 als primary nameserver. Integrieren Sie die Zonendatei
anschließend über die zu erstellende Datei named.conf.local in die Konfiguration
von dns8. Denken Sie daran, dass dns3 auch über die neue Zone in Kenntnis gesetzt
werden muss. Starten Sie den named auf dns8 und überprüfen Sie die Funktionalität der
neuen Zone.
21
b) Tragen Sie Adresszuweisungen für zwei beliebige Hosts in dieser Zone in die
Zonendatenbank von dns8 ein (diese müssen nicht existieren). Stellen Sie Anfragen
nach diesen neuen Einträgen.
c) Dns8 soll nun als secondary nameserver für die Zone site2.vnuml dienen. Tragen Sie
dazu dns8.dept23.site2.vnuml als Nameserver für die Zone site2.vnuml in die Zonefiles
der Server dns1 und dns3 ein. Auf dns3 muss zusätzlich noch die Option notify
yes; in der Datei named.conf.options gesetzt werden, damit dieser
Aktualisierungen seiner Datenbank an Slaves mitteilt. Beim Eintrag der Zone in die
named.conf.local des Clients ist zu beachten, dass hier der type auf slave
gesetzt werden muss und mittels masters {10.0.2.1;}; und allownotify
{10.0.2.1;}; der Masterserver, von dem die Zonendateien bezogen werden,
angegeben wird. Diese vom Master bezogenen Dateien werden auf dem secondary
nameserver im Verzeichnis /var/cache/bind abgelegt, daher reicht es einen
Zonendateinamen ohne Pfad anzugeben.
Lösungen:
a) Die zu erstellende Zonendatei sollte so aussehen:
; db.dept23.site2.vnuml
$TTL 300
dept23.site2.vnuml. IN SOA dns8.dept23.site2.vnuml. root.dns8.dept23.site2.vnuml. (
1 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
3600 ; minimum
)
dept23.site2.vnuml. IN NS dns8.dept23.site2.vnuml.
dns8.dept23.site2.vnuml. IN A 10.0.2.8
Auf dns3 muss die Datei db.site.vnuml ergänzt werden:
(...)
; Delegation of zone dept23
dept23.site2.vnuml. IN NS dns8.dept23.site2.vnuml.
dns8.dept23.site2.vnuml. IN A 10.0.2.8
22
Um die Änderungen in dieser Datei zu übernehmen, gibt es zwei Möglichkeiten.
Entweder der named wird neugestartet oder man benutzt rndc:
dns3:/etc/bind# rndc c /etc/bind/rndc.conf reload
server reload successful
Zur Einbindung der Zonefiles auf dns8 wird die Datei
/etc/bind/named.conf.local angelegt:
// named.conf.local auf dns8
zone "dept23.site2.vnuml." {
type master;
file "/etc/bind/db.dept23.site2.vnuml";
};
Der Serverdaemon named kann nun gestartet werden:
dns8:/etc/bind# /etc/init.d/bind9 start
Zum Testen der neuen Zone genügt es, von einem beliebigen Rechner mit dig eine
Anfrage danach zu stellen.
dns3:/etc/bind# dig dns8.dept23.site2.vnuml
Antwort (gekürzt):
;; ANSWER SECTION:
dns8.dept23.site2.vnuml. 300 IN A 10.0.2.8
;; AUTHORITY SECTION:
dept23.site2.vnuml. 300 IN NS dns8.dept23.site2.vnuml.
b) In der neu erstellten Zone werden die Hosts www und mail eingetragen. Die Datei
db.dept23.site2.vnuml wird daher um
; host entries
www.dept23.site2.vnuml. IN A 10.0.2.50
mail.dept23.site2.vnuml. IN A 10.0.2.51
ergänzt. Zum Übernehmen der Änderungen, muss auch hier die Zone neu geladen
werden:
dns8:/etc/bind# rndc c /etc/bind/rndc.conf reload
server reload successful
Das Testen erfolgt wiederum mit dig.
dns8:/etc/bind# dig mail.dept23.site2.vnuml
23
;; ANSWER SECTION:
mail.dept23.site2.vnuml. 300 IN A 10.0.2.51
;; AUTHORITY SECTION:
dept23.site2.vnuml. 300 IN NS dns8.dept23.site2.vnuml.
;; ADDITIONAL SECTION:
dns8.dept23.site2.vnuml. 300 IN A 10.0.2.8
c) Die Zonendatei db.site2.vnuml auf dns3 muss folgendermaßen ergänzt werden:
site2.vnuml. IN NS dns8.dept23.site2.vnuml.
Auf dns1 wird im Abschnitt „Delegation of site2.vnuml“ in der Datei db.vnuml der
Nameserver dns8 als secondary nameserver hinzugefügt.
site2.vnuml. IN NS dns8.dept23.site2.vnuml.
dns8.dept23.site2.vnuml. IN A 10.0.2.8
Die Adresszuweisung für dns8.dept23.site2.vnuml muss hier zusätzlich noch
stattfinden, da dns1 die IP von dns8 noch nicht bekannt ist. Auf dns3 ist dieser Eintrag
bereits vorhanden.
Auf dns3 in named.conf.options wird wie bereits erwähnt die Option notify
gesetzt:
options {
(...)
notify yes;
(...)
}
Dns8 erhält in der named.conf.local einen neuen Zoneneintrag:
zone "site2.vnuml." {
type slave;
file "db.site2.vnuml";
masters {10.0.2.1;};
allownotify {10.0.2.1;};
};
Um die Änderungen anzuwenden müssen wiederholt die Konfigurationen neu geladen
werden.
dns3:/etc/bind# rndc c /etc/bind/rndc.conf reload
server reload successful
24
dns8:/etc/bind# rndc c /etc/bind/rndc.conf reload
server reload successful
Überprüft man nun den Inhalt von /var/cache/bind, wird man feststellen, dass
hier die neue Datei db.site2.vnuml liegt, welche über Zonentransfer angelegt
wurde.
Demonstration des Ausfalls des primary nameservers dns3:
Solange dns3 läuft beantwortet er alle Anfragen an die Zone site2.vnuml. Führt man dig
mit der Option +trace aus, wird die Delegation der Zonen ersichtlich.
dns1:/etc/bind# dig +trace dns6.dept21.site2.vnuml
; <<>> DiG 9.3.2 <<>> +trace dns6.dept21.site2.vnuml
;; global options: printcmd
. 999999 IN NS dns1.vnuml.
;; Received 56 bytes from 127.0.0.1#53(127.0.0.1) in 6 ms
site2.vnuml. 300 IN NS dns3.site2.vnuml.
site2.vnuml. 300 IN NS dns8.dept23.site2.vnuml.
;; Received 118 bytes from 10.0.0.1#53(dns1.vnuml) in 1 ms
dept21.site2.vnuml. 300 IN NS dns6.dept21.site2.vnuml.
;; Received 71 bytes from 10.0.2.1#53(dns3.site2.vnuml) in 4 ms
dns6.dept21.site2.vnuml. 300 IN A 10.0.2.6
dept21.site2.vnuml. 300 IN NS dns6.dept21.site2.vnuml.
;; Received 71 bytes from 10.0.2.6#53(dns6.dept21.site2.vnuml)
in 4 ms
Dns1 verweist hier für die Zone site2.vnuml auf die Server dns3.site2.vnuml und
dns8.dept23.site2.vnuml. Als nächstes wird dns3 befragt (siehe hervorgehobener Text),
da er an erster Stelle steht. Testweise fahren wir nun den named auf dns3 herunter.
dns3:/etc/bind# killall named
Jetzt ergibt dig:
dns1:/etc/bind# dig +trace dns6.dept21.site2.vnuml
; <<>> DiG 9.3.2 <<>> +trace dns6.dept21.site2.vnuml
;; global options: printcmd
. 999999 IN NS dns1.vnuml.
;; Received 56 bytes from 127.0.0.1#53(127.0.0.1) in 7 ms
site2.vnuml. 300 IN NS dns8.dept23.site2.vnuml.
25
site2.vnuml. 300 IN NS dns3.site2.vnuml.
;; Received 118 bytes from 10.0.0.1#53(dns1.vnuml) in 2 ms
dept21.site2.vnuml. 300 IN NS dns6.dept21.site2.vnuml.
;; Received 71 bytes from 10.0.2.8#53(dns8.dept23.site2.vnuml) in 4 ms
dns6.dept21.site2.vnuml. 300 IN A 10.0.2.6
dept21.site2.vnuml. 300 IN NS dns6.dept21.site2.vnuml.
;; Received 71 bytes from 10.0.2.6#53(dns6.dept21.site2.vnuml)
in 4 ms
Hier wird dns3 zwar noch erwähnt, da er in der Datenbank von dns1 steht, jedoch ist er
nicht erreichbar, so dass dns8 alle Anfragen an die Zone site2.vnuml beantwortet.
6 Routing
6.1 Installation und Konfiguration von Zebra
Zebra ist eine Routingsoftware, die die Protokolle BGP-4, RIPv1, RIPv2 und OSPFv2
unterstützt. Zebra ist modular aufgebaut, wir benutzen hier nur RIPv2. Die benötigten
Pakete sind in unserer Debian-Distribution bereits vorinstalliert. Zur Konfiguration
dienen die Dateien /etc/zebra/zebra.conf und /etc/zebra/ripd.conf.
Für unsere Konfiguration kann die zebra.conf bei den Standardeinstellungen
belassen werden. Lediglich in der ripd.conf setzen wir mit der password-Option
das Passwort „zebra“ für den RIP-Daemon, indem wir den Kommentar aus der
entsprechenden Zeile entfernen. Jetzt muss nur noch die network-Option an unser
Netz angepasst werden:
network 10.0.0.0/8
Diese Einstellungen sind für alle drei Router gleich.
Auf den Clients muss ein erreichbarer Router als Standardgateway in der Routingtabelle
eingetragen werden, um alle physikalischen Netze zu erreichen. Für die Rechner aus
Net0 ist dies der router0, für Net1 der router1 und für Net2 der router2. Das setzen
dieser Gateways geschieht bei uns automatisch über das <exec>-Tag „config“ in dem
auf den virtuellen Maschinen der Befehl route entsprechend ausgeführt wird.
Beispiel für host0:
host0:~# route add default gw 10.0.0.10 eth1
26
Außerdem muss auf den Clients der rp_filter abgeschaltet werden. Er dient der
Überprüfung, ob ankommende Pakete aus dem gleichen Netz kommen, aus dem sie
angefordert wurden. Beim Routing kann es vorkommen, dass Antwortpakete eine
andere Route nehmen, als die Anfragepakete. Um zu verhindern, dass diese Pakete
durch den rp_filter verworfen werden, schalten wir den rp_filter für sämtliche
Netzwerkgeräte mit folgendem Befehl ab:
host0:~# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do \
echo 0 > $f; done
Auch dieser Befehl wird bereits automatisch über das <exec>-Tag „config“
ausgeführt.
Um den Routingdaemon zu starten, führt man zunächst zebra aus:
router0:~# zebra f /etc/zebra/zebra.conf u root d
Dann wird der RIP-Daemon gestartet:
router0:~# ripd f /etc/zebra/ripd.conf u root d
6.2 Aufbau der Routingtabellen
Als erklärendes Beispiel verwenden wir hier den Router router0. Zunächst läuft der
RIP-Daemon auf ihm noch nicht. Die Routingtabelle sieht dann folgendermaßen aus:
router0:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.176 * 255.255.255.252 U 0 0 0 eth0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth1
10.0.1.0 * 255.255.255.0 U 0 0 0 eth2
Durch seine zwei Interfaces hat router0 direkte Verbindungen in die Netze Net0
(10.0.0.0) und Net1 (10.0.1.0). Dann wird der RIP-Daemon gestartet. Nach kurzer Zeit
haben die Router unter sich ihre Routinginformationen ausgetauscht, so dass auf router0
diese Routingtabelle entsteht:
router0:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.176 * 255.255.255.252 U 0 0 0 eth0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth1
10.0.1.0 * 255.255.255.0 U 0 0 0 eth2
10.0.2.0 10.0.1.12 255.255.255.0 UG 2 0 0 eth2
27
Jetzt kann router0 auch Pakete in Net2 (10.0.2.0) über den Router router1 (10.0.1.12)
weiterleiten. Alternativ kann man sich Informationen über die RIP-Tabelle auch via
Telnet anzeigen lassen. Dazu loggt man sich auf dem Router auf Port 2602 mittels des
in der ripd.conf eingestellten Passworts ein.
router0:~# telnet localhost 2602
(...)
ripd> show ip rip
Codes: R RIP, C connected, S Static, O OSPF, B BGP
Subcodes:
(n) normal, (s) static, (d) default, (r) redistribute,
(i) interface
Network Next Hop Metric From Tag Time
C(i) 10.0.0.0/24 0.0.0.0 1 self 0
C(i) 10.0.1.0/24 0.0.0.0 1 self 0
R(n) 10.0.2.0/24 10.0.1.12 2 10.0.1.12 0 02:44
Über tcpdump kann man den RIP-Nachrichtenaustausch beobachten.
16:51:48.455754 IP 10.0.0.10.route > 224.0.0.9.route: RIPv2, Request, length: 24
16:51:48.484247 IP 10.0.0.20.route > 10.0.0.10.route: RIPv2, Response, length: 44
16:51:49.412548 IP 10.0.0.10.route > 224.0.0.9.route: RIPv2, Response, length: 44
16:52:12.934056 IP 10.0.0.20.route > 224.0.0.9.route: RIPv2,
Response, length: 44
Viele RIP-Pakete werden an die Adresse 224.0.0.9 geschickt. Diese Adresse gilt für RIP
als Multicastadresse, das heißt, alle Router, auf denen RIP läuft, empfangen diese
Pakete. Nach dem Request von 10.0.0.10 (router0) sendet 10.0.0.20 (router2) die ihm
bekannten Routinginformationen in einer Response an router0. Danach multicasten
diese beiden Router die ihnen bekannten Daten regelmäßig im Netzwerk.
6.3 Aufgabe
Simulieren Sie den Ausfall des Routers router1 und beobachten Sie den Vorgang
beispielsweise mit Hilfe der Routingtabellen oder tcpdump.
Lösung:
Durch den Ausfall von router1 muss router2 eine neue Route zu Net1 aufbauen. Solange
router1 aktiv ist, sieht die Routingtabelle von router2 so aus:
28
router2:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.184 * 255.255.255.252 U 0 0 0 eth0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth1
10.0.1.0 10.0.2.12 255.255.255.0 UG 2 0 0 eth2
10.0.2.0 * 255.255.255.0 U 0 0 0 eth2
Um den Ausfall zu demonstrieren, beenden wir den RIP-Daemon.
router1:~# killall ripd
router1:~# killall zebra
Nach kurzer Zeit haben die Router die neue Situation untereinander ausgetauscht. Auf
router0 ändert sich dabei nichts, da er eine direkte Verbindung ins Netz Net1 besitzt.
Router2 muss jetzt jedoch Pakete an Net1 über router0 weiterleiten, so dass sich seine
Routingtabelle folgendermaßen ändert:
router2:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.184 * 255.255.255.252 U 0 0 0 eth0
10.0.0.0 * 255.255.255.0 U 0 0 0 eth1
10.0.1.0 10.0.0.10 255.255.255.0 UG 2 0 0 eth1
10.0.2.0 * 255.255.255.0 U 0 0 0 eth2
Da hier das Thema Routing nur kurz abgehandelt wurde, verweisen wir für weitere
Informationen auf [9].
29
7 Literaturverzeichnis
[1] User Mode Linux Homepage
http://user-mode-linux.sourceforge.net/shared_fs.html
http://user-mode-linux.sourceforge.net/resize.html
[2] Seminararbeit: Eigener Kernel und eigenes Dateisystem für User-Mode-Linux,
Matthias Korn
http://www.uni-koblenz.de/~vnuml/docs/vnuml/kernel_fs.pdf
[3] Manpages zu apt-get
[4] VNUML 1.5-Reference
http://jungla.dit.upm.es/~vnuml/doc/1.5/reference/index.html
[5] Manpages zu dhcpd und dhcpcd
[6] BIND 9 Administrator Reference Manual
http://www.isc.org/index.pl?/sw/bind/arm93/
[7] Seminararbeit: Domain Name System in VNUML, Rufus Linke
http://www.uni-koblenz.de/~vnuml/docs/dns/dns.pdf
[8] Zebra Documentation
http://www.zebra.org/zebra/index.html
[9] Projektpraktikum Routing-Simulation SS05: RIP-Konfiguration mittels
VNUML-Simulator, Christian Perscheid
http://www.uni-koblenz.de/~vnuml/docs/rip/RIP-Konfiguration.pdf
30