We discussed this patch briefly in today's IRC developer meeting, and wanted some clarification on the intent/goal here. Comments inline (code removed since we're trying to wrap our heads around the feature in the general sense first.) Once we have a better idea of the intent, it will be easier to look at the code itself more in-depth.
As Arne noted in this thread, detailed code review & a merge strategy may well wait until the dual-stack support is in as to not complicate his work on that. On 08/08/13 12:59, Jesse Glick wrote: > Also as: https://github.com/OpenVPN/openvpn/pull/6 > > I was exploring the possibility of using a SOCKS5 server to multiplex > OpenVPN connections based on hostname (in the remote option), akin to > how HTTP reverse proxies commonly delegate to a physical server > according to the HTTP 1.1 Host header—so that many hostnames can map > to the same IP of the reverse proxy. There was some issue figuring out what this all means. Do you have an example use-case where this is helpful? I don't understand the bit about multiplexing, since the idea of a SOCKS transport is a one-to-one relationship. Since OpenVPN uses a single UDP (or TCP) socket to establish remote connections, I'm not sure what there is to multiplex. > I found that the SOCKS5 protocol does support DOMAINNAME rather than > IP V4 when using the UDP relay server. However, OpenVPN was never > using this option; it always sent a preresolved IP (v4) address, > giving the proxy server no way of inferring what hostname was > originally requested. > > This patch amends the socks_process_outgoing_udp method to send > DOMAINNAME for the first datagram of the connection, when an FQDN was > specified. Thereafter it sends IP V4since this is more compact—and > experimentation with the Dante server revealed that it > calledcgethostbyname on many, if not all, such datagrams it received, > which could be quite expensive. Since in the case of OpenVPN the > “desired destination address” is constant for the life of the tunnel, > it should suffice to send the hostname just once. This confused us too; what's the advantage of doing the DNS lookup remotely? Presumably this is in case the remote end comes up with a different IP than the local one, but what's to then stop the local side from using the then-miss-matched IPv4 address the _local_ end resolved and sending all future datagrams to a different IP than the first? > socks_adjust_frame_parameters also needed to be changed to allow for > the worst-case buffer size, a 255-character hostname (Linux generally > only allows 64) plus fixed-length fields (7 bytes). It would be nicer > to set this according to the actual hostname length, but I could not > see how to obtain that hostname during this early stage of > initialization. > > Filing this for the purpose of getting feedback. Probably there needs > to be a user option to configure this behavior: > > · disable (restoring original behavior; perhaps the default) > · enable for first packet only (as in the current patch) > · enable for all packets, which could be useful in case the reverse > proxy is using a single UDP relay server for many clients (since > SOCKS5 offers no apparent connection identifier other than the > BND.PORT) > > Note that the original code probably does not work with IPv6, but I > did not attempt to address that in this patch. Since >=2.3.0 officially supports IPv6, new features should probably do so as well. The code as I see will simply "not offer" this feature when info.proto == PROTO_UDPv6, but then we need to document the distinction. This is probably less important to address now; let's first see if the rest of us can figure out what this feature's use-case is. Thanks, -- Josh Cepek
signature.asc
Description: OpenPGP digital signature
