Re: Failover route

Linux Advanced Routing and Traffic Control

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

 



Hi,

On Sun, Mar 17, 2019 at 12:38:39PM -0600, Grant Taylor wrote:
> On 3/16/19 12:04 PM, Erik Auerswald wrote:
> 
> >Yeah, one needs to send a packet destined to the same machine out
> >an interface. That might need some trickery.
> 
> The more that I think about it, the more that I think:
> 
>  · BFD-EM style to-be-routed packet might work better than ICMP.
>  · link-net IPs shouldn't be a problem.
> 
> >I remember some related trickery from a Project Zero blog post: googleprojectzero.blogspot.de/2015/12/fireeye-exploitation-project-zeros.html
> 
> Either I'm not understanding what you're referring to.  Or I don't
> see how essentially sniffing a (mirror / SPAN) port differs from
> what I said previously about sniffing traffic.

I am referring to the following:

--------
In this case, I want the simulated network on 192.168.2.0/24 and the
management interface on 192.168.1.1/24. This requires adjusting the
local routing table and creating device specific rules accordingly.

# First, make sure Linux will accept local<->hub<->local traffic
echo 1 > /proc/sys/net/ipv4/conf/all/accept_local

# Give the two interfaces connected to the hub static addresses.
ip addr add 192.168.2.2 dev eth2
ip addr add 192.168.2.1 dev eth3

# Route traffic destined for each address to the *opposite* device
ip route add 192.168.2.1 dev eth2
ip route add 192.168.2.2 dev eth3

# Force Linux to forget that these are local interfaces so the traffic actually reaches the hub.
ip route del 192.168.2.2 table local
ip route del 192.168.2.1 table local

# Now add corresponding rules for each interface
ip rule add iif eth2 lookup 100
ip route add local 192.168.2.2 dev eth2 table 100
ip rule add iif eth3 lookup 101
ip route add local 192.168.2.1 dev eth3 table 101
--------

> Or are you talking about applying sniffing to the BFD-EM frame?
> 
> >A BFD daemon using RAW sockets (neither UDP nor TCP) might not
> >need something like the above, similar to ping -I <Iface> -r
> ><TargetIP>.
> 
> I'm really starting to question if I'm / we're not over complicating this.
> 
> I can't think of a reason why BFD-EM to from & to the local link-net
> IP via the far end router's MAC address won't work.

Yes, if you craft a packet accordingly. But what does the TCP/IP stack
do if you send a packet to a local IP address? The BFD Echo packet is
addressed to the local IP of the sending interface.

> The link-net IPs should only be used for things on the link.  So I
> don't see any disadvantage of said IPs not being reachable if the
> link is down / down.  Arguably, that's a state that BFD-EM should
> account for.  The reason for using BFD-EM would want to know about
> such a down / down state.

The question is how to create a packet with the local IP and the remote
MAC address, and send it out the local interface.

One way is editing a PCAP file with a hex editor and using tcpreplay to
send the PCAP data as a packet. ;-)

Thanks,
Erik
-- 
In the beginning, there was static routing.
                        -- RFC 1118



[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux