From owner-svn-doc-head@freebsd.org Thu Mar 5 20:40:00 2020 Return-Path: Delivered-To: svn-doc-head@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 430EF24BC42; Thu, 5 Mar 2020 20:40:00 +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 48YN0b3wShz4NQP; Thu, 5 Mar 2020 20:39:59 +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 E55ACD09D; Thu, 5 Mar 2020 20:39:58 +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 025Kdwwj067947; Thu, 5 Mar 2020 20:39:58 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id 025KdwJv067946; Thu, 5 Mar 2020 20:39:58 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <202003052039.025KdwJv067946@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Thu, 5 Mar 2020 20:39:58 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r53950 - 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: 53950 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 20:40:00 -0000 Author: bhd Date: Thu Mar 5 20:39:58 2020 New Revision: 53950 URL: https://svnweb.freebsd.org/changeset/doc/53950 Log: Update to r53911: - Simplify multiple sentences to remove the words: furthermore, also, ... - Fix typo's, IP address is redirect_port example & visible double space after sentence stop - Restructure TSO comment together with the in-kernel NAT instance paragraph - Add kernel option for libalias full functionality - Unify engine/facility/... to facility 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 Thu Mar 5 15:42:09 2020 (r53949) +++ head/de_DE.ISO8859-1/books/handbook/firewalls/chapter.xml Thu Mar 5 20:39:58 2020 (r53950) @@ -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: r53723 + basiert auf: r53911 --> und IPFW - &os;s integrierter NAT-Daemon, - &man.natd.8;, arbeitet in Verbindung mit - IPFW, um - Network Address Translation - bereitzustellen. NAT wird verwendet, um - mehreren internen Rechnern, über eine einzige - IP-Adresse, eine gemeinsame Verbindung zum - Internet zu ermöglichen. + Die IPFW-Firewall von &os; hat + zwei NAT-Implementierungen: die + Userland-Implementierung &man.natd.8; und die neuere, + kernelinterne NAT-Implementierung. Beide + arbeiten in Verbindung mit IPFW, um + die Übersetzung von Netzwerkadressen zu ermöglichen. Damit + kann eine Lösung zur gemeinsamen Nutzung der + Internetverbindung bereitgestellt werden, so dass mehrere + interne Rechner unter Verwendung einer einzigen öffentlichen + IP-Adresse eine Verbindung zum Internet + herstellen können. Um dies zu tun, muss der mit dem Internet verbundene &os;-Rechner als Gateway eingerichtet sein. Das System muss @@ -2349,8 +2352,8 @@ firewall_enable="YES" firewall_nat_enable="YES" - Wenn firewall_enable nicht gesetzt - ist, firewall_nat_enable jedoch schon, + Wenn firewall_nat_enable gesetzt ist, + firewall_enable jedoch nicht, hat dies keine Auswirkung, da die NAT-Implementierung im Kernel nur mit IPFW kompatibel ist. @@ -2361,25 +2364,12 @@ firewall_nat_enable="YES" 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: - - 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 - In-Kernel NAT zu konfigurieren. Zunächst werden - einige Variablen hinzugefügt, darunter Regelnummern, die + springen muss. 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 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 reduzieren: @@ -2392,13 +2382,28 @@ pif=dc0 ks="keep-state" good_tcpo="22,25,37,53,80,443,110" + Bei In-Kernel NAT muss aufgrund der + Architektur von &man.libalias.3;, einer Bibliothek, die als + Kernel-Modul implementiert ist, um die In-Kernel + NAT-Funktion für + IPFW bereitzustellen, + TCP segment offloading + (TSO) deaktiviert werden. + 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: + + net.inet.tcp.tso="0" + 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 + 1 benötigt. Die Konfiguration kann ein paar Optionen + enthalten, zum Beispiel: , dass die öffentliche Netzwerkschnittstelle angibt, , das dafür sorgt, dass Alias-Ports und lokale Portnummern identisch zugeordnet werden, @@ -2410,8 +2415,8 @@ good_tcpo="22,25,37,53,80,443,110" 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 + finden Sie in &man.ipfw.8;. Wenn eine zustandsorientierte + NAT-Firewall konfiguriert wird, ist es notwendig, dass übersetzte Pakete zur weiteren Verarbeitung in die Firewall eingespielt werden können, was durch die Deaktivierung des -Verhaltens beim @@ -2433,20 +2438,26 @@ ipfw -q nat 1 config if $pif same_ports unreg_o 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. + Schnittstelle erlauben. In der Regel sollte es nicht zu einer + Fragmentierung kommen, aber bei getunnelten + IPSEC/ESP/GRE-Verkehr kann es vorkommen, + und das Zusammensetzen von Fragmenten ist notwendig, bevor das + komplette Paket an das In-Kernel NAT + übergeben werden kann. - + 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. + übernimmt, bevor das Paket an den Socket ausgeliefert wird. + 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 + NAT-Regelnummer in diesem Beispiel + nicht mit der voreingestellten + NAT-Instanznummer und Regelnummer + übereinstimmt, wenn sie mit dem rc.firewall-Skript von &os; erstellt wurde. @@ -2555,10 +2566,10 @@ ipfw -q nat 1 config if $pif same_ports unreg_o 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 + rc.conf aktiviert ist. Das + Kernelmodul libalias.ko 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 @@ -2570,11 +2581,10 @@ ipfw -q nat 1 config if $pif same_ports unreg_o 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 + rc.conf. Wenn ein angepasster Kernel benutzt wird, kann die volle Funktionalität der Userland-Bibliothek im Kernel mit - gebaut werden. + gebaut werden. @@ -2627,7 +2637,7 @@ redirect_port tcp 192.168.0.3:80 80 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 + redirect_port tcp 192.168.0.3:80 80 Portbereiche können über festgelegt werden. Zum Beispiel würde @@ -2722,14 +2732,13 @@ 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. + &man.natd.8; benutzt werden. Die Ausnahmen sind die + Konfiguration der In-Kernel NAT-Instanz + (ipfw -q nat 1 config ...), die nicht + zusammen mit der Regel 99 benötigt wird, da die + -Aktion sich um die Fragmentierung + kümmert. Die Regeln 100 und 1000 müssen leicht modifiziert + werden, wie unten gezeigt. $cmd 100 divert natd ip from any to any in via $pif $cmd 1000 divert natd ip from any to any out via $pif @@ -2968,7 +2977,8 @@ ks="keep-state" # just too lazy to key this eac options IPFIREWALL_VERBOSE # enables logging for rules with log keyword to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=5 # limits number of logged packets per-entry options IPFIREWALL_DEFAULT_TO_ACCEPT # sets default policy to pass what is not explicitly denied -options IPFIREWALL_NAT # enables in-kernel NAT support +options IPFIREWALL_NAT # enables basic in-kernel NAT support +options LIBALIAS # enables full in-kernel NAT support options IPFIREWALL_NAT64 # enables in-kernel NAT64 support options IPFIREWALL_NPTV6 # enables in-kernel IPv6 NPT support options IPFIREWALL_PMOD # enables protocols modification module support