你在生产中有类似的配置吗？如果是这样 – 你使用了什么路由守护进程 – quagga？别的什么？你遇到过什么问题吗？
谢谢！
解决方法
过去对我来说非常好用的一个选项是使用tap设备而不是tun设备来构建我的OpenVPN隧道.这将以太网通过隧道而不是第3层封装,并且它允许您解决OpenVPN的固有限制,从而将自己的路由表与内核分开.缺点是你通过这种隧道方式会产生大量开销……想象一下通过TCP加密SSL的以太网TCP ……你明白了.上行是它已经工作并且横向扩展得相当好.
假设您的VPN服务器和客户端是Linux端点(我只在Linux上测试过),您可以创建一个新的虚拟网桥接口并将网关接口分配给网桥以获取您的第3层.在我的拓扑中,我为每个VPN服务器提供了拥有10.x.0.0 / 16子网,并部署了本地DHCP服务器,为连接客户端分配地址. DHCP服务器需要在那里,因为OpenVPN不再知道IP地址;它是隧道以太网.客户端在连接后运行dhclient以通过VPN接口获取IP,这全部由连接到OpenVPN配置的连接脚本管理.
一旦通过DHCP获得双方的IP地址,您就可以使用动态路由协议在连接的客户端之间通告路由.我过去使用的是Quagga,它的工作非常可靠.
使用tap的示例服务器配置：
mode server proto tcp-server port 1194 dev tap0
将tap接口添加到新桥的示例命令：
sudo brctl addbr vpnbr0 # create new bridge called vpnbr0 sudo brctl setfd vpnbr0 0 # set forwarding delay to 0 secs sudo brctl addif vpnbr0 tap0 # add openvpn tap interface to vpnbr0
示例拆卸命令：
sudo brctl delif vpnbr0 tap0 sudo brctl delbr vpnbr0
拥有vpnbr0网桥接口后,您可以在其上运行DHCP服务器或手动分配IP地址.然后,您可以像任何其他以太网接口一样对待它.您可能希望进行其他更改以调整MTU大小,您可能会尝试不同的协议和加密选项,直到您在效率和安全性之间找到适当的平衡.我没有任何好的规格可以提供整体吞吐量,这里有很多活动部件.
如果我要重新做一遍,我会坚持使用OpenVPN中的tun设备,并且我会按照第一段中链接的文章中的说明更新Linux内核的路由表,随时更新OpenVPN的内部地址表.这将消除堆栈中的DHCP,减少隧道开销,并允许我的客户端连接和操作,而无需参与动态路由.
