Hello,
Steve Fink a écrit :
I am trying to redirect all traffic generated on box $SRC to a
particular UDP port to a different host $SPY. I've done similar things
with whole TCP connections using DNAT and SNAT, but this time I want
UDP and I want to be able to start up the redirection after the
"connection" has been established. (I never see these packets in the
'nat' table.)
You don't see these packets in the 'nat' table because the "connection"
already exists and has an an entry in the conntrack table. You can
delete a conntrack entry with the conntrack command from the
conntrack-tools package. You can also prevent the packets to create a
conntrack entry by using the NOTRACK target in the 'raw' table until
after you add the NAT rules. Make sure to match packets in both
directions. After you remove the NOTRACK rules, the next packet will
enter the 'nat' chains and hit the NAT rules.
The only option that seemed viable, me not knowing much about
networking, was to use the 'mangle' table to set a mark on the
outgoing packets, then use 'ip' to route the packet to $SPY. I've used
iptables a fair amount, but ip not at all.
On $SRC, I ran:
iptables -t mangle -A OUTPUT -p udp --dport 8765 -j MARK --set-mark 1
ip rule add fwmark 1 table 50
ip route add via $SPY table 50
sysctl net.ipv4.ip_forward=1 # Dunno if this matters
It doesn't matter. Packets are locally generated, the box does not act
as a router.
ip route flush cache
On $SPY, I ran:
sysctl net.ipv4.ip_forward=1 # Makes sense here
$SRC, $SPY, and $ORIG_DEST (the original destination) can all reach each other.
According to iptables, the mark is getting set on the packets I want
redirected. But tcpdump shows packets still going to the original
destination, not $SPY. I am testing by running this on $SRC
nc -v -u $ORIG_DEST 8765
And I trigger packets to be sent by hitting enter in that window. The
packets are making it to my dummy server on $ORIG_DEST. They do not
show up to tcpdump on $SPY.
I don't know how to read the output of 'ip route show cache', but it includes
$SPY from $SRC tos lowdelay dev tun0
cache mtu 1412 advmss 1372 hoplimit 64
local $SRC from $SPY tos lowdelay dev lo src $SRC
cache <local,src-direct> iif tun0
(I'm testing this over a VPN, hence the tun0 device. Both $ORIG_DEST
and $SPY are accessible via the VPN.)
This matters a lot : for both $ORIG_DEST and $SPY, the actual next hop
is the VPN endpoint.
The only thing I can think of is that $SPY needs to be reachable in a
single hop
Indeed, otherwise the actual next hop will forward the packets based on
the destination address. Whether the packet is marked or not, the next
hop is the VPN endpoint anyway, and it forwards the packets to
$ORIG_DEST, not $SPY.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
