![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Zum Kapitel 5 - Das System aus dem Quelltext erzeugen] [Zum Kapitel 7 - Tastatur- und Bildschirmkontrollen]
Für den Rest dieses Dokumentes sei gesagt, dass es hilfreich ist, das Kapitel Kernelkonfiguration und Einstellungen der FAQ gelesen und zumindest teilweise verstanden zu haben. Weiterhin helfen die ifconfig(8)- und netstat(1)-Manualseiten.
Wenn du ein Netzwerkadministrator bist, Routingprotokolle aufsetzt und dein OpenBSD-Rechner dein Router wird, dann solltest du dein Wissen über IP-Netzwerke mit Understanding IP addressing vertiefen. Dies ist wirklich ein exzellentes Dokument. »Understanding IP addressing« beinhaltet grundlegendes Wissen, auf dem man bei der Arbeit mit IP-Netzwerken aufbauen kann; insbesondere wenn man es mit mehreren Netzwerken zu tun hat oder für sie verantwortlich ist.
Wenn du mit Anwendungen wie Web-, FTP- oder Mailservern arbeitest, dann könntest du viel vom Lesen der entsprechenden RFCs profitieren. Selbstverständlich kannst du nicht alle lesen. Aber dennoch: Lies jene, die dich interessieren oder die du bei deiner Arbeit brauchen könntest. Lies nach, wie alles funktionieren sollte. Die RFCs definieren mehrere (tausend) Standards für Protokolle im Internet und wie sie arbeiten sollten.
Unter OpenBSD werden Netzwerkkarten nach ihrem Typ, nicht nach Verbindungsart benannt. Du kannst entweder schon beim Booten oder auch später mit Hilfe des Befehls dmesg(8) sehen, ob deine Netzwerkkarte initialisiert wurde. Weiterhin kannst du mit dem Befehl ifconfig(8) deine Karte überprüfen. Als Beispiel hier die Ausgabe von dmesg für eine Intel-Fast-Ethernet-Netzwerkkarte, die als Gerätenamen fxp hat.
fxp0 at pci0 dev 10 function 0 "Intel 82557" rev 0x0c: irq 5, address 00:02:b3:2b:10:f7
inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 4
Wenn du deinen Gerätenamen nicht kennst, sieh bitte in der Liste der unterstützten Hardware für deine Plattform nach. Du wirst eine Liste vieler bekannter Karten mit ihren OpenBSD-Gerätenamen finden (wie etwa fxp). Kombiniere den alphabetischen Gerätenamen (zum Beispiel fxp) mit einer vom Kernel zugewiesenen Nummer und du hast den sogenannten Interfacenamen (wie z. B. fxp0). Die Nummer wird nach bestimmten Kriterien zugewiesen: Diese unterscheiden sich je nach Karte und weiteren Details deines Systems. Einige Karten werden in der Reihenfolge nummeriert, in der sie während des Bus-Probings gefunden werden. Bei anderen entscheidet die Einstellung der Hardwareressourcen oder die MAC-Adresse.
Du kannst herausfinden, ob deine Netzwerkkarte(n) erkannt wurde(n), indem du das Kommando ifconfig(8) benutzt. Das folgende Kommando zeigt uns alle Netzwerkinterfaces im System an. Diese Beispielausgabe zeigt ein physikalisches Netzwerkinterface an (ein fxp(4)).
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
lo1: flags=8008<LOOPBACK,MULTICAST> mtu 33224
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:04:ac:dd:39:6a
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::204:acff:fedd:396a%fxp0 prefixlen 64 scopeid 0x1
pflog0: flags=0<> mtu 33224
pfsync0: flags=0<> mtu 2020
sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
sl1: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 296
ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
tun0: flags=10<POINTOPOINT> mtu 3000
tun1: flags=10<POINTOPOINT> mtu 3000
enc0: flags=0<> mtu 1536
bridge0: flags=0<> mtu 1500
bridge1: flags=0<> mtu 1500
vlan0: flags=0<> mtu 1500
address: 00:00:00:00:00:00
vlan1: flags=0<> mtu 1500
address: 00:00:00:00:00:00
gre0: flags=9010<POINTOPOINT,LINK0,MULTICAST> mtu 1450
carp0: flags=0<> mtu 1500
carp1: flags=0<> mtu 1500
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif2: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
gif3: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
Wie du hier sehen kannst, gibt ifconfig(8) mehr Informationen aus, als wir zu diesem Zeitpunkt benötigen. Selbstverständlich sehen wir trotzdem unser Interface. Im obigen Beispiel ist die Netzwerkkarte bereits konfiguriert. Das ist offensichtlich, da auf fxp0 bereits ein IP-Netzwerk konfiguriert wurde, sprich die Werte "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255". Außerdem sind die Flags UP und RUNNING gesetzt.
Schlussendlich fällt auf, dass standardmäßig noch viele weitere Interfaces aktiviert sind. Dies sind virtuelle Interfaces, die verschiedene Funktionen haben. Informationen dazu findest du in den folgenden Manualseiten:
Das Interface wird während des Bootvorgangs über die /etc/hostname.if(5)-Dateien konfiguriert, wobei if für den vollständigen Namen deines Interfaces steht (für das vorherige Beispiel wäre es also /etc/hostname.fxp0).
Der Aufbau dieser Datei ist simpel:
address_family address netmask broadcast [weitere Optionen]
Eine typische Interface-Konfigurationsdatei für eine IPv4-Adresse würde so aussehen:
$ cat /etc/hostname.fxp0
inet 10.0.0.38 255.255.255.0 NONE
In diesem Fall haben wir eine IPv4-Adresse (inet) mit der IP-Adresse 10.0.0.38, einer Subnetmask von 255.255.255.0 und ohne bestimmter Broadcastadresse definiert (die in diesem Fall standardmäßig 10.0.0.255 ist).
Du solltest auch den Medientypen für Ethernet angeben, wenn du z. B. den 100baseTX-Fullduplex-Modus erzwingen willst.
inet 10.0.0.38 255.255.255.0 NONE media 100baseTX mediaopt full-duplex
(Auf keinen Fall solltest du das tun, wenn nicht beide Seiten der Verbindungen auf Vollduplex gestellt sind! Wenn du keine besonderen Anforderungen hast, kannst du diese Medieneinstellungen einfach ignorieren. Ein viel wahrscheinlicheres Beispiel wäre eine Einstellung auf 10base-T oder Halbduplex, wenn das Netzwerk dies erfordert.)
Oder vielleicht willst du auch spezielle Flags für ein einzelnes Interface benutzen. Das Format der Datei ändert sich dabei nicht besonders!
$ cat /etc/hostname.vlan0
inet 172.21.0.31 255.255.255.0 NONE vlan 2 vlandev fxp1
10.0.0.1
search example.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind
Wie in fast jedem anderen Unix-System (und vielen Nicht-Unix-Systemen) gibt es eine /etc/hosts-Datei, in die alle Systeme eingetragen werden können, die sich nicht in einem formalen DNS-System befinden (falls sie dort anders angegeben sind als gewünscht, kann man die »lookup«-Reihenfolge wie im vorherigen Beispiel anpassen).
Wenn du DHCP einsetzt, lies 6.4 - DHCP und achte auf den Einsatz von resolv.conf.tail(5).
puffy.example.com
# sh /etc/netstart
writing to routing socket: File exists
add net 127: gateway 127.0.0.1: File exists
writing to routing socket: File exists
add net 224.0.0.0: gateway 127.0.0.1: File exists
Dabei werden ein paar Fehlermeldungen ausgegeben. Indem du dieses Skript ausführst, versuchst du ein paar Sachen zu konfigurieren, die bereits konfiguriert sind. Daher existieren bereits einige der Routen in der Routingtabelle des Kernels. Von hier an sollte dein System laufen und online sein. Du kannst hier erneut mit ifconfig(8) prüfen, ob deine Interfaces richtig konfiguriert wurden.
Obwohl du dein Netzwerk unter OpenBSD ohne Neustart vollständig neukonfigurieren kannst, wird dir DRINGEND dazu geraten, wenn grundlegende Einstellungen geändert wurden. Der Grund hierfür ist, dass die Umgebung während des Bootvorgangs etwas anders ist als wenn das System bereits vollständig hochgefahren wurde. Wenn du zum Beispiel einen über DNS auflösbaren Namen in eine der Dateien geschrieben hast, wirst du diesen im laufenden Betrieb sicherlich auflösen können. Während des Bootvorgangs aber kann es sein, dass der externe Resolver noch nicht verfügbar ist und die Konfiguration somit fehlschlägt.
$ netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 10.0.0.1 UGS 0 86 - fxp0
127/8 127.0.0.1 UGRS 0 0 - lo0
127.0.0.1 127.0.0.1 UH 0 0 - lo0
10.0.0/24 link#1 UC 0 0 - fxp0
10.0.0.1 aa:0:4:0:81:d UHL 1 0 - fxp0
10.0.0.38 127.0.0.1 UGHS 0 0 - lo0
224/4 127.0.0.1 URS 0 0 - lo0
Encap:
Source Port Destination Port Proto SA(Address/SPI/Proto)
$ route show
Routing tables
Internet:
Destination Gateway Flags
default 10.0.0.1 UG
127.0.0.0 LOCALHOST UG
localhost LOCALHOST UH
10.0.0.0 link#1 U
10.0.0.1 aa:0:4:0:81:d UH
10.0.0.38 LOCALHOST UGH
BASE-ADDRESS.MCA LOCALHOST U
Dies sind nur die grundlegenden Informationen, um deinen OpenBSD-Rechner als Gateway (auch Router genannt) einzurichten. Wenn du OpenBSD als Router im Internet verwenden willst, solltest du auch die unten folgenden Packet-Filter-Instruktionen beachten, um potenziell schädliche IP-Daten zu blockieren. Auch solltest du wegen der Knappheit an IPv4-Adressen die Informationen bezüglich Network Address Translation beachten, um deinen IP-Adressbereich zu schonen.
Der GENERIC-Kernel kann bereits IP-Forwarding, muss aber erst eingeschaltet werden. Du solltest dies mit sysctl(8) tun. Um diese Änderung permanent einzutragen, musst du die Datei /etc/sysctl.conf editieren. Füge einfach folgende Zeile in diese Konfigurationsdatei ein.
net.inet.ip.forwarding=1
Ohne Neustart kannst du dies auch direkt mit sysctl(8) durchführen. Beachte aber, dass diese Änderung nach einem Neustart weg ist und dass der folgende Befehl als root ausgeführt werden muss.
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
Nun modifiziere die Routen der anderen Hosts. Es gibt viele verschiedene Möglichkeiten, OpenBSD als Router einzusetzen, z. B. mittels Software wie das OpenBSD-eigene OpenBGPD, routed(8), mrtd, zebra und quagga. OpenBSD hat Unterstützung im Portstree sowohl für zebra als auch für quagga und mrtd. OpenBGPD und routed werden als Teil des Basissystems installiert. OpenBSD unterstützt mehrere T1-, HSSI-, ATM-, FDDI-, Ethernet- und serielle Schnittstellen (PPP/SLIP).
OpenBSD hat einen einfachen Mechanismus, um IP-Aliase für deine Netzwerkkarten zu setzen. Dazu musst du einfach die Datei /etc/hostname.<if> editieren. Sie wird beim Booten vom /etc/netstart(8)-Skript gelesen, das ein Teil der rc-Starthierarchie ist. Für dieses Beispiel nehmen wir an, dass der Benutzer ein Interface dc0 hat und sich im Netzwerk 192.168.0.0 befindet. Weitere wichtige Informationen:
Ein paar Bemerkungen zu Aliasen: In OpenBSD verwendet man nur den Adapternamen. Es gibt keine Unterschiede zwischen dem ersten und dem zweiten Alias. Daher muss man sie nicht - wie in einigen anderen Betriebssystemen - als dc0:0, dc0:1 bezeichnen. Wenn du dich auf einen speziellen IP-Alias beziehst oder einen hinzufügst, dann nimm »ifconfig int alias« statt nur »ifconfig int« auf der Befehlszeile. Du kannst Aliase mit »ifconfig int delete« löschen.
Angenommen du verwendest mehrere IP-Adressen im selben IP-Subnetz mit Aliases, dann ist die Netzmaskeneinstellung für jeden Alias 255.255.255.255. Sie müssen nicht der Netzmaske der ersten IP der Netzwerkkarte folgen. In dieser /etc/hostname.dc0-Beispieldatei werden zwei Aliase zur Netzwerkkarte dc0 hinzugefügt, die als 192.168.0.2 mit Netzmaske 255.255.255.0 konfiguriert wurde.
# cat /etc/hostname.dc0
inet 192.168.0.2 255.255.255.0 media 100baseTX
inet alias 192.168.0.3 255.255.255.255
inet alias 192.168.0.4 255.255.255.255
Wenn du einmal diese Datei erstellt hast, benötigst du einen Neustart, um die Änderung automatisch durchzuführen. Du kannst aber auch die Aliase manuell mit ifconfig(8) hochbringen. Für den ersten Alias geht das so:
# ifconfig dc0 inet alias 192.168.0.3 netmask 255.255.255.255
Um die Aliases zu sehen:
$ ifconfig -A
dc0: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST>
media: Ethernet manual
inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
inet 192.168.0.3 netmask 0xffffffff broadcast 192.168.0.3
Um den im OpenBSD integrierten DHCP-Client dhclient(8) zu benutzen, editiere /etc/hostname.xl0 (wenn deine Hauptnetzwerkkarte xl0 ist. Deine könnte auch ep0 oder fxp0 oder irgendeine andere sein). Alles was du in diese Datei zu schreiben hast ist »dhcp«.
# echo dhcp > /etc/hostname.xl0
Dies wird OpenBSD veranlassen, den DHCP-Client automatisch beim Booten zu starten. OpenBSD wird sich seine IP-Adresse, sein Standardgateway und seine DNS-Server vom DHCP-Server besorgen.
Wenn du den DHCP-Client von der Befehlszeile aus starten willst, stelle sicher, dass /etc/dhclient.conf existiert, dann versuche:
# dhclient fxp0
Wobei fxp0 die Netzwerkkarte ist, auf der du dhcp empfangen willst.
Wie auch immer du den DHCP-Client startest, kannst du die /etc/dhclient.conf-Datei so editieren, dass dein DNS nicht mit den neuen DNS-Informationen aktualisiert wird: kommentiere zuerst die »request«-Zeilen aus (Es gibt Beispiele in den Standardeinstellungen, aber du musst die Standardeinstellungen vom dhclient überschreiben).
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
und dann domain-name-servers. Natürlich möchtest du vermutlich auch Einstellungen wie hostname entfernen.
Durch das Ändern der Optionen in deiner dhclient.conf(5)-Datei teilst du dem DHCP-Client mit, wie deine resolv.conf(5)-Datei erzeugt werden soll. Der DHCP-Client überschreibt jegliche Informationen, die du bereits in der resolv.conf(5) hast, mit jenen, die er vom DHCP-Server erhält. Daher wirst du alle Änderungen verlieren, die du manuell an der resolv.conf vorgenommen hast.
Zwei Mechanismen stehen zur Verfügung, um das zu verhindern:
Ein Beispielfall wäre, wenn du DHCP verwendest, aber lookup file bind an die von dhclient(8) erstellte resolv.conf(5) hängen möchtest. Hierfür gibt es keine Option in dhclient.conf, daher musst du resolv.conf.tail benutzen, um dieses Ziel zu erreichen.
# echo "lookup file bind" > /etc/resolv.conf.tail
nameserver 192.168.1.1
nameserver 192.168.1.2
lookup file bind
Wenn du OpenBSD als DHCP-Server dhcpd(8) einsetzen willst, editiere /etc/rc.conf.local so,
dass sie die Zeile dhcpd_flags="" beinhaltet. Die
Netzwerkkarten, auf denen dhcpd(8) lauschen soll, stehen in
/etc/dhcpd.interfaces.
# echo xl1 xl2 xl3 >/etc/dhcpd.interfaces
Dann editiere /etc/dhcpd.conf. Die Optionen sind
selbsterklärend.
option domain-name "example.com";
option domain-name-servers 192.168.1.3, 192.168.1.5;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
range 192.168.1.32 192.168.1.127;
}
Dies teilt deinen DHCP-Clients mit, dass die an DNS-Anfragen anzuhängende Domäne example.com ist (d. h. wenn der Benutzer »telnet joe« schreibt, dann wird an joe.example.com gesendet). Es wird auf die DNS-Server 192.168.1.3 und 192.168.1.5 verwiesen. Für Hosts, die sich im selben Netzwerk wie die Netzwerkkarte des OpenBSD-Rechners befinden, welche im 192.168.1.0/24 Adressbereich liegt, wird der DHCP-Server ihnen eine IP-Adresse zwischen 192.168.1.32 und 192.168.1.127 und als Standardgateway 192.168.1.1 zuweisen.
Wenn du den dhcpd(8) von der Befehlszeile aus starten willst, nachdem du
/etc/dhcpd.conf editiert hast, versuche:
# touch /var/db/dhcpd.leases
# dhcpd fxp0
Die touch-Zeile ist notwendig, um eine leere dhcpd.leases-Datei zu erzeugen, bevor dhcpd(8) starten kann. Die OpenBSD-Startskripte erstellen diese Datei beim Hochfahren, wenn es notwendig ist. Wenn du aber dhcpd(8) manuell startest, musst du sie zuerst erstellen. fxp0 ist ein Interface, auf dem du beginnen möchtest, DHCP anzubieten.
Wenn du DHCP-Dienste für einen Windows-Rechner bereitstellst, dann
willst du vielleicht auch eine WINS-Serveradresse liefern. Dafür füge
einfach die folgenden Zeilen zu deiner /etc/dhcpd.conf:
option netbios-name-servers 192.168.92.55;
(wobei 192.168.92.55 die IP deines Windows- oder Samba-Servers ist.) Siehe auch dhcp-options(5) für weitere Optionen, die deine DHCP-Clients wünschen.
Das Point-to-Point-Protokoll wird verwendet, um eine Verbindung zu deinem ISP mit deinem Einwahlmodem herzustellen. OpenBSD bietet dafür zwei Möglichkeiten:
Sowohl ppp als auch pppd führen zwar die gleichen Funktionen aus, dieses jedoch auf unterschiedliche Wege. pppd arbeitet mit dem ppp(4)-Treiber des Kernels, während ppp mit tun(4) im Userland arbeitet. Dieses Dokument wird sich nur mit dem PPP-Daemon des Userlands beschäftigen, da es mit ihm einfacher ist, Fehlfunktionen zu korrigieren sowie mit ihm zu interagieren. Um zu beginnen, benötigen wir einige einfache Informationen über deinen ISP. Hier eine Liste hilfreicher Informationen, die du brauchen wirst.
Einige von diesen benötigst du nicht unbedingt, aber sie wären beim Aufsetzen des ppp hilfreich. Der Userland-PPP-Daemon benutzt die Datei /etc/ppp/ppp.conf als seine Konfigurationsdatei. Es gibt viele hilfreiche Dateien in /etc/ppp, die verschiedene Einstellungen für verschiedene Situationen zeigen. Du solltest dir dieses Verzeichnis ansehen und es durchforsten.
Die ersten Einstellungen für den Userland-PPP-Daemon bestehen im Erstellen deiner /etc/ppp/ppp.conf-Datei. Diese Datei existiert nicht standardmäßig, aber du kannst einfach /etc/ppp/ppp.conf.sample editieren, um deine eigene ppp.conf-Datei zu erstellen. Hier werde ich mit den einfachsten und gebräuchlichsten Einstellungen beginnen. Hier eine kurze ppp.conf-Datei, die einfach einige Standardwerte setzt:
default:
set log Phase Chat LCP IPCP CCP tun command
set device /dev/cua01
set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT"
Der Absatz unter der default:-Bezeichnung wird jedes Mal ausgeführt. Hier stehen alle wichtigen Informationen. Mit »set log« stellen wir unsere Loglevel ein. Um dies zu ändern, lies ppp(8) für weitere Informationen. Unsere Schnittstelle wird mit »set device« eingestellt. Dies ist die Schnittstelle, mit der das Modem verbunden ist. In diesem Beispiel hängt das Modem auf COM-Port 2. Daher wird COM-Port 1 auf /dev/cua00 gesetzt. Mit »set speed« setzen wir die Geschwindigkeit unserer Einwahlverbindung und mit »set dail« setzen wir unsere Dialup-Parameter, mit denen wir den Timeout usw. setzen können. Diese Zeile sollte eigentlich ziemlich genau so bleiben, wie sie jetzt ist.
Nun können wir die spezifischen Informationen von unserem ISP eintragen. Wir tun dies, indem wir unter default: einen weiteren Absatz hinzufügen. Dieser kann benannt werden, wie du willst - am einfachsten nimmst du den Namen deines ISPs. Hier werde ich myisp: als Verweis auf unseren ISP nehmen. Hier ist ein einfaches Beispiel, das alles beinhaltet, um uns zu verbinden:
myisp:
set phone 1234567
set login "ABORT NO\\sCARRIER TIMEOUT 5 ogin:--ogin: ppp word: ppp"
set timeout 120
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
Hier stehen alle wichtigen Informationen für unseren spezifischen ISP. Die erste Option »set phone« setzt die Einwahlnummer deines ISPs. »set login« setzt unsere login-Optionen. Hier haben wir den Timeout auf 5 gesetzt, was bedeutet, dass wir unseren Loginversuch nach 5 Sekunden abbrechen, wenn wir kein Trägersignal bekommen. Ansonsten wird er auf »login:« warten und dann deinen Benutzernamen und dein Passwort senden.
In diesem Beispiel ist unser Benutzername ppp und das Passwort ppp. Diese Werte müssen geändert werden. Die Zeile »set timeout« setzt den Idle Timeout für die gesamte Verbindungsdauer auf 120 Sekunden. Die »set ifaddr«-Zeile ist ein bisschen schwieriger. Hier ist eine genauere Erklärung.
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
Die obige Zeile folgt dem Format »set ifaddr [meineAdr[/nn] [seineAdr[/nn] [netzmaske [startAdr]]]]«. Daher ist die erste spezifizierte IP diejenige, die wir als unsere IP wollen. Wenn du eine statische IP-Adresse hast, dann kannst du sie hier einsetzen. In unserem Beispiel benutzen wir /0, was besagt, dass keine Bits von dieser IP-Adresse übereinstimmen müssen und der gesamte Ausdruck ersetzt werden kann. Die zweite IP behandelt die von uns erwartete IP unserer Gegenstelle. Wenn du sie weißt, dann kannst du sie hier angeben. Wiederum wissen wir nicht in unserer Zeile, welche IP dies wird, also lassen wir sie uns wieder mitteilen. Die dritte Option ist unsere Netzmaske, hier auf 255.255.255.0 gesetzt. Wenn startAdr angegeben ist, dann wird diese anstelle von meineAdr während der initialen IPCP-Verhandlung; aber es wird nur eine Adresse aus dem meineAdr-Adressbereich akzeptiert. Dies ist nützlich, wenn Verhandlungen mit einigen PPP-Implementationen durchgeführt werden, die keine IP-Nummer vergeben, es sei denn, ihr Peer fordert »0.0.0.0« an.
Die nächste Option »add default HISADDR« setzt unsere Standardroute zu deren IP. Dies ist »klebrig«, d. h. falls deren IP sich ändern sollte, dann wird unsere Route auch automatisch aktualisiert. Mit »enable dns« teilen wir unserem ISP mit, unsere Nameserveradresse zu authentifizieren. Tu dies NICHT, wenn du deinen eigenen lokalen DNS laufen hast, da PPP dies umgehen wird, indem es einige Zeilen in /etc/resolv.conf schreibt.
Gegenüber den herkömmlichen Loginmethoden verwenden viele IPS nun entweder CHAP- oder PAP-Authentifizierung. Wenn das der Fall ist, wird unsere Konfiguration etwas anders aussehen:
myisp:
set phone 1234567
set authname ppp
set authkey ppp
set login
set timeout 120
set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
In dem oben genannten Beispiel geben wir unseren Benutzernamen (ppp) und das Passwort (ppp) unter jeweiliger Verwendung von authname und authkey an. Es ist nicht notwendig anzugeben, ob CHAP- oder PAP-Authentifizierung genutzt wird: Es wird automatisch ermittelt. »set login« gibt lediglich an, dass versucht wird, sich mit dem zuvor genannten Benutzernamen und dem Passwort anzumelden.
Nun, da wir unsere ppp.conf-Datei fertig eingerichtet haben, können wir beginnen, eine Verbindung zu unserem ISP aufzubauen. Hier einige Details über häufig verwendete Parameter mit ppp:
Wenn die gerade genannten Aufrufe fehlschlagen, kannst du versuchen, /usr/sbin/ppp ohne Optionen zu starten - somit wird ppp im interaktiven Modus ausgeführt. Die Optionen können nach und nach angegeben werden, um so nach Fehlern oder anderen Problemen zu suchen. Unter Verwendung der zuvor beschriebenen Einrichtung wird ppp in /var/log/ppp.log aufzeichnen. Diese Aufzeichnung, sowie die Manualseite, enthalten hilfreiche Informationen.
In einigen Situationen möchstest du Befehle ausführen, wenn die Verbindung gerade errichtet oder beendet wurde. Für diese Fälle gibt es zwei Dateien, die du erstellen kannst: /etc/ppp/ppp.linkup und /etc/ppp/ppp.linkdown. Beispielkonfigurationen kannst du hier finden:
Viele ISPs bieten nun xDSL-Dienste an, welche schneller als die herkömmlichen Einwählmethoden sind. Dies beinhaltet Varianten wie zum Beispiel ADSL und SDSL. Obwohl kein physikalisches Einwählen stattfindet, basiert die Verbindung weiterhin auf dem Point-to-Point-Protokoll. Beispiele beinhalten:
Das »Point to Point Protocol over Ethernet« (PPPoE) ist eine Methode, um PPP-Pakete in Ethernetframes zu versenden. Das »Point to Point Protocol over ATM« (PPPoA) läuft typischerweise in ATM-Netzwerken, wie sie in Großbritannien oder Belgien gefunden werden können.
Typischerweise bedeutet das, dass du eine Verbindung mit deinem ISP über eine normale Ethernetkarte und ethernetbasiertes DSL-Modem herstellen kannst (im Gegensatz zu einem Nur-USB-Modem).
Wenn du ein Modem hast, das PPPoE/PPPoA versteht, ist es möglich, das Modem so zu konfigurieren, dass es selbst die Verbindung aufbaut. Wenn das Modem einen Bridgemodus hat, ist es alternativ möglich, diesen zu aktivieren und so das Modem die Pakete einfach zu einer Maschine durchleiten zu lassen, welche PPPoE-Software einsetzt (siehe unten).
Das Haupt-Softwareinterface für PPPoE/PPPoA unter OpenBSD ist pppoe(8), welches die Userland-Implementation ist (auf fast die gleiche Art und Weise, wie wir ppp(8) weiter oben beschrieben haben). Eine Kernel-PPPoE-Implementation namens pppoe(4) wurde in OpenBSD eingebunden.
Das Point-to-Point-Tunneling-Protokoll (PPTP) ist ein proprietäres Microsoft-Protokoll. Ein pptp-Client ist verfügbar, der mit pppd(8) kommuniziert. Er ist in der Lage, sich zu PPTP-basierten virtuellen privaten Netzwerken (VPN) zu verbinden, die von einigen Kabel- und xDSL-Anbietern verwendet werden. pptp selbst muss als Package oder Port installiert werden. Weitere Anleitungen, wie man pptp einrichtet und verwendet, befinden sich in der Manualseite, die mit dem pptp-Package installiert wird.
Normalerweise möchtest du das entweder für Routing oder wegen Verbindungsproblemen. Selbstverständlich müssen beide Seiten der Verbindung ähnliche Werte verwenden, damit es am effektivsten ist.
Um dies zu tunen, verwende sysctl und erhöhe die Werte von:
net.inet.tcp.keepinittime
net.inet.tcp.keepidle
net.inet.tcp.keepintvl
Mittels sysctl -a kannst du die derzeitigen Werte dieser (und vieler anderer) Parameter sehen. Um einen Wert zu verändern, verwende etwas wie sysctl net.inet.tcp.keepidle=28800.
Normalerweise willst du dies nicht tun. Dies erlaubt jemandem, Datenverkehr zu der Broadcastadresse deines verbundenen Netzwerkes zu schicken, wenn du deinen OpenBSD-Rechner als Router verwendest.
Aber manchmal kann dies in geschlossenen Netzwerken nützlich sein; vor allem wenn man ältere Implementationen des NetBIOS-Protokolles verwendet. Mit sysctl net.inet.ip.directed-broadcast=1 wird dies aktiviert Beachte aber Smurfangriffe, wenn du wissen willst, warum dies standardmäßig nicht aktiviert ist.
Auch dafür gibt es einen eigenen sysctl-Befehl. Siehe sysctl(8):
Setze die Liste der reservierten TCP-Ports, die nicht dynamisch vom
Kernel vergeben werden sollen. Das kann man benutzen, um Daemons davon
abzuhalten, einen speziellen Port zu benutzen, den ein anderes Programm
braucht, damit es funktionieren kann. Listen-Elemente können
mit Kommas und/oder Leerzeichen getrennt werden.
# sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871
Es ist ebenso möglich, Ports aus der aktuellen Liste hinzuzufügen
oder zu entfernen.
# sysctl net.inet.tcp.baddynamic=+748
# sysctl net.inet.tcp.baddynamic=-871
net.inet.tcp.recvspace
net.inet.tcp.sendspace
NFS, oder Network File System (Netzwerkdateisystem), wird verwendet, um ein Dateisystem über das Netzwerk zu verwenden. Du solltest vorher noch folgende Manualseiten lesen, bevor du versuchst, einen eigenen NFS-Server aufzusetzen:
Dieses Kapitel zeigt die Schritte, um ein einfaches NFS-System aufzusetzen: Einen Server im LAN und Clients im LAN, die NFS verwenden. Es behandelt nicht, wie man NFS sicher macht. Wir nehmen an, dass du bereits Paketfilterung oder irgendeinen anderen Firewallschutz eingerichtet hast, damit von außerhalb nicht auf NFS zugegriffen werden kann. Wenn du Zugriff via NFS von außerhalb erlauben willst und sensible Daten dort gespeichert hast, dann empfehlen wir dir wärmstens den Gebrauch von IPsec. Ansonsten können andere Leute möglicherweise deinen NFS-Datenverkehr sehen. Jemand könnte auch vortäuschen, die IP-Adresse zu haben, der du Zugriff auf den NFS-Server zulässt. Es gibt mehrere Angriffe, die möglich sind. Wenn IPsec richtig konfiguriert wurde, dann schützt es gegen die Art von Angriffen.
Noch eine wichtige Anmerkung wegen Sicherheit: Füge niemals ein Dateisystem zu /etc/exports ohne eine Liste mit Rechnern, die explizit Zugriff haben sollen. Ohne einer solchen Liste, die ein bestimmtes Verzeichnis mounten können, kann jeder, der den Rechner erreichen kann, deine NFS-Exports mounten.
portmap(8) muss laufen, damit NFS funktionieren kann. Portmap(8) ist unter OpenBSD standardmäßig abgeschaltet, sodass du die Zeile
portmap=YES
# /usr/sbin/portmap
Der Server hat die IP 10.0.0.1. Dieser Server soll nur NFS für Rechner innerhalb dieses Netzwerkes bereitstellen. Der erste Schritt ist deine /etc/exports-Datei zu erstellen. Diese Datei listet die Dateisysteme auf, die du über NFS freigeben willst, und definiert, wer auf sie zugreifen darf. Es gibt viele Optionen, die du in deiner /etc/exports-Datei haben kannst. Am besten ist, du liest die exports(5)-Manualseite. Für dieses Beispiel sieht /etc/exports so aus:
#
# NFS exports Database
# See exports(5) for more information. Be very careful, misconfiguration
# of this file can result in your filesystems being readable by the world.
/work -alldirs -ro -network=10.0.0 -mask=255.255.255.0
D. h. dass das lokale Dateisystem /work via NFS zugänglich gemacht wird. -alldirs bedeutet, dass Clients jedes Verzeichnis unter dem /work-Mountpunkt mounten können. -ro bedeutet, dass nur Leseberechtigung gestattet wird. Die letzten zwei Argumente bedeuten, dass nur Clients innerhalb des 10.0.0.0-Netzwerkes mit einer Netzmaske von 255.255.255.0 dieses Dateisystem mounten dürfen. Dies ist wichtig für einige Server, die von verschiedenen Netzwerken aus zugänglich sind.
Ist einmal deine /etc/exports-Datei eingerichtet, kannst du weitergehen und deinen NFS-Server aufsetzen. Du solltest zuerst sicherstellen, dass deine Kernelkonfiguration die Optionen NFSSERVER u. NFSCLIENT enthält (der GENERIC-Kernel beinhaltet diese Optionen). Dann solltest du die Zeile
nfs_server=YES
# /sbin/nfsd -tun 4
Du musst nicht nur den nfsd(8)-Server starten, sondern auch mountd(8). Dies ist der Dienst, der eigentlich die Mountanfragen auf NFS bedient. Um mountd(8) zu starten, stelle sicher, dass eine leere mountdtab-Datei existiert und starte den Daemon:
# echo -n >/var/db/mountdtab
# /sbin/mountd
Wenn du Änderungen an /etc/exports durchführst, während NFS bereits läuft, musst du mountd dies mitteilen, indem du den Dienst neustartest!
# kill -HUP `cat /var/run/mountd.pid`
Um zu überprüfen, ob alle Dienste laufen und bei RPC registriert sind, verwende rpcinfo(8).
$ rpcinfo -p 10.0.0.1
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 633 mountd
100005 3 udp 633 mountd
100005 1 tcp 916 mountd
100005 3 tcp 916 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
Für den Normalgebrauch gibt es ein paar Hilfsprogramme, mit denen du den Status von NFS überprüfen kannst. Eines ist showmount(8) das dir anzeigt, wer was gerade mountet. Dann gibt es auch noch nfsstat(1), das genauere Statistiken anzeigt. Für showmount(8) versuche /usr/bin/showmount -a host. Zum Beispiel:
$ /usr/bin/showmount -a 10.0.0.1
All mount points on 10.0.0.1:
10.0.0.37:/work
NFS-Dateisysteme sollten mittels mount(8) geladen werden, oder genauer gesagt, mount_nfs(8). Um ein Dateisystem /work von Host 10.0.0.1 auf dem lokalen Dateisystem /mnt zu laden, tue folgendes (bedenke, dass du nicht IP-Adressen verwenden musst, denn mount wird Hostnamen auflösen):
# mount -o ro -t nfs 10.0.0.1:/work /mnt
Damit dein System dies beim Hochfahren wieder tut, füge Folgendes deiner /etc/fstab hinzu:
10.0.0.1:/work /mnt nfs ro 0 0
Es ist wichtig, dass du 0 0 am Ende dieser Zeile verwendest, damit dein Rechner nicht versucht, das NFS-Dateisystem beim Hochfahren mit fsck zu überprüfen!! Die anderen Sicherheitsoptionen wie noexec, nodev und nosuid sollten auch immer - wenn anwendbar - verwendet werden. Wie zum Beispiel:
10.0.0.1:/work /mnt nfs ro,nodev,nosuid 0 0
Mit diesen Optionen können keine Geräte oder setuid-Programme auf dem NFS-Server Sicherheitsmaßnahmen auf dem NFS-Client untergraben. Wenn du keine Programme auf diesem NFS-Dateisystem auf dem NFS-Client ausführen willst, füge noexec hinzu:
Eine Bridge ist ein Link zwischen zwei oder noch mehr separaten Netzwerken. Anders als ein Router reisen Pakete durch die Bridge »unsichtbar« - logisch erscheinen die beiden Netzwerksegmente wie eines für Rechner auf beiden Seiten der Bridge. Die Bridge wird nur Pakete weiterleiten, die auch von einem Segment in das andere müssen, sie bieten also auch einen einfachen Weg den Verkehr in einem komplexen Netzwerk zu reduzieren und erlauben trotzdem den Zugriff jedes Rechners zu jedem anderen, falls nötig.
Denk daran, dass aufgrund dieser »unsichtbaren« Natur ein Interface in einer Bridge eine IP-Adresse haben kann, aber nicht muss. Wenn sie eine hat, hat die Karte effektiv zwei Betriebsmodi: eine als Teil der Bridge, die andere als normale eigenständige Netzwerkkarte. Wenn keine der Karten eine IP-Adresse hat, wird die Bridge einfach Netzdaten verschieben, aber nicht extern administrierbar oder wartbar sein (was auch ein Feature sein kann).
Eines meiner Computerracks hat eine Anzahl alter Systeme, von denen keines eine eingebaute 10BASE-TX-Netzwerkkarte hat. Während sie alle einen AUI- oder AAUI-Stecker haben, sind die Empfänger auf Koax beschränkt. Eine der Maschinen in diesem Rack ist ein OpenBSD-basierter Terminalserver, der dauerhaft eingeschaltet und immer mit einem Highspeed-Netzwerk verbunden ist. Das Hinzufügen einer zweiten Netzwerkkarte mit einem Koax-Port erlaubt mir, diese Maschine als Bridge zum Koax-Netzwerk zu benutzen.
Dieses System hat jetzt zwei Netzwerkkarten (NICs), eine Intel EtherExpress/100 (fxp0) und eine 3c590-Combokarte (ep0) für den Koax-Port. fxp0 ist der Link zu meinem restliches Netzwerk und wird daher eine IP-Adresse haben, ep0 macht nur Bridging und hat daher keine. Maschinen, die an das Koax-Segment angeschlossen sind, sollen genau so kommunizieren, als wenn sie im Rest meines Netzwerkes wären. Wie also bewerkstelligen wir das?
Die Datei hostname.fxp0 enthält die Konfigurationsdaten für die fxp0-Karte. Diese Maschine soll DHCP machen, also sieht die Datei etwa so aus:
$ cat /etc/hostname.fxp0
dhcp NONE NONE NONE
Noch keinerlei Überraschungen.
Die ep0-Karte ist ein wenig anders, wie du dir denken kannst:
$ cat /etc/hostname.ep0
up media 10base2
Hier sagen wir dem System, es möge das Interface mittels ifconfig(8) aktivieren und auf 10BASE-2 (Koax) setzen. Keine IP-Addresse oder ähnliche Information muss für dieses Interface spezifiziert werden. Die Optionen, die von der ep-Karte akzeptiert werden, sind detailliert in der Manualseite aufgeführt.
Jetzt müsen wir die Bridge aufsetzen. Bridges werden durch die Existenz einer Datei namens bridgename.bridge0. initialisiert. Hier ist zum Beispiel eine Datei für meine Situation:
$ cat /etc/bridgename.bridge0
add fxp0
add ep0
up
Das sagt aus, es soll eine Bridge aus zwei NICs aufgesetzt und aktiviert werden: fxp0 und ep0. Es ist egal, in welcher Reihenfolge die Karten aufgeführt werden. Denke daran, dass die Bridge symmetrisch ist - Pakete fließen ja in beide Richtungen.
Das war es! Starte neu und du wirst eine funktionierende Bridge haben.
Denke daran, dass wegen der Natur der Bridge die gleichen Daten über beide Interfaces fließen, aber du nur auf einem Interface filtern brauchst. Deine »pass all«-Statements würden dann wie folgt aussehen:
pass in on ep0 any
pass out on ep0 any
pass in on fxp0 any
pass out on fxp0 any
Sagen wir nun, ich wolle den Traffic filtern, der auf diese alten Maschinen trifft. Ich möchte, dass nur Web- und SSH-Verkehr zu ihnen durchkommt. In diesem Fall lassen wir jeglichen Verkehr durch das ep0-Interface zu (sowohl rein als auch raus) aber filtern auf dem fxp0-Interface, indem wir keep state für die Antwortdaten benutzen:
# Pass all traffic through ep0
pass in quick on ep0 all
pass out quick on ep0 all
# Block fxp0 traffic
block in on fxp0 all
block out on fxp0 all
pass in quick on fxp0 proto tcp from any to any port {22, 80} \
flags S/SA keep state
Denke daran, dass dieses Regelwerk jeglichen Netzwerkverkehr mit Ausnahme von hereinkommendem HTTP- und SSH-Verkehr zur Bridge selbst und den Maschinen »dahinter« verhindert. Andere Resultate werden erzielt, wenn man auf dem anderen Interface filtert.
Um die Bridge zu überwachen und zu kontrollieren, benutze das brconfig(8)-Kommando, mit dem man eine Bridge auch nach dem Booten erzeugen kann.
Davon ausgehend, dass eine OpenBSD-Maschine die Quelle der Bootdateien
ist, muss die dhcpd.conf-Datei des DHCP-Servers folgende Zeile beinhalten:
filename "pxeboot";
damit der DHCP-Server diese Datei dem bootenden Arbeitsplatz anbietet.
Zum Beispiel:
shared-network LOCAL-NET {
option domain-name "example.com";
option domain-name-servers 192.168.1.3, 192.168.1.5;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
filename "pxeboot";
range 192.168.1.32 192.168.1.127;
default-lease-time 86400;
max-lease-time 90000;
}
}
Du musst außerdem den tftpd(8)-Daemon aktivieren. Dies wird normalerweise durch
inetd(8) realisiert.
Die standardmäßige OpenBSD-Installation hat eine Beispielzeile in
inetd.conf, die wunderbar für dich funktionieren wird:
#tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot
von der lediglich das »#«-Zeichen entfernt werden muss. Sende inetd(8)
ein -HUP Signal, um mitzuteilen, dass /etc/inetd.conf neu
geladen werden soll. tftpd(8) bietet die Dateien von einem bestimmten
Verzeichnis an, in dem Fall von dieser Zeile ist es das
/tftpboot-Verzeichnis, welches wir für dieses Beispiel
verwenden werden. Offensichtlich ist, dass dieses Verzeichnis angelegt
und eingerichtet werden muss. Typischerweise wirst du hier nur ein paar
Dateien für das PXE-Booting haben:
Wenn deine DHCP- und TFTP-Server laufen, bist du bereit, es auszuprobieren.
Du wirst PXE-Boot auf deinem System oder auf der Netzwerkkarte aktivieren
müssen; konsultiere deine Systemdokumentation. Wenn du es gesetzt hast,
solltest du etwas sehen, das diesem ähnlich ist:
Intel UNDI, PXE-2.0 (build 067)
Copyright (C) 1997,1998 Intel Corporation
For Realtek RTL 8139(X) PCI Fast Ethernet Controller v1.00 (990420)
DHCP MAC ADDR: 00 E0 C5 C8 CF E1
CLIENT IP: 192.168.1.76 MASK: 255.255.255.0 DHCP IP: 192.168.1.252
GATEWAY IP: 192.168.1.1
probing: pc0 com0 com1 apm pxe![2.1] mem[540k 28m a20=on]
disk: hd0*
net: mac 00:e0:c5:c8:cf:e1, ip 192.168.1.76, server 192.168.1.252
>> OpenBSD/i386 PXEBOOT 1.00
boot>
Zu diesem Zeitpunkt hast du den normalen OpenBSD-Bootprompt.
Wenn du hier einfach »bsd.rd« eintippst, wirst du die Datei
bsd.rd von dem TFTP-Server laden.
>> OpenBSD/i386 PXEBOOT 1.00
boot> bsd.rd
booting tftp:bsd.rd: 4375152+733120 [58+122112+105468]=0x516d04
entry point at 0x100120
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2007 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 4.2 (RAMDISK_CD) #468: Tue Aug 28 11:02:17 MDT 2007
...
Der bsd.rd-Installationskernel wird nun
booten.
CARP ist ein Werkzeug um beim Erreichen von Systemredundanz zu helfen, indem mehrere Computer ein einzelnes, virtuelles Netzwerkinterface zwischen sich errichten, sodass beim Ausfall eines Systems ein anderes antworten kann. Des Weiteren wird somit ein gewisser Grad an Lastverteilung zwischen Systemen ermöglicht. CARP ist eine Verbesserung vom Standard Virtual-Router-Redundancy-Protokoll (VRRP). Es wurde entwickelt, nachdem VRRP als nicht frei genug wegen einem möglicherweise überlappendem Cisco-Patent angesehen wurde. Für weitere Informationen über CARPs Ursprünge und den rechtlichen Problemen mit VRRP, besuche bitte diese Seite.
Um gesetzliche Konflikte zu umgehen, entwarf Ryan McBride (mit Hilfe von Michael Shalayeff, Marco Pfatschbacher und Markus Friedl) CARP so, dass es fundamental anders war. Die Einbindung von Kryptographie ist eine der prominentesten Änderungen - aber weiterhin nur eine von vielen.
Wie es funktioniert: CARP ist ein Multicast-Protokoll. Es gruppiert mehrere physikalische Computer unter einer oder mehreren virtuellen Adressen zusammen. Von diesen ist ein System der Master und antwortet auf alle Pakete, die für diese Gruppe bestimmt sind, während die anderen Systeme als Hotspares agieren. Unbedeutend wie die IP- und MAC-Adressen des lokalen Interfaces sind, werden Pakete, die zum CARP-Interface gesendet worden sind, mit CARP-Informationen zurückgesendet.
Zu konfigurierbaren Intervallen bekündet der Master seine Operation auf der IP-Protokollnummer 112. Wenn der Master offline geht, beginnen die anderen Systeme in der CARP-Gruppe mit dem bekünden. Der Host, der in der Lage ist am häufigsten zu bekünden, wird der neue Master. Wenn das Hauptsystem wieder online kommt, wird es standardmäßig ein Backuphost, obwohl wenn es wünschenswerter ist, dass ein Host immer Master wird wenn das möglich ist (z. B. wenn ein Host eine schnelle Sun Fire V120 ist und die anderen vergleichbar langsame SPARCstation IPCs sind), kannst du sie so konfigurieren.
Während hoch redundante und fehlertolerante Hardware die Notwendigkeit von CARP verringert, vernichtet sie sie nicht. Es gibt keine Hardwarefehlertoleranz die in der Lage ist zu helfen, wenn jemand das Stromkabel herauszieht oder wenn dein Systemadministrator reboot im falschen Fenster eintippt. CARP macht es außerdem einfacher, den Patch- und Rebootzyklus transparent den Anwendern gegenüber zu gestalten, und einfacher ein Software- oder Hardwareupgrade zu testen - wenn es nicht funktioniert, kannst du auf deine Spares zurückgreifen, bis es behoben ist.
Es gibt jedoch Situationen, in denen CARP nicht helfen wird. CARPs Design setzt voraus, dass die Mitglieder einer Gruppe sich im selben physikalischen Subnetz mit einer statischen IP-Adresse befinden, obwohl mit der Einführung der carpdev-Direktive es keine Notwendigkeit mehr gibt, den physischen Interfaces IP-Adressen zuzuweisen. Ähnlich werden Dienste, die eine durchgehende Verbindung zum Server benötigen (so wie SSH oder IRC), nicht transparent auf andere Systeme weitergeleitet - obwohl in diesem Fall CARP helfen kann, die Ausfallzeit zu minimieren. CARP wird von sich aus Daten zwischen Applikationen nicht synchronisieren, dies muss über »alternative Kanäle« wie zum Beispiel pfsync(4) (für redundantes Filtern), manuelles Duplizieren von Daten zwischen Systemen mit rsync oder was auch immer für deine Anwendungen geeignet ist, durchgeführt werden.
CARPs Kontrollen befinden sich an zwei Orten: sysctl(8) und ifconfig(8). Lass uns nun zuerst die sysctls betrachten.
Die erste sysctl namens net.inet.carp.allow definiert, ob der Host überhaupt CARP-Pakete handhabt. Klarerweise ist dies notwendig, um CARP nutzen zu können. Diese sysctl ist standardmäßig aktiviert.
Die zweite namens net.inet.carp.arpbalance wird für die Lastverteilung verwendet. Wenn diese Funktion aktiviert ist, wird CARP ein Sourcehash auf die Quell-IP der Anfrage durchführen. Dieser Hash wird dann verwendet, um einen virtuellen Host aus dem zur Verfügung stehenden Pool auszuwählen, damit dieser die Anfrage verarbeitet. Dies ist standardmäßig deaktiviert.
Die dritte namens net.inet.carp.log zeichnet CARP-Fehler auf. Standardmäßig deaktiviert.
Die vierte namens net.inet.carp.preempt aktiviert natürliche Auswahl zwischen CARP-Hosts. Der passendste für den Job (das heißt, wer in der Lage ist am schnellsten zu bekünden) wird zum Master. Standardmäßig deaktiviert: Das bedeutet, dass ein System, das nicht zum Master auserwählt wurde, nicht versuchen wird den Masterstatus (wieder) zu erhalten.
Alle diese sysctl-Variablen sind in sysctl(3) dokumentiert.
Für den Rest von CARPs Konfiguration verlassen wir uns auf ifconfig(8). Die CARP-spezifischen Kommandos advbase und advskew behandeln das Intervall zwischen CARP-Advertisements. Die Formel (in Sekunden) ist advskew dividiert durch 256 und dann zu advbase addiert. advbase kann verwendet werden, um Netzwerkverkehr zu verringern oder eine längere Latenz zuzulassen, bevor ein Backuphost übernimmt; advskew lässt dir die Möglichkeit zu verwalten, welcher Host Master sein wird, ohne große Failoververzögerungen (sollte das notwendig sein).
Als nächstes setzt pass ein Passwort und vhid die virtuelle Hostidentifizierungsnummer der CARP-Gruppe. Du musst jeder CARP-Gruppe eine einzigartige Nummer verteilen, selbst wenn (für Lastverteilung) sie sich die gleiche IP-Adresse teilen. CARP ist auf 255 Gruppen begrenzt.
Zum Schluss gibt carpdev an, welches physische Interface zu dieser bestimmten CARP-Gruppe gehört. Standardmäßig gilt, dass jedes Interface, das eine IP-Adresse im gleichen Subnetz von CARP zugewiesen bekam, genutzt wird.
Lass uns alle diese Einstellungen zusammen in eine Grundkonfiguration packen. Angenommen du setzt zwei identische Webserver auf, rachael (192.168.0.5) und pris (192.168.0.6), um ein älteres System zu ersetzen, das unter 192.168.0.7 verfügbar war. Die Befehle:
rachael# ifconfig carp0 create
rachael# ifconfig carp0 vhid 1 pass tyrell carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
erstellen das carp0-Interface und geben es eine vhid von 1, ein Passwort, das tyrell lautet, und die IP-Adresse 192.168.0.7 mit der Maske 255.255.255.0. Weise fxp0 als Mitgliedsinterface zu. Um es über die nächsten Reboots hinaus permanent zu machen, kannst du eine /etc/hostnamecarp0-Datei anlegen, die wie folgt aussieht:
inet 192.168.0.7 255.255.255.0 192.168.0.255 vhid 1 pass tyrell carpdev fxp0
Mache das Gleiche auf pris. Welches System von beiden das CARP-Interface zu erst aufsetzt wird Master (unter der Annahme, dass »preempt« deaktiviert ist; das Gegenteil ist der Fall, wenn »preempt« aktiviert wurde).
Aber lass uns sagen, dass du nicht von Anfang an aufsetzst. rachael war bereits unter der Adresse 192.168.0.7 vorhanden. Wie umgehst du das? Glücklicherweise kann CARP mit dieser Situation umgehen. Du kannst die Adresse einfach dem CARP-Interface zuweisen und das physikalische Gerät bei der Angabe des »carpdev«-Schlüsselwortes belassen, ohne eine IP-Adresse zuzuweisen. Trotz allem tendiert es dazu sauberer zu sein jeweils eine IP für jedes System zu haben - es macht individuelle Überwachungen und Zugriffe viel einfacher.
Lass uns nun einen weiteren Schwierigkeitsgrad hinzufügen; wir möchten, dass rachael so lange wie möglich Master bleibt. Es gibt einige Gründe, warum wir das benötigen könnten: Hardwareunterschiede, einfache Vorurteile, »wenn das System nicht Master ist, wird es Probleme geben« oder zu wissen, wer der standardmäßige Master ist ohne mit Skripten die Ausgabe von ifconfig zu verarbeiten und per E-Mail zu versenden.
Auf rachael werden wir die sysctl verwenden, die wir weiter oben erstellt haben und editieren dann /etc/sysctl.conf, um sie permanent zu machen.
rachael# sysctl net.inet.carp.preempt=1
Wir werden ebenfalls die Konfiguration auf pris durchführen:
pris# ifconfig carp0 advskew 100
Dies verzögert die Bekündungen von pris ein wenig, was bedeutet, dass rachael Master sein wird, wenn der Host angeschlossen wurde.
Bedenke, dass du »proto carp« mit folgender Zeile an alle beteiligten Interfaces übergeben musst, wenn du PF auf einem geCARPten Computer verwendest:
pass on fxp0 proto carp keep state
Siehe nun einige Monate nach vorne. Unsere Firma des vorherigen Beispiels ist so gewachsen, dass sie an dem Punkt angekommen ist, an dem ein einzelner Webserver die Last gerade so verarbeiten kann. Was nun? CARP ist die Rettung. Es ist Zeit, Lastverteilung zu versuchen. Erstelle ein neues CARP-Interface und eine neue CARP-Gruppe auf rachael:
rachael# ifconfig carp1 create
rachael# ifconfig carp1 vhid 2 advskew 100 pass bryant carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
Auf pris werden wir ebenfalls eine neue Gruppe und Interface anlegen und dann das »preempt«-sysctl setzen:
pris# ifconfig carp1 carp1
pris# ifconfig carp1 vhid 2 pass bryant carpdev fxp0 \
192.168.0.7 netmask 255.255.255.0
pris# sysctl net.inet.carp.preempt=1
Nun haben wir zwei CARP-Gruppen mit der gleichen IP-Adresse. Jede Gruppe zeigt auf einen anderen Host. Das bedeutet, dass rachael Master der originalen Gruppe bleibt, aber pris die neue übernehmen wird.
Alles, was wir nun tun müssen, ist die sysctl für die Lastverteilung auf beiden Systemen zu laden, die wir zuvor besprochen haben:
# sysctl net.inet.carp.arpbalance=1
Während diese Beispiele für einen Cluster bestehend aus zwei Maschinen sind, gelten die gleichen Prinzipien auch für mehrere Systeme. Bitte bedenke, dass es trotzdem nicht erwartet wird, dass du perfekte 50/50-Distribution zwischen den beiden Maschinen erreichst - CARP verwendet einen Hash der ankommenden IP-Adresse um zu ermitteln, welches System die Anfrage verarbeitet, statt durch Auslastung zu entscheiden.
OpenNTPD ist ein Versuch, einige dieser Probleme zu lösen, es einfacher zu administrieren zu machen und ein sicherer und simpler NTP-kompatibler Weg zu sein, um eine genaue Uhrzeit auf deinem Computer zu haben. OpenBSDs ntpd(8) wird von einer einfach zu verstehenden Konfigurationsdatei gesteuert: /etc/ntpd.conf.
Aktiviere ntpd(8) einfach in rc.conf.local und das Resultat wird sein, dass deine Computeruhr nach und nach weiter nach vorne gestellt wird, bis sie sich selbst mit den pool.ntp.org-Servern synchronisiert halten kann - einer Sammlung von öffentlich verfügbaren Zeitservern. Wenn deine Uhr erst einmal genau eingestellt ist, wird ntpd sie auf einem sehr hohen Genauigkeitsgrad halten. Sollte deine Uhr jedoch um einige Minuten falsch gehen, so wird dringend dazu geraten, sie zuerst genau einzustellen, da es Tage oder sogar Wochen dauern kann, eine sehr ungenau eingestellte Uhr zu synchronisieren. Du kannst dies tun, indem du entweder die Option »-s« an ntpd(8) übergibst oder aber einen anderen Weg findest, wie du deine Systemzeit richtig einstellen kannst.
Es gibt Anwendungsgebiete, bei denen ntp.orgs ntpd genauer ist, trotzdem geht man davon aus, dass für einen Großteil der restlichen Anwender OpenNTPD mehr als ausreichend sein wird.
Eine ausführlichere Antwort hierauf von den OpenNTPD-Entwicklern kannst du hier lesen.
Obwohl nun ntpd(8) erreichbar ist, kann es durchaus passieren, dass sich andere Maschinen noch immer nicht synchronisieren können. Ein erst kürzlich gestarteter ntpd(8)-Daemon (wenn du zum Beispiel jetzt gerade nach der Anpassung der ntpd.conf neugestartet hast) verweigert die Angabe von Zeitinformationen an andere Clients, bis er seine eigene Uhrzeit auf ein hinnehmbar stabiles Maß angepasst hat. Wenn ntpd(8) seine eigene Zeitinformation als stabil betrachtet, wird der Eintrag »clock now synced« in /var/log/daemon geschrieben. Selbst wenn die Systemzeit bereits von Anfang an sehr genau war, kann es bis zu 10 Minuten dauern, bis alles synchronisiert ist - wenn die Uhrzeit nicht genau eingestellt ist sogar Stunden oder Tage.
Karten, die auf diesen Chips basieren, können fast genauso wie andere Netzwerkkarten genutzt werden, um ein OpenBSD-System mit Hilfe von ifconfig(8) an ein existierendes Drahtlosnetzwerk anzubinden (bitte lies die Manualseiten für präzise Details). Einige dieser Karten können jeodch auch im hostbasierten Accesspointmodus genutzt werden, das ihnen erlaubt, in deinen Wireless-Accesspoint für dein Netzwerk als Teil deiner Firewall gesetzt zu werden.
Beachte bitte, dass du für einige Karten erst die Firmwaredateien beziehen musst, bevor du sie einsetzen kannst. Dies gilt für alle Firmwaredateien, für die die Hersteller keine freie Weiterverbreitung erlauben, sodass sie nicht in OpenBSD eingebunden werden können. Wenn möglich, dann lies die zuvor aufgelisteten Manualseiten. Sie beinhalten Kontaktadressen für die zuständigen Mitarbeiter der Firma, sodass du sie anschreiben und ihnen mitteilen kannst, wie du darüber denkst. Oder teile ihnen mit, welches Produkt du stattdessen erworben hast.
Eine andere Möglichkeit, mit deiner OpenBSD-basierten Firewall einen Wireless Access anzubieten, ist die Verwendung einer konventionellen NIC und einem externen Bridging-Accesspoint. Dies hat den zusätzlichen Vorteil, dass du die Position der Antenne mit Leichtigkeit an die Stelle ändern kannst, an der sie am effektivsten ist, was nicht häufig direkt auf der Rückseite deiner Firewall ist.
»Equal-cost multipath routing« bedeutet, dass sich mehrere Routen in der Routingtabelle für das gleiche Netzwerk befinden - zum Beispiel die Standardroute 0.0.0.0/0. Wenn der Kernel nach einer Route sucht, um Pakete an ein bestimmtes Netzwerk senden zu können, kannn er eine von den »equal-cost routes« auswählen. In den meisten Fällen wird Multipathrouting eingesetzt, um redundante Uplinkverbindungen aufzubauen, z. B. redundante Internetverbindungen.
Das Kommando route(8) wird verwendet, um Routen zur Routingtabelle hinzuzufügen, dort zu ändern oder sie aus der Routingtabelle zu löschen. Das Argument -mpath wird verwendet, um Multipath-Routen hinzuzufügen.
# route add -mpath default 10.130.128.1
# route add -mpath default 10.132.0.1
Überprüfe die Routen wie folgt:
# netstat -rnf inet | grep default
default 10.130.128.1 UGS 2 134 - fxp1
default 10.132.0.1 UGS 0 172 - fxp2
In diesem Beispiel können wir sehen, dass eine Standardroute auf 10.130.128.1 zeigt, die über das fxp1-Interface erreichbar ist. Die andere zeigt auf 10.132.0.1 und ist über fxp2 erreichbar.
Da die Datei mygate(5) bisher noch keine Multipath-Standardrouten unterstützt, sollte der vorherige Befehl an das Ende der hostname.if(5)-Dateien für die Interfaces fxp1 und fxp2 angehängt werden. Die /etc/mygate-Datei sollte danach gelöscht werden.
Vergiss zum Schluss nicht, dass du den Einsatz von Multipathrouten mit der dafür vorgesehenen sysctl(3)-Variablen aktivieren musst.
# sysctl net.inet.ip.multipath=1
# sysctl net.inet6.ip6.multipath=1
Ändere ebenfalls die Datei sysctl.conf(5), um die Änderungen permanent zu machen.
Versuch nun traceroute mit verschiedenen Zielen aufzurufen. Der Kernel wird die Datenlast auf die einzelnen Multipathrouten ausgleichen.
# traceroute -n 154.11.0.4
traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets
1 10.130.128.1 19.337 ms 18.194 ms 18.849 ms
2 154.11.95.170 17.642 ms 18.176 ms 17.731 ms
3 154.11.5.33 110.486 ms 19.478 ms 100.949 ms
4 154.11.0.4 32.772 ms 33.534 ms 32.835 ms
# traceroute -n 154.11.0.5
traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets
1 10.132.0.1 14.175 ms 14.503 ms 14.58 ms
2 154.11.95.38 13.664 ms 13.962 ms 13.445 ms
3 208.38.16.151 13.964 ms 13.347 ms 13.788 ms
4 154.11.0.5 30.177 ms 30.95 ms 30.593 ms
Lies im RFC2992 das Kapitel »Analysis of an Equal-Cost Multi-Path Algorithm« wenn du Genaueres über die Routenauswahl erfahren möchtest.
Des Weiteren ist es erwähnenswert, dass beim Ausfall eines Interfaces (z. B. beim Verlust des Carriers) für eine Multipathroute der Kernel weiterhin versucht, Pakete über die Route zu senden, die an dieses Interface gebunden wurde. Der Datenverkehr wird natürlich ins Nichts führen und somit verloren gehen. Es wird daher dringend empfohlen, ifstated(8) auf nicht verfügbare Interfaces zu überprüfen und die Routingtabelle dementsprechend anzupassen.
[FAQ-Index] [Zum Kapitel 5 - Das System aus dem Quelltext erzeugen] [Zum Kapitel 7 - Tastatur- und Bildschirmkontrollen]
![[zurück]](../../images/back.gif){kind=small}
www@openbsd.org