Kapitel 12. Netzwerke

“Diskless Booting” bedeutet, dass die FreeBSD-Maschine über ein Netzwerk gebootet wird und die notwendigen Dateien von einem Server anstatt von der Festplatte liest. Vollständige Details finden Sie im Handbucheintrag über den plattenlosen Betrieb.

Ja. Genaue Informationen zu diesem Thema finden Sie im Abschnitt Gateways und Routen des Handbuchkapitels Weiterführende Netzwerkthemen.

Personen, die diese Frage stellen, haben typischerweise zwei PCs zu Hause: einen mit FreeBSD und einen mit einer Windows-Variante. Die Idee ist, die FreeBSD-Maschine an das Internet anzubinden, um in der Lage zu sein, von der Windows-Maschine über die FreeBSD-Maschine auf das Internet zuzugreifen. Das ist tatsächlich nur ein Spezialfall der vorherigen Frage.

Das User-Mode ppp(8) von FreeBSD kennt die Option -nat. Wenn Sie ppp(8) mit der Option -nat starten, in /etc/rc.conf die Variable gateway_enable auf YES setzen und Ihre Windows-Maschine korrekt konfigurieren, sollte das hervorragend funktionieren. Weitere Informationen erhalten Sie in der Hilfeseite ppp(8) oder im Abschnitt User-PPP des Handbuchs.

Wenn Sie Kernel-Mode PPP verwenden oder ihre Verbindung zum Internet über Ethernet erstellt wurde, müssen Sie natd(8) verwenden. Weitere Informationen dazu finden Sie im natd-Abschnitt des Handbuchs.

Ja. Lesen Sie die Manualpages slattach(8), sliplogin(8), pppd(8) und ppp(8). ppp(8) und pppd(8) liefern Unterstützung sowohl für eingehende, als auch ausgehende Verbindungen. sliplogin(8) behandelt ausschließlich eingehende Verbindungen und slattach(8) behandelt ausschließlich ausgehende Verbindungen.

Diese Programme werden im Abschnitt PPP und SLIP des Handbuchs beschrieben.

Falls Sie nur durch einen “Shell-Account” Zugang zum Internet haben, sehen Sie sich einmal das Package net/slirp an. Es kann Ihnen (eingeschränkten) Zugang zu Diensten wie ftp und http direkt von Ihrer lokalen Maschine aus ermöglichen.

Ja. Wenn Sie NAT über eine User-PPP-Verbindung einsetzen wollen, lesen Sie bitte den User-PPP Abschnitt des Handbuchs. Wollen Sie NAT über eine andere Verbindung einsetzen, lesen Sie bitte den NATD Abschnit des Handbuchs.

Dieses Thema wird im Handbuch-Kapitel PLIP behandelt.

Weil das nicht notwendig ist. Bei Berkeley-basierten Netzwerkimplementationen kann nur vom Kernel-Code aus direkt auf Netzwerkkarten zugegriffen werden. Zur weiteren Information lesen Sie bitte die Datei /etc/rc.network und die Manualpages zu den unterschiedlichen Netzwerkprogrammen, die dort erwähnt werden. Falls Sie danach total verwirrt sind, sollten Sie sich ein Buch besorgen, das die Netzwerkadministration auf einem anderen BSD-ähnlichen Betriebssystem beschreibt; mit wenigen signifikanten Ausnahmen gleicht die Netzwerkadministration auf FreeBSD im Grunde der auf SunOS™ 4.0 oder Ultrix.

Wenn sich die zweite Adresse im gleichen Subnetz befindet wie eine der Adressen, die bereits auf dem Interface konfiguriert sind, benutzen Sie netmask 0xffffffff in Ihrer ifconfig(8) Befehlszeile, wie z.B.:

# ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff

Andernfalls geben sie die Adresse und die Netzmaske so an, wie sie es bei einem normalen Interface auch tun würden:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Wenn Sie die anderen Anschlüsse benutzen möchten, müssen Sie einen zusätzlichen Parameter in der ifconfig(8)-Befehlszeile spezifizieren. Der Standard-Anschluss ist link0. Um den AUI-Anschluss anstelle des BNC-Anschlusses zu verwenden, benutzen Sie link2. Diese Angaben sollten durch Benutzung der Variablen ifconfig_* in der Datei /etc/rc.conf spezifiziert werden.

Gewisse PC-Netzwerkkarten sind (um es gelinde auszudrücken) besser als andere und können manchmal Probleme mit netzwerkintensiven Anwendungen wie NFS verursachen.

Weitere Informationen zu diesem Thema finden Sie im Handbucheintrag zu NFS.

Einige Versionen des NFS-Codes von Linux akzeptieren Mount-Requests nur von einem privilegierten Port. Versuchen Sie

# mount -o -P linuxbox:/blah /mnt

Sun Workstations mit SunOS 4.X akzeptieren Mount-Requests nur von einem privilegierten Port. Versuchen Sie

