OpenVPN高级路由技术-反向推送信息

在《VPN的概念以及要点》中，我指出了OpenVPN构建的网络是单向的，也就是说在不手工配置系统路由的情况下，只能由OpenVPN客户端一侧发起连接。这是因为OpenVPN服务器会把自己一侧的路由推送至OpenVPN客户端，反之，OpenVPN客户端却不能把自己一侧的路由推送给OpenVPN服务器。于是我自己修改代码手工实现了一个PUSH消息，将客户端的信息放在PUSH_REQUEST的后面进行发送，然后OpenVPN服务器端进行解析。此举改动了大量的代码，浪费了我一天无聊的时间…

    有什么更直接的方式么？事实上，当你认为没有的时候，蓦然回首，那人正在灯火阑珊处等你呢。如果你执行openvpn –help的时候，你会发现一个很有趣的选项，那就是push-peer-info选项，正如help解释所说，它只能用于client。该选项的含义是将OpenVPN客户端的信息推送至OpenVPN服务器。那么赶紧试试看。

    有时候，大多数时候，事情总是不像你想象的那样顺利。在客户端配置文件中天剑push-peer-info后，日志级别开到最高，服务器端并没有任何信息输出，那么请问，客户端都推送给服务器哪些信息，这些信息又推到哪里去了？带着这两个问题，我看了OpenVPN的源代码。

    我找到了push_peer_info函数，在该函数中，有很多的判断，比如下面这句：

if (!strncmp(e->string, "UV_", 3)&& buf_safe(&out, strlen(e->string)+1))         buf_printf(&out, "%s\n", e->string);

必须以UV_开头的信息才可被推送，当我去掉这个限制的时候，在客户端打印出了推送的信息，可是服务器端还是没有收到。为了尽快得到服务器端哪个位置可能会接收这个信息，首先要找到客户端哪里推送了这个信息，也就是说push_peer_info函数是被谁调用的，因为对于数据通信程序而言，处理一般都是对称的。

    经查阅，发现是key_method_2_write调用了这个push_peer_info函数，那么对应的服务端，就是key_method_2_read中读取这个信息了。待会再看key_method_2_read，先把key_method_2_write搞明白再说。在key_method_2_write中：

static boolkey_method_2_write (struct buffer *buf, structtls_session *session){     ASSERT(session->opt->key_method == 2);     ASSERT(buf_init (buf, 0));     /* writea uint32 0 */     buf_write_u32 (buf, 0)     /* writekey_method + flags */     buf_write_u8(buf, (session->opt->key_method & KEY_METHOD_MASK))     /* writekey source material */     key_source2_randomize_write(ks->key_src, buf, session->opt->server)     /* writeoptions string */     write_string(buf, local_options_string (session), TLS_OPTIONS_LEN)     /* writeusername/password if specified */     if(auth_user_pass_enabled){           auth_user_pass_setup (NULL);           write_string(buf, auth_user_pass.username, -1)           write_string(buf, auth_user_pass.password, -1)           purge_user_pass (&auth_user_pass, false);      }else{           write_empty_string (buf)/* no username */           write_empty_string (buf) /* no password */      }     push_peer_info (buf, session)…}

通过以上的逻辑，发现无论如何，这个顺序执行都是要进行的，也就是说，一个信息没有写对，那么握手就不会完成，如果不理解OpenVPN密钥协商的过程，那么请参考前面的关于OpenVPN协议的文章。因此可以知道，这个peer-info信息是绝对写进去了的，那么既然服务器端没有收到，问题肯定在服务器端了，也就是说，服务器端根本就没有读取，或者说读取了丢掉了。接下来就该看服务器端的key_method_2_read代码逻辑了。

    在key_method_2_read中，逻辑要复杂一些，但是基本框架还是简单的，无非就是key_method_2_write的逆过程：

