[OpenBSD]

6.0 - Netzwerken

6.0.1 - Bevor wir weiter gehen

Für den Rest dieses Dokumentes sei gesagt, daß es hilfreich ist, das Kapitel des FAQ Kernelkonfiguration und Einstellungen gelesen und zumindest teilweise verstanden zu haben, weiters helfen die Manual Seiten ifconfig(8) und netstat(1).

Wenn du ein Netzwerkadministrator bist und Routingprotokolle aufsetzt und dein OpenBSD Rechner dein Router wird, dann solltest du dein Wissen über IP Netzwerken mit Understanding IP addressing vertiefen. Dies ist ein exzellentes Dokument. "Understanding IP addressing" beinhaltet grundlegendes Wissen, auf dem man beim IP Netzwerken aufbauen kann, insbesondere wenn man mit mehreren Netzwerken arbeitet oder für sie verantwortlich ist.

Wenn du mit Anwendungen wie Web-, FTP- oder Mailserver 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 sich arbeiten sollten. Die RFCs definieren mehrere (tausend) Standards für Protokolle im Internet und wie sie arbeiten sollten. 

6.1 - Erste Netzwerkeinstellungen

6.1.1 - Identifzieren und Einstellen deiner Netzwerkkarten

Um beginnen zu können, mußt 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 beim Booten oder später mittel mit dem Befehl dmesg(8). Weiters kannst du mit dem Befehl ifconfig(8) deine Karte überprüfen. Zum Beispiel ist hier die Ausgabe in dmesg für eine ne2k Netzwerkkarte, die den Gerätenamen ne hat. Solltest du nicht den deinen Gerätenamen kennen, dann findest du hier eine Liste gebräuchlicher Karten und deren Gerätenamen.

Nochmals: Du kannst mit ifconfig(8) überprüfen, welche Karten identifiziert wurden. Hier ist die Ausgabe einer  ne2k Karte.

Wie du sehen kannst, gibt ifconfig(8) reichlich Information aus, die wir benötigen. Aber dies erlaubt uns auch, unsere Karte zu identifizieren. Im obigen Beispiel wurde die Netzwerkkarte bereits konfiguriert. Du kannst dies anhand der Werte "inet 10.0.0.38 netmask 0xffffff00 broadcast 10.0.0.255" sehen und daß die UP und RUNNING Kennzeichen eingeschalten sind. Du wirst auch viele weitere Schnittstellen bemerken. Hier eine Liste, die vorhanden sein werden.

Der 1. Schritt zur Konfiguration deiner Netzwerkkarte ist das Erstellen der /etc/hostname.${IF} Datei. Wobei der Name deiner Karte den Platz von ${IF} einnehmen sollte. Aus der Information der obigen Beispiele würde der Name /etc/hostname.ne3 lauten. Das Layout dieser Datei sollte so aussehen (siehe für weitere Information die hostname.if(5) Manual Seite): Für das obige Beispiel würde eine korrekte Datei so aussehen:

Der nächste Schritt ist das Einstellen deines Gateways. Dazu trag 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. 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. Für den Normalgebrauch ist hier ein Beispiel, in dem deine Nameserver 125.2.3.4 und 125.2.3.5 sind. Du gehörst zur Domäne "deinedomaene.com".

Jetzt kannst du entweder rebooten oder das /etc/netstart Script ausführen, indem du (als root) folgendes eingibst:

Die Fehlermeldung betreffen das loopback Interface. Daher kann dies ignoriert werden. Ab jetzt sollte dein System funktionieren. Du kannst wiederum mit ifconfig(8) überprüfen, ob deine Netzwerkkarte aktiv ist. Die Routingtabelle überprüfe mit netstat(1) oder route(8). Hier ist ein Beispiel für beides.

6.1.2 - Einrichten deines OpenBSD Rechners als Gateway

Dies ist nur die grundlegende Information, um deinen OpenBSD Rechner als Gateway (auch Router genannt) einzurichten. Wenn du OpenBSD als Router im Internet verwenden willst, solltest du auch die IP Filter unten folgenden 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 muß erst eingeschalten werden. Du solltest dies mit sysctl(8) tun. Um diese Änderung permanent einzutragen, mußt du die Datei /etc/sysctl.conf editieren. Füge einfach folgende Zeile in diese Konfigurationsdatei ein.

Ohne Reboot kannst du dies auch direkt mit sysctl(8) durchführen. Beachte aber, daß diese Änderung nach einem Reboot weg ist und der folgende Befehl als root ausgeführt werden muß.

Nun modifiziere die Routen der anderen Hosts. Es gibt viele verschiedene Möglichkeiten, OpenBSD als Router einzusetzen, z. B. mittels Software wie routed(8), gated, mrtd und zebra. OpenBSD hat Unterstützung in der ports Kollektion sowohl für gated als auch mrtd. OpenBSD unterstützt mehrere T1, HSSI, ATM, FDDI, Ethernet und serielle (PPP/SLIP) Schnittstellen.

6.1.3 - Einrichten von Aliases auf deiner Netzwerkkarte.

Beginnend mit OpenBSD 2.8 wird /etc/ifaliases nicht mehr benutzt!

OpenBSD hat einen einfachen Mechanismus, um IP Aliases auf einer Schnittstelle einzurichten. Dazu mußt du nur die Datei /etc/hostname.<if> editieren. Diese Datei wird beim Starten vom /etc/rc Script gelesen, welches Teil der rc startup Hierarchie ist. Für das Beispiel nehmen wir an, daß der Benutzer eine Schnittstelle dc0 hat und sich im Netzwerk 192.168.0.0 befindet. Weitere wichtige Informationen:

Bei OpenBSD verwendet man nur den Adapternamen. Es gibt keine Unterschiede zwischen dem ersten und dem zweiten Alias. Daher muß 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 nur "ifconfig int" auf der Befehlszeile. Du kannst Alias 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 Alias zur Netzwerkkarte dc0 hinzugefügt, die als 192.168.0.2 mit Netzmaske 255.255.255.0 konfiguriert wurde.

Wenn du einmal diese Datei erstellt hast, benötigst du einen Reboot, um die Änderung automatisch durchführen. Du kannst aber auch die Aliases manuell mit ifconfig(8) hochbringen. Für das erste Alias:

Um die Aliases zu sehen:

6.2 - IP Filter

Das IP Filter Packet wurde geschaffen, um zwei Aufgaben zu erfüllen: Berechtigungen von packet level forwarding ipf(8) und das Umlegen von hosts/subnets auf einen externen Adressbereich ipnat(8). Die Konfigurationsdateien dieser zwei Dienste sind /etc/ipf.rules und /etc/ipnat.rules.

Du mußt /etc/rc.conf editieren, um sie beim Starten zu aktivieren. Und net.inet.ip.forwarding=1 muß in deiner /etc/sysctl.conf gesetzt sein (oder dein Kernel muß mit IPFORWARDING oder GATEWAY Option AN kompiliert sein.). Du brauchst auch einen Kernel mit den Optionen IPFILTER und IPFILTER_LOG (GENERIC Kernel haben diese Optionen).

Wenn du IP Filter im Kernel einkompiliert hast, aber nicht in /etc/rc.conf eingeschalten hast, kannst du es einfach aktivieren.

Die -E Option bei ipf aktiviert ('enables') IP Filter. -Fa löscht alle Regeln, die du noch hast. -f /etc/ipf.rules lädt die Regeln aus der Datei /etc/ipf.rules.

Wenn du /etc/ipf.rules nach dem Laden von ipf änderst, kannst du deine Regeln sehr leicht neu laden!

Gleiches für ipnat... Um ipmon im Debugmodus zu starten:

Dieses Dokument wird einige grundlegende ipf und ipnat Konfigurationen im Folgenden darstellen. In /usr/share/ipf/ findest du ein paar nette Beispiele für ipnat und ipf. Wir empfehlen dir, jenes, daß dir am ehesten paßt, auszuwählen und auf deine Bedürfnisse abzuändern. Du kannst weitere Informationen im IP Filter Mailinglistenarchiv, auf der IP Filter Website und noch im IP Filter HOWTO finden.

IPF

Um ipf beim Booten zu aktivieren, mußt du /etc/rc.conf modifzieren: IPFILTER=YES. IP Filter (ipf) wird von /etc/ipf.rules gesteuert, welche beim Booten gelesen wird. Für weitere Erklärungen siehe ipf(5). In den folgenden Beispielen wird fxp0 das externe Netzwerkinterface zum Internet sein. Dies wird für dich anders sein, wenn du einen anderen Ethernetadapter in deinem Computer hast. Diese Regeln nehmen eine Standleitungsverbindung an, so wie sie bei einem Webserver zu erwarten ist.

IP Filter Regeln werden sequentiell von Anfang bis Ende abgearbeitet. Es mag hilfreich sein, sich vorzustellen, daß jedes einzelne Paket zunächst jede Regel erfüllen muß, bevor es sein Ziel erreicht.

Z. B. erlauben die Standardregeln, daß alle Pakete rein und raus dürfen:

Nun angenommen, wir wollen keine ankommenden Verbindungen zu Port 3306 (mysql) zulassen, weil die Datenbank nur mit dem localhost verbunden sein soll. Die Regeln würden so aussehen: Dies bedeutet, daß alle ankommenden Pakete von überall nach überall mit Zielport 3306 auf dem Interface fxp0 blockiert werden. Genauergesagt wird ein Paket für Port 3306 auf dem Adapter fxp0 zunächst die erste "pass in" Regeln passieren und dann von der "block in port = 3306" Regel blockiert werden. Wenn du die Anordnung unserer ankommenden Regel vertauschst (NB: die Reihenfolge ist wichtig): Pakete mit Zielport 3306 würden passieren, weil die letzte Regel alle Pakete passieren läßt. Dies muß man immer im Hinterkopf behalten, wenn man Paketfilterregeln schreibt: Die letzte passende Regel gewinnt.

Natürlich gibt es Ausnahmen zu jeder Regel. Die quick Option läßt jedes Paket bei der ersten passenden Regel fallen. Bei obigem "falschen" Beispiel mit quick zur "block in" Regel:

Ein Paket mit Ziel für unseren Rechner auf Port 3306 wird die "block in quick" Regel treffen und sofort fallengelassen. Alle Pakete für die anderen Ports werden keine passende Regel finden bis sie auf unsere "pass in" Regel treffen, die alle Pakete passieren läßt.

Standardmäßiges Ablehnen

Die sicherste Paketfilterregel ist standardmäßiges Ablehnen. Jeder Datenverkehr, der nicht ausdrücklich erlaubt ist, wird abgelehnt. Diese Richtlinie ist bei weitem sicherer, als jeden geschützten Dienst ausdrücklich zu erlauben. erlaubt kleineren Umfang der Regeln und kann Schutz bieten, wenn ein unabsichtlich mißkonfigurierter Dienst ungeschützt zurückgelassen wurde.

Sehen wir uns einen anderen, realen Beispielregelsatz an und erklären Zeile für Zeile. Hier ein Beispiel für einen Webserver mit standardmäßigem Ablehnen; erlaubt werden nur ssh Verbindungen (für Administration) und Verbindung zu http (port 80) und https (port 443).

Dies wird ankommende Verbindungen von überall zu Ports 22 (ssh), 80 (http), and 443 (https) erlauben. Es werden alle anderen Verbindungsversuche fallengelassen und alle ausgehenden Verbindungen erlaubt. Dies ist ein recht fester Regelsatz. Aber wenn wir nur interne Rechner vom 1.1.1.0 Adressbereich zu ssh verbinden lassen wollen, aber Verbindungen von außerhalb zu http und https zulassen wollen?

Recht nett, aber wenn nur eine einzige Machine (1.1.1.1) den Webserver administrieren darf? In diesem Fall ändern wir dies: in: IP Filter unterstützt sowohl CIDR als auch Punkt/Dezimalformat der Netzmaskenadresse. Obiges in anderer Schreibweise: aber warum solltest du?

Beispielregeln

Hier ein paar gute Regeln, die jeder verwenden kann (angenommen wird, daß fxp0 das externe Interface mit Internetverbindung ist). Zunächst einfacher Schutz gegen Adressenschwindel ("address spoofing").

Eine gute Idee ist es, das loopback Interface von deinen anderen Regeln zu trennen. Unsere Regelsatz schaut schon recht gut aus. Zusammen sieht er so aus:

Paket logging

Nun, dies ist zwar schon recht gut, aber es könnte besser sein. Z. B. wenn wir alle Verbindungsversuche zu Port 22(ssh) loggen wollten, die von unserer Firewall blockiert werden? Einfach - IP Filter hat dafür das log Stichwort:

Diese Regel wird erlauben, daß sich unser Administrationsrechner auf Port 22 verbinden darf, aber alle anderen Verbindungsversuche auf Port 22 ablehnt und aufzeichnet.

Protokollbasierende Paketfilterung

IP Filter kann auch nach jedem IP Protokoll filtern, entweder nach seiner Nummer oder in /etc/protocols aufgelistet ist. Im Sinne der Klarheit werden wir uns nur mit tcp, udp und icmp beschäftigen. Dies sind die am meisten verwendeten Protokolle, auf denen alle grundlegenden Internetanwendungen basieren.

Damit IPF protokollbasierend filtert muß das Stichwort proto verwendet werden. Um unsere frühere ssh Beispielsregel zu verwenden, da ssh ja über tcp rennt,  sollten wir nur tcp Pakete zur Verbindung zulassen. Mit dem proto Stichwort erlauben wir nur tcp, und wir bekommen eine Regel wie folgt:

Aber wenn wir eine Verbindung für einen Dienst brauchen, die tcp und udp benötigt (wie z. B. bind)? Nun im Falle von tcp/udp erlaubt uns IP Filter beide Protokolle zusammen zu schreiben. NB: Dies gilt nur für tcp/udp. Für das bind Beispiel würde folgende Regel tcp und udp Verbindungen (bei standardmäßigem Ablehnen) erlauben:

Paketfilterung

Zusätzlich zur protokollbasierenden Filterung ist IP Filter auch zum Handhaben der zersplitterten IP Pakete fähig (eine allgemeine Methode des Besiegens der Paketfilter). Es gibt zwei mögliche Schlüsselwörter:  frag für allgemein zersplitterte IP Pakete, oder short für IP Pakete mit für Vergleiche zu kurzen Informationen (headers). Da zersplitterte Pakete auch normalerweise auftreten können, abhängig von den Verbindungsumständen, es ist am besten, Pakete mit den Vorsätzen nur zu filtern, die für gültigen Vergleich zu klein sind. Dieses kann mit der folgenden Richtlinie vollendet werden:

Und bzgl. IP Optionen? IP Filter kann jene Pakete auch behandeln. Pakete können entweder fallengelassen werden, wenn sie IP Optionen haben, oder sie spezifischen IP Optionen besitzen, die eingestellt werden. Z. B. läßt die folgende Richtlinie fallen und protokolliert alle Pakete mit den eingestellten IP Optionen. Dies kann aber einige Dinge wie traceroute(8) brechen. Du kannst auch bestimmte Optionen verbieten. Z. B. ist eine gute Regel, alle Pakete mit "source routing" Option zu verbieten. Dies geschieht mit dieser Regel: TCP Flags, bestehende Verbindungen und keep state

Nun kommt IP Filter in vollem Ernst: IP Filters größte Stärken liegen in der Fähigkeit, Pakete anhand ihrer TCP flags (=Kennzeichen) zu filtern und bestehende Verbindungen und Verbindungszustände aufrechtzuerhalten. Man sollte die Rolle jedes TCP flags verstehen, wenn man die Pakete danach filtern will. Z. B. wenn du alle Pakete mit den FIN, URG und PSH flags filtern willst (für z. B. einen "nmap OS fingerprinting attempt"), dann solltest du eine Regel wie diese einsetzen:

(Danke an Kyle Hargraves für diesen Tip)

Die nächste Fähigkeit von IP Filter ist, Verbindungszustände beizubehalten. Den Zustand beizubehalten ist beschrieben worden, wie " nicht sprechend bis gesprochen mit ", das heißt, sobald ein Anschluß hergestellt ist, müssen Pakete die Regelsätze nicht mehr überqueren. Dieses ist eine sehr leistungsfähige Eigenschaft, was viel einfacheres und sichereres Richtlinie Schreiben erlaubt.

Z. B. lassen sehen wir uns an, wie wir Zustand an unserem vorhergehenden Beispielregelsatz anwenden können (schon verwirrt?). Zu Wiederholung, wir erlauben Managementzugriff von unserem Klasse C Netz zu Kanal 22 (ssh) und erlauben allen ankommenden Web-Verkehr auf Kanälen 80 (http) und 443 (https). Wir blocken jeglichen weiteren Verkehr. Aber was, wenn ich mit ssh aus dem webserver heraus wünsche? Was, wenn ich lynx benutzen muß, um etwas im FAQ nachzuschauen? Gut, kann ich nicht, weil ich alle ankommenden Anschlüsse anders als auf den spezifizierten Kanälen geblockt habe. Während dieses der sicherste Weg ist, kann es ziemlich ungünstig bzw. unhandlich sein. Indem wir die Schlüsselwörter keep state unserer "pass out" Richtlinie hinzufügen, können wir ankommende Verbindungen in Erwiderung auf von uns selbst initialisierte Verbindungen automatisch erlauben, wie z. B. beim Webbrowsen. NB: Wir müssen das Protokol angeben, für das wir "keep state" halten.

Diese kleine Änderung wird die Flexibilität und Sicherheit unseres Regelsatzes dramatisch erhöhen, weil IP Filter extrem flexibel ist. Z. B. erlauben wir im obigen Regelsatz jeden TCP-Datenverkehr auf Ports 80 & 443. Wir können dies noch besser machen: Um eine TCP Verbindung zu errichten, müssen wir nur die erste Verbindungsanfrage erlauben. Sobald dies geschieht, können wir diesen Kanal blockieren und unsere "keep state" Regel die Verbindung verwalten lassen. Um die erste Verbindungsanfrage vollenden zu lassen, benötigen wir nur Pakete mit SYN und SYNACK Kennzeichen. Indem wir nur solche Pakete durchlassen, können wir z. B. viele Arten von "portscanning" aufgrund von FIN Kennzeichen verhindern. Die Regel sieht nun so aus: Nun schreiben wir alles zusammen: Dieser Regelsatz hat standardmäßiges Ablehnen, erlaubt Administration nur via ssh vom internen Netzwerk und erlaubt ankommenden Datenverkehr zu Ports 80 (http) und 443 (https). Er wird auch gegen Adressenschwindel von nicht-routebaren Adressen schützen und alle zu fragmentierten Pakete verwerfen. Eine recht umfassende Einstellung für einen Webserver. Hier unsere /etc/ipf.rules:

Wenn du Schwierigkeiten hast, dann kannst du Logging für bestimmte Regelsätze aktivieren; z.B.: pass in log uick on fxp0 from 1.1.1.0/24 to any port = 22 Wenn du die Konfigurationsdatei so modifizierst, um Pakete zu loggen, vergiß nicht, mit "ipf -Fa -f /etc/ipf.rules" die Änderungen auch zu aktivieren! ipmon wird die ip-Logeinträge in /var/log/ipflog schreiben. Für weitere Informationen über ipf siehe das IPF how-to als exzellente Informationsquelle sowie die IP Filter Homepage.

6.3 - IPNAT

Initiale Arbeit von Wayne Fergerstrom <wayne@methadonia.net>

6.3.1 NAT Einführung

Kapiteleinführung

Dieses Kapitel versucht jenen zu helfen, die Network Address Translation ("NAT") auf ihrem OpenBSD Rechner installieren und konfigurieren wollen. Der Benutzer sollte bereits den OpenBSD Rechner mit zwei Netzwerkkarten installiert und konfiguriert haben (eine mit dem Internet verbunden, die andere mit dem lokalen Netzwerk). IP NAT wird auch auf Rechnern mit nur einer Netzwerkkarte laufen, aber da die IP Pakete auf ein und demselben Interface ein- und ausgehen, werden Ethernetkollisionen die Leistung drastisch vermindern.

Gemä RFC 1631 bietet ipnat einen einfachen Weg, um interne Netzwerke auf eine einzige routebare ("reale") Internetadresse umzulegen. Dies ist sehr nützlich, wenn man nicht für jeden Rechner des internen Netzwerkes eine offizielle Adresse zugewiesen bekommen hat. Wenn man ein privates/internes Netzwerk besitzt, dann kann man die (in RFC 1918 definierten) Adressbereiche benutzen:

10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
192.168.0.0/16 (192.168.0.0 - 192.168.255.255)

Terminologie

Die in diesem Dokument verwendeten Konventionen sind sehr einfach. Für Documentationszwecke werde ich einige der Terme und Formate erklären.


Konfiguration

So sind die Computer eingerichtet, die in diesem Dokument beschrieben werden. Deine werden von diesen abweichen, aber der Zweck dieses Dokumentes ist, dir eine Übersicht zu verschaffen, damit du diese Information für deine Bedürfnisse verwenden kannst.


6.3.2 Network Address Translation


Einführung zu NAT

Da immer mehr und mehr Firmen und Private das Internet benutzen, muß jeder eine IP Adresse haben. Öffentliche IP Adressen sind immer schwieriger zu bekommen. Die Lösung für viele Leute ist Network Address Translation (oder "NAT"). NAT ist ein sehr einfaches, aber sehr wirkungsvoller Weg, um dein LAN mit dem Internet zu verbinden, ohne IP Adressen kaufen oder mieten zu müssen. NAT ist unter Linuxbenutzern auch als "IP Masquerading" bekannt.

Wenn NAT richtig eingerichtet ist, erlaubt es den Benutzern des internen LANs, das Internet mit einer anderen IP Adresse (jene von deinen Provider) zu benutzen. Jeder Rechner im LAN benutzt diese eine IP Adresse (transparent) vom Rechner mit der vom ISP zugewiesenen IP Adresse.

NAT arbeitet auf erblüffend einfache Weise. Wenn ein Rechner im LAN sich mit einem Rechner im Internet verbinden will, sendet er ein TCP Paket mit einer Verbindungsanfrage. Innerhalb des TCP Paketdatenkopfes ("headers") steht die Rechner IP Adresse (hier 192.168.1.40) und die erwünschte Server IP Adresse (z. B. 123.45.67.89). Die Maschine mit NAT fängt das TCP Paket ab und ändert die Rechner IP Adresse in die Adresse des Rechners, der mit dem Internet verbunden ist (z. B. 24.5.0.5). Dies täuscht den Server eigentlich, indem es ihn glauben macht, daß die Verbindung vom NAT Rechner und nicht vom eigentlichen Rechner A kommt. Der Server schickt dann die Antworten zurück zum NAT Rechner. Wenn der NAT Rechner die Antwort erhält, dann übersetzt er die Zieladresse zurück von seiner eigenen IP zu der von Rechner A und schick das Paket an Rechner A weiter. Rechner A bekommt von alledem nichts mit und die vorgetäuschte Internetverbindung ist total transparent.

Das folgende Beispiel zeigt NAT noch ein bißchen deutlicher:


Warum NAT verwenden

In meiner neuen Wohnung bekam ich ein Kabelmodem und somit ein kleines Problem. Wie können meine Zimmerkameraden Internetanschluß bekommen, wenn das Kabelmodem in meinem Zimmer steht? Ich hatte ein paar Alternativen wie zusätzliche IP Adressen kaufen, einen Proxyserver aufsetzen oder eben NAT einsetzen. (Laß dich nicht vom Kabelmodembeispiel täuschen: NAT ist fähig, ein großes Netzwerk mit hunderten oder auch tausenden Computern zu maskieren!)

Es gibt viele Gründe, warum ich NAT aufsetzen wollte. Nummer eins: Geld sparen. Zwei Zimmerkameraden in meinem Haus haben ihre eigenen PCs und ich besitze insgesamt 3 Computer. Mein ISP erlaubt nur drei IP Adressen pro Haushalt. D. h., daß wir nicht genug IPs hätten, um jedem Rechner Internetzugang zu verschaffen.

Mit NAT hat jeder Rechner eine eindeutige (interne) IP Adresse, aber alle teilen sich eine IP Adresse von meinem ISP. Die Kosten sinken.


Setup

Damit NAT auf deinem OpenBSD Rechner läuft, mußt du zunächst IPF und NAT aktivieren. Dies geschieht einfach, indem du die unten angeführten Dateien editierst (ändere die Dateien gemäß den folgenden Optionen):

/etc/rc.conf (diese Datei wird beim Booten fürs Starten von Diensten gelesen)

/etc/sysctl.conf

Nachdem diese Änderungen durchgeführt wurden, ist der Rechner endlich für die Konfiguration von NAT bereit.


Konfiguration

Der erste Schritt ist die Konfiguration der IPF Regelsatzdatei (/etc/ipf.rules). Dafür werden wir in diesem Dokument jeden Datenverkehr durch diese Firewall passieren lassen. Die Datei sollte so aussehen:

Siehe wiederum FAQ 6.2 für weitere Informationen.

Die NAT Konfigurationsdatei (/etc/ipnat.rules) folgt einer sehr einfachen Syntax. Um obige Konfiguration fortzusetzen, sollte die Datei die folgenden Einträge enthalten:

Hier eine Erklärung für die obigen Zeilen.

Die zweite Zeile hat beinahe den selben Eintrag außer für den letzten Teil. Dies bedeutet für ipnat, auch alle anderen (nicht tcp/udp Pakete, die bereits von der ersten Zeile erfaßt worden sind) zu jenen Ports umzulegen, die erfragt werden (z. B. ICMP und andere Protokolle). Wenn dies einmal in dieser Datei ist, dann hat man alles, um den IPF Dienst zu betreiben.


Betrieb

NAT zu betreiben ist auch ein sehr einfacher Vorgang. Ist die Konfiguration erst einmal komplett, dann gibt es zwei Möglichkeiten, um NAT zu aktivieren. Die erste (und beste, um die Rebootphase zu testen), ist, deinen OpenBSD Rechner zu rebooten. Dies geschieht mit dem Befehl "reboot"

Wenn du ipnat von der Kommandozeile starten willst, dann benutze die folgenden Befehle:

Die erste Zeile aktiviert IPF (NB: NAT setzt auf IPF auf, daher muß IPF initialisiert und gestartet werden, bevor NAT geladen werden kann). Die Optionen der Kommandozeile "-Fa" klären alle noch existierende Einträge. "-f /etc/ipf.rules" sagt IPF, wo die Regeldatei gefunden werden kann. "-E" ist die Option, um den IPF Dienst zu aktivieren.

Die zweite Kommandozeile aktiviert NAT. "-CF" klärt alle existierenden Enträge in der NAT Tabelle. "-f /etc/ipnat.rules" sagt NAT, wo die NAT Regeldatei zu finden ist. NAT läft nun. So einfach ist das.

NB: Um die NAT Einstellungen neu zu laden (im Falle, daß du die Datei editiert hast, aber nicht rebooten willst), mußt du nur den zweiten Befehl wiederholen. Die Einstellungen werden neu geladen.


6.3.3 NAT Grundwissen


Überprüfen des NAT Status

Um herauszufinden, was NAT tut oder um sicherzustellen, daß die gewünschten Einstellungen auch in Kraft sind, kannst du die "-l" Option verwenden. Diese Option listet alle Einstellungen und laufende Sitzungen:

Der Zweck der ersten beiden Zeilen ist, die Einstellungen von /etc/ipnat.rules zu bestätigen. Die Zeile(n) darunter zeigen die aktiven NAT Verbindungen.

Einschränkungen von NAT (bei FTP)

Es gibt a paar Einschränkungen von NAT. Eine ist bei FTP. Wenn ein Benutzer sich zu einem entfernten FTP Server verbindet und Informationen oder Dateien verlangt, wird der FTP Server eine Verbindung zum Klient aufbauen und die Daten auf einem willkürlichen freien Port übertragen. Dies ist ein Problem für Benutzer innerhalb des LAN. Denn der FTP Server sendet seine Informationen an die externe Netzwerkkarte auf einem willkürlichen Port. Der NAT Rechner wird dies zwar empfangen, aber weil es keine Umlegungsregeln für dieses unbekannte Paket oder für diesen Kanal gibt, wird er das Paket verwerfen und nicht liefern.

Die Lösung dafür ist, das FTP Programm in "passive mode" zu setzen. Dies teilt dem Server mit, daß dich du selbst aktiv zum Server verbinden willst. Wenn du nun eine Verbindung nach draussen machst, wird NAT deine Verbindung richtig behandeln.

IP Filter bietet eine andere Lösung für dieses Problem an: ein FTP Proxy, der im NAT Quelltext eingebaut ist. Um ihn zu aktivieren, füge etwas wie folgendes VOR deinen anderen NAT Regeln ein. 

map dc0 192.168.1.0/24 -> 24.5.0.5/32 proxy port ftp ftp/tcp
Mit dieser Regel wird der Kernel deine FTP Verbindungen auf den "PORT" Befehl vom FTP Programm überwachen und wird die IP Adresse und Port mit seiner eigenen externen IP Adresse austauschen und einen Port seiner Wahl bestimmen. Dann wird er einen Kanal öffen und die Daten zum Port, nach dem dein FTP Programm gefragt hat, tunneln. Dies ist offensichtlich etwas ressourcenintensiver. Aber es sollte gehen, solange dein NAT/IP Filter Rechner nicht übermäßig beansprucht wird.


Datenverkehr umleiten

Zuweilen willst du ankommenden oder ausgehenden Datenverkehr eines bestimmten Protokolles oder Kanals umleiten. Ein gutes Beispiel dafür ist ein Webserver, der im internen LAN hängt. Ankommende Verbindungen zu deiner gültigen, offziellen IP Adresse werden keine Verbindung aufbauen können, wenn auf deinem NAT Rechner kein Webserver rennt. Dafür gibt es bei NAT die 'rdr' Direktive in der Regelsatzdatei, die festlegt, ob und wohin eine bestimmte Verbindung umgeleitet werden soll.

Für unser Beispiel nehmen wir an, daß ein Webserver im LAN mit der IP Adresse 192.168.1.80 existiert. Die NAT Regeldatei benötigt eine neue Direktive. F¨ge eine Zeile wie folgende in ipnat.conf ein:

Die Erklärung:

Danach lade die NAT Regeln neu und die Umleitungen werden sofort in Kraft treten.


NAT versus Proxy

Der Unterschied zwischen NAT und einem applikationsbasierten Proxy liegt darin, daß die Proxysoftware als Mittelsmann zwischen Internet und den im LAN verbundenen Rechnern agiert. Nur muß für jede Anwendung und Internetverbindung ein dafür geeigneter Proxy bereitstehen. Nicht alle Anwendungen können dies (vor allem Spiele nicht). NAT "mapped" dein internes Netzwerk transparent, sodass es mit dem Internet verbunden ist. Der einzige Sicherheitsvorteil von Proxysoftware gegenüber NAT ist, daß die Proxysoftware sicherheitstechnisch im Vorteil ist, wenn wenn den Inhalt filtern kann; z. B. Makroviren für Windowsrechner filtert, oder gegen Buffer-overflows schützt, udgl. Diese Filter zu administrieren bedeutet viel Arbeit.

6.3.4 Links und Querverweise

OpenBSD Dateien:

NAT Internet Links:


6.4 - DHCP

6.4.1 DHCP Klient

Um den DHCP Klient 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 Klient 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 Klient von der Befehlszeile starten willst, stelle sicher, daß /etc/dhclient.conf existiert, dann versuche: 

# dhclient fxp0
Wobei fxp0 die Netzwerkkarte ist, auf der du DHCP empfangen willst.

Wie du auch immer dhclient startest, du kannst die /etc/dhclient.conf Datei immer so editieren, daß dein DNS nicht erneuert wird aufgrund der neuen DNS Informationen, indem du die 'require' Zeilen auskommentierst (Es gibt Beispiele in den Standardeinstellungen, aber du mußt die Standardeinstellungen von dhclient überschreiben.). 

request subnet-mask, broadcast-address, time-offset, routers,
      domain-name, domain-name-servers, host-name, lpr-servers, ntp-servers;
und dann entferne domain-name-servers. Natürlich kannst du auch hostname oder andere Einstellungen entfernen.

6.4.2 DHCP Server

Wenn du OpenBSD als DHCP Server dhcpd(8) einstetzen willst, editiere /etc/rc.conf. Setze dhcpd_flags="-q" anstelle von dhcpd_flags=NO. Und die Netzwerkkarten, auf denen dhcpd lauschen soll, gib in /etc/dhcpd.interfaces. 
# echo xl1 xl2 xl3 >/etc/dhcpd.interfaces
Dann editiere /etc/dhcpd.conf. Die Optionen sind selbsterklärend. 
        option  domain-name "xyz.mil";
        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 Klienten mit, daß die an DNS Anfragen anzuhängende Domäne xyz.mil ist (d. h., wenn der Benutzer schreibt 'telnet joe', dann wird an joe.xyz.mil 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 dhcpd von der Befehlszeile starten willst, nachdem du /etc/dhcpd.conf editiert hast, versuche: 

# dhcpd -q fxp0
Wobei fxp0 die Netzwerkkarte ist, auf der DHCP serviert werden soll. Die -q Option setzt die Ausgabe von dhcpd auf ruhig, ansonsten ist sie sehr ausführlich.

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 Klienten wünschen.

6.5 - PPP

Das "Point-to-Protocol" wird verwendet, um eine Verbindung zu deinem ISP mit deinem Modem herzustellen. OpenBSD bietet dafür 2 Möglichkeiten.

Den ersten, den wir behandeln, wird der Userland PPP Dämon sein. 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&aum;ren hilfreich. Der Userland PPP Dämon 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.

Solltest du keinen GENERIC Kernel verwenden, dann stelle sicher, daß du folgende Zeile in deiner Kernelkonfigurationsdatei hast:

Erste Einstellungen - für PPP(8)

Die ersten Einstellungen für den Userland PPP Dämon 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 kreieren. Hier werde ich mit dem einfachsten und gebrächlichsten Einstellungen beginnen. Hier eine schnelle ppp.conf Datei, die uns einfach zu deinem ISP verbindet und die Standardrouten und Nameserver setzt. Für diese Datei brauchst du nur die Telefonnummer deines ISP sowie deinen Benutzernamen und dein Passwort.

ANMERKUNG - Mit OpenBSD 2.6 wurde das System mit einer /etc/ppp/ppp.conf.example ausgeliefert, die nicht korrekte Einstellungen für die Schnittstelle hatte, dessen Name war "set device /dev/cuaa0". Es sollte aber /dev/cua00 sein, was der seriellen Schnittstelle 1 (COM1) entspricht. Deine Schnittstelle muß nicht COM1 sein, aber die Bezeichnung in OpenBSD 2.6 war falsch.

Der Absatz unter der default: Bezeichnung wird jedes Mal ausgeführt. Hier stehen alle wichtigen Informationen. Mit "set log" stellen wir die 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 dem 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 wird die Geschwindigkeit unserer Dialup Verbindung und mit "set dial" setzen wir unsere Dialup Parameter, mit denen wir die timeout Zeit, usw. setzen können. Diese Zeile sollte eigentlich ziemlich genau so, wie sie jetzt ist, bleiben.

Nun können wir die ISP spezifischen Informationen eintragen. Wir tun dies, indem wir unter default: einen weiteren Absatz hinzufügen. Dieser kann als alles benannt werden, 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 beinhält, um uns zu verbinden.

Hier stehen alle wichtigen Informationen für unseren spezifischen ISP. Die erste Option "set phone" setzt die Telefonnummer deines ISP. "set login" setzt unsere login-Optionen. Hier haben wir die timeout auf 5 gesetzt, was bedeutet, daß 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 Passwort senden. In diesem Beispiel ist unser username = ppp und das Password = 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 bißchen schwieriger. Hier ist eine genauere Erklärung.

Die obigen 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, daß kein Bits von dieser IP Adresse übereinstimmen muß 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 um 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.

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.

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 dem Aufruf von /usr/sbin/ppp ohne Optionen kommst du in den interaktiven Modus. Hier kannst du direkt mit dem Modem interagieren, was sich hervorragend eignet, um Probleme in deiner ppp.conf Datei zu debuggen.

ppp(8) Extras

In einigen Situationen möchstest du Befehle ausführen, wenn die Verbindung gerade erichtet oder beendet wurde. Für diese Fälle gibts es zwei Dateien, die du kreieren kannst: /etc/ppp/ppp.linkup und /etc/ppp/ppp.linkdown. Beispielskonfigurationen kannst du hier finden:

Weitere Informationen findest du unter http://www.freebsd.org/handbook/userppp.html oder http://www.freebsd.org/faq/userppp.html.

6.6 - Netzwerkparameter tunen

6.6.1 - Wie kann ich den Kernel einstellen, damit es eine höhere Anzahl an Verbindungsversuchen und längere Timeouts für TCP Sitzungen gibt?

Du solltest dies normalerweise nur verwenden, wenn du Routing- oder Verbindungsprobleme hast. Natürlich sollten - um die beste Wirkung zu erzielen - beide Seiten der Verbindung dieselben Werte verwenden.

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 sysctl -w, wie z. B. sysctl -w net.inet.tcp.keepidle=28800.

6.6.2 - Wie kann ich "directed broadcasts" aktivieren?

Normalerweise willst du dies nicht tun. Dies erlaubt jemand, 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) ützlich sein, vor allem wenn man ätere Implementierungen des NetBIOS Protokolles verwendet. Wiederum mit sysctl. sysctl -w net.inet.ip.directed-broadcast=1 aktiviert dies. Beachte aber Smurfangriffe, wenn du wissen willst, warum dies standardmäßig nicht aktiviert ist.

6.6.3 - Der Kernel soll Ports nicht dynamisch allozieren

Wieder ein eigener sysctl Befehl dafür. Siehe sysctl(8): 
Set the list of reserved TCP ports that should not be allocated by the
kernel dynamically.  This can be used to keep daemons from stealing a
specific port that another program needs to function.  List elements may
be separated by commas and/or whitespace.

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

It is also possible to add or remove ports from the current list.

   sysctl -w net.inet.tcp.baddynamic=+748
   sysctl -w 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 Manualseiten lesen, bevor du versuchst, einen eigenen NFS Server aufzusetzen:

Dieses Kapitel zeigt die Schritte, um ein einfaches NFS System aufzusetzen: Ein Server im LAN und Klienten im LAN, die NFS verwenden. Es behandelt nicht, wie man NFS sicher macht. Wir nehmen an, daß 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 sein, der du Zugriff auf den NFS Server läßt. 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.

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 exports(5). Für dieses Beispiel sieht /etc/exports so aus:

Dh., daß das lokale Dateisystem /work via NFS zugänglich gemacht wird. -alldirs bedeutet, daß Klienten jedes Verzeichnis unter dem /work Mount-point mounten können. -ro bedeutet, daß nur Leseberechtigung gestattet wird. Die letzten zwei Argumente bedeuten, daß nur Klienten 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, daß deine Kernelkonfiguration die Optionen NFSSERVER & NFSCLIENT enthält. (Der GENERIC Kernel hat diese Optionen inkludiert.) Dann solltest du nfs_server=YES in /etc/rc.conf eintragen. 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 mußt sicherstellen, daß 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 Klientenanfragen, die du bedienen willst, zu bewerkstelligen.

Du mußt 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, gib einfach folgendes ein:

Wenn du Änderungen an /etc/exports durchführst, während NFS bereits läuft, mußt du mountd dies mitteilen, indem du den Dienst neu startest!

NFS Status überprüfen

Um zu überprüfen, ob alle Dienste laufen und bei RPC registriert sind, verwende rpcinfo(8).

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. Z. B.:

NFS Dateisysteme mounten

NFS Dateisysteme sollten mittels mount(8) geladen werden, oder genauer mount_nfs(8). Um ein Dateisystem /work von Host 10.0.0.1 auf dem lokalen Dateisystem /mnt zu laden, tue folgendes (NB: du mußt nicht IP Adressen verwenden, mount wird Hostnamen auflösen):

Damit dein System dies beim Hochfahren wieder tut, füge folgendes zu deiner /etc/fstab:

Es ist wichtig, daß 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. Z. B.:

Mit diesen Optionen können keine Geräte oder setuid Programme auf dem NFS Server Sicherheitsmaßnahmen auf dem NFS Klient untergraben. Wenn du keine Programme auf diesem NFS Dateisystem auf dem NFS Klient ausführen willst, füge noexec hinzu:

6.8 - Domain Name Service - DNS, BIND und named

6.8.1 Was ist DNS?

Domain Name Service bietet die Möglichkeit, Name-zu-IP Adresse Auflösung und IP Adresse-zu-Namen Auflösung auf eine Anfrage zu generieren. Deine OpenBSD Installation ist standardmäßig als DNS Klient, aber nicht als DNS Server konfiguriert. D.h., deine OpenBSD Installation kann eine DNS Anfrage an einen Domain Name Server für die Adresse einer Maschine stellen, aber sie kann nicht selbst solche DNS Anfrage beantworten, bis du dies nicht selbst so konfigurierst.

Meine OpenBSD Maschine ist derzeit mit dem Internet durch meinen ISP verbunden, so daß ich mit nslookup(8) DNS Anfragen ausführen kann:

165.87.201.244 ist der Nameserver, der geantwortet hat, weil es der Nameserver ist, den mein ISP mir zu meinem Konto zugeteilt hat und in /etc/resolv.conf eingetragen ist. Aber die Antwort war nicht authoritativ. Für eine authoritative Antwort müssen wir den DNS Server für die openbsd.org Domäne finden und ihn nach der Adresse von www.openbsd.org fragen:

Auf zeus.theos.com läft OpenBSD und ist korrekt als DNS server für die openbsd.org Domäne konfiguriert.

6.8.1.1 Wo kann ich alles über DNS und seine Implementationen unter OpenBSD lernen?

Der dig(1) Befehl ist besonders nützlich, weil er eine Domäne befragen kann und Informationen zurückliefert, die einem Format unterliegen, das BIND Konfigurationsdateien sehr ähnlich ist. Du kannst mit dig(1) Nameserver untersuchen, von denen du weißt, daß sie richtig funktionieren, und sie mit deinen Einstellungen vergleichen.

6.8.2 Muß meine Maschine ein Domain Name Server sein?

Wenn du dir nicht sicher bist, ob dein Rechner die Rolle eines DNS Server spielen soll, dann konfiguriere ihn nicht als solchen. Die OpenBSD Installation konfiguriert nicht standardmäßig deine Maschine als einen Domain Name Server, obwohl alle notwendigen Dateien dafür installiert werden. Für die meisten Arbeitsplatzrechner genügt die /etc/hosts Datei, um IP Adressen lokaler Rechner zu benennen und die /etc/resolv.conf Datei, um die DNS Server im Intranet oder Internet einzustellen.

Aber wenn du vielleicht doch deinen Rechner als Domain Name Server konfigurieren mußt:

Eine weitere Überlegung ist die Ausführungsgeschwindigkeit. Da die Namensauflösung ein iterativer Prozess ist, in dem der Nameserver wiederholende Anfragen an andere Nameserver in entfernten Domänen stellt, kann die Namensauflösung länger dauern, wenn du eine Modemverbindung ins Internet hast und deinen DNS Server nach anderen, entfernten IP Adressen auf der Modemleitung befragst (die ihrerseits wieder andere entfernte DNS Server befragen), als wenn du den Nameserver deines ISP befragst (der wahrscheinlich eine schnellere Verbindung zu entfernten Nameservern hat).

6.8.3 Was sind die Softwarekomponenten der DNS Server?

6.8.3.1 Welche Versionen von BIND werden unterstützt?

BIND ist der Name einer Spezifikation eines Domänennamensservers mit einem bestimmten Verhalten. Die DNS Komponenten ergeben gemeinsam die Implementation von BIND.

Es gibt zwei getrennte BIND Specifikationen:

  1. BIND 4
  2. BIND 8

Standardmässig unterstützt OpenBSDs named BIND 4.x.

6.8.3.2 Welche Alternativen zu der Standard-BIND 4.x-Implementation gibt, um DNS Dienste bereitzustellen?

6.8.3.2.1 Sicherheitsanmerkung

Wenn du diese alternativen Implementationen von DNS Diensten in betracht ziehst, dann stellst du einen kritischen Netzwerkdienst zur Verfügung, dessen Software nicht dem selben Niveau an Überprüfung wie durch Sicherheit dem named name daemon in der Basisinstallation zu Teil wurde. Dies ist eine signifikante Überlegung, da, falls ein DNS Server kompromittiert wird, die Klients zu betrügerischen Webseiten umgeleitet werden können.

6.8.4 Wieviel muß ich installieren?

Wenn die standmässige Netzwerkinstallation korrekt bei der Installation von OpenBSD eingerichtet hast, dann ist bereits alles installiert. Du mußt nur mehr den Nameserverdienst ("named") konfigurieren.

6.8.5 Wie konfiguriere ich DNS?

Du konfigurierst OpenBSD DNS, indem du Dateien editierst und/oder erstellst, die den Nameserverdienst named steuern. Diese Dateien liegen standardmäßig im Verzeichnis /var/named und dessen Unterverzeichnisse, hauptsächlich in der Datei /var/named/named.boot, das die Initialisierungsdatei für named ist. Weiters gibt es ein paar andere notwendige Konfigurationsschritte in /etc.

In diesem Dokument werden wir den Nameserverdienst auf nemo.yewtopia.com konfigurieren, der der primäre Nameserver für die (sehr kleine!) Domäne yewtopia.com sein wird. Die Adresse von nemo.yewtopia.com ist 192.168.1.9. Zwei andere Maschinen befinden sich im selben Subnet, crater.yewtopia.com auf 192.168.1.1 und earhart.yewtopia.com auf 192.168.1.2.

6.8.5.1 Konfiguration in /etc/named

6.8.5.1.1 /var/named/named.boot

Dies teilt dem Initialisierungsprozeß mit, in welchem Unterverzeichnis und unter welchem Dateinamen die Konfigurationsdateien für yewtopia.com zu finden sind.

6.8.5.1.2 /var/named/namedb/localhost.rev
6.8.5.1.3 /var/named/namedb/yewtopia
6.8.5.1.4 /var/named/namedb/yewtopia.rev

6.8.5.2 Konfiguration in /etc

6.8.5.2.1 /etc/resolv.conf

Stelle sicher, daß /etc/resolv.conf nun auf die Domäne des lokalen Rechners (anstatt auf, z. B., den Nameserver deines ISPs) zeigt, so daß die Namensauflösungsanfragen auch wirklich zu dem named geschickt werden, den du konfiguriert hast!

6.8.5.2.2 /etc/hosts

Wenn du vorher die Adressen von diversen Rechnern zu der /etc/hosts Datei hinzugefügt hattest, dann solltest du in Betracht ziehen, deine /etc/hosts Datei wieder auf Standardgröße zu kürzen:

Damit named nicht zugunsten von (möglicherweise veralteten) Adressen in der /etc/hosts Datei übergangen wird. Stelle sicher, daß du zumindest den Standardeintraglocalhost hast, oder dein Netzwerk wird nicht richtig starten!! Auch nemo muß in seiner eigenen hosts-Datei aufscheinen, oder du wirst eine (eher harmlosen) Fehlermeldung zu Bootzeit bemerken, wenn /etc/netstart route(8) aufruft, um nemo hinzuzufügen (dessen Name in /etc/myname aufscheint).

