\documentclass[a4paper]{article} \usepackage{linuxdoc-sgml} \usepackage{qwertz} \usepackage{url} \usepackage[latin1]{inputenc} \usepackage[german]{babel} \usepackage{amsmath} \usepackage{amssymb} \usepackage{epsfig} \usepackage{null} \def\addbibtoc{ \addcontentsline{toc}{section}{\numberline{\mbox{}}\relax\bibname} }%end-preamble \title{Linux 2.4 NAT HOWTO} \author{Rusty Russell, Mailingliste {\ttfamily netfilter@lists.samba.org}} \date{v1.0.1 Mon May 1 18:38:22 CST 2000} \begin{document} \maketitle Ins Deutsche übersetzt von Melanie Berg (mel@sekurity.de) \abstract{Dieses Dokument beschreibt, wie man Masquerading, transparente Proxies, Port Forwarding und andere Formen der Network Address Translation mit dem 2.4er Linuxkernel einsetzen kann. Diese deutsche Übersetzung steht unter den Bedingungen der GNU General Public License (http://www.gnu.org/copyleft/gpl.html)} \tableofcontents \section{Einleitung\label{intro}} Willkommen, geschätzter Leser, Du bist dabei, in die faszinierende (und manchmal schreckliche) Welt der NAT einzutauchen: Network Address Translation, und dieses HOWTO wird etwas wie Dein Führer zum 2.4er Kernel und weiter sein. Mit Linux 2.4 wurde eine Infrastruktur für das Untersuchen von Paketen, genannt `netfilter', eingeführt. Eine darauf aufbauende Schicht bietet NAT, komplett von den vorangegangenen Kerneln neu implementiert. \section{Wo ist die offizielle Website und Mailingliste?} Es gibt drei offizielle Seiten: \begin{itemize} \item Dank an \nameurl{http://antarctica.penguincomputing.com/~netfilter/}{Penguin Computing}. \item Dank an \nameurl{http:/netfilter.samba.org/}{The Samba Team and SGI}. \item Dank an \nameurl{http://netfilter.kernelnotes.org}{Jim Pick}. \end{itemize} Für die offizielle Netfilter-Mailingliste siehe Sambas Listserver \nameurl{http://lists.samba.org}{Samba's Listserver}. \subsection{Was ist Network Address Translation?} Gewöhnlich reisen Pakete in einem Netzwerk von ihrer Quelle (z.B. Dein Computer) zu ihrem Ziel (z.B. www.kernelnotes.org) durch viele verschiedene Links: ungefähr 19 von da, wo ich in Australien bin. Keiner dieser Links verändert das Paket wirklich, sie schicken es einfach weiter. Wenn einer dieser Links NAT machen würde, dann würde er die Quelle oder das Ziel des Paket verändern, wenn es eintrifft. Wie Du Dir vorstellen kannst, wurde das System nicht entworfen, so zu arbeiten, also ist NAT immer etwas, was man mit Vorsicht behandeln sollte. Gewöhnlich wird sich der Link, der NAT macht, daran erinnern, wie er das Paket verändert hat, und wenn ein Antwortpaket aus der anderen Richtung kommt, wird er genau das Umgekehrte darauf anwenden, und so funktioniert es. \subsection{Warum sollte ich NAT wollen?} In einer perfekten Welt würdest Du das gar nicht. In der Zwischenzeit sind hier die Gründe: \begin{description} \item[Modemverbindungen zum Internet] \mbox{} Die meisten Internetanbieter geben Dir eine einzelne Adresse, wenn Du Dich bei ihnen einwählst. Du kannst Pakete mit welcher Quelladresse auch immer verschicken, aber nur Pakete mit dieser Antwortadresse werden zu Dir zurückkommen. Wenn Du mehrere verschiedene Maschinen (so wie ein Heim-Netzwerk) benutzen willst, um Dich durch diesen Link mit dem Internet zu verbinden, wirst Du NAT brauchen. Dies ist die heute am meisten verbreitete Art von NAT, gewöhnlich in der Linuxwelt als `Masquerading' bekannt. Ich nenne dies SNAT, weil die {\bfseries Quell} (`source') Adresse des ersten Pakets verändert wird. \item[Mehrere Server] \mbox{} Manchmal möchtest Du ändern, wohin einkommende Pakete in Deinem Netzwerk gehen sollen. Oft ist das so, weil Du (wie oben erwähnt) nur eine IP-Adresse hast, Du möchtest den Leuten aber die Möglichkeit geben, auch die Rechner hinter dem einen mit der `echten' IP-Adresse zu erreichen. Du kannst das schaffen, wenn Du das Ziel von einkommenden Paketen ändern kannst. Eine bekannte Variation dessen nennt sich `load-sharing': Eine große Anzahl von Paketen wird über eine Reihe von Maschinen verändert, indem die Pakete `aufgefächert' werden. Diese Version von NAT wurde unter früheren Linuxversionen Port-Forwarding genannt. \item[Transparente Proxies] \mbox{} Manchmal möchtest Du so tun, also ob jedes Paket, das durch Deinen Linuxrechner geht, für ein Programm auf dem Linuxrechner selbst bestimmt ist. Dies wird für transparente Proxies verwendet: ein Proxy ist ein Programm, das zwischen Deinem Netzwerk und der Außenwelt steht und die Kommunikation dazwischen regelt. Der transparente Teil kommt daher, weil Dein Netzwerk nicht einmal weiß, dass es mit mit einem Proxy redet, es sei denn natürlich, der Proxy funktioniert nicht. Squid kann auf diese Art konfiguriert werden, unter früherern Linuxversionen hieß das Umleiten (redirection) oder auch transparentes Proxying. \end{description} \section{Die zwei Formen von NAT} Ich unterscheide NAT in zwei verschiedene Typen: {\bfseries Source Nat} (SNAT) und {\bfseries Destination} NAT (DNAT). Wenn Du die Quelladresse des ersten Pakets änderst, ist das Source NAT: Du veränderst den Ursprung der Verbindung. Source NAT ist immer Post-% Routing, es wirkt, gerade bevor das Paket in die Leitung geht. Masquerading ist eine spezielle Form von SNAT. Wenn Du die Zieladresse des ersten Pakets anderst, ist das Destination NAT: Du veränderst das Ziel, wohin die Verbindung geht. Destination NAT ist immer Pre-Routing, gerade wenn das Paket aus der Leitung kommt. Port-Forwarding, load-sharing und transparente Proxies sind alles Formen von DNAT. \section{Schnelle Übersetzung vom 2.0er und 2.2er Kernel} Sorry an alle von Euch, die noch immer geschockt sind vom Übergang von 2.0 (ipfwadm) auf 2.2 (ipchains). Es gibt gute und schlechte Neuigkeiten. Zuerst einmal kannst Du ipfwadm und ipchains wie gewohnt weiterbenutzen. Um das zu tun, mußt Du das `ipchains.o' oder `ipfwadm.o' Kernelmodul aus der letzten netfilter-Distribution laden (insmod). Diese beiden schließen sich gegenseitig aus (Du bist gewarnt) und sollten nicht mit anderen netfilter-Modulen kombiniert werden. Sobald eins dieser Module installiert ist, kannst Du ipchains und ipfwadm wie gewohnt benutzen, mit den folgenden Unterschieden: \begin{itemize} \item Das Masquerading Timeout mit ipchains -M -S, oder mit ipfwadm -M -S, zu setzen, bringt nichts. Da die neuen Timeouts der neuen NAT-Infrastruktur länger sind, sollte das aber egal sein. \item Die init\_seq, delta und previous\_delta Felder in der ausführlichen Masqueradingliste sind immer Null. \item Gleichzeitig die Zähler auflisten und auf Null setzen (-Z -L) funktioniert nicht mehr: Die Zähler werden nicht zurückgesetzt. \end{itemize} Für Hacker: \begin{itemize} \item Du kannst jetzt auch Ports von 61000-65095 einbinden, sogar wenn Du Masquerading machst. Der Masquerading Code hatte früher angenommen, dass alles im diesem Bereich freigehalten werden sollte, so dass Programme ihn nicht nutzen konnten. \item Der (undokumentierte) `getsockname' Hack, welchen man nutzen konnte, um bei transparenten Proxies das wirkliche Ziel herauszufinden, funktioniert nicht mehr. \item Der (undokumentierte) `bind-to-foreign-address' Hack ist auch nicht implementiert; dies wurde verwendet, um die Illusion von transparenten Proxies komplett zu machen. \end{itemize} \subsection{Ich will nur Masquerading! Hilfe!} Das ist das, was die meisten Leute wollen. Wenn Du durch eine PPP-Verbindung eine dynamische IP-Adresse hast (wenn Du das nicht weißt, dann hast Du eine), möchtest Du Deinem Rechner einfach sagen, dass alle Pakete, die aus Deinem internen Netzwerk kommen, so aussehen sollen, als ob sie von dem Rechner mit der PPP-Verbindung kommen würden. \begin{tscreen} \begin{verbatim} # Das NAT-Modul laden (dies zieht all die andern mit). modprobe iptable_nat # In der NAT-Tabelle (-t nat) eine Regel fuer alle an ppp0 (-o ppp0) # ausgehenden Pakete hinter dem Routing (POSTROUTING), die maskiert # werden sollen, anhaengen (-A). iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # IP-Forwarding aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward \end{verbatim} \end{tscreen} Beachte, dass Du hier keine Pakete filterst: hierzu lese das Packet-% Filtering-HOWTO: Kombinieren von NAT und Paketfiltern. \subsection{Was ist mit ipmasqadm?} Das ist eine verzwicktere Sache, und ich habe mir hier keine großen Sorgen um die Rückwärts-Kompatibilität gemacht. Um Port-Forwarding zu verwenden, kannst Du einfach `iptables -t nat' benutzen. Unter Linux 2.2 hättest Du es zum Beispiel so machen können: \begin{tscreen} \begin{verbatim} # Linux 2.2 # TCP-Pakete, die an 1.2.3.4 Port 8080 gehen, an 192.168.1.1 Port 80 # weiterleiten ipmasqadm portfw -a -P tcp -L 1.2.3.4 8080 -R 192.168.1.1 80 \end{verbatim} \end{tscreen} Jetzt würdest Du folgendes tun: \begin{tscreen} \begin{verbatim} # Linux 2.4 # Eine Pre-Routing (PREROUTING) Regel an die NAT-Tabelle (-t nat) an- # haengen (-A), die besagt, dass alle TCP-Pakete (-p tcp) fuer 1.2.3.4 # (-d 1.2.3.4) Port 8080 (--dport) auf 192.168.1.1:80 # (--to 192.168.1.1:80) gemappt werden (-j DNAT). iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 8080 \ -j DNAT --to 192.168.1.1:80 \end{verbatim} \end{tscreen} Wenn Du willst, dass diese Regel auch lokale Verbindung verändert (ich meine, wenn sogar auf dem NAT-Rechner selbst ein Telnet auf 1.2.3.4 Port 8080 an 192.168.1.1 Port 80 geleitet wird), kannst Du diese Regel in die OUTPUT-Kette (für lokal ausgehende Pakete) einfügen: \begin{tscreen} \begin{verbatim} # Linux 2.4 iptables -A OUTPUT -t nat -p tcp -d 1.2.3.4 --dport 8080 \ -j DNAT --to 192.168.1.1:80 \end{verbatim} \end{tscreen} \section{Kontrollieren, worauf man NAT anwendet} Du mußt NAT-Regeln erstellen, die dem Kernel sagen, was für Verbindungen er ändern soll, und wie er sie ändern soll. Um das zu tun, setzen wir das vielseitige {\ttfamily iptables} Tool ein und sagen ihm durch das Angeben der `-t nat' Option, dass es die NAT-Tabelle ändern soll. Die Tabelle der NAT-Regeln enthält drei Listen, die `Ketten' genannt werden: Alle Regeln werden der Reihe nach untersucht, bis eine davon zutrifft. Die drei Ketten heißen PREROUTING (für Destination NAT, da die Pakete hereinkommen), POSTROUTING (für Source NAT, da die Pakete ausgehen) und OUTPUT (für Destination NAT von lokal generierten Paketen). Wenn ich irgendein künstlerisches Talent hätte, würde dieses Diagramm es ganz gut zeigen: %\begin{tscreen} %\begin{verbatim} % _____ _____ %/ \ / \ %PREROUTING -->[Routing ]----------------->POSTROUTING-----> %\D-NAT/ [Entscheidung] \S-NAT/ % | ^ % | __|__ % | / \ % | | OUTPUT| % | \D-NAT/ % | ^ % | | % -------->Lokaler Prozess------ %\end{verbatim} %\end{tscreen} \begin{center} {% Picture saved by xtexcad 2.4 \unitlength=1.000000pt \begin{picture}(320.00,140.00)(0.00,0.00) \put(290.00,120.00){\vector(1,0){30.00}} \put(40.00,120.00){\vector(1,0){30.00}} \put(20.00,120.00){\circle{40.00}} \put(20.00,120.00){\makebox(0.00,0.00){\shortstack{Pre-\\routing\\D-NAT}}} \put(150.00,120.00){\vector(1,0){100.00}} \put(110.00,0.00){\line(0,1){105.00}} \put(110.00,0.00){\vector(1,0){40.00}} \put(270.00,70.00){\vector(0,1){30.00}} \put(270.00,0.00){\vector(0,1){30.00}} \put(230.00,0.00){\line(1,0){40.00}} \put(190.00,0.00){\makebox(0.00,0.00){Lokaler Proze"s}} \put(270.00,50.00){\makebox(0.00,0.00){\shortstack{Out-\\put\\D-NAT}}} \put(270.00,50.00){\circle{40.00}} \put(270.00,120.00){\circle{40.00}} \put(270.00,120.00){\makebox(0.00,0.00){\shortstack{Post-\\routing\\S-NAT}}} \put(70.00,105.00){\framebox(80.00,30.00){\shortstack{Routing\\Entscheidung}}} \end{picture}} \end{center} Wenn ein Paket durchgeht, schauen wir an jedem der obigen Punkte nach, zu was für einer Verbindung es gehört. Wenn es eine neue Verbindung ist, sehen wir in der entsprechenden Kette der NAT-Tabelle nach, was zu tun ist. Die Antwort, die wir erhalten, wird auf alle weiteren Pakete dieser Verbindung angewendet. \subsection{Einfache Auswahl mit iptables} {\ttfamily iptables} benötigt eine Reihe von Standardoptionen, die weiter unten aufgelistet werden. Die Optionen mit einem doppelten Gedankenstrich können abgekürzt werden, solange {\ttfamily iptables} sie danach noch von den anderen Optionen unterscheiden kann. Wenn Dein Kernel {\ttfamily iptables} als Modul unterstützt, wirst Du das `iptables.o' Modul zuerst laden müssen: `insmod iptables.o'. Die wichtigste Option ist hier die, mit der man die Tabelle auswählen kann, `-t'. Für alle NAT Operationen wirst Du `-t nat' verwenden wollen, um in die NAT-Tabelle zu schreiben. Die zweitwichtigste Option ist das `-A', mit dem man eine neue Regel an das Ende einer Kette anhängen kann (z.B. `-A POSTROUTING'), oder `-I', um eine Regel am Anfang einer Kette einzufügen (z.B. `-I PREROUTING'). Du kannst die Quelle (`-s' oder `--source') und das Ziel (`-d' oder (`--destination') eines Pakets bestimmen, auf das Du NAT anwenden willst. Diesen Angaben kann eine einzelne IP-Adresse (z.B. 192.168.1.1), ein Name (z.B. www.kernelnotes.org) oder ein Netzwerkadresse (z.B. 192.168.1.0/24 oder 192.168.1.0/255.255.255.0) folgen. Du kannst die Schnittstelle bestimmen, an der Pakete eingehen (`-i' oder `--in-interface') oder ausgehen (`-o' oder `--out-interface'), aber welche von beiden hängt davon ab, in welche Kette Du diese Regel einfügst: Bei der PREROUTING-Kette kannst Du nur die eingehende Schnittstelle wählen, und bei der POSTROUTING-Schnittstelle (OUTPUT) nur die ausgehende. Wenn Du die falsche wählst, wird {\ttfamily iptables} Dir eine Fehlermeldung geben. \subsection{Genauere Auswahl der betreffenden Pakete} Ich habe weiter oben gesagt, dass Du eine Quell- und eine Zieladresse bestimmen kannst. Wenn Du die Quelladresse wegläßt, wird jegliche Adresse zutreffend sein. Wenn Du die Zieladresse wegläßt, wird jegliche Zieladresse zutreffend sein. Du kannst auch ein bestimmtes Protokoll (`-p' oder `--protocol') angeben, so wie TCP oder UDP; nur auf Pakete dieses Typs wird die Regel zutreffen. Der Hauptgrund hierfür besteht darin, dass das Bestimmen eines Protokolls Extra-Optionen erlaubt: insbesondere die `--source-port' und die `--destination-port' Optionen (abgekürzt als `-sport' und `-dport'). Diese Optionen erlauben Dir, zu bestimmen, dass eine Regel nur auf Pakete mit einem bestimmten Quell- oder Zielport zutrifft. Dies ist nützlich für umgeleitete Web-Anfragen (TCP-Port 80 und 8080) und läßt andere Pakete außer Acht. Diese Optionen müssen der `-p' Option folgen (welche den Nebeneffekt hat, dass die Erweiterungen für die shared libraries für das entsprechende Protokoll geladen werden). Du kannst Portnummern verwenden oder Namen aus der /etc/services Datei. All die verschiedenen Eigenschaften, nach denen Du Pakete auswählen kannst, werden in schmerzhaften Einzelheiten detailliert in der Man-Page beschrieben ({\ttfamily man iptables}). \section{Wie die Pakete verändert Werden sollen} Jetzt wissen wir also, wie wir die Pakete, die wir verändern wollen, auswählen können. Um unsere Regel zu vervollständigen, müssen wir dem Kernel sagen, was genau er mit dem Paket tun soll. \subsection{Source NAT} Du möchtest Source NAT machen; verändere die Quelladresse von Paketen zu etwas anderem. Dies wird in der POSTROUTING-Kette gemacht, kurz bevor das Paket schließlich geschickt wird; dies ist ein wichtiges Detail, da es bedeutet, dass alles andere auf dem Linuxrechner selbst (Routing, Paketfilter) das unveränderte Paket sehen wird. Es bedeutet auch, dass die `-o' (ausgehende Schnittstelle) Option verwendet werden kann. Source NAT wird durch `-j SNAT' bestimmt und die `--to-source' Option bestimmt eine IP-Adresse, eine Reihe von IP-Adressen, und einen optionalen Port oder eine Reihe von Ports (nur für UDP und TCP Protokolle). \begin{tscreen} \begin{verbatim} ## Quelladresse auf 1.2.3.4 aendern # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4 ## Quelladresse auf 1.2.3.4, 1.2.3.5, oder 1.2.3.5 aendern # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6 ## Quelladresse zu 1.2.3.4, Ports 1 - 1023, aendern # iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to \ # 1.2.3.4:1-1023 \end{verbatim} \end{tscreen} \subsubsection{Masquerading} Es gibt einen Spezialfall von Source NAT, der Masquerading genannt wird: es sollte nur für dynamisch zugeordnete IP-Adressen verwendet werden wie bei normalen Wählverbindungen (Benutze bei statischen IP-Adressen SNAT weiter oben). Beim Masquerading mußt Du die Quelladresse nicht explizit angeben: es wird die Quelladresse der Schnittstelle nehmen, an der das Paket ausgeht. Wichtiger ist, dass, wenn der Link unterbrochen wird, die Verbindungen (die jetzt sowieso verloren sind) vergessen werden, was weniger Störungen bedeutet, wenn die Verbindung mit einer neuen IP-Adresse wieder aufgebaut wird. \begin{tscreen} \begin{verbatim} ## Maskiere alles, was an ppp0 ausgeht # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE \end{verbatim} \end{tscreen} \subsection{Destination NAT} Dies wird in der PREROUTING-Kette erledigt, wenn das Paket gerade eingegangen ist; das bedeutet, dass alles andere auf dem Linuxrechner selbst (Routing, Paketfilter) das Paket zum `wirklichen' Ziel gehen sehen wird. Es bedeutet auch, dass die `-i' Option (eingehende Schnittstelle) verwendet werden kann. Um das Ziel von lokal generierten Paketen zu ändern, kann auch die OUTPUT-Kette benutzt werden, das ist aber eher ungewöhnlich. Destination NAT wird durch `-j DNAT' bestimmt und die `--to-destination' Option bestimmt eine IP-Adresse, eine Reihe von IP-Adressen, und einen optionalen Port oder eine Reihe von Ports (nur für UDP und TCP Protokolle). \begin{tscreen} \begin{verbatim} ## Zieladresse zu 5.6.7.8 aendern # iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 5.6.7.8 ## Zieladresse zu 5.6.7.8, 5.6.7.9 oder 5.6.7.10 aendern # iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 5.6.7.8-5.6.7.10 ## Aendern der Zieladresse von Webtraffic auf 5.6.7.8 Port 8080 # iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 \ -j DNAT --to 5.6.7.8:8080 ## Lokale Pakete fuer 1.2.3.4 an das Loopback umleiten # iptables -t nat -A OUTPUT -d 1.2.3.4 -j DNAT --to 127.0.0.1 \end{verbatim} \end{tscreen} \subsubsection{Umadressierung (Redirection)} Es gibt einen speziellen Fall von Destination NAT, der Redirection genannt wird: Es ist eine einfache Bequemlichkeit, die genau das gleiche tut wie NAT auf der eingehenden Schnittstelle. \begin{tscreen} \begin{verbatim} ## Eingehenden Webtraffic an Port 80 an unseren (transparenten) Squid- # Proxy weiterleiten # iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \ -j REDIRECT --to-port 3128 \end{verbatim} \end{tscreen} \subsection{Mappings genauer betrachtet} Es ist gibt ein paar subtile Einzelheiten bei NAT, um die sich die meisten Leute nie werden kümmern müssen. Für die Neugierigen sind sie hier dokumentiert. \subsubsection{Auswahl von mehrere Adressen in einer Reihe} Wenn eine Reihe von IP-Adressen gegeben ist, wir diejenige ausgewählt, die im Moment am wenigsten für IP-Verbindungen, von denen die Maschine weiß, benutzt wird. Dies macht primitives `load-balancing' möglich. \subsubsection{Ein Null NAT Mapping erstellen} Du kannst das `-j ACCEPT' Ziel verwenden, um eine Verbindung zuzulassen, ohne dass irgendein NAT stattfindet. \subsubsection{Standard NAT-Verhalten} Gewöhnlich verändert man eine Verbindung so wenig wie möglich, entsprechend den Vorgaben einer durch den Benutzer gegebenen Regel. Das bedeutet, dass wir Ports nicht `re-mappen' werden, solange wir es nicht unbedingt tun müssen. \subsubsection{Implizites Quellport-Mappen} Sogar, wenn für eine Verbindung kein NAT benötigt wird, kann Quellportveränderung stillschweigend auftreten, wenn eine andere Verbindung über die neue gemappt wurde. Stell Dir den Fall von Masquerading vor, der recht gewöhnlich ist: \begin{enumerate} \item Eine Webverbindung von einem Rechner 192.168.1.1 Port 1024 ist zu www.netscape.com Port 80 aufgebaut. \item Dies wird von einem Masquerading-Rechner maskiert, um 1.2.3.4 als Quelle zu verwenden. \item Der Masqerading-Rechner versucht, von 1.2.3.4 (die Adresse seiner externen Schnittstelle) Port 1024, eine Webverbindung zu www.netscape.com aufzubauen. \item Damit die Verbindung sich nicht überschneidet, wird der NAT-Code die Quelle der zweiten Verbindung auf 1025 ändern. \end{enumerate} Wenn dieses implizite Quell-Mapping auftaucht, werden Ports in drei Klassen aufgeteilt: \begin{itemize} \item Ports unter 512. \item Ports zwischen 512 und 1023. \item Ports ab 1024. \end{itemize} Ports werden niemals implizit in eine andere Klasse gemappt. \subsubsection{Was passiert, wenn NAT versagt} Wenn es keine Möglichkeit gibt, eine Verbindung einheitlich zu mappen wie es der Benutzer verlangt, so wird sie verworfen werden. Dies trifft auch auf Pakete zu, die nicht als Teil einer Verbindung klassifiziert werden konnten, weil sie beschädigt sind, oder der Rechner nicht genug Speicher hat, etc. \subsubsection{Mehrere Mappings, Overlaps und Clashes} Du kannst NAT-Regeln haben, die Pakete in denselben Bereich mappen; der NAT-Code ist clever genung, um Zusammenstöße zu vermeiden. Es ist also okay, zwei Regeln zu haben, die die Quelladressen 192.168.1.1 und 192.168.1.2 jeweils auf 1.2.3.4 mappen. Außerdem kannst Du über wirklich verwendete IP-Adressen mappen, solange diese Adressen auch durch den Mapping-Rechner müssen. Wenn Du also ein zugewiesenes Netzwerk (1.2.3.0/24) hast, aber auch ein internes Netzwerk, das dieselben Adressen benutzt, und eins, das private Internet Adressen (192.168.1.0/24) verwendet, kannst Du die 192.168.1.0/24-er Adressen auf das 1.2.3.0/24-er Netzwerk mappen, ohne Dir Sorgen um Zusammenstöße machen zu müssen: \begin{tscreen} \begin{verbatim} # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \ -j SNAT --to 1.2.3.0/24 \end{verbatim} \end{tscreen} Dieselbe Logik kann auf Adressen angewandt werden, die der NAT-Rechner selbst benutzt: So funktioniert Masquerading (indem die Adressen der Schnittstellen von maskierten Paketen mit den `wirklichen' Paketen, die durch den Rechner gehen, geteilt werden). Außerdem kannst die dieselben Pakete auf viele verschiedene Ziele mappen, und sie werden aufgeteilt werden. Du könntest zum Beispiel, wenn Du nichts über 1.2.3.5 mappen willst, folgendes tun: \begin{tscreen} \begin{verbatim} # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \ -j SNAT --to 1.2.3.0-1.2.3.4 --to 1.2.3.6-1.2.3.254 \end{verbatim} \end{tscreen} \subsubsection{Das Ziel von lokal-generierten Verbindungen verändern} Wenn das Ziel eines lokal-generierten Pakets geändert wird (ich meine durch die OUTPUT-Kette) und das bewirkt, dass das Paket durch eine andere Schnittstelle muß, wird die Quelladresse auch zu der Adresse der Schnittstelle geändert. Wenn Du zum Beispiel das Ziel eines Loopback-Pakets auf eth0 änderst, wird die Quelle auch von 127.0.0.1 zur Adresse von eth0 geändert werden; im Gegensatz zu anderen Source-Mappings geschieht das im selben Augenblick. Natürlich wird beides wieder umgekehrt, wenn Antwortpakete eintreffen. \section{Spezielle Protokolle} Manche Protokolle werden nicht gern geNATted. Für jedes dieser Protokolle müssen zwei Erweiterungen geschrieben werden; eine für das Connection-Tracking des Protokolls, und eine für das eigentliche NAT. In der netfilter-Distibution gibt es zur Zeit Module für FTP: ip\_conntrack\_ftp.o und ip\_nat\_ftp.o. Wenn Du diese Module mit insmod in den Kernel lädst (oder sie permanent hineinkompilierst), sollte NAT auf FTP-Verbindungen funktionieren. Wenn Du das nicht tust, kannst Du nur passives FTP verwenden, und sogar das könnte nicht zuverlässig funktionieren, wenn Du mehr als einfaches Source-NAT machst. \section{Einsprueche gegen NAT} Wenn Du NAT auf einer Verbindung machst, müssen alle Pakete in {\bfseries beide} Richtungen (in und aus dem Netzwerk) durch den NAT-Rechner, sonst wird es nicht zuverlässig funktionieren. Im Besonderen heißt das, dass der connection tracking Code Fragmente wieder zusammensetzt, was bedeutet, dass Deine Verbindung nicht nur unzuverlässig sein wird, sondern könnten Pakete sogar überhaupt nicht durchkommen, da Fragmente zurückgehalten werden. \section{Danke } Danke zuerst an Watchguard, und an David Bonn, der stark genug an die netfilter-Idee geglaubt hat, um mich während meiner Arbeit daran zu unterstützen. Danke auch allen anderen, die meine Wortschwälle ertragen mußten, als ich über die unschönen Dinge von NAT gelernt habe. Besonders auch denen, die mein Tagebuch gelesen haben. Rusty. \end{document}