[OpenBSD]

[FAQ-Index] [Zum Kapitel 5 - Das System aus dem Quelltext erzeugen] [Zum Kapitel 7 - Tastatur- und Bildschirmkontrollen]

6 - Vernetzung


Inhaltsverzeichnis


6.1 - Bevor wir weitermachen

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)-Handbuchseiten.

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.

6.2 - Netzwerkkonfiguration

Normalerweise wird OpenBSD während der Installation das erste Mal konfiguriert. Es ist jedoch von Vorteil, wenn man genau versteht, was während des Vorgangs passiert und wie genau das alles funktioniert. Die gesamte Netzwerkkonfiguration wird mit einfachen Textdateien im /etc-Verzeichnis abgehandelt.

6.2.1 - Identifizieren und Einstellen deiner Netzwerkkarten

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 33200
        priority: 0
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:04:ac:dd:39:6a
        priority: 0
        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
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
        priority: 0
        groups: pflog

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 Handbuchseiten:

Andere virtuelle Schnittstellen werden bei Bedarf erzeugt, einschließlich:

Schnittstelle werden während des Startvorgangs mit Hilfe von /etc/hostname.if-Dateien konfiguriert, wobei hier if durch den vollen Namen der Schnittstelle zu ersetzen ist; jede Schnittstelle besitzt somit eine eigene Datei. Das obige Beispiel würde eine Datei namens /etc/hostname.fxp0 nutzen.

Der Aufbau dieser Datei ist simpel:

address_family address netmask broadcast [weitere Optionen]
Weitere Details über dieser Datei findest du in der Handbuchseite für hostname.if(5). In ihr finden sich vor allem Informationen für nicht ganz so einfache Konfigurationen.

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

6.2.2 - Standardgateway

Schreib die IP-Adresse deines Standardgateways in die Datei /etc/mygate. Damit wird dein Gateway während des Bootvorgangs eingestellt. Die Datei besteht nur aus einer einzigen Zeile, in der die Adresse deines Gateways steht:
10.0.0.1
Es ist möglich, hier einen symbolischen Namen zu benutzen, doch sei vorsichtig: du kannst während des Bootvorgangs nicht davon ausgehen, dass die Namensauflösung bereits funktioniert oder der Nameserver überhaupt erreichbar ist BIS das Standardgateway definiert wurde. Mit anderen Worten: Es ist besser eine IP-Adresse oder etwas in /etc/hosts fest definiertes in diese Datei zu schreiben.

6.2.3 - DNS-Auflösung

Die DNS-Auflösung wird über die Datei /etc/resolv.conf verwaltet. Hier ist ein Beispiel einer /etc/resolv.conf-Datei:
search example.com
nameserver 125.2.3.4
nameserver 125.2.3.5
lookup file bind
In diesem Fall wird der Standarddomainname auf example.com gesetzt, zwei DNS-Resolver (125.2.3.4 und 125.2.3.5) definiert und vorgegeben, dass die Datei /etc/hosts durchsucht werden soll bevor eine Anfrage an die DNS-Resolver gesendet wird.

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).

6.2.4 - Hostname

Jede Unix-Maschine hat einen Namen. Unter OpenBSD wird der Name als »Fully Qualified Domain Name« (FQDN) in einer einzelnen Zeile in der Datei /etc/myname angegeben. Falls die Maschine »puffy« heißt und sich in der Domain »example.com« befindet, würde folgende Zeile in der Datei stehen:
puffy.example.com

6.2.5 - Änderungen übernehmen

Jetzt kannst du entweder neustarten oder das Skript /etc/netstart 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 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.

6.2.6 - Routen überprüfen

Deine Routen kannst du mit netstat(1) oder route(8) überprüfen. Wenn du Probleme mit dem Routing hast, möchtest du vielleicht die Option -n mit route(8) benutzen, das die IP-Adressen ausgibt, statt eine DNS-Auflösung durchzuführen, und um den Hostnamen anzuzeigen. Hier ist ein Beispiel mit beiden Kommandos, um die Routingtabelle 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

6.2.2 - Deinen OpenBSD-Rechner als Gateway einrichten

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 auf beiden Seiten. Dies wird oft mit statischen Routeneinträgen gemacht, doch fortgeschrittenere Netzwerke können von der reichen Sammlung an Routing-Dämonen Gebrauch machen, die Teil von OpenBSD sind, um Routen zu anderen Systemen zu legen. Wir reden über OpenBGPD, ospfd(8), ospf6d(8), ldpd(8) und ripd(8). Zusätzlich beinhaltet die Portierungs-Kollektion Software wie bird, igmpproxy und quagga. OpenBSD unterstützt verschiedene T1-, HSSI-, ATM-, FDDI- und serielle (PPP/SLIP)-Schnittstellen, und natürlich viele Etherne-Geräte (einscließlich 10 Gb).

6.2.8 - Einrichten von Aliases auf deiner Netzwerkkarte

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 NONE 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
(Und wieder ist ein Neustart empfehlenswert um sicherzustellen, dass alles wie erwartet konfiguriert wird!)

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

6.3 - Wie kann ich mit OpenBSD filtern und eine Firewall aufsetzen?

Packet Filter (ab hier nur noch als PF bezeichnet) ist OpenBSDs System zum Filtern von IP-Verkehr und zum Ausführen von Network Address Translation. PF ist außerdem in der Lage, IP-Verkehr zu normalisieren und zu konditionieren, eine Priorisierung von Paketen durchzuführen und eine mächtige und flexible Firewall zu erzeugen. Er wird im PF-Benutzerhandbuch beschrieben.

6.4 - Dynamic-Host-Configuration-Protokoll (DHCP)

Das Dynamic-Host-Configuration-Protokoll ist ein Weg, um die Netzwerkkarten »automatisch« zu konfigurieren. OpenBSD kann als DHCP-Server (der andere Maschine konfiguriert), als ein DHCP-Client (der von einer anderen Maschine konfiguriert wird) und in einigen Fällen auch als beides eingesetzt werden.

6.4.1 - DHCP-Client

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 host-name 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
Nun sollte deine resolv.conf(5) »lookup file bind« am Ende stehen haben.
nameserver 192.168.1.1
nameserver 192.168.1.2
lookup file bind

6.4.2 - DHCP-Server

Wenn du OpenBSD als DHCP-Server dhcpd(8) einsetzen willst, editiere /etc/rc.conf.local so, dass sie die Zeile dhcpd_flags="" enthält. Zum Beispiel:

     # echo 'dhcpd_flags=""' >>/etc/rc.conf.local
Dies führt zum Start des dhcpd, der sich im Folgenden auf alle NICs aufschalten wird, die gültige Konfigurationseinträge in /etc/dhcpd.conf besitzen. Du kannst stattdessen auch einzelne Schnittstellen spezifizieren, indem du sie explizit anführst, wie zum Beispiel dhcpd_flags="xl1 xl2 xl3".

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.

Willst du den dhcpd(8) von der Befehlszeile aus starten, nachdem du /etc/dhcpd.conf editiert hast, so versuche:

    # /etc/rc.d/dhcpd start
    dhcpd(ok)
Wurden während des Starts fatale Konfigurationsfehler gefunden, so wird er sich beenden und dich wissen lassen, dass sein Start fehlgeschlagen ist ("dhcpd(failed)") und in /var/log/messages den genauen Grund dafür aufzeigen.

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.

6.5 - PPP

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.

Erste Einstellungen - für PPP(8)

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.

PPP(8) verwenden

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 Handbuchseite, enthalten hilfreiche Informationen.

ppp(8)-Extras

In einigen Situationen möchtest 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:

ppp(8)-Varianten

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:

PPPoE/PPPoA

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.

PPTP

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 Pakete oder Portierungen installiert werden. Weitere Anleitungen, wie man pptp einrichtet und verwendet, befinden sich in der Handbuchseite, die mit dem pptp-Paket installiert wird.

6.6 - Netzwerkparameter tunen

Eines der Ziele von OpenBSD ist, dass das System für einen Großteil unserer Nutzer einfach läuft. An Einstellungen rumspielen, deren Funktion du nicht verstehst, wird das System eher beeinträchtigen und nicht dessen Geschwindigkeit erhöhen. Fang immer mit den Standardwerten an und ändere nur Einstellungen, die tatsächlich ein Problem darstellen.

SEHR WENIGE Personen werden ihre Netzwerk-Parameter anpassen müssen!

6.6.1 - Der Kernel soll bestimmte Ports nicht dynamisch allozieren

Von sysctl(8):

Um die Liste der reservierten TCP-Ports zu setzen, die vom Kernel nicht
automatisch alloziert werden sollen:

      # sysctl net.inet.tcp.baddynamic=749,750,751,760,761,871

Dies kann benutzt werden, um Dämonen vom stehlen eines speziellen Ports
abzuhalten, den ein anderes Programm benötigt, um funktionieren zu können.
Listeneinträge können durch Kommata or Leerzeichen separiert werden.

Es ist ebenfalls möglich, Ports zu der aktuellen hinzuzufügen, oder aus ihr zu
entfernen:

      # sysctl net.inet.tcp.baddynamic=+748
      # sysctl net.inet.tcp.baddynamic=-871

6.7 - Einfache NFS-Anleitung

NFS, oder Network File System (Netzwerkdateisystem), wird verwendet, um ein Dateisystem über das Netzwerk zu verwenden. Du solltest vorher noch folgende Handbuchseiten 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.

Einen NFS-Server einrichten

Folgende Dienste müssen auf dem Server aktiviert sein und laufen:

Unter OpenBSD sind diese standardmäßig deaktiviert. Füge die folgenden Zeilen deiner rc.conf.local(8) hinzu, um sie zu aktivieren:

portmap_flags=""
mountd_flags=""
nfsd_flags="-tun 4"

Im nächsten Schritt wird die Liste der Dateisysteme konfiguriert, die den Clients für Mountoperationen bereitgestellt werden sollen.

In diesem Beispiel haben wir einen Server mit der IP-Adresse 10.0.0.1. Der Server wird NFS nur den Clients anbieten, die sich im gleichen Subnet befinden. Dies wird alles in der /etc/exports-Datei konfiguriert. In dieser Datei werden für alle Dateisysteme, auf die über NFS zugegriffen werden kann, auch die jeweiligen Zugriffsrechte aufgeführt. Es gibt sehr viele Optionen, die du in /etc/exports verwenden kannst; es wäre daher am besten, wenn du die exports(5)-Handbuchseite lesen würdest. Für dieses Beispiel haben wir eine exports-Datei angelegt, die wie folgt aussieht:

#
# 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

Das heißt, dass das lokale Dateisystem /work via NFS zugänglich gemacht wird. Die -alldirs-Option bedeutet, dass Clients jedes Verzeichnis unter dem /work-Mountpunkt (und auch /work selbst) mounten können. Wenn beispielsweise ein Verzeichnis namens /work/monday vorhanden ist, können Clients /work mounten (und damit auf alle folgenden Dateien/Verzeichnisse zugreifen können) oder /work/monday mounten und nur auf Dateien/Verzeichnisse zugreifen können, die sich dort befinden. Die -ro-Option gibt an, 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.

Ein weiterer wichtiger Sicherheitshinweis: Füge nicht einfach ein Dateisystem in /etc/exports ein, ohne eine Liste zulässiger Hosts (oder einen einzelnen Host) anzugeben. Ohne Angabe einer Liste für erlaubte Zugriffe kann jeder, der den Server ansprechen kann, deine über NFS bereitgestellten Verzeichnisse mounten.

Nun kannst du die Serverdienste starten. Entweder startest du neu (nachdem du sie mit den oben angegebenen Schritten aktiviert hast) oder du startest sie manuell.

# /etc/rc.d/portmap start
# /etc/rc.d/mountd start
# /etc/rc.d/nfsd start

Die nfsd_flags aktivieren Verbindungen über TCP (-t) und UDP (-u) und ermöglichen vier gleichzeitige Instanzen (-n) des nfsd. Du solltest durch Anpassung der nfsd_flags Zeile in rc.conf.local eine Anpassung der Anzahl der NFS-Server-Instanzen vornehmen, entsprechend der maximalen Anzahl der gleichzeitig zu bedienenden Clients.

Nun kannst du die exportierten Dateisysteme von den Clients (oder dem Client) aus mounten.

Bedenke: Wenn du Änderungen an /etc/exports gemacht hast während NFS bereits lief, musst du mountd über diese Änderungen informieren! Sende einfach ein HUP an mountd und die Änderungen werden übernommen.

# /etc/rc.d/mountd reload

NFS-Dateisysteme mounten

NFS-Dateisysteme können vom Client gemountet werden, ohne dass zusätzliche Dienste oder Daemons gestartet werden müssen; sie können wie jedes andere Dateisystem gemountet werden.

NFS-Dateisysteme sollten mit mount(8) gemountet werden - genauer gesagt mit mount_nfs(8). Um ein Dateisystem namens /work des Hosts 10.0.0.1 auf das lokale Dateisystem /mnt zu mounten, führe Folgendes aus (beachte, dass du nicht auf eine IP-Adresse angewiesen bist; mount löst auch Hostnamen auf):

# mount -t nfs 10.0.0.1:/work /mnt

Damit das Dateisystem während des Bootvorgangs gemountet wird, füge eine Zeile wie diese in /etc/fstab ein:

10.0.0.1:/work /mnt nfs rw 0 0

Es ist wichtig, dass du 0 0 am Ende der Zeile angibst, damit dein Computer während des Bootvorgangs nicht versucht, fsck für das NFS-Dateisystem aufzurufen. Die anderen Standardsicherheitsoptionen wie noexec, nodev und nosuid sollten je nach Anwendungszweck ebenfalls gesetzt werden. Ein Beispiel:

10.0.0.1:/work /mnt nfs rw,nodev,nosuid 0 0

Auf diese Weise können keine Devices oder setuid-Programme auf dem NFS-Server die Sicherheitsmaßnahmen des NFS-Clients unterwandern. Wenn du keine auf dem gemounteten Dateisystem befindlichen Programme auf dem NFS-Client starten willst, füge dieser Liste noexec hinzu.

Wenn mit Rootrechten auf einen NFS-Mount zugegriffen wird, setzt der Server automatisch die Berechtigung auf Benutzername »nobody« und Gruppe »nobody«. Es ist sehr wichtig, diese Eigenschaft zu berücksichtigen, wenn Dateiberechtigungen gesetzt werden. Die Berechtigungen dieser Datei soll als Beispiel dienen:

-rw-------    1 root     wheel           0 Dec 31 03:00 _daily.B20143

Wenn diese Datei sich auf einem NFS-Share befindet und der Benutzer root versucht, über einen NFS-Client auf sie zuzugreifen, wird ihm der Zugriff verwehrt bleiben. Dies liegt daran, dass der Server die Kennung des Benutzers »nobody« verwendet, wenn root auf die Datei zugreifen möchte. Da der Benutzer nobody aber keine Zugriffsberechtigung auf diese Datei hat, bleibt sie ihm verwehrt.

Der Benutzer und die Gruppe, die bei Rootzugriffen genutzt werden, können über die exports(5)-Datei auf dem NFS-Server eingestellt werden.

NFS-Status überprüfen

Um sicherzustellen, dass der NFS-Betrieb reibungslos verlaufen kann, überprüfe, ob alle Daemons über RPC erfolgreich registriert wurden. Verwende hier für 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

