正文共:1111 字 8 图,预估阅读时间:1 分钟
在上篇文章中(以openVPN为例,介绍一下VPN网络中的递归路由问题),我们介绍了递归路由问题出现的原因以及解决方案。但是到最后我们发现,小伙伴在公网上配置的服务器和我在内网搭建的服务器配置还是存在差异,我自己的服务器就下发了到openVPN服务器的明细路由,规避了递归路由的问题出现。
然后我分析了一下两者的服务器配置文件,发现确实存在差异。
首先是我本地服务器server.conf的配置。
local 0.0.0.0
proto tcp
port 44331
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/tietou.crt
key /etc/openvpn/server/tietou.key
dh /etc/openvpn/server/dh.pem
topology subnet
server 10.153.113.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 192.168.10.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
duplicate-cn
keepalive 20 120
persist-key
persist-tun
整体上还是比较规范的,下发了192.168.10.0/24的业务网段,但是没有下发默认路由。
然后是公网服务器server.conf的配置。
local 0.0.0.0
proto tcp
port 44331
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/ctyuns.crt
key /etc/openvpn/server/ctyuns.key
dh /etc/openvpn/server/dh.pem
topology subnet
server 10.153.2.0 255.255.255.0
push "route 0.0.0.0 128.0.0.0"
push "route 128.0.0.0 128.0.0.0"
push "dhcp-option DNS 8.8.8.8"
duplicate-cn
keepalive 20 120
persist-key
persist-tun
对比下来,无外乎就3类配置不一样。
一是我本地的服务器配置了客户端IP地址记录文件。
ifconfig-pool-persist /etc/openvpn/ipp.txt
实际上这条配置也没真正用起来,所以不是这条配置的问题。
二是公网服务器中推送了DNS。
push "dhcp-option DNS 8.8.8.8"
实际上,这条配置只是为客户端推送了DNS服务器的配置,正常应该也不是这个问题,我们等下也测试一下。
三是服务器推送的路由信息。
这一点相对就比较明显了,公网服务器中推送的是两条可以替代默认路由的明细路由。
push "route 0.0.0.0 128.0.0.0"
push "route 128.0.0.0 128.0.0.0"
也正是这两条路由,导致了递归路由问题的出现。
而我本地的服务器,推送的是业务网段192.168.10.0/24和替代默认路由。
push "route 192.168.10.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
下面这条命令我们之前介绍过(openVPN服务器配置的31个关键点),如果配置此命令,将配置所有客户端的默认网关到VPN中,会导致所有IP流量(如Web浏览和DNS查找等流量)经openVPN服务器网关转发。这一条命令的嫌疑最大。
接下来,我们验证看一下。
首先,我们将本地服务器的服务器配置server.conf替换成公网服务器的,之后重启openVPN服务。
然后使用客户端连接测试一下。
果然就复现了递归路由的问题,看来配置文件肯定是出问题了。
接下来,我们先配置上记录客户端IP地址的文件。
ifconfig-pool-persist /etc/openvpn/ipp.txt
重启服务,再重新测试一下。
问题依旧,证明跟这条配置没有关系。
然后,我们把推送DNS服务器的配置删掉。
push "dhcp-option DNS 8.8.8.8"
重启服务,再重新测试一下。
我们可以发现,下发的配置中已经没有DNS服务器的相关配置了,但是问题依旧。可以证明跟这条配置也没有关系。
最后就是配置下发默认路由的配置了,我们在保留两条明细路由的同时新增下面这条配置:
push "redirect-gateway def1 bypass-dhcp"
重启服务,再重新测试一下。
可以看到,这次没有再出现递归路由的问题,但是出现了新的报错,感觉像是下发明细路由下发了两边,我们看一下系统路由表。
可以看到,有一条单独的指向服务器主机的明细路由,也正是这条路由,规避了递归路由问题的出现。
现在基本上找到问题了,接下来就是看一下自动配置下发默认路由的配置和手工配置默认路由的配置有什么区别。
接下来,我们在服务器配置文件中移除手工配置默认路由的命令。
push "route 0.0.0.0 128.0.0.0"
push "route 128.0.0.0 128.0.0.0"
重启服务,再重新测试一下。
可以看到,openVPN也是用两条明细路由代替的默认路由,所以手工再配置下发时会出现报错。
现在看来,下发默认路由时,还是使用系统命令好一些,不要再手工配置了,毕竟获取网关地址、添加服务器明细路由这个配置手工配置来还是挺麻烦的。
最后公布一下调整后的配置。
cat /etc/openvpn/server.conf
local 0.0.0.0
proto tcp
port 44331
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/tietou.crt
key /etc/openvpn/server/tietou.key
dh /etc/openvpn/server/dh.pem
topology subnet
server 10.153.113.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 192.168.10.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
duplicate-cn
keepalive 20 120
persist-key
persist-tun
解铃还须系铃人,问题解决。
长按二维码
关注我们吧
在SD-WAN网络中应用OpenVPN,chatGPT是这样想的