When using multihome, create environment variables for target IP and interface on the server
PATCH 1/1 When using multihome, create environment variables for target IP and interface on the server
This patch creates two new environment variables: "multihome_iface" and "multihome_ip", which contain respectively the interface name and IP address where the client connection came in, so scripts can use them.
Tested on IPv4, "works for me". The patch is against the master branch.
Besides the style issues or the errors that surely this patch contains, I have some questions:
- Is this (ie, function link_socket_connection_initiated()) the right place to do it?
- Currently it uses the same variable names for IPv4 and IPv6; would using multihome_ip and multihome_ip6 make more sense, for example? (I don't think so, but asking for confirmation)
- For consistency, I think it would be nice to set the same variables even when --multihome is not in effect. However, as it is now, OpenVPN explicitly checks for --multihome and if it's not set, it doesn't set the IP_PKTINFO/IP_RECVDSTADDR option in the socket, so that information is not always available (hence the addr_defined_ipi() check is needed). Any reason why this is so? What would be the problem in always setting IP_PKTINFO/IP_RECVDSTADDR (if supported by the platform, of course)?
- Again for consistency, the same variables could/should be set for TCP connections, however I have no idea where to look for that (I don't even know whether link_socket_connection_initiated() is called at all when using TCP). Any suggestions?
Thanks.
--- socket.c | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 68 insertions(+), 0 deletions(-)
socket.c +68 -0
@@ -2112,6 +2112,74 @@ link_socket_connection_initiated (const struct buffer *buf,/* set environmental vars */ setenv_str (es,"common_name" , common_name); +#if ENABLE_IP_PKTINFO + { +/* determine server's IP and interface where the connection came in, +and create corresponding environment variables */ + +char ifname[IF_NAMESIZE ]; +int ok_ifindex =1 ;/* whether if_indextoname() succeeded */ + +if (addr_defined_ipi (act)) + { +switch (act->dest.addr.sa.sa_family) + { +case AF_INET : + { +struct openvpn_sockaddr sa; +char v4addr[INET_ADDRSTRLEN ]; +CLEAR (sa); +CLEAR (v4addr); + +#ifdef IP_PKTINFO + sa.addr.in4.sin_addr = act->pi.in4.ipi_spec_dst; +if (!if_indextoname (act->pi.in4.ipi_ifindex, ifname)) + ok_ifindex =0 ; + +#elif defined(IP_RECVDSTADDR ) + sa.addr.in4.sin_addr = act->pi.in4; + ifname[0 ] =0 ; + +#else +#error ENABLE_IP_PKTINFO is set without IP_PKTINFO xor IP_RECVDSTADDR (fix syshead.h) +#endif + +if (ok_ifindex) +setenv_str (es,"multihome_iface" , ifname); +else +msg (M_WARN ,"WARNING: if_indextoname() failed for index %d: %s" , act->pi.in4.ipi_ifindex,strerror (errno)); + +if (inet_ntop (AF_INET , &(sa.addr.in4.sin_addr), v4addr,INET_ADDRSTRLEN )) +setenv_str (es,"multihome_ip" , v4addr); +else +msg (M_WARN ,"WARNING: inet_ntop() failed when converting address: %s" ,strerror (errno)); + + } +break ; +case AF_INET6 : + { +struct sockaddr_in6 sin6; +char v6addr[INET6_ADDRSTRLEN ]; +CLEAR (sin6); +CLEAR (v6addr); + sin6.sin6_addr = act->pi.in6.ipi6_addr; + +if (if_indextoname (act->pi.in6.ipi6_ifindex, ifname)) +setenv_str (es,"multihome_iface" , ifname); +else +msg (M_WARN ,"WARNING: if_indextoname() failed for index %d: %s" , act->pi.in6.ipi6_ifindex,strerror (errno)); + +if (inet_ntop (AF_INET6 , &(sin6.sin6_addr), v6addr,INET6_ADDRSTRLEN )) +setenv_str (es,"multihome_ip" , v6addr); +else +msg (M_WARN ,"WARNING: inet_ntop() failed wen converting address: %s" ,strerror (errno)); + } +break ; + } + } + } +#endif +/* Process --ipchange plugin */ if (plugin_defined (info->plugins,OPENVPN_PLUGIN_IPCHANGE )) {
Signature · 1 line
1.7.5.4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 9 lines · Davide Brini
Signed-off-by Davide Brini <[email protected]...>This patch creates two new environment variables: "
multihome_iface" and "multihome_ip", which contain respectively the interface name and IP address where the client connection came in, so scripts can use them.Tested on IPv4, "works for me". The patch is against the master branch.
Which platforms have this been tested on? Linux, *BSD? ... not a requirement, but would be good to know if there are more platforms this should be tested on explicitly.
Quoted 5 lines
Besides the style issues or the errors that surely this patch contains, I have some questions:
- Is this (ie, function
link_socket_connection_initiated()) the right place to do it?
At a cursory glance, this looks like a relevant place. But I'm not that familiar with socket handling in OpenVPN. And socket.c is a dreadful place to be.
Quoted 3 lines
- Currently it uses the same variable names for IPv4 and IPv6; would using
multihome_ipandmultihome_ip6make more sense, for example? (I don't think so, but asking for confirmation)
I think it makes sense to use the same variable for both. However, I'm not convinced the 'multihome' prefix is appropriate. Yes, it is multihome related, feature wise. But a more generic prefix might be better. F.ex. like 'client_conn_ip' and 'client_conn_iface' (or something like that) is more explicit in what the variable will contain.
Quoted 9 lines
- For consistency, I think it would be nice to set the same variables even when --multihome is not in effect. However, as it is now, OpenVPN explicitly checks for --multihome and if it's not set, it doesn't set the IP_PKTINFO/IP_RECVDSTADDR option in the socket, so that information is not always available (hence the
addr_defined_ipi()check is needed). Any reason why this is so? What would be the problem in always setting IP_PKTINFO/IP_RECVDSTADDR (if supported by the platform, of course)?
Quoted 4 lines
- Again for consistency, the same variables could/should be set for TCP connections, however I have no idea where to look for that (I don't even know whether
link_socket_connection_initiated()is called at all when using TCP). Any suggestions?
Well, the challenge here is that --multihome is only suitable in UDP mode, iirc. So most likely many of these multihome code paths are avoided when running in TCP mode.
Maybe in the areas around multo_process_* functions would be a better place to implement this then ... not sure, just thinking aloud.
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6lOPMACgkQDC186MBRfrqGDQCbBNZUEDI8dYPg5BO7qXYXUbly BIAAoIpIIncCk4w2bfITaVVIpdvvNxfg
=ZUJl
-----END PGP SIGNATURE-----
Quoted 11 lines · David Sommerseth
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 7 lines · Davide Brini
Signed-off-by Davide Brini <[email protected]...>This patch creates two new environment variables: "
multihome_iface" and "multihome_ip", which contain respectively the interface name and IP address where the client connection came in, so scripts can use them.
Quoted 6 lines
Quoted 2 lines
Tested on IPv4, "works for me". The patch is against the master branch.
Which platforms have this been tested on? Linux, *BSD? ... not a requirement, but would be good to know if there are more platforms this should be tested on explicitly.
Only Linux I'm afraid, although I tried to preserve the necessary #ifdef's (read: copied them from other places) so it should use the relevant structures (IP_RECVDSTADDR etc.) when running on *BSD. But tested only on Linux. Of course, more testing is always welcome.
Quoted 14 lines
Quoted 5 lines
Besides the style issues or the errors that surely this patch contains, I have some questions:
- Is this (ie, function
link_socket_connection_initiated()) the right place to do it?At a cursory glance, this looks like a relevant place. But I'm not that familiar with socket handling in OpenVPN. And
socket.cis a dreadful place to be.Quoted 3 lines
- Currently it uses the same variable names for IPv4 and IPv6; would using
multihome_ipandmultihome_ip6make more sense, for example? (I don't think so, but asking for confirmation)
Quoted 5 lines
I think it makes sense to use the same variable for both. However, I'm not convinced the 'multihome' prefix is appropriate. Yes, it is multihome related, feature wise. But a more generic prefix might be better. F.ex. like '
client_conn_ip' and 'client_conn_iface' (or something like that) is more explicit in what the variable will contain.
Sure, I used multihome_* because this came up in that context, but of course other names may be better (that's why I asked in the first place).
Quoted 14 lines
Quoted 9 lines
- For consistency, I think it would be nice to set the same variables even when --multihome is not in effect. However, as it is now, OpenVPN explicitly checks for --multihome and if it's not set, it doesn't set the IP_PKTINFO/IP_RECVDSTADDR option in the socket, so that information is not always available (hence the
addr_defined_ipi()check is needed). Any reason why this is so? What would be the problem in always setting IP_PKTINFO/IP_RECVDSTADDR (if supported by the platform, of course)?Quoted 4 lines
- Again for consistency, the same variables could/should be set for TCP connections, however I have no idea where to look for that (I don't even know whether
link_socket_connection_initiated()is called at all when using TCP). Any suggestions?
Quoted 6 lines
Well, the challenge here is that --multihome is only suitable in UDP mode, iirc. So most likely many of these multihome code paths are avoided when running in TCP mode.
Maybe in the areas around multo_process_* functions would be a better place to implement this then ... not sure, just thinking aloud.
When using TCP, you get multihome for free, so to speak, as TCP automatically works the way UDP --multihome works (in fact, "switch to using TCP" was the suggestion given to people before --multihome for UDP was introduced).
What I'd like to have is a couple of variables that contain the target IP address and interface a given client connection is using, regardless of whether the connection is using TCP, UDP, or the server has multiple interfaces or not. I understand these variables would be most useful when the server can receive connections on multiple interfaces, but I think it wouldn't hurt and would be more consistent to always set them regardless.
Thanks!
Signature · 1 line
D.