6.8.5.3 Mittels dig(1) die Ergebnis untersuchen.

6.8.6 Wie kann ich DNS starten und stoppen?

6.8.6.1 DNS starten

Der Nameserverdienst named wird beim Systemstart von /etc/rc gestartet, wenn die folgende Zeile (standardmäßig vorhanden) sich in /etc/rc.conf befindet.

verändere in

Beachte auch diese Zeilen in /etc/rc.conf:

Diese Standardeinstellungen werden für beinahe alle Installationen korrekt sein.

Um named händisch zu starten, verwende den ndc(8) Befehl. Z. B.:

6.8.6.2 DNS Stoppen

Der beste Weg, um den Nameserverdienst zu stoppen, ist den ndc(8) Befehl zu verwenden. Z. B.:

Wenn dies fehlschlägt, finde die Prozeß-ID von named und verwende den kill(1) Befehl, um diesen Prozeß zu beenden. Die PID für named, solange er läft, kannst du in der ersten Zeile der Datei /var/named/named.pid finden.

6.8.6.3 Restarting DNS with an altered configuration

6.8.7 How do I block AXFR queries?

Beispiel:

Diese Information ist nützlich für das Debuggen von DNS, aber in manchen Fällen willst du diesen Output nicht in aller Welt zeigen. Wenn du klassenloses in-addr(rfc2317) für reverse benutzt, könnte 'host -l' jede Domain anzeigen, die dein System hostet! Dies kann man einfach mit der 'allow-transfer' Formulierung in deinem zone file verhindern.

Wenn du Bind8 benutzt, musst du die Hosts spezifizieren, denen du den "Zonen-Transfer" erlauben willst, und zwar in deinen individuellen Zone Datei(en):

Du kannst auch Transfers für alle Domains stoppen, indem du /var/named.conf anpasst und und den 'allow-transfer' Parameter zur options Sektion der Konfigurationsdatei hinzuf&uulm;gst:
Die Bind8 Methode funktioniert auch mit Bind9.
Bei Bind 4 (Standard in OpenBSD) kannst du /var/named/named.boot anpassen und die 'xfrnets' Option nutzen.

Bind 4 erlaubt Transfers von ganzen Klassen, ist also nicht so exakt. Typischerweise sind die einzigen Hosts, die Transfers durchführen müssen deine DNS Slaves und Hosts von denen du vielleicht 'debug'en willst (127.0.0.1 ist meist ein guter Host, dem man Transfers erlauben sollte!) AXFR queries zu blocken fügt einen zusätzlichen Level an Privatsphere ein, kann aber ein sinnvolles DNS debugging behindern. (Danke an Nicholas Tang für diesen Tip)

6.8.8 Was hast du mir nicht über das Aufsetzen von DNS erzählt?

Es gibt eine Menge von Dingen, die ich dir nicht erzählt habe, z.B. wie man DNS so aufsetzt, dass Anfragen für Intranet Domains, die von der root der Domain-Hierarchie aus nicht sichtbar sind, zu Servern innerhalb deines Unternehmens weitergeleitet werden. Lies die empfohlenen Dokumente, um mehr Informationen über DNS zu erhalten.

6.9 - Eine PPTP Verbindung mit OpenBSD aufsetzen

HINWEIS: Dies bezieht sich nicht auf ALLE ADSL Provider, aber viele der Informationen können aus diesem Setup übernommen werden. Dieses Setup funktioniert auf jeden Fall bei Inode, einem ADSL Provider in Österreich.

Zunächst benötigt man ein pptp. Ein port wurde dem OpenBSD ports tree NACH der Veröffentlichung von OpenBSD 2.8 hinzugefügt und arbeitet bestens. Der port ist unter /ports/net/pptp zu finden. Lies die FAQ 8.6, wenn du mehr über den OpenBSD ports tree herausfinden willst.

Wegen des Konflikts der "Im-Kernel" gre(4) Unterstützung und pptp wirst du deinen Kernel neu kompilieren müssen und die Unterstützung für gre(4) entfernen müssen.

Um deinen Kernel neu zu kompilieren mache einen "check out" von OpenBSD 2.8-stable via cvs (siehe die OpenBSD Stable Webseite) , benutze den folgenden Patch, und baue einen neuen Kernel wie unter FAQ 5.3.

Nachdem du das pptp package und einen neuen Kernel installiert hast, musst du ein paar Dateien für deine neue Verbindung editieren. Diese packages benutzen das standardmässige OpenBSD ppp(8), wenn du dich also mit ppp(8) auskennst, kommt dir vieles bekannt vor. Siehe auch FAQ 6.5.

Für eine /etc/ppp/options Datei wird ein Setup wie das unten vermutlich alles notwendige tun:

LOGINNAME sollte mit deiner User-ID ersetzt werden.

In /etc/ppp/pap-secrets gehört eine Zeile wie diese hier:

Wobei LOGINNAME deine User-ID und PASSWORD dein Password ist. 10.0.0.138 ist die zugewiesene IP deines Modems im Falle, dass du ADSL nutzt, etc. Stelle sicher, dass diese Datei nur von root gelesen werden kann (mode 600).

6.9.1 - Deinem Network Interface eine Adresse zuweisen

Im obigen Beispiel hatte unser Modem eine vorkonfigurierte Adresse von 10.0.0.138. Jetzt müssen wir UNSEREM Interface noch eine Adresse zuweisen. Es ist am besten eine IP zu wählen, die nahe an der deines MODEMS liegt, oder einfach die statische Adresse zu benutzen, die dir zugewiesen wurde. Mehr darüber, wie man Interfaces IP-Adressen zuweist, kannst du in FAQ 6.1 lesen.

Wenn dein Interface eingerichtet ist, solltest du eine pptp Verbindung mit dem Kommando

aufbauen können.

Da hier auch der "in-house" OpenBSD ppp(8) benutzt wird, werden hier zwei Prozesse gestartet. Du kannst pptp beenden, indem du diesen beiden Prozesse killst:

Wir empfehlen /var/log/messages in einem weiteren Terminalfenster zu öffnen, um mögliche Probleme zu erkennen.

Wir schlagen vor, die Startsequenz in /etc/rc.local unterzubringen, so dass bei jedem reboot die Verbindung automatisch aufgebaut wird.

[Zurück zum Hauptindex] [Zu Kapitel 5.0 - Kernelkonfiguration] [Zu Kapitel 7.0 - Tastatureinstellungen]

[zurück] www@openbsd.org
Originally [OpenBSD: faq6.html,v 1.86 ]
$Translation: faq6.html,v 1.21 2000/12/28 21:43:02 jufi Exp $
$OpenBSD: faq6.html,v 1.15 2001/01/05 14:52:18 reinhard Exp $