# mount -o -P sunbox:/blah /mnt

Die häufigste Ursache für dieses Problem ist, dass Sie den Aufbau der exports(5) nicht oder nicht richtig verstanden haben. Überprüfen Sie Ihre exports(5) und lesen das Kapitel NFS im Handbuch, speziell den Abschnitt Konfiguration.

Versuchen Sie, die TCP-Erweiterung in /etc/rc.conf zu deaktivieren, indem Sie die folgende Variable auf NO setzen:

tcp_extensions=NO

Xylogic's Annex-Maschinen arbeiten hier auch fehlerhaft und Sie müssen die obige Änderung benutzen, um über Sie Verbindungen herzustellen.

Multicast-Host-Funktionen werden standardmäßig unterstützt. Wenn Sie Ihre Maschine als Multicast-Router betreiben wollen, müssen Sie Ihren Kernel mit der Option MROUTING neu kompilieren und mrouted(8) starten. Wenn Sie die Variable mrouted_enable in der Datei /etc/rc.conf auf "YES" setzen, wird mrouted(8) während des Systemstart automatisch gestartet.

MBONE-Tools sind in ihrer eigenen Ports-Kategorie mbone verfügbar. Schauen Sie dort nach, wenn Sie die Konferenztools vic und vat suchen!

Hier ist eine von Glen Foster <gfoster@driver.nsta.org> zusammengetragene Liste mit einigen aktuellen Ergänzungen:

Sie werden wahrscheinlich feststellen, dass der Host sich tatsächlich in einer anderen Domäne befindet; wenn Sie sich zum Beispiel in foo.example.org befinden und einen Host namens mumble in der Domäne example.org erreichen wollen, werden Sie den fully-qualified Domainnamen mumble.example.org, anstatt nur mumble benutzen müssen.

Traditionell war dies bei BSD-BIND-Resolvern erlaubt. Die aktuelle Version von bind, die mit FreeBSD ausgeliefert wird, ermöglicht jedoch nicht mehr die standardmäßige Abkürzung von nicht-fully-qualified Domainnamen für andere als ihre eigene Domäne. Ein nicht-qualifizierter Host mumble muss also entweder als mumble.foo.example.org gefunden werden, oder er wird in der Hauptdomäne gesucht.

Dies unterscheidet sich vom vorherigen Verhalten, wo die Suche über mumble.example.org und mumble.edu fortgesetzt wurde. Werfen Sie einen Blick in RFC 1535, um zu erfahren, warum dies als schlechter Stil oder sogar als eine Sicherheitslücke betrachtet wurde.

Als Abhilfe können Sie die Zeile

search foo.example.org example.org

anstelle der vorherigen

domain foo.example.org

in Ihre Datei /etc/resolv.conf einfügen. Stellen Sie jedoch sicher, dass die Suchreihenfolge nicht über die “Grenze zwischen lokaler und öffentlicher Administration”, wie RFC 1535 sie nennt, hinausreicht.

Dieses Problem kann auftreten, wenn Sie einen Kernel mit der Option IPFIREWALL erstellt haben. In der Voreinstellung werden alle Pakete, die nicht explizit erlaubt wurden, blockiert.

Falls sie Ihr System unbeabsichtigt als Firewall konfiguriert haben, können Sie die Netzwerkfunktionalität wiederherstellen, indem Sie als root folgendes eingeben:

# ipfw add 65534 allow all from any to any

Sie können in /etc/rc.conf auch firewall_type="open" setzen.

Weitere Informationen über die Konfiguration einer FreeBSD-Firewall finden Sie im Handbuch-Abschnitt.

Diese Frage wird im Handbuch-Kapitel Firewalls im Abschnitt IPFW Overhead und Optimierung ausführlich behandelt.

Der wahrscheinlichste Grund ist, dass Sie Network Address Translation (NAT) brauchen und nicht die einfache Weiterleitung von Pakete. Die “fwd” Anweisung macht genau das, was da steht: Sie leitet Pakete weiter; die Daten in den Paketen werden aber nicht verändert. Ein Beispiel:

01000 fwd 10.0.0.1 from any to foo 21

Wenn ein Paket mit dem Ziel foo die Maschine mit dieser Regel erreicht, wird das Paket an 10.0.0.1 weitergeleitet; die Zieladresse im Paket lautet aber immer noch foo! Die Zieladresse wird nicht in 10.0.0.1 geändert. Die meisten Rechner werden allerdings Pakete verwerfen, wenn die Zieladresse des Paketes nicht mit der Adresse des Rechners übereinstimmt. Das ist der Grund, warum eine “fwd” Regel oft nicht den Effekt hat, den der Benutzer wollte. Dieses Verhalten ist aber kein Fehler, sondern erwünscht.

Wenn Sie einen Dienst auf eine andere Maschine umleiten wollen, sollten Sie sich den FAQ-Eintrag über die Umleitung von Diensten oder die Online-Hilfe zu natd(8) durchlesen. Auch in der Ports Sammlung sind diverse Hilfsprogramme für diesen Zweck enthalten.

Sie können FTP-Requests (und andere Dienste) mit dem Package socket umleiten, das im Ports-Tree in der Kategorie “sysutils” verfügbar ist. Ersetzen sie die Befehlszeile für den Dienst einfach so, dass stattdessen socket aufgerufen wird, zum Beispiel so:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.example.com ftp

wobei ftp.example.com und ftp entsprechend der Host und der Port sind, wohin umgeleitet werden soll.

Für FreeBSD gibt es drei Bandbreiten-Managementtools. dummynet(4) ist in FreeBSD (um genau zu sein, in ipfw(4)) integriert. ALTQ gibt es umsonst; Bandwidth Manager von Emerging Technologies ist ein kommerzielles Produkt.

Der Berkeley-Paket-Filter (bpf(4)) muss in den Kernel eingebunden werden, bevor er von einem Programme aus genutzt werden kann. Fügen Sie folgendes zu Ihrer Kernelkonfigurationsdatei hinzu und erstellen Sie einen neuen Kernel:

pseudo-device bpf     # Berkeley Packet Filter

Unter FreeBSD 4.X und früheren Versionen müssen Sie noch die Gerätedateien erstellen. Wechseln Sie dazu nach dem Neustart in das Verzeichnis /dev und führen Sie den folgenden Befehl aus:

# sh MAKEDEV bpf0

Weitere Informationen über den Umgang mit Geräten finden Sie im Handbucheintrag über Device Nodes.

Benutzen Sie die Kernel-Erweiterungen und Benutzerprogramme aus dem Programmpaket SMBFS. Das Paket und weitergehende Informationen sind unter net/smbfs in den Ports verfügbar; ab der Version 4.5 ist SMBFS Bestandteil des Basissystems.

Mit dieser Meldung teilt Ihnen der Kernel mit, dass irgend jemand versucht, ihn zur Generierung von zu vielen ICMP oder TCP reset (RST) Antworten zu provozieren. ICMP Antworten sind oft das Ergebnis von Verbindungsversuchen zu unbenutzten UDP Ports. TCP Resets werden generiert, wenn jemand versucht, eine Verbindung zu einem ungenutzten TCP Port aufzubauen. Die Meldungen können unter anderem durch die folgenden Ereignisse ausgelöst werden:

• Denial of Service (DoS) Angriffe mit der Brechstange (und nicht durch Angriffe mit einzelnen Paketen, die gezielt eine Schwachstelle des Systems ausnutzen sollen).

• Port Scans, bei denen versucht wird, Verbindungen zu einer großen Anzahl von Ports (und nicht nur einigen bekannten Ports) herzustellen.

Die erste Zahl gibt an, wie viele Pakete vom Kernel ohne das Limit versendet worden wären; die zweite Zahl gibt das Limit an. Sie können das Limit mit Hilfe der sysctl-Variable net.inet.icmp.icmplim einstellen. Im Beispiel wird das Limit auf 300 Pakete pro Sekunde gesetzt:

# sysctl -w net.inet.icmp.icmplim=300

Wenn Sie zwar die Begrenzung benutzen möchten, aber die Meldungen nicht in Ihren Logfiles sehen möchten, können Sie die Meldungen mit der sysctl-Variable net.inet.icmp.icmplim_output abschalten:

# sysctl -w net.inet.icmp.icmplim_output=0

Falls Sie die Begrenzung ganz abschalten wollen, können Sie die Sysctl-Variable net.inet.icmp.icmplim auf 0. Wir raten Ihnen aus den oben genannten Gründen dringend von diesem Schritt ab.

Ein Gerät im lokalen Ethernet verwendet eine MAC-Adresse in einem Format, das FreeBSD nicht kennt. Der wahrscheinlichste Grund ist, dass jemand Experimente mit einer Ethernet-Karte anstellt. Die Meldung tritt sehr häufig in Netzwerken mit Cable Modems auf. Die Meldung ist harmlos und sollte die Performance Ihres Systems nicht negativ beeinflussen.

Schauen Sie bitte zuerst nach, ob Sie eine Fehlermeldung wie die unten gezeigte erhalten.

/usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found

Solche Fehlermeldungen erhalten Sie, wenn Sie den net/cvsup Port auf einer Maschine installieren, die kein XFree86™-System besitzt. Wenn Sie das GUI von CVSup benutzen wollen, müssen Sie XFree86 installieren. Wenn Sie CVSup nur auf der Kommandozeile benutzen wollen, entfernen Sie bitte den Port, den Sie gerade installiert haben. Installieren Sie stattdessen den Port net/cvsup-without-gui. Genauere Informationen finden Sie im CVSup Abschnitt des Handbuchs.