[PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[Cédric de Launois]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

Fabrice,

Here are two patches to update the Netfilter-Extension HOWTO, concerning
the ROUTE target.

The first one [netfilter-extensions-HOWTO.sgml.PATCH] is against
the english version of the sgml master.
The second patch is against [netfilter-extensions-HOWTO.sgml.PATCH-FR]
is against the french version.

Cédric


[-- Attachment #2: netfilter-extensions-HOWTO.sgml.PATCH --]
[-- Type: text/x-diff, Size: 2243 bytes --]

--- netfilter-extensions-HOWTO.sgml.orig	Wed Jul 24 11:05:14 2002
+++ netfilter-extensions-HOWTO.sgml	Fri Sep 20 14:52:06 2002
@@ -1093,8 +1093,6 @@
 Send the packet directly through the interface with the name specified.
 <tag>--ifindex index</>
 Send the packet directly through the interface with the index specified.
-This is Useful when you want to remove a rule with an interface which doesn't
-exist anymore (e.g. a tunnel which has been destroyed).
 </descrip>
 
 <p>
@@ -1106,7 +1104,7 @@
 
 <p>
 A solution is to simply reroute packets with destination port 22 to the
-computer having the same IP as the router and hosting the ssh service,
+computer having the same IP as the router, and hosting the ssh service,
 thanks to this ROUTE target and an ipip tunnel.
 
 <p>
@@ -1130,22 +1128,21 @@
 would add the following rules :
 
 <tscreen><verb>
-# iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 22 -j ROUTE --iface tunl1
-# iptables -A PREROUTING -t nat -i tunl1 --j ROUTE --iface eth0
+# iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 22 -j ROUTE --iface tunl1
+# iptables -A PREROUTING -t mangle -i tunl1 --j ROUTE --iface eth0
 
 # iptables -L PREROUTING -t nat
 Chain PREROUTING (policy ACCEPT)
 target     prot opt source               destination         
-ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE iface tunl1(7) 
-ROUTE      all  --  anywhere             anywhere           ROUTE iface eth0(3) 
+ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE iface tunl1 
+ROUTE      all  --  anywhere             anywhere           ROUTE iface eth0
 </verb></tscreen>
 
 <p>
 The first rule is for rerouting packet coming from the Internet, and the second
-one is for rerouting all packets coming from the host. The value shown inside parentheses
-after the interface name is the interface index. We use the nat table
-because this table provides a PREROUTING hook, but this does not imply any packet
-alteration. 
+one is for rerouting all packets coming from the host. The ROUTE target can only
+be inserted inside the mangle table, in the PREROUTING chain.
+
 
 <sect>New connection tracking patches
 <p>

[-- Attachment #3: netfilter-extensions-HOWTO.sgml.PATCH-FR --]
[-- Type: text/plain, Size: 2034 bytes --]

--- netfilter-extensions-HOWTO.sgml.orig	Wed Jul 24 11:05:14 2002
+++ netfilter-extensions-HOWTO.sgml	Fri Sep 20 14:55:45 2002
@@ -1129,7 +1129,7 @@
 
 <p>
 Une solution est de simplement rerouter les paquets dont le port de destination est 22
-vers l'ordinateur ayant la même adresse que le routeur, et habritant le serveur ssh.
+vers l'ordinateur ayant la même adresse que le routeur, et hébergeant le serveur ssh.
 Ceci peut se faire grâce à cette target ROUTE, en utilisant un tunnel IPIP.
 
 <p>
@@ -1153,23 +1153,21 @@
 les règles suivantes :
 
 <tscreen><verb>
-# iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 22 -j ROUTE --iface tunl1
-# iptables -A PREROUTING -t nat -i tunl1 --j ROUTE --iface eth0
+# iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 22 -j ROUTE --iface tunl1
+# iptables -A PREROUTING -t mangle -i tunl1 --j ROUTE --iface eth0
 
 # iptables -L PREROUTING -t nat
 Chain PREROUTING (policy ACCEPT)
 target     prot opt source               destination         
-ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE iface tunl1(7) 
-ROUTE      all  --  anywhere             anywhere           ROUTE iface eth0(3) 
+ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE iface tunl1
+ROUTE      all  --  anywhere             anywhere           ROUTE iface eth0
 </verb></tscreen>
 
 <p>
 La première règle reroute les paquets venant de l'Internet et les envoie dans le tunnel.
 La seconde règle reroute vers l'Internet tous les paquets venant de l'hôte (c'est-à-dire
-les paquets sortant du tunnel). La valeur indiquée entre parenthèses après le nom
-de l'interface est l'index de celle-ci. Nous utilisons la table nat parce qu'elle
-fournit une chaîne PREROUTING, mais ceci n'implique aucunement une modification des
-paquets.
+les paquets sortant du tunnel). Cette target ne peut être insérée que dans la table
+'mangle', dans la chaîne PREROUTING.
 
 <sect>Les nouveaux patches de suivi de connexion
 <p>

Re: [PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[Cédric de Launois]

>   I want to be clear here... the ROUTE target lets me change the destination
> of a packet to be a specific interface, right?
Right, but the target also directly routes the packet to that interface.
That is, the packet does _not_ traverse the standard linux kernel
routing table, but is sent to the interface.

ASCII art may help :

Packets matching ROUTE target go directly from PREROUTING chain
to the interface.


          Regular routed Packet
---->PRE------>[kernel routes]--->FWD------->POST------>
      |                                            ^
      |                                            |
       `-------------------------------------------'
          Packets matching ROUTE target


Note that, if the interface is a tunnel, then the packet is
encapsulated, and this encapsulated packet then goes
through the OUPUT and POSTROUTING chains.

>   Does it continue through the rest of the table?
No, once the ROUTE target applies for a packet, the packet is 'stolen'.
No further rules are consulted.

> Could I, for instance, add QoS tags, or other stuff to it?
You can always mark a packet, add QoS tags and then, use
the ROUTE target applying on the marked packets.

> Could a later rule override the ROUTE again?
See 2nd question.

>   This is ideal for future FreeSWAN use.
If you tell me what exactly the problem is, I can even
add some features to help for this ;)

>   I agree that the interaction with NAT is confusing at present. 
The ROUTE target is now to be inserted in the mangle table.
This means that the ROUTE target applies before NAT (mangle
table has higher priority than nat table, but lower than
conntrack table).
So there is no longer interactions with the NAT.

Cédric

Re: [PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[Michael Richardson]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "dric" == dric de Launois <C> writes:
    >> I want to be clear here... the ROUTE target lets me change the
    >> destination of a packet to be a specific interface, right?

    dric> Right, but the target also directly routes the packet to that
    dric> interface.  That is, the packet does _not_ traverse the standard
    dric> linux kernel routing table, but is sent to the interface.

  Ah, I see.
  Interesting. My opinion is that standard routing should really become
a netfilter "module" :-)

    dric> Note that, if the interface is a tunnel, then the packet is
    dric> encapsulated, and this encapsulated packet then goes through the
    dric> OUPUT and POSTROUTING chains.

  Yes, I'm familliar with this part.

    >> Does it continue through the rest of the table?

    dric> No, once the ROUTE target applies for a packet, the packet is
    dric> 'stolen'.  No further rules are consulted.

  Hmm. We really want to redirect the packet to the IPsec device at the end
of the line, rather than steal it. The reason is because we want the rest
of the system to get a chance to add other marks to the packet. This seems
the best way to deal with different systems that want to add different
attributes to the packet.

  In general, we were thinking that it might be interesting for skb->dst
to be a *stack*

  All of the various QoS stuff probably wants look at the unencrypted packet.

    >> This is ideal for future FreeSWAN use.

    dric> If you tell me what exactly the problem is, I can even add some
    dric> features to help for this ;)

  We need to divert flows to our device. The resulting ESP packet needs to
be routed differently (need to avoid routing loops). We also need to except
various flows from our device (e.g. UDP port 500, but also DNS, and LDAP
for some). 

  We are not entirely happy with the device model for some reasons. Mostly 
it involves us in layer-2 issues that we'd rather not care about.

  On the other hand, the device model is very powerful, works better with
routing protocols, and permits more clarity in firewalling. 

  The model we are going for, called the "MAST" model, is that one can
have one MAST per tunnel if one wishes. Or, multiple tunnels per MAST
(selecting by upper bits of fwmark, marking with fwmark on the way out).

  In general, we see one MAST per policy type.

  Sometimes there are also multiple paths to the same destination (multiple
tunnels). This may be for redundancy or load balancing. 

  Right now, we have "ipsecX" devices which are essentially bump-in-the-stack
on top of ppp0/eth0/etc. - i.e. are layered. But, they don't steal the
dst->output function, they insert redundant routes. We call this "stoopid
routing tricks", and it bites.

  We still don't quite understand how the advanced routing tunnel stuff
works. It seems that the "ip" command doesn't use netlink for this, but
rather does an ioctl() on the "ipip" interface, and inserts the tunnel
descriptor in someone. I haven't been able to see where that gets set,
because this is in many ways what we want to happen for us.

    >> I agree that the interaction with NAT is confusing at present.

    dric> The ROUTE target is now to be inserted in the mangle table.  This
    dric> means that the ROUTE target applies before NAT (mangle table has
    dric> higher priority than nat table, but lower than conntrack table).
    dric> So there is no longer interactions with the NAT.

  NAT is done in POSTROUTING, unless you mean the un-NAT stuff, which I
don't understand.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPYtKD4qHRg3pndX9AQECcQP8CCqeZKJd3IJbkJtEbzj/GjliikLeq469
qy+9jtcajvQ6GJ5j4ewAjoXfFKsXHQSLe+tv1qjoB95A8916qFALsJDfeD7hgz2S
lEVJ9qAYO0B4k1lSlNIBixedAAeYiGP4QgCejEst/emUx8u55lQ4ikKNqzP0jvUV
bKoiFMIJOAc=
=LtTQ
-----END PGP SIGNATURE-----

Re: [PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[Toshihiro Sonoda]

hi, I have one question.

> 
>     >> I agree that the interaction with NAT is confusing at present.
> 
>     dric> The ROUTE target is now to be inserted in the mangle table.  This
>     dric> means that the ROUTE target applies before NAT (mangle table has
>     dric> higher priority than nat table, but lower than conntrack table).
>     dric> So there is no longer interactions with the NAT.
> 
>   NAT is done in POSTROUTING, unless you mean the un-NAT stuff, which I
> don't understand.
> 

I think NAT is not done in POSTROUTING in this case.

Packets, which are matched by the rule of 'ROUTE tareget',
flow as following route.

-> [mangle: PREROUTING]->[some tunnel device]->
         [OUTPUT]->[POSTROUTING]-> send to another machine.

The packets go through the POSTROUTING, but netfilter does not use 
the NAT tables matching rule in the POSTROUTING, because of 
hook of mangle tables.

Is that OK? or Do I mistake?

If I am right, I want to send masqueraded packets to ROUTE target.
 

Re: [PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[Fabrice MARIE]

Hello Cédric,

On Friday 20 September 2002 21:19, Cédric de Launois wrote:
> Fabrice,
> Here are two patches to update the Netfilter-Extension HOWTO, concerning
> the ROUTE target.
> The first one [netfilter-extensions-HOWTO.sgml.PATCH] is against
> the english version of the sgml master.
> The second patch is against [netfilter-extensions-HOWTO.sgml.PATCH-FR]
> is against the french version.

Thanks a lot. Applied.

Have a nice day,

Fabrice.
--
Fabrice MARIE
Senior R&D Engineer
Celestix Networks
http://www.celestix.com/

"Silly hacker, root is for administrators"
       -Unknown

[PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[Cedric de Launois]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

Hi Fabrice,

Here are two patches to update Netfilter-Extension HOWTO, concerning
the ROUTE target. The patches are against the english and french
versions of the sgml master.

The patches update the descriptions of the ROUTE options and move
the section so that it appears alphabetically (between the NETMAP
and the SAME patch sections).

Have a nice day,

Cédric



[-- Attachment #2: netfilter-extensions-HOWTO.patch --]
[-- Type: text/plain, Size: 7359 bytes --]

--- netfilter-extensions-HOWTO.sgml.orig	Sat Nov  9 10:30:38 2002
+++ netfilter-extensions-HOWTO.sgml	Wed Mar  5 16:07:54 2003
@@ -1088,6 +1088,95 @@
 <tag>--to address[/mask]</> -&gt; Network address to map to.
 </descrip>
 
+<sect1>ROUTE patch
+<p>
+This patch by Cédric de Launois &lt;delaunois@info.ucl.ac.be&gt; adds a new 
+target which allows you to setup unusual routes not supported by the 
+standard kernel routing table. The ROUTE target lets you route 
+a received packet through an interface or towards a host, even if the 
+regular destination of the packet is the router itself. The ROUTE target is 
+also able to change the incoming interface of a packet. Packets are
+directly put on the wire and do not traverse any other table.
+
+<p>
+This target does not modify the packets and is a final target.
+It has to be used inside the mangle table.
+
+<p>
+Whenever possible, you should use the MARK target together with
+iproute2 instead of this ROUTE target. However, this target is useful
+to force the use of an interface or a next hop and to change the 
+incoming interface of a packet. People also use it for easiness 
+and to simplify their rules (one rule to route a packet is easier 
+that one MARK rule + one iproute2 rule).
+
+<p>
+Options supported by the ROUTE target are :
+
+<descrip>
+<tag>--oif ifname</>
+Send the packet out using `ifname' network interface. The destination
+host must be on the same link or the interface must be a tunnel.
+Otherwise, arp resolution cannot be performed and the packet is dropped.
+<tag>--iif ifname</>
+Change the packet's incoming interface to `ifname'.
+<tag>--gw ip</>
+Route the packet via this gateway. The packet is routed as if
+its destination IP address was this ip.
+</descrip>
+
+
+<p>
+For example, assume that you want to redirect ssh packets towards a 
+server inside your network, without modifying those packets in any way 
+(this excludes the use of the standard port forwarding mechanism).
+A solution is to use an ipip tunnel and the ROUTE target to reroute ssh 
+packets to the real ssh server, which has the same IP address as the router.
+It is not possible to reroute those packets using the standard routing
+mechanisms, because the kernel locally delivers a packet having
+a destination address belonging to the router itself.
+
+<p>
+Time for ASCII art :
+<verb>
+              eth0  +------+ 192.168.0.1        192.168.0.2 +----+
+    ----------------|router|--------------------------------|host|
+    IP: 150.150.0.1 +------+                                +----+
+                       | | tunl1              IP: 150.150.0.1 | |
+                       | +------------------------------------+ |
+                       +----------------------------------------+
+                                      IPIP tunnel
+</verb>
+
+<p>
+For the example above, you can do as follows :
+
+<tscreen><verb>
+# iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 22 -j ROUTE --oif tunl1
+# iptables -A PREROUTING -t mangle -i tunl1 -j ROUTE --oif eth0
+
+# iptables -L PREROUTING -t mangle
+Chain PREROUTING (policy ACCEPT)
+target     prot opt source               destination         
+ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE oif tunl1
+ROUTE      all  --  anywhere             anywhere           ROUTE oif eth0
+</verb></tscreen>
+
+<p>
+Another example : if you want to quickly and easily balance the load between two 
+gateways 10.0.0.1 and 10.0.0.2, then you can do as follows :
+
+<tscreen><verb>
+# iptables -A PREROUTING -t mangle -m random --average 50 -j ROUTE --gw 10.0.0.1
+# iptables -A PREROUTING -t mangle -j ROUTE --gw 10.0.0.2
+
+# iptables -L PREROUTING -t mangle
+Chain PREROUTING (policy ACCEPT)
+target     prot opt source               destination         
+ROUTE      all  --  anywhere             anywhere           random 50% ROUTE gw 10.0.0.1
+ROUTE      all  --  anywhere             anywhere           ROUTE gw 10.0.0.2
+</verb></tscreen>
+
 <sect1>SAME patch
 <p>
 This patch by Martin Josefsson &lt;gandalf@wlug.westbo.se&gt; adds a new target
@@ -1184,74 +1273,6 @@
 Harald maintains a 
 <url url="http://www.gnumonks.org/projects/ulogd" name="web page"> containing the proper documentation
 for ULOG, so there is no point for me to explain this here..
-
-<sect1>ROUTE patch
-<p>
-This patch by Cédric de Launois &lt;delaunois@info.ucl.ac.be&gt; adds a new target
-which allows you to directly route a packet towards a specified interface,
-even and especially if the packet IP address is one of the router itself. 
-Since the kernel locally delivers those packets, they cannot be forwarded to 
-another computer using the standard routing mechanisms.
-Sometimes, this is useful to do that, without modifying the packets.
-
-<p>
-Options supported by the ROUTE target are :
-
-<descrip>
-<tag>--iface name</>
-Send the packet directly through the interface with the name specified.
-<tag>--ifindex index</>
-Send the packet directly through the interface with the index specified.
-</descrip>
-
-<p>
-For example, assume that you want to install a service, say ssh, on a 
-computer inside your network. But, you also want this service to appear
-exactly as if it was located on the router itself, including the
-fact that the packets remain unmodified. This prevents us using the 
-standard port forwarding mechanism.
-
-<p>
-A solution is to simply reroute packets with destination port 22 to the
-computer having the same IP as the router, and hosting the ssh service,
-thanks to this ROUTE target and an ipip tunnel.
-
-<p>
-Time for ASCII art :
-<verb>
-              eth0  +------+ 192.168.0.1        192.168.0.2 +----+
-    ----------------|router|--------------------------------|host|
-    IP: 150.150.0.1 +------+                                +----+
-                       | | tunl1              IP: 150.150.0.1 | |
-                       | +------------------------------------+ |
-                       +----------------------------------------+
-                                      IPIP tunnel
-</verb>
-<p>
-It is not possible to reroute those packets using the standard routing
-mechanisms, simply because the kernel thinks those packets should be 
-locally delivered (they contain the IP address of the router itself).
-
-<p>
-The ROUTE target provides a way to do that. For our example above, we
-would add the following rules :
-
-<tscreen><verb>
-# iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 22 -j ROUTE --iface tunl1
-# iptables -A PREROUTING -t mangle -i tunl1 --j ROUTE --iface eth0
-
-# iptables -L PREROUTING -t nat
-Chain PREROUTING (policy ACCEPT)
-target     prot opt source               destination         
-ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE iface tunl1 
-ROUTE      all  --  anywhere             anywhere           ROUTE iface eth0
-</verb></tscreen>
-
-<p>
-The first rule is for rerouting packet coming from the Internet, and the second
-one is for rerouting all packets coming from the host. The ROUTE target can only
-be inserted inside the mangle table, in the PREROUTING chain.
-
 
 <sect>New connection tracking patches
 <p>

[-- Attachment #3: netfilter-extensions-HOWTO.FR.patch --]
[-- Type: text/plain, Size: 8108 bytes --]

--- netfilter-extensions-HOWTO.sgml.orig	Sat Nov  9 10:30:38 2002
+++ netfilter-extensions-HOWTO.sgml	Wed Mar  5 16:05:50 2003
@@ -1118,6 +1118,95 @@
 <tag>--to address[/mask]</> -&gt; L'adresse réseau à mapper.
 </descrip>
 
+<sect1>Le patch ROUTE
+<p>
+Ce patch par Cédric de Launois &lt;delaunois@info.ucl.ac.be&gt; ajoute une 
+nouvelle target qui vous d'établir des routes particulières qui ne sont pas
+supportées par la table de routage standard du noyau. La target ROUTE vous
+permet the router un paquet vers une interface ou un hôte, même si la 
+destination normale du paquet est le routeur lui-même. La target ROUTE permet
+également de changer l'interface d'arrivée d'un paquet. Les paquets sont
+envoyés directement sur la ligne, sans traverser aucune autre table.
+
+<p>
+Cette target ne modifie jamais les paquets et est une target finale. Elle
+doit être utilisée dans la table `mangle'.
+
+<p>
+Lorsque c'est possible, il est préférable d'utiliser la target MARK couplée
+à l'utilisation d'iproute2. Cette target ROUTE est cependant utile pour forcer
+l'utilisation d'une interface ou d'une passerelle, et pour changer l'interface
+d'arrivée d'un paquet. Certaines personnes l'utilisent aussi par facilité et
+pour simplifier leur règles (une règle pour router un paquet est plus facile
+qu'une règle MARK + une règle iproute2).
+
+<p>
+Les options supportées par la target ROUTE sont :
+
+<descrip>
+<tag>--oif ifname</>
+Envoie le paquet en utilisant l'interface de nom `ifname'. La machine de
+destination doit être sur le même lien, ou bien l'interface doit être un tunnel.
+Dans le cas contraire, la résolution arp ne peut se faire et le paquet est
+jeté.
+<tag>--iif ifname</>
+Modifie l'interface d'arrivée du packet en l'interface `ifname'.
+<tag>--gw ip</>
+Route le paquet via cette passerelle. Le paquet est routé comme si son
+adresse IP de destination était cette ip.
+</descrip>
+
+<p>
+Supposons par exemple que vous voulez rediriger les paquets ssh vers un serveur
+situé à l'intérieur de votre réseau, sans modifier ces paquets (ceci exclu
+l'utilisation de la technique de redirection de port).
+Une solution est d'utiliser un tunnel ipip et la target ROUTE pour rerouter les
+paquets ssh vers le vrai serveur ssh, qui a la même adresse IP que le routeur.
+Il n'est pas possible de rerouter ces paquets en utilisant la table de routage
+du noyau car le noyau délivre localement les paquets ayant une adresse
+de destination appartenant au routeur lui-même.
+
+<p>
+Un peu d'art ASCII :
+<verb>
+              eth0  +-------+ 192.168.0.1         192.168.0.2 +----+
+    ----------------|routeur|---------------------------------|hôte|
+    IP: 150.150.0.1 +-------+                                 +----+
+                       | | tunl1               IP: 150.150.0.1 | |
+                       | +-------------------------------------+ |
+                       +-----------------------------------------+
+                                      tunnel IPIP
+</verb>
+
+<p>
+Pour l'exemple ci-dessus, vous pouvez faire comme suit :
+
+<tscreen><verb>
+# iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 22 -j ROUTE --oif tunl1
+# iptables -A PREROUTING -t mangle -i tunl1 -j ROUTE --oif eth0
+
+# iptables -L PREROUTING -t mangle
+Chain PREROUTING (policy ACCEPT)
+target     prot opt source               destination         
+ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE oif tunl1
+ROUTE      all  --  anywhere             anywhere           ROUTE oif eth0
+</verb></tscreen>
+
+<p>
+Autre exemple : si vous voulez facilement et rapidement répartir la charge entre
+deux passerelles 10.0.0.1 et 10.0.0.2, faites comme suit :
+
+<tscreen><verb>
+# iptables -A PREROUTING -t mangle -m random --average 50 -j ROUTE --gw 10.0.0.1
+# iptables -A PREROUTING -t mangle -j ROUTE --gw 10.0.0.2
+
+# iptables -L PREROUTING -t mangle
+Chain PREROUTING (policy ACCEPT)
+target     prot opt source               destination         
+ROUTE      all  --  anywhere             anywhere           random 50% ROUTE gw 10.0.0.1
+ROUTE      all  --  anywhere             anywhere           ROUTE gw 10.0.0.2
+</verb></tscreen>
+
 <sect1>Le patch SAME
 <p>
 Ce patch par Martin Josefsson &lt;gandalf@wlug.westbo.se&gt; ajoute une nouvelle
@@ -1215,76 +1304,6 @@
 Harald maintient une
 <url url="http://www.gnumonks.org/projects/ulogd" name="page web"> contenant de la documentation
 sur l'utilisation de la target ULOG ainsi que sur la librairie, et donc on ne l'expliquera pas ici..
-
-<sect1>Le patch ROUTE
-<p>
-Ce patch par Cédric de Launois &lt;delaunois@info.ucl.ac.be&gt; ajoute une nouvelle target
-qui vous permet de directement router un paquet entrant vers une interface que vous spécifiez.
-Ceci peut se faire même, et en particulier, si l'adresse IP de destination est une des adresses 
-du routeur lui-même. D'habitude, le kernel délivre ces paquets localement. Ils ne peuvent donc 
-être routés vers un autre ordinateur en utilisant les mécanismes standards de routage.
-Parfois, il s'avère utile de le faire, tout en conservant l'intégrité des paquets.
-
-<p>
-Les options supportées par la target ROUTE sont :
-
-<descrip>
-<tag>--iface name</>
-Envoie le paquet directement vers l'interface de nom &lt;name&gt;.
-<tag>--ifindex index</>
-Envoie le paquet directement vers l'interface dont l'index est spécifié.
-Ceci est utile lorsque vous voulez supprimer une règle concernant une interface qui
-n'existe plus (par exemple si c'est un tunnel qui a été détruit entretemps).
-</descrip>
-
-<p>
-Supposons par exemple que vous désirez installer un service, disons ssh, sur un
-ordinateur de votre réseau interne. Vous voulez cependant que ce service apparaisse
-exactement comme s'il se situait sur le routeur lui-même, y compris le fait que les
-paquets ne soient pas modifiés. Ceci ne nous permet donc pas d'utiliser le mécanisme
-standard de redirection de port.
-
-<p>
-Une solution est de simplement rerouter les paquets dont le port de destination est 22
-vers l'ordinateur ayant la même adresse que le routeur, et hébergeant le serveur ssh.
-Ceci peut se faire grâce à cette target ROUTE, en utilisant un tunnel IPIP.
-
-<p>
-Un peu d'art ASCII :
-<verb>
-              eth0  +-------+ 192.168.0.1         192.168.0.2 +----+
-    ----------------|routeur|---------------------------------|hôte|
-    IP: 150.150.0.1 +-------+                                 +----+
-                       | | tunl1               IP: 150.150.0.1 | |
-                       | +-------------------------------------+ |
-                       +-----------------------------------------+
-                                      tunnel IPIP
-</verb>
-<p>
-Il n'est pas possible de rerouter ces paquets en utilisant les mécanismes standards
-de routage, tout simplement parce que le kernel pense que ces paquets doivent être
-délivrés localement (ils contiennent l'adresse IP du routeur lui-même).
-
-<p>
-La target ROUTE fournit un moyen de le faire. Pour notre exemple, nous rajouterions
-les règles suivantes :
-
-<tscreen><verb>
-# iptables -A PREROUTING -t mangle -i eth0 -p tcp --dport 22 -j ROUTE --iface tunl1
-# iptables -A PREROUTING -t mangle -i tunl1 --j ROUTE --iface eth0
-
-# iptables -L PREROUTING -t nat
-Chain PREROUTING (policy ACCEPT)
-target     prot opt source               destination         
-ROUTE      tcp  --  anywhere             anywhere           tcp dpt:ssh ROUTE iface tunl1
-ROUTE      all  --  anywhere             anywhere           ROUTE iface eth0
-</verb></tscreen>
-
-<p>
-La première règle reroute les paquets venant de l'Internet et les envoie dans le tunnel.
-La seconde règle reroute vers l'Internet tous les paquets venant de l'hôte (c'est-à-dire
-les paquets sortant du tunnel). Cette target ne peut être insérée que dans la table
-`mangle', dans la chaîne PREROUTING.
 
 <sect>Les nouveaux patches de suivi de connexion
 <p>

Re: [PATCH] update for ROUTE target in Netfilter-Extension HOWTO [ENG][FR]

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

On Wed, Mar 05, 2003 at 04:17:57PM +0100, Cedric de Launois wrote:

> Here are two patches to update Netfilter-Extension HOWTO, concerning
> the ROUTE target. The patches are against the english and french
> versions of the sgml master.
> 
> The patches update the descriptions of the ROUTE options and move
> the section so that it appears alphabetically (between the NETMAP
> and the SAME patch sections).

thanks, applied.

> Cédric

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]