Am 26.08.20 um 18:51 schrieb Vladislav Grishenko: > DNS SRV host discovery allows to have multiple OpenVPN servers for a single > domain w/o explicit profile enumeration, to move services from host to host > with little fuss, and to designate hosts as primary servers for a service > and others as backups. > Feature has been asked several times already, useful in case of huge > ammounts of client & servers deployed. > > Patch introduces "--remote-service-discovery [service]" option, which > enables discovery and optionally allows to change "openvpn" default service > to user specified. > Client will try to resolve ``_service._proto.host`` name via DNS > and use returned DNS SRV records as OpenVPN remote server list > ordered by server selection mechanism defined in RFC 2782: > > A client MUST attempt to contact the target host with the > lowest-numbered priority field value it can reach, target hosts > with the same priority SHOULD be tried in an order defined by the > weight field. > The weight field specifies a relative weight for entries with the > same priority. Larger weights SHOULD be given a proportionately > higher probability of being selected. > Domain administrators SHOULD use Weight 0 when there isn't any > server selection to do. In the presence of records containing > weights greater than 0, records with weight 0 SHOULD have a very > small chance of being selected. > > Example: instead of multiple remotes on order in profile: > remote s1.example.com 1194 udp > remote s2.example.com 1194 udp > remote s3.example.com 1194 udp > remote s4.example.com 1194 udp > remote example.com 1194 udp > > now it's possible to specify one remote with discovery: > remote example.net 1194 udp > remote-service-discovery > > and addconfigure following DNS SRV records, for examle: > _openvpn._udp.example.net IN SRV 10 60 1194 s1.example.net > _openvpn._udp.example.net IN SRV 10 40 1194 s2.example.net > _openvpn._udp.example.net IN SRV 10 0 1194 s3.example.net > _openvpn._udp.example.net IN SRV 20 0 1194 s4.example.net
I haven't reviewed this yet but I think we need to agree what we actually want to solve/implement here or what the overall goal is. Traditionally OpenVPN is configure with a number of remotes in order of preference: e.g. server1 udp 1194 server1 tcp 443 server2 udp 1194 server2 tcp 443 DNS SRV discovery is a more modern way to get the actual proto/protocol/IP to connect to. So I feel this should be able to replace a handwritten list of remote in the config. E.g. something like remote-srv mydomain However, the current patches forces all remotes to be either UDP or TCP or have a fixed UDP over TCP (or vice versa) priority. Also reusing --remote for both service discovery and fallback is not great a solution. It suffer from trying to force two very different things into a single command. I can see that a fallback behaviour if DNS SRV is desirable but I think the normal case is not to fallback to just a single remote but rather a list of --remote. So I would propose to instead have something like remote-dnsserv that does all the discovery and *also* a list of --remotes and then fallback to those if DNS SRV falls. If no fallback is desired, then only remote-dnnsserv is specified. I am sure that the current implementation is good enough for your use case but I feel the current version is not useful enough as general feature but more only solves a specific use case. Arne
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
