Hello,
Am 26.06.2015 um 16:36 schrieb Gert Doering:
Hi,
On Fri, Jun 26, 2015 at 01:24:02PM +0200, Gert Doering wrote:
This is more wondering about what we *should* do for persistant tun
interfaces... (and, now, why your tun ifs behave that way even if they
are not actually persistant :) ).
Mulling over this for a while, I think I've come to a conclusion on
"what we should do", and "what we should do in the 'persistant tun'
case" (#141)
- normal case: we do "ip addr add" and "delete" - proper housekeeping,
and having IPv4 and IPv6 in sync (so, Holger's patch for Linux,
and possible similar additional code for all the other OSes)
I looked at some other OSes in tun.c and found no other with this flaw
at a first glance (other do simply a 'destroy' or 'unplumb' of the
interface). But probably I oversaw something here.
- if someone really wants/needs a persistant device (created with
"openvpn --mktun --dev tun3" on Linux / "ifconfig tun3 create"
on *BSD), and expect it to always keep the addresses on it, they
should call "openvpn --ifconfig-noexec".
Yes, this sounds like a good idea to me. Had also something like
"--ifconfig-notouch" in mind, but your proposal is shorter.
This will then neither add *nor delete* the IP addresses on the
interface (of course, in that case you need to run the ifconfig /
ip addr statements manually before starting OpenVPN, or from an --up
script which can then choose to just ignore the error if the address is
already there). So this would cover the case "I want <daemon x> to
listen on my tun device, but it cannot rebind if the interface goes
away".
Simple and pragmatic enough?
I second this proposal, and it would solve a long outstanding bug.
Holger
(Having OpenVPN check addresses for persistant tun interfaces, and only
add them if needed, and actually *change* them if needed would be a cool
thing to have, but we have no infrastructure yet to do so)
gert
