[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NAT



>>>>> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:
>>>>> Ivan Shmakov a écrit :
>>>>> Pascal Hambourg <pascal.mail@plouf.fr.eu.org> writes:

 >>> [...] although IPv6 NAT could be a helpful quick and dirty hack in
 >>> a some situations (e. g. source NAT to work around some flaws in
 >>> the source address selection).

 >> Couldn't ip(8) be used for that?

 > Last time I checked, the 'src' option in IPv6 routes was ignored.

	To be honest, I don't know for sure.

 >> $ /sbin/ip route show table myvpn 

 >> default via <IPv4> dev <Tunnel-Iface>

 >> This rule makes all the packets for which this table was invoked to
 >> be routed through <Tunnel-Iface>...

 >> default dev <Tunnel-Iface> scope link src <IPv4>

 >> ... and this one apparently alters the source address selection.

 > Err...  Aren't these two routes to the same destination, and thus
 > conflicting with each other ?

	Apparently, they're not.

	IIUC, the first rule means, in pseudocode:

  if (destination: default, nexthop: <IPv4>) {
    set! output-device: <Tunnel-Iface>;
  }

	While the second one:

  if (destination: default, scope: link) {
    set! output-device: <Tunnel-Iface>,
         source:        <IPv4>;
  }

	Thus, the second rule only applies to the packets being OUTPUT
	(because of scope: link), while the first one applies only to
	the packets being FORWARDED.

 > In that situation the kernel will use only one (if ask me which one,
 > I'll say either, don't rely on it).

 >> For the more complicated cases, some ``mark'' (fwmark?) selector
 >> could be used in conjunction with iptables-based marking of packets.

 > Unfortunaltey the netfilter mark comes too late, after the source
 > address selection is performed.  Source address selection is
 > performed when the packet is created, before it enters the OUTPUT
 > chains where marking takes place.  So there is a rerouting after
 > OUTPUT to take the mark or destination address change into account
 > and update the routing, but the source address is not updated.

	Agreed.  As I've said before, I'm not quite keen at ip(8) yet.
	(After all, I'm using it for only a few days.)

-- 
FSF associate member #7257


Reply to: