![[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) Manual Seiten.
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. Natürlich 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.
Um beginnen zu können, musst du zunächst deine Netzwerkkarte identifizieren können. Bei OpenBSD werden Netzwerkkarten nach ihrem Typ, nicht nach Verbindungsart benannt. Du kannst sehen, ob deine Netzwerkkarte initialisiert wurde, entweder schon beim Booten oder auch später mit Hilfe des Befehls dmesg(8). 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äte-Namen nicht kennst, sieh bitte in der Liste der unterstützten Hardware für deine Plattform nach. Du wirst eine Liste vieler bekannter Karten und ihre OpenBSD Geräte-Namen finden (wie etwa fxp), zusammen mit einer Nummer, die vom Kernel zugewiesen wird, und du hast den sogenannten Interface-Namen (wie z.B. fxp0).
Du kannst herausfinden, ob deine Netzwerkkarte(n) erkannt wurde(n), indem du das ifconfig(8) Kommando benutzt. Das folgende Kommando zeigt uns alle Netzwerk-Interfaces im System an. Diese Beispielausgabe zeigt ein physikalisches Ethernet Interface, ein fxp(4).
$ ifconfig -a
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 uns ifconfig(8) eine Menge mehr Informationen, als wir zu diesem Zeitpunkt benötigen. Natürlich sehen wir trotzdem unser Interface. Im obigen Beispiel ist die Netzwerkkarte bereits konfiguriert. Das ist offensichtlich, da auf fxp0 bereits ein IP Netzwerk konfiguriert ist, sprich die Werte "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255". Außerdem sind die UP und RUNNING Flags gesetzt.
Schlussendlich fällt auf, dass standardmäßig eine Menge mehr Interfaces aktiviert sind. Dies sind virtuelle Interfaces, die verschiedene Funktionen haben. Informationen dazu findest du auf den folgenden Manual Seiten:
Falls du deine Netzwerkkarte noch nicht konfiguriert hast, ist der erste Schritt
das Erstellen der /etc/hostname.xxx Datei, wobei der Name deiner Karte
den Platz von ,xxx' einnnimmt. Aus der Information der obigen Beispiele
würde der Name /etc/hostname.fxp0 lauten. Das Layout dieser Datei
ist simpel:
(Viel mehr Details zu dieser Datei findest du in der hostname.if(5) Manual Seite.)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
Du solltest auch den ,media type' für Ethernet angeben, wenn du z.B. den 100baseTX full-duplex 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 Voll-Duplex gestellt sind! Wenn du keine besonderen Anforderungen hast, kannst du diese media Einstellungen einfach ignorieren.)
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
Der nächste Schritt ist das Einstellen deines Standard-Gateways (default gateway). Dazu trage einfach die IP deines Gateways in die Datei /etc/mygate ein. Dies erlaubt das Aktivieren deines Gateways beim Starten. Jetzt solltest du deine Nameserver eintragen und die Datei /etc/hosts einrichten (siehe die hosts(5)-Manualseite). Für die Nameserver benötigst du eine Datei namens /etc/resolv.conf. Mehr über das Format dieser Datei findest du in der resolv.conf(5) Manual Seite. Wenn du DHCP einsetzt, solltest du 6.4 - DHCP lesen und den Einsatz von resolv.conf.tail(5) in Erwägung ziehen. Aber hier folgt nun ein Beispiel für eine normale Verwendung.
In diesem Beispiel sind deine Nameserver 125.2.3.4 und 125.2.3.5. Du gehörst ebenfalls zur Domain ,example.com'.
$ cat /etc/resolv.conf search example.com nameserver 125.2.3.4 nameserver 125.2.3.5 lookup file bind
Jetzt kannst du entweder rebooten oder das /etc/netstart Skript ausführen, indem du (als root) folgendes eingibst:
# 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 Kernel Routing Tabelle. Von hier ab sollte dein System laufen und online sein. Du kannst hier erneut mit ifconfig(8) prüfen, ob deine Interfaces richtig konfiguriert wurden. Deine Routen kannst du via netstat(1) oder route(8) überprüfen. Wenn du Probleme mit dem Routing hast, möchtest du vielleicht das -n Flag für route(8) benutzen, das die IP-Adressen ausgibt, statt einen DNS Lookup zu machen, und um den Hostnamen anzuzeigen. Hier ist ein Beispiel mit beiden Kommandos, um die Routing Tabelle anzeigen zu lassen:
$ 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 potentiell 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 hat bereits die Fähigkeit für IP Forwarding, aber dies muss 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 Reboot kannst du dies auch direkt mit sysctl(8) durchführen. Beachte aber, dass diese Änderung nach einem Reboot 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 in der Ports-Kollektion 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 (PPP/SLIP) Schnittstellen.
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 startup Hierarchie ist. Für dieses Beispiel nehmen wir an, dass der User 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" anstelle 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 diesem Beispiel /etc/hostname.dc0 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 Reboot, 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 DHCP Client dhclient(8) zu benutzen, der Teil von OpenBSD ist, editiere /etc/hostname.xl0 (wenn deine Hauptethernetkarte xl0 ist. Deine kann 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 immer so editieren, dass dein DNS nicht erneuert wird aufgrund der neuen DNS Informationen, indem du die 'request' Zeilen auskommentierst (Es gibt Beispiele in den Standardeinstellungen, aber du musst die Standardeinstellungen von dhclient überschreiben).
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
sowie domain-name-servers entfernen. 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 resolv.conf(5) hängen möchtest, die von dhclient(8) erstellt wurde. Hierfür gibt es keine Option in dhclient.conf, so musst du resolv.conf.tail benutzen, um dieses Ziel zu erreichen.
Nun sollte deine resolv.conf(5) ,lookup file bind' am Ende stehen haben.# 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. Und 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 Startup Skripte erstellen diese Datei beim Hochfahren, wenn es notwendig ist, aber wenn du 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 Einwahl-Modem herzustellen. OpenBSD bietet dafür 2 Möglichkeiten:
Sowohl ppp als auch pppd führen zwar die gleichen Funktionen auf, 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, siehe ppp(8) für weitere Info. 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 Einwahl-Verbindung 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 ISP. 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 login-Versuch 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 von "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 spezifiziert 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 Implementierungen 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 upgedatet. 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 Login-Methoden, 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ähl-Methoden 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 Ethernet-Frames zu versenden. Das ,Point to Point Protocol over ATM' (PPPoA) läuft typischerweise in ATM-Netzwerken, wie sie in UK oder Belgien gefunden werden können.
Typischerweise bedeutet das, dass du eine Verbindung mit deinem ISP über eine normale Ethernetkarte und Ethernet-basierendes DSL-Modem herstellen kannst (im Gegensatzu 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 ,bridge'-Modus hat, ist es alternativ möglich, dies 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-Implementierung ist (auf fast die gleiche Art und Weise, wie wir ppp(8) weiter oben beschrieben haben). Eine Kernel-PPPoE-Implementierung, pppoe(4), wurde in OpenBSD eingebunden.
Das ,Point to Point Tunneling Protocol' (PPTP) ist eine proprietäres Microsoft-Protokoll. Ein pptp-Client ist verfügbar, welcher mit pppd(8) kommuniziert und ist in der Lage, sich zu PPTP-basierenden Virtuellen Privaten Netzwerken (VPN) zu verbindungen, die von einigen Kabel- und xDSL-Anbietern verwendet werden. pptp selbst muss von den Packages oder Ports aus installiert werden. Weitere Anleitungen, wie man pptp einrichtet und verwendet, befinden sich in der Manualseite, welche mit dem pptp-Package installiert wird.
Normalerweise möchtest du das tun, um Routing zuzulassen oder wegen Verbindungsproblemen. Natürlich 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 broadcast Adresse 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 Implementierungen des NetBIOS Protokolles verwendet. Wiederum mit sysctl. sysctl net.inet.ip.directed-broadcast=1 aktiviert dies. 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 Kommata 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
NFS, oder Network File System (Netzwerkdateisystem), wird verwendet, um ein Dateisystem über das Netzwerk zu verwenden. Du solltest vorher noch folgende Manual Seiten 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 ist, 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 ab OpenBSD 3.2 standardmäßig abgeschaltet, so dass du die Zeile
in rc.conf.local(8) einfügen und neustarten musst.portmap=YES
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, und am besten ist, du liest die exports(5) Manual Seite. 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 Mount Point 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 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 & NFSCLIENT enthält. (Der GENERIC Kernel beinhaltet diese Optionen.) Dann solltest du die Zeile nfs_server=YES in /etc/rc.conf.local einfügen. Dies wird sowohl nfsd(8) und mountd(8) starten, wenn du rebootest. Nun kannst du fortschreiten und die Dienste selber starten. Diese Dienste müssen als root gestartet werden und du musst sicherstellen, dass portmap(8) auf deinem System läuft. Hier ein Beispiel von nfsd(8), der sowohl mit TCP als auch mit UDP bedient mittels 4 Diensten. Du solltest eine angemessenene Anzahl von NFS Serverdiensten einsetzen, um die maximale Anzahl von gleichzeitigen Clientanfragen, die du bedienen willst, zu bewerkstelligen.
# /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, was und wer gerade mountet. Dann gibt es auch noch nfsstat(8), 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, 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 mehr separaten Netzwerken. Anders als ein Router reisen Pakete durch die Bridge "unsichtbar" -- logisch erscheinen die beiden Netzwerksegmente als 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, nämlich eine als Teil der Bridge, die andere als normale, stand-alone Netzwerk-Karte. Wenn keine der Karten eine IP-Adresse hat, wird die Bridge einfach Netz-Daten verschieben, aber nicht extern administrierbar oder wartbar sein (was auch ein Feature sein kann).
Eines meiner Computer Racks 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 Transceiver auf Koax beschränkt. Eine der Maschinen in diesem Rack ist ein OpenBSD-basierender Terminal-Server, der dauerhaft eingeschaltet und auch immer mit einem High-Speed-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-Combo Karte (ep0) für den Koax-Port. fxp0 ist der Link in mein 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 genauso 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 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 Manual Seite 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, die Bridge ist symmetrisch -- Pakete fließen ja in beide Richtungen.
Das war es! Reboote, 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 wollte 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 Antwort-Daten 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 Netzwerk-Verkehr 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 und 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-2005 OpenBSD. All rights reserved. http://www.OpenBSD.org
OpenBSD 3.8 (RAMDISK_CD) #794: Sat Sep 10 15:58:32 MDT 2005
...
Der bsd.rd Installationskernel wird nun booten.
CARP ist ein Werkzeug um beim Erreichen von System Redundanz zu helfen, indem mehrere Computer ein einzelnes, virtuelles Netzwerk Interface zwischen sich errichten, so dass, falls irgendein System ausfällt, ein anderes antworten kann, und/oder einen gewissen Grad an Load Sharing zwischen Systemen erlaubt. CARP ist eine Verbesserung vom Virtual Router Redundancy Protokoll (VRRP) Standard. 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 um 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 mehrerer 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 ,hot spares' 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 Protokoll Nummer 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 Backup Host, 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 Fehler-tolerante 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 Hardware Upgrade 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 Subnet befinden und jedes Interface benötigt eine reale, statische IP Adresse zusätzlich zu einer statischen CARP IP Adresse. Ä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 durch "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, 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, net.inet.carp.arpbalance, wird für das Load Balancing verwendet. Wenn diese Funktion aktiviert ist, wird CARP ein ,source-hash' 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, net.inet.carp.log, loggt CARP Fehler. Standardmäßig deaktiviert.
Vierte, 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 Master Status (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 addiert zu advbase. advbase kann verwendet werden, um Netzwerkverkehr zu verringern oder eine längere Latenz zuzulassen, bevor ein Backup Host übernimmt; advskew lässt dir die Möglichkeit zu verwalten, welcher Host Master sein wird, ohne große ,failover´ Verzögerungen (sollte das notwendig sein).
Als nächstes setzt pass ein Passwort und vhid setzt die virtuelle Hostidentifizierungsnummer der CARP Gruppe. Du musst jeder CARP Gruppe eine einzigartige Nummer verteilen, selbst wenn (für Load Balancing Zwecke) 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 Web Server 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 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:
Achte darauf, dass die Broadcast-Adresse in der Zeile neben der vhid und dem Passwort mit angegeben wurde. Das Vergessen der Angabe dieser Adresse ist ein häufiger Grund für Fehler, da sie als Platzhalter benötigt wird.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: Hardware Unterschiede, 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 ist.
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 Web Server die Last gerade so verarbeiten kann. Was nun? CARP ist die Rettung. Es ist Zeit, Load Balancing zu versuchen. Erstelle ein neues CARP Interface und eine Gruppe auf rachael:
rachael# ifconfig carp1 create rachael# ifconfig carp1 vhid 2 advskew 100 pass bryant carpdev fxp0 \ 192.168.0.7 255.255.255.0
Auf pris werden wir ebenfalls eine neue Gruppe und Interface anlegen und dann das "preempt" sysctl setzen:
pris# ifconfig create carp1 pris# ifconfig carp1 vhid 2 pass bryant carpdev fxp0 192.168.0.7 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, was bedeutet, dass rachael Master der originalen Gruppe bleibt, aber pris wird die neue übernehmen.
Alles, was wir nun tun müssen, ist die Load Balancing sysctl auf beiden Systemen zu laden, die wir zuvor besprochen haben:
# sysctl net.inet.carp.arpbalance=1
Während diese Beispiele für einen zwei-Maschinen Cluster 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 durch rc.conf.local und das Resultat wird sein, dass dein Computer sich selbst ständig mit den pool.ntp.org Servern synchronisiert, einer Sammlung von öffentlich verfügbaren Zeit Servern. 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 manuell mittels dem Kommando date(1), semiautomatisch unter Verwendung des Kommandos rdate(8) oder durch das manuelle Einstellen der Hardwareuhr deines PCs machen.
Es gibt Anwendungsgebiete, bei denen ntp.orgs ntpd genauer ist, trotzdem geht man davon aus, dass für 95% der anderen Anwender OpenNTPD mehr als ausreichend sein wird.
Eine ausführlichere Antwort hierauf von den Entwicklern von OpenNTPD kann hier gelesen werden.
Eine andere Möglichkeit, mit deiner OpenBSD-basierenden Firewall einen Wireless Access anzubieten, ist die Verwendung einer konventionellen NIC und einem externen Bridging Access Point. 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.
Bedenke, dass du, um die Intel-basierten Karten nutzen zu können, die Firmware-Dateien beziehen musst, welche Intel nicht für freie Distribution zur Verfügung stellet, wodurch sie nicht mit OpenBSD ausgeliefert werden können. Kontaktiere Intel, um ihnen zu sagen, was du darüber denkst oder um ihnen zu sagen, welches andere Produkt du stattdessen gekauft hast.
Andere Anbieter, wie zum Beispiel Broadcom, Texas Instruments und Connexant, haben sich aktiv gegen unsere Versuche aufgelehnt, freie Treiber für ihre Produkte zu entwicklen. Wir bitten dich, ihre Wünsche zu akzeptieren, indem du ihre Produkte nicht kaufst. Realtek, Ralink, Atmel und ADMtex erstellen gute Produkte und unterstützen den Wunsch der Open-Source-Gemeinschaft nach freien Treibern und haben sich somit unsere Unterstützung und das Geschäft verdient.
[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