1 OpenVPN简介 vpn替代昂贵的专线用以在开放的Internet上实现了一个虚拟的网络，该虚拟网络本身在不安全的真实网络上对数据提供安全保护。 OpenVPN实现了一个灵活的vpn，和通过修改协议栈而实现的基于IPSec的vpn相比，OpenVPN有以下的优点：1. OpenVPN无需对协议栈进行任何修改，无需专门的策略来解决VPN数据穿越NAT的问题，因此可在现有的网络进行规划；2. OpenVPN使用虚拟网卡和路由进行虚拟网络的构建，配置十分方便；3. OpenVPN使用SSL协议对虚拟网络提供保护，从而实现“专用”，而SSL提供了丰富灵活的安全特性；4. OpenVPN的push模式可以最大限度简化客户端配置，服务器和客户端可以不必花费太多的精力来使得两端一致。OpenVPN实际上是虚拟网卡设备，TCP/IP网络技术，路由技术，SSL结合而成的一个应用，前三者构建了虚拟网络—隧道连接的网络，最后SSL保证了虚拟网络通信的安全—隧道通信的认证和加密，因此使用OpenVPN的过程基本就是对上述四方面进行配置的过程。2 OpenVPN的参数集以及配置实例2.1 参数详解OpenVPN拥有很多的参数，但是很多参数涉及到很多的细节，首先如果不考虑过多的细节，那么这些参数大致可以分为五类，其中有一些参数是为了配置方便，组合其它的参数而成的：2.1.1 虚拟网卡配置参数：1) –dev tunX|tapX：配置虚拟网络使用的网卡设备，X是一个数字表示网卡的编号，在Unix/Linux系统中，它是一个字符设备，在Windows中，它是一个设备命名空间中的一个节点，tun设备和tap设备的区别在于出入前者的第三层（IP）数据报，而出入后者的是第二层（以太网）数据帧。注意：tap设备是二层设备，tun设备为三层设备，此二者各有优劣，简述如下：tap特点：a) 应用这种设备可以复用任意的三层数据报；b) 构成一个两路层网络，比如以太网，因此广播数据可以自由跨隧道传输；c) 无需路由即可进行节点通信；d) 配置简单，但是缺乏灵活性，IP层的优良特性无法自由应用。tun特点：a) 可以应用IP层的所有特性，比如Routing，IP-Qos，IP-fragment/de等，但是只支持IP数据报；b) 构成三层网络，节点间如不在一个子网要路由；c) 三层虚拟网络的每个子网下面没有链路层承载（ip数据报直接导出），因此链路层特性无法应用，比如以太网广播无法跨隧道传输，因此此虚拟网络是无法指定网关的。2) –dev-type dt：指示虚拟网卡设备的类型，仅仅在—dev参数无法识别设备类型的时候使用。3) –dev-node node：任意节点node被指示为虚拟网卡设备，node的路径以及名称可以任意，但是如果不是tunX/tapX的形式，那么必须配置—dev-type参数。4) –lladdr hw：为虚拟网卡配置链路层地址。2.1.2 网络配置参数：1) –local host：配置本地使用的IP地址，如果不是为了bind，那么可以不配置此参数，OpenVPN会自行处理。2) –remote host [port]：用于client端，配置client连接的server的IP或者主机名以及port，该参数可以配置多个用以实现一定的冗余，client则按照配置顺序依次连接server，直到连接成功为止。3) –proto p：配置隧道的类型，可以是udp或者tcp，其中tcp必须指明是server还是client，而udp可以不区分server和client，因此p可以为udp，tcp-server，tcp-client。注意：用tcp还是用udp构建隧道呢？默认是udp。任何有连接的协议在出现丢包时都会要求重发或者自动超时重发，为了避免因对网络带宽的未知或者网络拥塞而丢包从而导致端点重发，tcp实现了慢启动，滑动窗口以及加增承减等机制，不幸的是，以上机制仅可用于分层模型中的一层，在不同层次都实现得如此复杂就可能引起判断叠加从而使得上述机制无法做出最好的判断，比如用tcp建立的隧道，并且上面承载的又是tcp数据，那么一旦出现丢包，最终的端点以及隧道都要重发数据，这就导致了网络流量突然增大，后面的行为很难在短时间给出预测并采取措施。事实上如果隧道本身并不是非用tcp不可，那么最好使用 udp，保证连接与否是最终终端的事，而不是隧道的事，如果说最终用户使用tcp，那么他自己就保证了连接，如果他使用udp，那么说明他不在乎是否有连接，因此隧道使用udp，相反隧道使用tcp建立的话，如果最终用户使用tcp已经保证了连接，隧道没必要再多此一举，如果最终用户使用udp，那么隧道的tcp就降低了用户连接的效率，抵消了他使用udp的结果。4) –connect-retry n：配置连接重试的次数，仅仅对于—proto参数为tcp-client时有效。5) –connect-timeout n：连接重试的间隔。6) –auto-proxy：7) –bind：8) –nobind：9) –link-mtu n：配置四层链路的MTU，同时用同样的数值配置设备的MTU。注意：这个配置可能会引起莫名其妙的问题，就其本质是由于OpenVPN不允许通过隧道的数据被任意分段，即使是IP分片也必须妥善处理，OpenVPN 用一种规则的方式来收发socket数据。IP层将数据路由到虚拟网卡前如果发现数据报的长度大于虚拟网卡的MTU，那么就会将数据报分片，如果VPN两端的虚拟网卡的MTU设置不一致，OpenVPN接收socket数据的时候就会产生问题，因为最一般的情况下OpenVPN调用 recv/recvfrom的时候，参数中的len总是设置成自己的link-mtu，假设两端H1和H2的link-mtu分别为L1 和L2（L1L2），H1端发送数据给H2，则数据在H2则会接收不完整，因此势必会产生错误，即使解密收到的数据可能正确，由于数据长度不一致，校验时也会出错，即使在没有校验的情形下，由OpenVPN发送给虚拟网卡的IP数据报也会不完整。因此最好不要配置link-mtu参数，让它默认值好了，如果非要配置，保持两端一致。可以在linux上用strace，tcpdump以及OpenVPN源代码确认以上问题，具体为何这样设计还不清楚。如果在不考虑安全因素（程序输出的意思是防止active attack）可以更合理一些的话，我觉得recv数据时要按照对方的mtu来接收，毕竟recv和send只是一个中间阶段，数据从对端虚拟网卡的字符设备出来后就被send了，然后在本端被recv，之后被write进本端的虚拟网卡字符设备，如果仅仅按照本端的mtu来接收，势必会有问题，就好像在物理层上将数据截断一样。（在隧道的一端ping另一端，如果mtu不一致并且ping包大于mtu的小者的话，一定不同，可是仅仅将两端作为中间隧道的话就不一定了，数据从主机A，经由隧道的起始Ts，到达隧道终点Te，最终到达主机B，如果Ts和Te的mtu中小者都比A和B的mtu的大者大，在不考虑复杂的分段情况下是可以通的）因此，一种“几乎总是正确”的配置方法就是将mtu配置成一个很大的值，要比已知的物理链路的mtu都大，这样一来不会出错，二来可以不必担心两端不一致，三来可以最大限度的发送数据，而不会因为隧道太窄的缘故而降低数据发送速率，如果不理解以上这些或者为了保险起见，还是将mtu留默认比较好。10) –tun-mtu：注意事项同上，但是要强调和link-mtu之不同，此二者配置一个即可且只能配置一个，此中之缘由在于其关联性，tun-mtu为虚拟网卡之mtu，而link-mtu则为链路的mtu，其大小相差一个固定长度，二者区别等同于TCP的MSS和物理链路的MTU之区别。11) –shaper：该参数对隧道的带宽进行了限制，主要用于建立多个通道时在各个通道进行策略化带宽分配，如果只建立一个通道，也就是说仅仅运行一个 OpenVPN实例的话，这个参数就目前版本而言意义不大，因为本身单进程单线程的OpenVPN速度就很慢，再限速更没有意义了。12) –txqueuelen：该参数设定虚拟网卡的最大排队包的数量，也就是队列长度，默认为100，对于OpenVPN这样很慢的VPN来说，100就够了，即使你设得再大，用户空间的OpenVPN进程处理不过来还是白搭。2.1.3 路由参数：1) –route network [...]
Wednesday, June 22, 2011
OpenVPN简易文档
1 OpenVPN简介 vpn替代昂贵的专线用以在开放的Internet上实现了一个虚拟的网络，该虚拟网络本身在不安全的真实网络上对数据提供安全保护。 OpenVPN实现了一个灵活的vpn，和通过修改协议栈而实现的基于IPSec的vpn相比，OpenVPN有以下的优点：1. OpenVPN无需对协议栈进行任何修改，无需专门的策略来解决VPN数据穿越NAT的问题，因此可在现有的网络进行规划；2. OpenVPN使用虚拟网卡和路由进行虚拟网络的构建，配置十分方便；3. OpenVPN使用SSL协议对虚拟网络提供保护，从而实现“专用”，而SSL提供了丰富灵活的安全特性；4. OpenVPN的push模式可以最大限度简化客户端配置，服务器和客户端可以不必花费太多的精力来使得两端一致。OpenVPN实际上是虚拟网卡设备，TCP/IP网络技术，路由技术，SSL结合而成的一个应用，前三者构建了虚拟网络—隧道连接的网络，最后SSL保证了虚拟网络通信的安全—隧道通信的认证和加密，因此使用OpenVPN的过程基本就是对上述四方面进行配置的过程。2 OpenVPN的参数集以及配置实例2.1 参数详解OpenVPN拥有很多的参数，但是很多参数涉及到很多的细节，首先如果不考虑过多的细节，那么这些参数大致可以分为五类，其中有一些参数是为了配置方便，组合其它的参数而成的：2.1.1 虚拟网卡配置参数：1) –dev tunX|tapX：配置虚拟网络使用的网卡设备，X是一个数字表示网卡的编号，在Unix/Linux系统中，它是一个字符设备，在Windows中，它是一个设备命名空间中的一个节点，tun设备和tap设备的区别在于出入前者的第三层（IP）数据报，而出入后者的是第二层（以太网）数据帧。注意：tap设备是二层设备，tun设备为三层设备，此二者各有优劣，简述如下：tap特点：a) 应用这种设备可以复用任意的三层数据报；b) 构成一个两路层网络，比如以太网，因此广播数据可以自由跨隧道传输；c) 无需路由即可进行节点通信；d) 配置简单，但是缺乏灵活性，IP层的优良特性无法自由应用。tun特点：a) 可以应用IP层的所有特性，比如Routing，IP-Qos，IP-fragment/de等，但是只支持IP数据报；b) 构成三层网络，节点间如不在一个子网要路由；c) 三层虚拟网络的每个子网下面没有链路层承载（ip数据报直接导出），因此链路层特性无法应用，比如以太网广播无法跨隧道传输，因此此虚拟网络是无法指定网关的。2) –dev-type dt：指示虚拟网卡设备的类型，仅仅在—dev参数无法识别设备类型的时候使用。3) –dev-node node：任意节点node被指示为虚拟网卡设备，node的路径以及名称可以任意，但是如果不是tunX/tapX的形式，那么必须配置—dev-type参数。4) –lladdr hw：为虚拟网卡配置链路层地址。2.1.2 网络配置参数：1) –local host：配置本地使用的IP地址，如果不是为了bind，那么可以不配置此参数，OpenVPN会自行处理。2) –remote host [port]：用于client端，配置client连接的server的IP或者主机名以及port，该参数可以配置多个用以实现一定的冗余，client则按照配置顺序依次连接server，直到连接成功为止。3) –proto p：配置隧道的类型，可以是udp或者tcp，其中tcp必须指明是server还是client，而udp可以不区分server和client，因此p可以为udp，tcp-server，tcp-client。注意：用tcp还是用udp构建隧道呢？默认是udp。任何有连接的协议在出现丢包时都会要求重发或者自动超时重发，为了避免因对网络带宽的未知或者网络拥塞而丢包从而导致端点重发，tcp实现了慢启动，滑动窗口以及加增承减等机制，不幸的是，以上机制仅可用于分层模型中的一层，在不同层次都实现得如此复杂就可能引起判断叠加从而使得上述机制无法做出最好的判断，比如用tcp建立的隧道，并且上面承载的又是tcp数据，那么一旦出现丢包，最终的端点以及隧道都要重发数据，这就导致了网络流量突然增大，后面的行为很难在短时间给出预测并采取措施。事实上如果隧道本身并不是非用tcp不可，那么最好使用 udp，保证连接与否是最终终端的事，而不是隧道的事，如果说最终用户使用tcp，那么他自己就保证了连接，如果他使用udp，那么说明他不在乎是否有连接，因此隧道使用udp，相反隧道使用tcp建立的话，如果最终用户使用tcp已经保证了连接，隧道没必要再多此一举，如果最终用户使用udp，那么隧道的tcp就降低了用户连接的效率，抵消了他使用udp的结果。4) –connect-retry n：配置连接重试的次数，仅仅对于—proto参数为tcp-client时有效。5) –connect-timeout n：连接重试的间隔。6) –auto-proxy：7) –bind：8) –nobind：9) –link-mtu n：配置四层链路的MTU，同时用同样的数值配置设备的MTU。注意：这个配置可能会引起莫名其妙的问题，就其本质是由于OpenVPN不允许通过隧道的数据被任意分段，即使是IP分片也必须妥善处理，OpenVPN 用一种规则的方式来收发socket数据。IP层将数据路由到虚拟网卡前如果发现数据报的长度大于虚拟网卡的MTU，那么就会将数据报分片，如果VPN两端的虚拟网卡的MTU设置不一致，OpenVPN接收socket数据的时候就会产生问题，因为最一般的情况下OpenVPN调用 recv/recvfrom的时候，参数中的len总是设置成自己的link-mtu，假设两端H1和H2的link-mtu分别为L1 和L2（L1L2），H1端发送数据给H2，则数据在H2则会接收不完整，因此势必会产生错误，即使解密收到的数据可能正确，由于数据长度不一致，校验时也会出错，即使在没有校验的情形下，由OpenVPN发送给虚拟网卡的IP数据报也会不完整。因此最好不要配置link-mtu参数，让它默认值好了，如果非要配置，保持两端一致。可以在linux上用strace，tcpdump以及OpenVPN源代码确认以上问题，具体为何这样设计还不清楚。如果在不考虑安全因素（程序输出的意思是防止active attack）可以更合理一些的话，我觉得recv数据时要按照对方的mtu来接收，毕竟recv和send只是一个中间阶段，数据从对端虚拟网卡的字符设备出来后就被send了，然后在本端被recv，之后被write进本端的虚拟网卡字符设备，如果仅仅按照本端的mtu来接收，势必会有问题，就好像在物理层上将数据截断一样。（在隧道的一端ping另一端，如果mtu不一致并且ping包大于mtu的小者的话，一定不同，可是仅仅将两端作为中间隧道的话就不一定了，数据从主机A，经由隧道的起始Ts，到达隧道终点Te，最终到达主机B，如果Ts和Te的mtu中小者都比A和B的mtu的大者大，在不考虑复杂的分段情况下是可以通的）因此，一种“几乎总是正确”的配置方法就是将mtu配置成一个很大的值，要比已知的物理链路的mtu都大，这样一来不会出错，二来可以不必担心两端不一致，三来可以最大限度的发送数据，而不会因为隧道太窄的缘故而降低数据发送速率，如果不理解以上这些或者为了保险起见，还是将mtu留默认比较好。10) –tun-mtu：注意事项同上，但是要强调和link-mtu之不同，此二者配置一个即可且只能配置一个，此中之缘由在于其关联性，tun-mtu为虚拟网卡之mtu，而link-mtu则为链路的mtu，其大小相差一个固定长度，二者区别等同于TCP的MSS和物理链路的MTU之区别。11) –shaper：该参数对隧道的带宽进行了限制，主要用于建立多个通道时在各个通道进行策略化带宽分配，如果只建立一个通道，也就是说仅仅运行一个 OpenVPN实例的话，这个参数就目前版本而言意义不大，因为本身单进程单线程的OpenVPN速度就很慢，再限速更没有意义了。12) –txqueuelen：该参数设定虚拟网卡的最大排队包的数量，也就是队列长度，默认为100，对于OpenVPN这样很慢的VPN来说，100就够了，即使你设得再大，用户空间的OpenVPN进程处理不过来还是白搭。2.1.3 路由参数：1) –route network [...]
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment