## Quelladresse auf 1.2.3.4 ändern
# 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 ändern
# 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, ändern
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to \
# 1.2.3.4:1-1023
	 

6.1.1 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 musst 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.

## Maskiere alles, was an ppp0 ausgeht
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
	  

## Zieladresse zu 5.6.7.8 ändern
# 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 ändern
# iptables -t nat -A PREROUTING -i eth1 -j DNAT --to 5.6.7.8-5.6.7.10

## ändern 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 für 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
	 

6.2.1 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.

## 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
	  

6.3.1 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.

6.3.2 Ein Null NAT Mapping erstellen

Du kannst das -j ACCEPT Ziel verwenden, um eine Verbindung zuzulassen, ohne dass irgendein NAT stattfindet.

6.3.3 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.

6.3.4 Implizites Quellport-Mappen

Sogar, wenn für eine Verbindung kein NAT benötigt wird, kann Quellport- Veränderung stillschweigend auftreten, wenn eine andere Verbindung über die neue gemappt wurde. Stell Dir den Fall von Masquerading vor, der recht gewöhnlich ist:

1. Eine Webverbindung von einem Rechner 192.168.1.1 Port 1024 ist zu www.netscape.com Port 80 aufgebaut.
2. Dies wird von einem Masquerading-Rechner maskiert, um 1.2.3.4 als Quelle zu verwenden.
3. Der Masquerading-Rechner versucht, von 1.2.3.4 (die Adresse seiner externen Schnittstelle) Port 1024, eine Webverbindung zu www.netscape.com aufzubauen.
4. Damit die Verbindung sich nicht überschneidet, wird der NAT-Code die Quelle der zweiten Verbindung auf 1025 ändern.

Wenn dieses implizite Quell-Mapping auftaucht, werden Ports in drei Klassen aufgeteilt:

• Ports unter 512.
• Ports zwischen 512 und 1023.
• Ports ab 1024.

Ports werden niemals implizit in eine andere Klasse gemappt.

6.3.5 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.

6.3.6 Mehrere Mappings, Overlaps und Clashes

Du kannst NAT-Regeln haben, die Pakete in denselben Bereich mappen; der NAT-Code ist clever genug, 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:

 # iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 \
 -j SNAT --to 1.2.3.0/24
	  

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:

# 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
	  

6.3.7 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 muss, 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.