使用OpenVPN时，有几点需要注意：

1. 如果不是OpenVPN客户端将自己的虚拟IP地址作为源地址发出的数据包，而是由其forward的数据包，那么就要在数据进入虚拟网卡之前做一个SNAT了，否则OpenVPN服务器将会拒绝接收这种数据包；
2. 如果使用的是tap虚拟网卡模式，那么一定要将OpenVPN服务器的虚拟ip设置成网关而不能仅仅设置一个出口设备，因为tap模式需要进行arp，如果目的地址不在OpenVPN服务器上或者即使在OpenVPN服务器上但是其arp_ignore设置了不同的值，arp都会不成功进而无法发送数据；
3. 在开启了client-to-client的情况下并且使用tun模式时，不要以为所有的client和server均在同一子网内，tun是点对点的，没有子网的概念，所以一个client或者其后的主机为了访问另一个client c2后面的资源，不能将网关设置成c2，除非做复杂的源/目的地址转换，因为OpenVPN服务器将不认识c2后面的目的地址。
4. 如果使用tap模式，并且开启了c2c，那么所有的client连同server共同组成一个虚拟子网，内部arp可流通，作为一个虚拟以太网和真实的以太网是一样的，OpenVPN服务器就是一个以太网交换机，可以设置任意的client或者server作为网关，这个意义上，OpenVPN服务器是一个三层交换机。

具体的代码都在multi_process_incoming_link中：

OpenVPN在help中列举了push-peer-info选项，可是man手册中却没有，google之，发现了以下的帖子以及回复：

Subject:how to use --push-peer-info under 2.2-RC2?
Flow:
I'm testing out 2.2-RC2 under Linux - installed on both client and server (--help shows it's there too). I have add "push-peer-info" to the client, and have up/down
 scripts on the server that include a printenv line to capture environment variables. However, I'm not seeing any new vars showing up.
So can someone tell me where does that detail show up on the server?
 
Subject:how to use --push-peer-info under 2.2-RC2?
Flow:
AFAIK (and AFAICT from looking at the sources) the 'push-peer-info' option is not complete yet. The *client* side works, but the server never extracts the right UV_* 
variables which are pushed out by the client to the server. 
November last year I asked the -devel list what this option is supposed to do ; the result of that discussion was that "this is a work in progress"  :-/

根据这个帖子，是否可以说OpenVPN对于push-peer-info的实现是个半吊子实现呢？实际上确实有点这个意思。可是这么做并没有什么不妥，永远不要指望开源代码能做到完美实现你的任意需求，人家开发者没有义务这么做。代码在自己手上，如果你看懂了逻辑，自己修改一下使之符合自己的需求便是了。唯一的问题就是将来有一天，他们实现了你现在通过修改代码实现的功能，你还要花一些时间来合并自己的实现和新版本的实现，有时候你要丢弃你的所有修改。

​ 日志记录机制是很多大型软件必不可少的组成部分，日志记录其实是蛮有趣的，既不能记录太多又要切中要害，因此很多程序将日志记录分为若干级别，比如调试级别只输出错误和调试信息，而错误级别则不再输出调试信息等，另外需要管理日志记录的分类，想完全实现这些机制是要动一番脑筋的，既有效又巧妙的实现遍布各大开源代码中，其中linux内核以及openvpn的记录都不错，都将日志作为一个协议而编码，该协议的通信双方是代码的处理逻辑部分和实际日志记录部分，不像printf或者fprintf仅仅记录内容本身，printk还包含一个级别信息，我们将此信息称作日志头，而消息本身就是日志体了，openvpn的实现更加精妙，本文详述其日志头的构成。实际上任何的消息如果想更加方便的管理和应用，都可以增加一个协议头，毕竟协议本身就是为了方便隔离的交互双方的耦合的。

​ OpenVPN中自定义IP地址分配有两种实现方式，一种是写一个plugin，plugin_call这个调用可以被添加到任何地方，OpenVPN中的plugin挂载点也可在任意位置定义，因此利用plugin来自定义IP地址分配策略就有两种方式，第一种方式是可以新定义一个plugin挂载点，紧接着动态分配IP的代码，然后在plugin中实现策略，当然具体到如何将已经分配的ip地址的指针传入plugin中还需要前文中介绍的方式，将ip地址的内存地址作为环境变量加入到env_set，然后…，这种方式需要修改OpenVPN的代码，要么自己定义一个挂载点，要么在已有的CLIENT_CONNECT中加入新的内存地址环境变量；第二种方式是一种标准的方式，也就是OpenVPN建议的方式，那就是在multi_connection_established中做文章，OpenVPN的代码不需要做任何修改：

​ server将topology推送至client，这就是为何必须实现net30模式的原因，就是为了兼容windows，由于windows的低版本tap-win32驱动只支持这种模式，而后的topology为p2p(实际上windows的tap-win32驱动通过简单修改，比如改掉自问自答的那一部分逻辑看上去也支持这种拓扑，但是如果涉及到dhcp，事情就复杂了，因为通过net30拓扑分给windows的两个主机ip中有一个会充当虚假的dhcp服务器，如果在windows上采用了p2p拓扑，那么tap-win32网卡将直连server的虚拟网卡，而server的虚拟网卡可不敢担此大任)，对于server来讲，没有什么变化，只是对于client来讲，解放了ip的占用，但是client必须是非windows的，不过server倒是可以是 windows，因为对于net30和p2p而言，server端的虚拟ip地址是一样的，不同的是对client的影响

​ 广播到底通过还是不通过OpenVPN呢？tap处理二层，tun处理三层，虽然tun两端ip是同一个子网，但是其二层却不是，广播是无法进行的，但是tap可以传输广播；由于windows的虚拟网卡驱动的特殊性，为了让windows也能进入vpn，OpenVPN和虚拟网卡驱动作了特殊且复杂的处理。本文详述之(注意，本文不介绍OpenVPN的各种专业术语，比如路由模式和桥接模式之类，需要的话请参考OpenVPN的文档或者FAQ)。

​ 对于提供服务的程序，一般而言喜欢使用0.0.0.0这个地址，但是如果这个服务是UDP的，那么就有可能出现一些问题，比如如果某块网卡配置了多个IP地址，那么问题就可能重现。最近使用OpenVPN的时候就遇到了这样的问题。OpenVPN建议使用UDP协议，然而正是由于使用了UDP协议才出现了问题。以下几个要点帮助解决这样的问题，记之备忘：

基本描述

tap-win32虚拟网卡

tap-win32虚拟网卡并不包含任何实际硬件，仅仅是一个驱动，该驱动中包含了一个DHCP服务器程序，可以回复DHCP协议的offer/ack/nak数据包。该驱动的DHCP服务器的参数是可配置的。 tap-win32驱动分为三大部分，首先它作为一个网卡驱动和NDIS中间驱动接口并且设置了一些回调函数，第二部分是一个DHCP服务器，但是这个DHCP的功能是简化的，这部分不和 NDIS接口。二者的关系在NDIS的网卡发送数据的回调函数中体现，网卡发送数据的回调函数中将特殊处理DHCP数据包，然后直接回复。第三部分，tap-win32实现了一个可以读/写/控制的文件，导出给用户态程序比如OpenVPN作为接口。