Hey Iain,
Since I havn't seen the other thread I was wondering to myself what is
the relevant output of these steps that you gave example to?
like
(remove any confidential info)
"ip addr"
"ip route"
This OpenSWAN\IPsec tunnels goes down and up??
I do remember from the far past that when setting\adding a route the
protocol used to add these routes can be identified and if OpenSWAN do
that it can be set in a way that could be identified.
When you have for example OpenSSL tunnel it can use one of two ways
handle routing:
1: define the interface with a mask that the tap interface will handle
on the lower level stuff,
2: push routes on connection to the clients as "static" ones (with
probably metrics or other values)
And eventually there should be a route on the machine in order to get
into the other side of the tunnel or else no traffic will make it there..
I assume it's not that complex since most of the basic route questions
can be answered very fast.
Eliezer
On 11/10/2013 05:35 PM, Iain Buchanan wrote:
(1) parse output from “ip route” to determine the default route
(2) parse output from “ip address” to determine the set of local IP
addresses
(3) parse output from “ipsec auto status” looking for any of the
“network diagram” lines that show the connectivity where one end or the
other goes through a local IP address
(4) update the routing table with calls to "ip route"
(5) somehow prod Bird so that it reads the table
I hope I’ve horribly over-complicated things and there’s an easier way
to do this… does this sound like the way to go?
Iain
