From owner-svn-doc-all@freebsd.org Sat Dec 28 22:50:27 2019 Return-Path: Delivered-To: svn-doc-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 353221CAA8E; Sat, 28 Dec 2019 22:50:27 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47lf6W1GwHz3LCY; Sat, 28 Dec 2019 22:50:27 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 227D68215; Sat, 28 Dec 2019 22:50:27 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id xBSMoRw0095559; Sat, 28 Dec 2019 22:50:27 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id xBSMoRmt095558; Sat, 28 Dec 2019 22:50:27 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201912282250.xBSMoRmt095558@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Sat, 28 Dec 2019 22:50:27 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r53713 - head/de_DE.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head X-SVN-Commit-Author: bhd X-SVN-Commit-Paths: head/de_DE.ISO8859-1/books/handbook/firewalls X-SVN-Commit-Revision: 53713 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 22:50:27 -0000 Author: bhd Date: Sat Dec 28 22:50:26 2019 New Revision: 53713 URL: https://svnweb.freebsd.org/changeset/doc/53713 Log: Update to r53486: Rewrite the NAT chapter to focus on in-kernel NAT, with a small section about natd at the end. Reviewed by: bcr Differential Revision: https://reviews.freebsd.org/D22944 Modified: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Dec 28 21:32:11 2019 (r53712) +++ head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Dec 28 22:50:26 2019 (r53713) @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/firewalls/chapter.xml,v 1.53 2012/04/30 16:15:52 bcr Exp $ - basiert auf: r53425 + basiert auf: r53486 --> - + - <acronym>NAT</acronym> Konfiguration + In-Kernel <acronym>NAT</acronym> @@ -2302,6 +2302,16 @@ $ Beigetragen von + + + + + Dries + Michiels + + Aktualisiert von + + @@ -2325,58 +2335,50 @@ $ mit dem internen Netzwerk. Jeder Rechner im internen Netzwerk sollte eine RFC - 1918 konforme Adresse zugewiesen bekommen. Zudem - muss das Standard-Gateway der Rechner auf die interne - IP-Adresse des &man.natd.8;-Systems - gesetzt werden. + 1918 konforme Adresse zugewiesen bekommen. Es ist noch ein wenig Konfiguration nötig, um die - NAT-Funktion von - IPFW zu aktivieren. Wenn das - System einen angepassten Kernel hat, muss die - Kernelkonfigurationsdatei die Zeile - option IPDIVERT sowie weitere - IPFIREWALL-Optionen, die in beschrieben sind, - enthalten. - - Um die NAT-Unterstützung beim Booten - zu aktivieren, müssen folgende Einträge in + In-Kernel NAT-Funktion von + IPFW zu aktivieren. Um die + In-Kernel NAT-Unterstützung beim Booten zu + aktivieren, müssen folgende Einträge in /etc/rc.conf vorhanden sein: - gateway_enable="YES" # enables the gateway -natd_enable="YES" # enables NAT -natd_interface="rl0" # specify interface name of NIC attached to Internet -natd_flags="-dynamic -m" # -m = preserve port numbers; additional options are listed in &man.natd.8; + gateway_enable="YES" +firewall_enable="YES" +firewall_nat_enable="YES" - Es ist auch möglich eine Konfigurationsdatei zu - verwenden, welche die Optionen enthält, die an - &man.natd.8; übergeben werden: - - natd_flags="-f /etc/natd.conf" - - Die angegebene Datei muss die Konfigurationsoptionen - enthalten, eine Option pro Zeile. Zum Beispiel: - - redirect_port tcp 192.168.0.2:6667 6667 -redirect_port tcp 192.168.0.3:80 80 - - Weitere Informationen zu dieser Konfigurationsdatei - finden Sie in &man.natd.8;. + Wenn firewall_enable nicht gesetzt + ist, firewall_nat_enable jedoch schon, + hat dies keine Auswirkung, da die + NAT-Implementierung im Kernel nur mit + IPFW kompatibel ist. - Als nächstes werden die NAT-Regeln - hinzugefügt. Wenn die Regeln zustandsorientiert sind, ist die - Platzierung der NAT-Regeln sehr wichtig und - die skipto-Aktion wird verwendet. Dies - erfordert, dass jede Regel über eine eindeutige Nummer - verfügt, um eindeutige Sprungziele zu erhalten. + Wenn der Regelsatz zustandsorientierte Regeln enthält, ist + die Position der NAT-Regel kritisch und die + skipto-Aktion wird benutzt. Die Aktion + skipto benötigt eine Regelnummer, damit + IPFW weiß, zu welcher Regel es + springen muss. Darüber hinaus ist es aufgrund der Architektur + von &man.libalias.3;, einer Bibliothek die als Kernelmodul + implementiert ist und für das In-Kernel NAT + von IPFW benutzt wird, notwendig, + TCP segmentation offloading + (TSO) zu deaktivieren. + TSO kann pro Netzwerkschnittstelle mit + &man.ifconfig.8;, oder systemweit mit &man.sysctl.8; + deaktiviert werden. Um TSO systemweit zu + deaktivieren, muss folgende Zeile in + /etc/sysctl.conf enthalten sein: - Das folgende Beispiel baut auf dem im vorherigen Abschnitt + net.inet.tcp.tso="0" + + Das folgende Beispiel baut auf den im vorherigen Abschnitt gezeigten Firewall-Relgelsatz auf. Es werden einige neue Einträge hinzugefügt und bestehende Regeln modifiziert, um - NAT zu konfigurieren. Zunächst werden + In-Kernel NAT zu konfigurieren. Zunächst werden einige Variablen hinzugefügt, darunter Regelnummern, die keep-state-Option und eine Liste mit TCP-Ports um die Anzahl der Regeln zu @@ -2385,24 +2387,74 @@ redirect_port tcp 192.168.0.3:80 80 #!/bin/sh ipfw -q -f flush cmd="ipfw -q add" -skip="skipto 500" +skip="skipto 1000" pif=dc0 ks="keep-state" good_tcpo="22,25,37,53,80,443,110" + Danach wird eine NAT-Instanz + konfiguriert. Mit In-Kernel NAT ist es + möglich, mehrere NAT-Instanzen mit jeweils + eigener Konfiguration zu betreiben. In diesem Beispiel wird + jedoch nur eine NAT-Instanz mit der Nummer + 1 benötigt. Die Konfiguration nimmt ein paar Argumente und + Schalter an, zum Beispiel: , dass die + öffentliche Netzwerkschnittstelle angibt, + , das dafür sorgt, dass Alias-Ports + und lokale Portnummern identisch zugeordnet werden, + führt dazu, dass nur + unregistrierte (private) Adressräume von der + NAT-Instanz verarbeitet werden, und + , was dazu beiträgt, dass eine + NAT-Instanz auch dann erhalten bleibt, + wenn sich die öffentliche IP-Adresse des + Rechners ändert. Weitere mögliche Optionen, die an einzelne + NAT-Instanzen übergeben werden können, + finden Sie in &man.ipfw.8;. Darüber hinaus ist es aufgrund + der zustandsorientierten NAT-Firewall + notwendig, dass übersetzte Pakete zur weiteren Verarbeitung in + die Firewall eingespielt werden können, was durch die + Deaktivierung des -Verhaltens beim + Start des Firewall-Skripts erreicht werden kann. + + ipfw disable one_pass +ipfw -q nat 1 config if $pif same_ports unreg_only reset + Die NAT-Regel für eingehende Pakete wird nach den beiden Regeln, die das - interne Netzwerk und die Loopback-Schnittstelle erlauben und - vor der + interne Netzwerk und die Loopback-Schnittstelle erlauben, und + nach der Reassamble-Regel, aber vor der check-state-Regel eingefügt. Es ist wichtig, dass die Nummer der NAT-Regel (in diesem Beispiel 100) höher ist, als - die beiden vorherigen Regeln und niedriger, als die - check-state-Regel: + die drei vorherigen Regeln und niedriger, als die + check-state-Regel. Darüber hinaus wird + aufgrund des Verhaltens von In-Kernel NAT + empfohlen, eine Reassamble-Regel kurz vor der ersten + NAT-Regel, aber hinter den Regeln zu + platzieren, die den Datenverkehr auf einer vertrauenswürdigen + Schnittstelle erlauben. + + Die Reassamble-Regel wird beim Userland &man.natd.8; + nicht benötigt, da die Aktion divert von + IPFW dies bereits automatisch + übernimmt. Dies ist auch in &man.ipfw.8; + dokumentiert. + + Beachten Sie, dass die aktuelle + NAT-Instanznummer und + NAT-Regelnummer nicht mit der + voreingestellten NAT-Instanznummer + und Regelnummer übereinstimmt, wenn sie mit dem + rc.firewall-Skript von &os; erstellt + wurde. + + $cmd 005 allow all from any to any via xl0 # exclude LAN traffic $cmd 010 allow all from any to any via lo0 # exclude loopback traffic -$cmd 100 divert natd ip from any to any in via $pif # NAT any inbound packets +$cmd 099 reass all from any to any in # reassamble inbound packets +$cmd 100 nat 1 ip from any to any in via $pif # NAT any inbound packets # Allow the packet through if it has an existing entry in the dynamic rules table $cmd 101 check-state @@ -2410,12 +2462,18 @@ good_tcpo="22,25,37,53,80,443,110" modifiziert, um Aktionen mit der $skipto-Variable zu erlauben und anzuzeigen, dass die Prüfung mit der Regel - 500 fortgesetzt wird. Die sieben Regeln + 1000 fortgesetzt wird. Die sieben Regeln für TCP wurden durch die Regel 125 ersetzt, da die sieben erlaubten ausgehenden Ports in der Variable $good_tcp0 enthalten sind. + + Beachten Sie, dass die Leistung von + IPFW weitgehend von der Anzahl + der im Regelsatz vorhandenen Regeln bestimmt wird. + + # Authorized outbound packets $cmd 120 $skip udp from any to x.x.x.x 53 out via $pif $ks $cmd 121 $skip udp from any to x.x.x.x 67 out via $pif $ks @@ -2431,19 +2489,19 @@ good_tcpo="22,25,37,53,80,443,110" Regel haben und die Nummer muss über die skipto-Aktion referenziert werden. In diesem Regelsatz leitet die Regel mit der Nummer - 500 alle ausgehenden Pakete zur - Weiterverarbeitung an &man.natd.8; weiter. Die darauf + 1000 alle ausgehenden Pakete zur + konfigurierten NAT-Instanz weiter. Die darauf folgende Regel lässt alle von NAT verarbeiteten Pakete passieren. - $cmd 499 deny log all from any to any -$cmd 500 divert natd ip from any to any out via $pif # skipto location for outbound stateful rules -$cmd 510 allow ip from any to any + $cmd 999 deny log all from any to any +$cmd 1000 nat 1 ip from any to any out via $pif # skipto location for outbound stateful rules +$cmd 1001 allow ip from any to any In diesem Beispiel steuern die Regeln 100, 101, - 125, 500 und - 510 die Adressübersetzung der ein- und + 125, 1000 und + 1001 die Adressübersetzung der ein- und ausgehende Pakete, so dass immer die private LAN IP-Adresse in der dynamische Zustandstabelle registriert werden. @@ -2463,7 +2521,7 @@ good_tcpo="22,25,37,53,80,443,110" Regel zutreffen, werden zwei Aktionen ausgeführt. Zuerst wird durch die Aktion keep-state ein dynamischer Eintrag in der Statustabelle erstellt und die - angegebene Aktion skipto 500 ausgeführt. + angegebene Aktion skipto 1000 ausgeführt. Als nächstes durchläuft das Paket NAT und wird dann an das Internet gesendet. Nachdem dieses Paket am Webserver angekommen ist, wird dort eine Antwort erzeugt und @@ -2485,14 +2543,44 @@ good_tcpo="22,25,37,53,80,443,110" LAN freigegeben. Das Antwortpaket wird von der Regel check-state als Paket einer aktiven Sitzung erkannt. Das Paket wird dann von Regel - 500 per NAT - verarbeitet, bevor es über die externe Schnittstelle versendet - wird. + 1000 per NAT + verarbeitet, bevor es über die externe Schnittstelle + verschickt wird. + + Der Wechsel vom Userland &man.natd.8; zu In-Kernel + NAT mag zunächst nahtlos erscheinen, aber + es gibt einen kleinen Haken. Bei Verwendung des + GENERIC-Kernels wird + IPFW das Kernelmodul + libalias.ko laden, wenn + firewall_nat_enable in + rc.conf aktiviert ist. Das geladene + Kernelmodul stellt nur grundlegende + NAT-Funktionalität bereit, während + die Userland-Implementierung &man.natd.8; alle + Funktionalitäten ohne zusätzliche Konfiguration zur + Verfügung stellt. Die gesamte Funktionalität bezieht sich + auf die folgenden Kernelmodule, die bei Bedarf zusätzlich + zu libalias.ko geladen werden können: + alias_cuseeme.ko, + alias_ftp.ko, + alias_bbt.ko, + skinny.ko, irc.ko, + alias_pptp.ko und + alias_smedia.ko unter Verwendung der + kld_list Direktive in + rc.conf, um die volle Funktionalität + der Userland-Implementierung zu erreichen. Wenn ein + angepasster Kernel benutzt wird, kann die volle + Funktionalität der Userland-Bibliothek im Kernel mit + gebaut werden. + + Weiterleitung von Ports - Der Nachteil von &man.natd.8; ist, dass die Rechner im + Der Nachteil von NAT ist, dass die Rechner im LAN nicht aus dem Internet zugänglich sind. Diese Rechner können zwar ausgehende Verbindungen zur Außenwelt aufbauen, jedoch keine eingehenden @@ -2501,7 +2589,7 @@ good_tcpo="22,25,37,53,80,443,110" anbieten möchten, die aus dem Internet erreichbar sein sollen. In diesem Fall können Sie die Ports, welche über das Internet erreichbar sein sollen, über die - &man.natd.8;-Maschine an den Rechner im + NAT-Maschine an den Rechner im LAN weiterleiten. Angenommen es gibt einen IRC-Server @@ -2511,39 +2599,42 @@ good_tcpo="22,25,37,53,80,443,110" (IRC) und 80 (HTTP) an die jeweiligen Rechner weitergeleitet werden. - Die Syntax für - lautet: + Bei In-Kernel NAT wird die gesamte + Konfiguration in der NAT-Instanz selbst + vorgenommen. Alle Optionen, die in einer + NAT-Instanz benutzt werden können, sind + in &man.ipfw.8; dokumentiert. Die Syntax für + IPFW folgt dabei der von + natd. Die Syntax für + lautet: - -redirect_port proto targetIP:targetPORT[-targetPORT] - [aliasIP:]aliasPORT[-aliasPORT] - [remoteIP[:remotePORT[-remotePORT]]] + redirect_port proto targetIP:targetPORT[-targetPORT] + [aliasIP:]aliasPORT[-aliasPORT] + [remoteIP[:remotePORT[-remotePORT]]] Für das obige Beispiel sollten die Argumente wie folgt aussehen: - -redirect_port tcp 192.168.0.2:6667 6667 --redirect_port tcp 192.168.0.3:80 80 + redirect_port tcp 192.168.0.2:6667 6667 +redirect_port tcp 192.168.0.3:80 80 - Damit werden die entsprechenden - TCP-Ports an die Rechner im - LAN weitergeleitet. + Nachdem diese Argumente der Konfiguration der + NAT-Instanz 1 im obigen Regelsatz + hinzugefügt wurden, werden die TCP-Ports + an die Rechner im LAN weitergeleitet, auf + denen IRC- und + HTTP-Dienste laufen. - Portbereiche können über + ipfw -q nat 1 config if $pif same_ports unreg_only reset \ + redirect_port tcp 192.168.0.2:6667 6667 \ + redirect_port tcp 192.1683.0.3:80 80 + + Portbereiche können über festgelegt werden. Zum Beispiel würde tcp 192.168.0.2:2000-3000 2000-3000 alle Verbindungen auf die Ports 2000 bis 3000 an die Ports 2000 bis 3000 an Rechner A weiterleiten. - - Diese Optionen können über - natd_flags="" in - /etc/rc.conf direkt beim Start an - &man.natd.8; übergeben werden. Alternativ können die - Optionen in eine Konfigurationsdatei eingetragen - werden. - - Weitere Konfigurationsmöglichkeiten sind in - &man.natd.8; beschrieben. @@ -2552,9 +2643,9 @@ good_tcpo="22,25,37,53,80,443,110" Das Weiterleiten von Adressen ist nützlich, wenn mehr als eine IP-Adresse zur Verfügung steht. Jeder Rechner im LAN kann über - &man.natd.8; seine eigene externe + &man.ipfw.8; seine eigene externe IP-Adresse zugewiesen bekommen. - &man.natd.8; wird dann den ausgehenden Datenverkehr der + IPFW wird dann den ausgehenden Datenverkehr der Rechner aus dem LAN mit der entsprechenden externen IP-Adresse umschreiben. Auch der eingehenden Datenverkehr über die @@ -2568,56 +2659,103 @@ good_tcpo="22,25,37,53,80,443,110" 128.1.1.3 zur Verfügung stehen, kann 128.1.1.1 als externe - Adresse der &man.natd.8;-Maschine verwendet werden, während + Adresse der &man.ipfw.8;-Maschine verwendet werden, während 128.1.1.2 und 128.1.1.3 an Rechner A und Rechner B im LAN weitergeleitet werden. - Die Syntax für - lautet: + Die Syntax für + lautet wie im Folgenden, wobei localIP + die interne IP-Adresse des Rechners im + LAN, und publicIP die + externe IP-Adresse ist, die dem Rechner + im LAN entspricht. - -redirect_address localIP publicIP + redirect_address localIP publicIP - - - - - localIP - Die interne IP-Adresse des - Rechners im LAN. - + Auf das Beispiel bezogen, würden die Argumente so + lauten: - - publicIP - Die externe IP-Adresse für - den entsprechenden Rechner im - LAN. - - - - + redirect_address 192.168.0.2 128.1.1.2 +redirect_address 192.168.0.3 128.1.1.3 - Für das obige Beispiel sollten die Argumente wie - folgt aussehen: + Genau wie bei , werden + diese Argumente in der Konfiguration der + NAT-Instanz gesetzt. Bei der + Weiterleitung von Adressen ist keine Portumleitung + notwendig, da alle Daten, die auf einer bestimmten + IP-Adresse empfangen werden, + weitergeleitet werden. - -redirect_address 192.168.0.2 128.1.1.2 --redirect_address 192.168.0.3 128.1.1.3 - - Genau wie bei , werden - diese Argumente innerhalb der - /etc/rc.conf-Option - natd_flags="" angegeben, oder alternativ - über eine Konfigurationsdatei. Allerdings müssen beim - Weiterleiten von Adressen keine Ports umgeleitet werden, da - der gesamte eingehende Datenverkehr einer bestimmte - IP-Adresse weitergeleitet wird. - Die externe IP-Adresse der - &man.natd.8;-Maschine muss auf der externen Schnittstelle + &man.ipfw.8;-Maschine muss auf der externen Schnittstelle aktiv und mit einem Alias versehen sein. Weitere - Einzelheiten sind in &man.natd.8; beschrieben. + Einzelheiten sind in &man.rc.conf.5;; beschrieben. + + + + Userland <acronym>NAT</acronym> + + Zunächst sei gesagt, dass &man.natd.8;, die + Userland-Implementierung aufwändiger ist als In-Kernel + NAT. Damit &man.natd.8; Pakete + übersetzen kann, müssen die Pakete vom Kernel ins + Userland und zurück kopiert werden, was zusätzlichen Aufwand + mit sich bringt. Dieser Aufwand entfällt bei In-Kernel + NAT. + + Um den Userland NAT-Daemon + &man.natd.8; beim Systemstart zu aktivieren, ist etwas + Konfiguration in /etc/rc.conf nötig. + wird auf den Namen der mit + dem Internet verbundenen Schnittstelle gesetzt. Das + &man.rc.8;-Skript von &man.natd.8; wird selbstständig + prüfen, ob eine dynamische IP-Adresse + benutzt wird und sich selbst so konfigurieren, dass es damit + umgehen kann. + + gateway_enable="YES" +natd_enable="YES" +natd_interface="rl0" + + Generell kann der obige Regelsatz, wie er für In-Kernel + NAT erklärt wurde, auch zusammen mit + &man.natd.8; benutzt werden. Die einzigen Ausnahmen sind, + dass die Konfiguration der In-Kernel + NAT-Instanz + (ipfw -q nat 1 config ...) nicht + anwendbar ist und die Regeln müssen wie unten beschrieben + leicht geändert werden, und Regel 99 wird nicht mehr + benötigt, da die -Aktion sich um die + Fragmentierung kümmert. + + $cmd 100 divert natd ip from any to any in via $pif +$cmd 1000 divert natd ip from any to any out via $pif + + Um eine Port- oder Adressumleitung zu konfigurieren, + wird eine ähnliche Syntax wie bei In-Kernel + NAT verwendet. Anstatt die Konfiguration + in unserem Regelsatz-Skript wie bei In-Kernel + NAT anzugeben, wird die Konfiguration von + &man.natd.8; am besten in einer Konfigurationsdatei + vorgenommen. Dazu muss eine zusätzliche Option in + /etc/rc.conf übergeben werden, welche + den Pfad zur Konfigurationsdatei angibt. + + natd_flags="-f /etc/natd.conf" + + + Die Konfigurationsdatei muss eine Liste von Optionen + enthalten, eine pro Zeile. Weitere Informationen über die + Konfigurationsdatei und mögliche Variablen finden Sie in + &man.natd.8;. Hier zwei Beispieleinträge, einer pro + Zeile: + + redirect_port tcp 192.168.0.2:6667 6667 +redirect_address 192.168.0.3 128.1.1.3 +