static boolkey_method_2_read (struct buffer *buf,struct tls_multi *multi, struct tls_session *session){     …     //前面密钥协商相关的我不关心，因此从读取option开始     /*get options */     read_string(buf, options, TLS_OPTIONS_LEN)     //按照write的逆过程，接下来该读取username和password了，如果没有这两项，比如不使用username的话，那么也要读取两个0     /* should wecheck username/password? */     ks->authenticated= false;     if(session->opt->auth_user_pass_verify_script      || plugin_defined(session->opt->plugins, OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY)      || man_def_auth == KMDA_DEF) {             …            //在这个if分支中确实有读取peer-info的#ifdef MANAGEMENT_DEF_AUTH            /* get peer info from control channel */            free (multi->peer_info);            multi->peer_info = read_string_alloc(buf);             …#endif            //可是，根本就没有进入这个if分支，只有在相关plugin定义时才会进入            //因此对于peer-info的读取，并不是和peer-info的设置对称的，读取是有条件的。      } else {           //else分支中也没有读取peer-info      }      …     buf_clear(buf);//直接clear了，peer-info胎死腹中，烂在了buf里面     ...}

问题找到了，那么在else分支中加上读取peer-info的语句会怎样？那就是试试看，在else分支的最开始加上：

buf_read_u16 (buf); //略去一个0，代表usernamebuf_read_u16 (buf);//略去一个0，代表password//至于为何这么写，还请看看前面介绍的OpenVPN的协议封装格式。printf(“#####-peer-info:%s\n”, read_string_alloc (buf);//最后将以上的字符串赋值给multi->peer_info即可。//注意，对multi->peer_info的赋值和前面的打印对read_string_alloc是互斥的，因为该read函数会推进buf的当前指针。multi->peer_info=read_string_alloc (buf);

再次测试，屏幕上打印出了客户端的信息。可是这些信息看样子没有什么用处啊，我该怎样把路由信息加入其中呢？这才是最关键的啊。大的框架问题已经解决，于是回过头来看push_peer_info函数，掠过无关紧要的信息，我看到了一个for：

for (e=es->list; e != NULL; e=e->next) {           if (e->string) {              //去掉前导字符串匹配限制，为了尽可能多的发送信息              if (/*!strncmp(e->string, "UV_", 3) &&*/ buf_safe(&out, strlen(e->string)+1))                buf_printf (&out, "%s\n", e->string);            }}

可以看出，是从一个envset中取出的值加入了peer-info中。现在问题就转化成了如何将路由信息加入其中。在动手修改之前还是要深入理解OpenVPN本身是否支持某些现成的机制。再次help，发现了有一个—setenv-safe name value选项，真是太好了，看看能否从这里做点文章，于是在客户端配置文件中加入了setenv-safe route 172.17.0.0/16，再次测试，发现服务器端的multi->peer_info真的就包含了这个OPENVPN_route=172.17.0.0/16这条信息，只可惜所有的peer-info信息是分行的，不便于env解析操作，于是下面的修改就是将分行的改成单行的，这个太简单了，直接将push_peer_info中的\n换成;即可啦，而且正是因为setenv-safe传入的只是一个字符串，那么我就可以自己定义这个串的格式，完全可以支持由:分割的多条路由啦：

setenv-safe route 172.17.0.0/16:1.2.3.0/24:2.2.3.0/24:123.234.123.0/24…

        现在离最后的成功就差一步了，那就是既然OpenVPN服务器端得到了OpenVPN客户端的路由信息：

OPENVPN_route=172.17.0.0/16:1.2.3.0/24:2.2.3.0/24:123.234.123.0/24

那么怎么将其加入到OpenVPN服务器主机的系统路由表里面呢？可以想象，到达这些路由的网关一定指向分配给该客户端的虚拟网卡的IP地址，或者在TUN模式下直接指向本地的虚拟网卡。在什么情况下能得到分配给客户端的虚拟地址呢？最简单的方式就是使用plugin/script机制添加这些路由，于是添加了一个client-connect的script，因为在这个脚本中，已经为客户端分配了IP地址了，虽然该script可以覆盖这个地址，但不管怎么说都是在script内部完成的，于是在script中实现添加路由即可，对应的plugin是OPENVPN_PLUGIN_CLIENT_CONNECT

这个HOOK点，这里再次体现了OpenVPN事件机制的强大。

        还有最后一步就是在调用script或者plugin之前将对应客户端的tls_multi->peer_info信息存入env中，而这个再简单不过了：

if (mi->context.c2.tls_multi->peer_info)        setenv_str(mi->context.c2.es,"peerinfo", mi->context.c2.tls_multi->peer_info);

两行即搞定了。接下来的代码就是：

if (plugin_defined (mi->context.plugins,OPENVPN_PLUGIN_CLIENT_CONNECT))

上述的代码在函数multi_connection_established中。

        最后，看看client-connect的定义：

#!/bin/bashgateway=$(printenv ifconfig_pool_remote_ip)peer=$(printenv peerinfo)for rt in `echo$peer | awk -F';' '{ for (i = 1; i<NF;i++) print $i }' |grep route|awk -F'=' '{print $2}'`;do    forrrt in `echo $rt|awk -F ':' '{for (j = 1;j<=NF;j++) print $j}'`;    do        routeadd -net $rrt gw $gateway    donedone

最后再次测试，非常完美，客户端的路由完美的推送到了服务器端！

   总结一下就是一共修改了以下几个地方，总共添加修改的代码不超过10行：

1.ssl.c中修改了key_method_2_read和push_peer_info函数

2.multi.c中修改了multi_connection_established函数

OpenVPN至此已经非常完美，非常对称。至此我可以说，OpenVPN已经可以完美兼容IPSec VPN的网络拓扑了。