Message-ID: <20110313014000.27475.qmail@...1287...> Date: Sun, 13 Mar 2011 02:40:00 +0100 From: Peter Stuge References: <20110309085656.18e0e796@...1451...> <20110311122309.1292c1dd@...1451...> <4D7A7455.4070805@...1114...> <20110312003517.3a86c508@...1451...> <20110312153620.8987.qmail@...1287...> <20110312184423.3fee2f17@...1451...> <20110312215420.31033.qmail@...1287...> <20110312195923.55eaa915@...1451...> <20110312232602.10422.qmail@...1287...> <20110312213345.694340df@...1451...> MIME-Version: 1.0 In-Reply-To: <4D7C1D05.70408@...1114...> <20110312213345.694340df@...1451...> Subject: Re: [Openvpn-devel] [PATCH] Bind only to specified interface List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Content-Disposition: inline To: openvpn-devel@lists.sourceforge.net Federico Heinz wrote: > > > Because I don't know it at configuration time. > > > > You said that you already have a solution in place for dealing > > with interface reconfiguration. > > I said I have a solution in place to restart OpenVPN when the > configuration changes. I understand. So there is no solution for dealing with the reconfiguration. > Sure, I could change a few system scripts, and include something > like Alon suggested (/sbin/ip addr show dev ppp0 | grep inet | sed > 's#.*inet \(.*\)/.*#\1#'), to figure out the IP address, change the > configuration files and only then restart OpenVPN. Would suggest wrapping openvpn instead of changing system scripts. > What I fail to see is how that is "simpler" or easier to understand > or maintain than writing "local if:ppp0" in the daemon's config file. It remains clear that openvpn binds to only one IP. > > Until OpenVPN has multilisten there's no point in OpenVPN trying > > to do this, because it will only do a poor job. > > This is simply not true. It will do a good job in most cases, and a > well-specified, if incomplete, job in the rather unlikely case that > someone deliberately attempts to use this feature together with > multiple IP addresses on a single interface, and even then it will > emit a warning. > > You are arguing that because it cannot do the job perfectly in an > unlikely edge case, it shouldn't even attempt to solve a > different, well-defined use case. > > I'm sorry, that doesn't make sense to me. I like do it right or don't do it at all. Only working in some cases is not good behavior for a feature. > > The domain name is irrelevant. Go closer to the authoritative > > source, not further away. > > Agreed. I'm going as close to it as I can: the interface itself, > from the viewpoint of the program that is using it. No, the source is the system component which configures the interface, not the interface itself, which is more like a data store in this case. > > > which in some cases involves messing around with the way > > > your distro usually does things, > > > > Why would it? > > It means modifying the distro's startup scripts for OpenVPN, to get > them to figure out the IP address of the interface for *some* > instances of the server but not necessarily for all. Changing startup scripts or wrapping openvpn is one way. But I would probably drive everything from the DHCP client instead. As I wrote, udhcpc is very very easy to deal with. David Sommerseth wrote: > As Davide Brini already mentioned, I really wonder if this issue is > due to lack of --multihome in your configuration, combined with > listen on 0.0.0.0. He wants different openvpn servers on different interfaces using same port. //Peter