Diese Ausgabe zeigt, dass der Client 10.0.0.37 den vom Server 10.0.0.1 bereitgestellten Export /work gemountet hat.

6.9 - Aufsetzen einer Bridge mit OpenBSD

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).

Ein einfaches Beispiel einer Bridgeanwendung

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-Adresse oder ähnliche Information muss für dieses Interface spezifiziert werden. Die Optionen, die von der ep-Karte akzeptiert werden, sind detailliert in der Handbuchseite aufgeführt.

Jetzt müssen wir die Bridge aufsetzen. Bridges werden durch die Existenz einer Datei, die so ähnlich heißt wie hostname.bridge0, initialisiert. Hier ist ein Beispiel für meine Situation hier:

$ cat /etc/hostname.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.

Eine als DHCP-Server fungierende Brücke

Angenommen, wir verfügen über ein kleines System, das vier vr(4) Schnittstellen besitzt, vr0 bis vr3. Wir möchten vr1, vr2 und vr3 mit einer Brücke verbinden, und vr0 als Netzanbindung (z. B. für ein Kabelmodem) auslassen. Ebenso möchten wir IP-Adressen durch DHCP über die verbrückten Schnittstellen anbieten. Als DHCP-Server und Router für die Netzanbindung muss die Maschine über eine IP-Adresse in dem verbrückten Netzwerk verfügen (im Gegensatz zum vorigen Beispiel, in welchem die überbrückende Maschine im Netzwerk nicht sichtbar war).

Es ist nicht möglich, einer bridge(4)-Schnittstelle eine IP-Adresse direkt zuzuweisen. Die IP-Adresse sollte einem der teilnehmenden Schnittstellen hinzugefügt werden, jedoch können wir keine physische Schnittstelle benutzen, da keine aktive Anbindung an das Netz vorhanden sein könnte, in welchem Falle die Adresse nicht erreichbar wäre. Glücklicherweise, beginnend mit OpenBSD 4.7, gibt es einen Treiber für eine virtuelle Ethernet-Schnittstelle, nämlich vether(4), der für diese Zweck genutzt werden kann. Wir fügen ihn der Brücke hinzu, weisen ihm die IP-Adresse zu, und lassen dhcpd(8) dort auf Anfragen warten.

Bemerkungen:

Als erstes kennzeichne vr1, vr2 and vr3 als aktiv:

$ cat /etc/hostname.vr1
up
$ cat /etc/hostname.vr2
up
$ cat /etc/hostname.vr3
up

Erzeuge dann die Konfiguration für vether0:

$ cat /etc/hostname.vether0
inet 192.168.1.1 255.255.255.0 192.168.1.255
up

Wir konfigurieren die Brückenschnittstelle, sodass sie alle oben aufgeführten Schnittstellen enthält:

$ cat /etc/hostname.bridge0
add vether0
add vr1
add vr2
add vr3
up

Und schlussendlich lassen wir dhcpd(8) auf der vether0-Schnittstelle lauschen:

$ grep ^dhcpd_flags= /etc/rc.conf.local
dhcpd_flags="vether0"

Starte den Computer neu -- und voilà!

Filtern auf der Bridge

Während es sicher auch eine Menge Anwendungen für eine solch einfache Bridge gibt, ist es doch wahrscheinlich, dass du etwas mit den ganzen Paketen TUN willst, während sie durch deine Bridge laufen. Wie zu erwarten, kann man Packet Filter dazu benutzen, den Traffic einzuschränken, der durch deine Bridge fließt.

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 ifconfig(8)-Kommando, mit dem man eine Bridge auch nach dem Booten erzeugen kann.

Tipps zum Bridging

6.10 - Wie boote ich mit PXE? (i386, amd64)

Das »Preboot Execution Environment« (oder kurz PXE) ist ein Weg, um einen Computer statt von Festplatte, Diskette oder CD-ROM vom Netzwerk zu booten. Diese Technologie wurde zuerst von Intel entwickelt, doch wird nun von den meisten führenden Netzwerkkarten- und Computerherstellern unterstützt. Bedenke, dass es viele verschiedene Netzwerkbootprotokolle gibt: PXE ist relativ neu. Traditionellerweise wird das PXE-Booting unter Verwendung von ROMs auf dem NIC oder dem Mainboard ausgeführt, doch sind ebenfalls Bootdisketten von etlichen Quellen verfügbar, die ebenfalls das PXE-Booting zulassen. Viele ROMs auf älteren NICs unterstützen zwar das Booten vom Netzwerk, allerdings NICHT PXE; OpenBSD/i386 oder am64 können mit diesen zurzeit nicht über das Netzwerk gebootet werden.

Wie funktioniert das PXE-Booting?

Zuerst sollte die Funktionsweise des OpenBSD-Bootprozesses auf i386- und am64-Plattformen verstanden werden. Auf den Bootprozess folgend sendet die PXE-fähige NIC eine DHCP-Anfrage über das Netzwerk. Der DHCP-Server wird dem Adapter eine IP zuweisen und gibt ihm den Namen einer Datei, die von einem tftp(1)-Server bezogen und ausgeführt werden muss. Diese Datei leitet dann den Rest des Bootprozesses ein. Für OpenBSD ist es die pxeboot-Datei, die den Platz der standardmäßigen boot(8)-Datei einnimmt. pxeboot(8) ist dann in der Lage, einen Kernel wie zum Beispiel bsd oder bsd.rd vom gleichen tftp(1)-Server zu laden und auszuführen.

Wie mache ich das?

Der erste und offensichtlichste Schritt ist, dass du einen PXE-bootfähigen Computer oder Netzwerkadapter haben musst. Einige Dokumente weisen darauf hin, dass alle modernen NICs und Computer PXE-Unterstützung hätten, aber das ist einfach nicht wahr - viele Niedrigpreissysteme liefern keine PXE-ROMs mit oder verwenden ein älteres Netzwerkbootprotokoll. Du brauchst außerdem einen ordentlich konfigurierten DHCP- und TFTP-Server.

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. Normalerweise geschieht dies durch das Hinzufügen der Zeile "tftpd_flags=/tftpboot" zu deiner /etc/rc.conf.local-Datei. 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:

Denke daran, dass /etc/boot.conf nur gebraucht wird, wenn der Kernel, den du booten möchtest, nicht bsd heißt oder andere pxeboot-Standardwerte nicht so sind, wie du sie haben möchtest (zum Beispiel, wenn du eine serielle Konsole wünschst). Du kannst deinen tftpd(8)-Server mit einem tftp(1)-Client testen, indem du sicherstellst, dass du die benötigten Dateien herunterladen kannst.

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 3.19
    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 3.19
    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-2013 OpenBSD.  All rights reserved.  http://www.OpenBSD.org

    OpenBSD 5.4 (RAMDISK_CD) #34: Tue Jul 30 12:20:01 MDT 2013
      ...
Der bsd.rd-Installationskernel wird nun booten.

Kann ich außer bsd.rd auch andere OpenBSD Kernel via PXE booten?

Ja, obwohl mit den Programmen, die zurzeit in OpenBSD enthalten sind, PXE-Booting primär für die Installation des OS gedacht ist.

6.11 - Das Common-Address-Redundancy-Protokoll (CARP)

6.11.1 - Was ist CARP und wie funktioniert es?

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 bekundet der Master seine Operation auf der IP-Protokollnummer 112. Wenn der Master offline geht, beginnen die anderen Systeme in der CARP-Gruppe mit dem bekunden. Der Host, der in der Lage ist am häufigsten zu bekunden, 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.

6.11.2 - Konfiguration

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, net.inet.carp.log, logged CARP Zustandsänderungen, schlechte Pakete und andere Fehler. Setze diese Variable, um die genannten Meldungen standardmäßig zu loggen.

Die dritte 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 bekunden) 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
Achte darauf, dass die Broadcastadresse 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.

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 aufsetzt. 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 Bekundungen 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

