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)
- 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".
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?
(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
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpFEGIPFKzJV.pgp
Description: PGP signature