6.11.3 - Lastverteilung

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.

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.

6.11.4 - Weitere Informationen zu CARP

6.12 - OpenNTPD verwenden

Genaue Zeit ist wichtig für viele Computerapplikationen. Trotzdem mussten viele Leute feststellen, dass ihre $5-Uhr eine genauere Uhrzeit halten kann als ihr $2000-Computer. Zusätzlich zum Wissen, welche Uhrzeit gerade ist, ist es ebenfalls häufig wichtig, Computer zu synchronisieren, sodass sie alle mit der gleichen Uhrzeit übereinstimmen. Für eine gewisse Zeit hat ntp.org ein Applikation für das Network-Time-Protokoll (RFC1305, RFC2030) entwickelt, verfügbar als Portierung, die verwendet werden kann, um die Uhren auf den Computern über das Internet zu synchronisieren. Trotzdem ist dies ein nicht triviales Programm zum Einrichten, schwerer Code zum Überprüfen und hat eine große Speicheranforderung. Kurz gesagt spielt es eine wichtige Rolle für einige Leute, aber es ist weit entfernt von einer Lösung für jedermann.

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.

6.12.1 - »Aber OpenNTPD ist nicht so genau wie der ntp.org-Daemon!«

Das mag wahr sein. Es ist nicht OpenNTPDs Entwurfssziel. Es ist vorgesehen, dass es frei, simpel, zuverlässig und sicher ist. Wenn du wirklich Mikrosekundenpräzision mehr als die Vorteile von OpenNTPD brauchst, tu dir keinen Zwang an und verwende ntp.orgs ntpd, da er weiterhin als Portierung und Paket verfügbar sein wird. Es existieren weder ein Plan noch das Verlangen, OpenNTPD mit allen vorstellbaren Funktionen vollzustopfen.

6.12.2 - »Jemand hat behauptet, dass OpenNTPD schädlich ist!«

Einige Leute haben die Ziele von OpenNTPD nicht verstanden: ein einfacher, sicherer und einfach zu verwaltender Weg, um die Uhr deines Computers genau zu halten. Wenn genaue Zeit wichtig ist, haben einige Benutzer berichtet, dass die Ergebnisse von OpenNTPD besser sind als die von ntp.orgs ntpd. Wenn Sicherheit wichtig ist, ist OpenNTPDs Code sehr viel besser lesbar (und daher kontrollierbar) und wurde unter Verwendung von OpenBSD-Funktionsaufrufen wie strlcpy statt portableren Funktionen wie strcpy entwickelt und wurde von Anfang an sicher geschrieben und nicht »später sicher gemacht«. Wenn es wertvoll ist, dass so viele Leute wie möglich Zeitsynchronisierung verwenden, macht es OpenNTPD einer großen Anzahl Leute einfacher, diese zu nutzen. Wenn das »schädlich« ist, stimmen wir dem voll und ganz zu.

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.

6.12.3 - Warum können meine anderen Systeme nicht ihre Uhrzeit mit OpenNTPD abgleichen?

Standardmäßig hört ntpd(8) auf keiner Adresse. Damit du OpenNTPD also als Server verwenden kannst, musst du die Zeile »#listen on *« in /etc/ntpd.conf auskommentieren und den ntpd(8)-Daemon neustarten. Selbstverständlich kannst du auch eine bestimmte IP-Adresse angeben, so dass er nicht auf allen verfügbaren Adressen und Interfaces hört: ersetze »*« mit der gewünschten Adresse.

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.

6.13 - Welche Möglichkeiten stehen mir für Drahtlosnetzwerke zur Verfügung?

OpenBSD hat Unterstützung für eine Vielzahl an Wireless-Chipsätzen: (AP) weist darauf hin, dass diese Karte als Accesspoint eingesetzt werden kann.
(NFF) weist darauf hin, dass der Chip eine nicht freie Firmware benötigt, die nicht in OpenBSD eingebunden werden kann.

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 Handbuchseiten für präzise Details). Einige dieser Karten können jedoch 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 Handbuchseiten. 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.

Konfiguration deines Drahtlos-Adapters

Deine Drahtlos-Adapter können mit Hilfe einer hostname.if(5)-Datei konfiguriert werden, wie andere Netzwerkadapter auch, jedoch sind sie, da sie mehr Optionen haben, oft ein wenig komplizierter.

Beispiele einer »hostname«-Datei für Drahtlos wären, z. .:

nwid puffyuberalles
wpakey puffyguffy
dhcp
oder
inet 10.0.0.157 255.255.255.0
nwid puffyuberalles
wpakey puffyguffy
Beachte, dass das dhcp NACH den anderen Konfigurationszeilen kommen sollte, da der Netzwerkadapter keine Anfrage via DHCP stellen kann, solange er nicht konfiguriert ist.

Bringe deine Drahtlos-Adapter unter einen Schirm - via trunk(4)

Viele Laptops haben sowohl einen Drahtlos- als auch eine fest-verdrahteten Adapter. Manchmal wirst du direkt mit deinem Hochgeschwindigkeitsnetzwerk verbunden sein, und dessen volle Geschwindigkeit in Anspruch nehmen wollen, zu anderen Zeiten jedoch Drahtlos funken wollen Vielleicht willst du nicht mit jedem Ortswechsel deine Maschine neu konfigurieren wollen.

Du KÖNNTEST beide Schnittstellen via DHCP einrichten, aber dann müsstest du darauf warten, das während des Startvorgangs das Konfigurations-Zeitlimit der gerade unbenutzten Schnittstellen abläuft, und außerdem wären die Umstände ein wenig verwirrend wenn beide Ressourcen verfügbar wären, und das hin- und herschalten zwischen den Ressourcen wäre ein wenig lästig.

Die Nutzung eines trunk(4)-Geräts mag dein Leben erleichtern. trunk(4)s sind virtuelle Schnittstellen, die aus einem oder mehreren Netzwerkschnittstellen bestehen. In diesem Fall nutzen wir einen Laptop mit einer verdrahteten bge0 und einer drahtlosen iwn0 Schnittstelle. Mit Hilfe dieser zwei Schnittstellen werden wir uns eine Schnittstelle bauen, trunk0 genannt, und dann mittels DHCP eine IP-Adresse für diese virtuelle Schnittstelle anfordern. Wir wollen die verdrahtete Schnittstelle nutzen, falls sie verfügbar ist, anderenfalls die drahtlose Schnittstelle.

Um dies zu erreichen konfigurieren wir zuerst zwei physische Ports. Da wir sie einzig einer kombinierten Schnittstelle trunk0 zuweisen, machen wir nicht viel mehr mit der verdrahteten Schnittstelle, als sie zu aktivieren:

# cat /etc/hostname.bge0
up
Die drahtlose Schnittstelle braucht jedoch ein wenig mehr Konfiguration. Es muss sich in unser drahtloses, WPA-gesichertes Netzwerk einhängen:
# cat /etc/hostname.iwn0 nwid puffynet wpakey mysecretkey up
Nun wird unsere trunk-Schnittstelle wie folgt definiert:
# cat /etc/hostname.trunk0 trunkproto failover trunkport bge0 trunkport iwn0 dhcp
Der trunk wurde im »failover«-Modus konfiguriert, sodass jede Schnittstelle genutzt werden kann, jedoch bge0 präferiert wird, sollten beide verfügbar sein, das es als Erstes zu der trunk Schnittstelle hinzugefügt wurde.

6.14 - Wie kann ich »equal-cost multipath routing« durchführen?

»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, kann 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.

/etc/hostname.fxp1
!route add -mpath default 10.130.128.1
/etc/hostname.fxp2
!route add -mpath default 10.132.0.1

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] www@openbsd.org
$OpenBSD: faq6.html,v 1.146 2013/12/06 20:52:46 ajacoutot Exp $