CentOS 上的 OpenVPN 服务器:无法让客户端连接到互联网

网络工程 虚拟专用网
2022-02-17 07:56:35

我在 CentOS 6.7 上设置了 OpenVPN 服务器

我从已知的工作服务器复制了配置,因此我很确定服务器配置正确。

我遇到的问题是 VPN 客户端可以正常连接,但无法访问 Internet 上的任何内容。

  • 客户端正在使用证书进行身份验证。
  • 我正在推送 Google 的公共 DNS 服务器(8.8.8.8)

我在 sysctl.conf 中启用了数据包转发

net.ipv4.conf.all.forwarding = 1 net.ipv4.conf.all.mc_forwarding = 0 net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.mc_forwarding = 0 net.ipv4.conf.lo.forwarding = 1 net.ipv4.conf.lo.mc_forwarding = 0 net.ipv4.conf.eth0.forwarding = 1 net.ipv4.conf.eth0.mc_forwarding = 0 net.ipv4.conf.tun0.forwarding = 1 net.ipv4.conf.tun0.mc_forwarding = 0 net.ipv4.ip_forward = 1 net.ipv4.ip_forward_use_pmtu = 0

我添加了这些 iptables 规则:

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE -m comment --comment "Masquerade OpenVPN traffic"

iptables -A INPUT -i tun0 -j ACCEPT -m comment --comment "Allow all incoming OpenVPN"

iptables -A FORWARD -i tun0 -j ACCEPT

tun0配置如下:

$ ip address show tun0 6: tun0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/[65534] inet 172.16.1.1 peer 172.16.1.2/32 scope global tun0

在我的 openvpn.log 中,我可以看到客户端连接正常:

Thu Aug 20 06:54:59 2015 us=94453 31.108.32.42:55065 [David] Peer Connection Initiated with [AF_INET]31.108.32.42:55065 Thu Aug 20 06:54:59 2015 us=94789 MULTI: new connection by client 'David' will cause previous active sessions by this client to be dropped. Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect. Thu Aug 20 06:54:59 2015 us=94913 MULTI_sva: pool returned IPv4=172.16.1.6, IPv6=(Not enabled) Thu Aug 20 06:54:59 2015 us=94991 MULTI: Learn: 172.16.1.6 -> David/31.108.32.42:55065 Thu Aug 20 06:54:59 2015 us=95013 MULTI: primary virtual IP for David/31.108.32.42:55065: 172.16.1.6 Thu Aug 20 06:55:00 2015 us=350681 David/31.108.32.42:55065 UDPv4 READ [56] from [AF_INET]31.108.32.42:55065: P_CONTROL_V1 kid=0 [ ] pid=6 DATA len=42 Thu Aug 20 06:55:00 2015 us=351165 David/31.108.32.42:55065 PUSH: Received control message: 'PUSH_REQUEST' Thu Aug 20 06:55:00 2015 us=351212 David/31.108.32.42:55065 send_push_reply(): safe_cap=940 Thu Aug 20 06:55:00 2015 us=351282 David/31.108.32.42:55065 SENT CONTROL [David]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,route 172.16.1.1,topology net30,ping 10,ping-restart 120,ifconfig 172.16.1.6 172.16.1.5' (status=1)

如果我使用 tshark 观看 tun0 我可以看到正在执行 DNS 查询,但似乎没有任何响应:

1.935018671 172.16.1.6 -> 8.8.8.8 DNS 74 Standard query 0xe4a3 A external-lhr3-1.xx.fbcdn.net 1.937067717 172.16.1.6 -> 8.8.8.8 DNS 68 Standard query 0xdbc8 A edge-chat.facebook.com 2.324716221 172.16.1.6 -> 8.8.8.8 DNS 65 Standard query 0xc98b A clients4.google.com 2.331865976 172.16.1.6 -> 8.8.8.8 DNS 65 Standard query 0x5acb AAAA clients4.google.com 2.335206663 172.16.1.6 -> 8.8.8.8 DNS 65 Standard query 0x6ba8 A clients4.google.com 2.610867667 172.16.1.6 -> 8.8.8.8 DNS 62 Standard query 0xfb5e A www.google.co.uk 2.612555200 172.16.1.6 -> 8.8.8.8 DNS 62 Standard query 0xcaf7 A www.google.co.uk 2.628983231 172.16.1.6 -> 8.8.8.8 DNS 75 Standard query 0x803d A fbcdn-photos-a-a.akamaihd.net

我也可以在 eth0 上看到数据包,它有一个公共互联网 IP。

$ tshark -i eth0 -f "host 172.16.1.6" Running as user "root" and group "root". This could be dangerous. Capturing on eth0 0.000000000 172.16.1.6 -> 8.8.8.8 DNS 79 Standard query 0x7afb A clients4.google.com 0.002199239 172.16.1.6 -> 8.8.8.8 DNS 74 Standard query 0x4f3c A m.facebook.com 0.003786487 172.16.1.6 -> 8.8.8.8 DNS 74 Standard query 0x7033 A m.facebook.com 0.005484385 172.16.1.6 -> 8.8.8.8 DNS 70 Standard query 0x86a1 A google.com 0.008791391 172.16.1.6 -> 8.8.8.8 DNS 74 Standard query 0x031d AAAA api.amazon.com

再一次 - 没有别的方式

客户端可以 ping vpn 服务器 (172.16.1.1) 但除此之外什么都没有。

我不确定我还能检查什么。

2个回答

刚刚做了一个快速测试,以查看 tcpdump (I̶ ̶a̶s̶s̶u̶m̶e̶ ̶T̶S̶H̶A̶R̶K̶ ̶b̶e̶h̶a̶v̶e̶s̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶) 在使用 iptables 配置 NAT 时,即使没有配置 OpenVPN,也会在出口接口上显示 NAT'd 或原始源 IP 地址。

设置:Ubuntu eth1 <-> eth1 CentOS eth0 <->“互联网”

Ubuntu 配置:

sudo ip addr add 172.16.1.2/30 dev eth1
sudo ip link set dev eth1 up
sudo ip route add default via 172.16.1.1

CentOS 配置:

dhclient -v eth0
ip addr add 172.16.1.1/30 dev eth1
ip link set dev eth1 up
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -F FORWARD
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT

(只需询问您是否需要解释上述任何配置。)

现在我们从 Ubuntu (172.16.1.2) ping 到 8.8.8.8 (Google DNS) ...

内部的 :

[root@localhost ~]# tcpdump -ni eth1 'icmp'
tcpdump:详细输出被抑制,使用 -v 或 -vv
在 eth1 上进行完整协议解码侦听,链接类型 EN10MB(以太网),捕获大小 65535 字节
11:02: 44.251212 IP 172.16.1.2 > 8.8.8.8:ICMP echo request,id 2996,seq 1,长度 64
11:02:44.269621 IP 8.8.8.8 > 172.16.1.2:ICMP echo reply,id 2996,seq 1,长度 64
11: 02:45.252338 IP 172.16.1.2 > 8.8.8.8:ICMP echo request,id 2996,seq 2,长度 64
11:02:45.268138 IP 8.8.8.8 > 172.16.1.2:ICMP echo reply,id 2996,seq 2,长度 64
11:02:46.253904 IP 172.16.1.2 > 8.8.8.8:ICMP echo 请求,id 2996,seq 3,长度 64
11:02:46.270498 IP 8.8.8.8 > 172.16.1.2:ICMP echo 回复,id 2996,seq 3,长度 64

外部的 :

[root@localhost ~]# tcpdump -ni eth0 'icmp'
tcpdump:详细输出被抑制,使用 -v 或 -vv
在 eth0 上进行完整协议解码侦听,链接类型 EN10MB(以太网),捕获大小 65535 字节
11:02: 44.251252 IP 10.0.2.15 > 8.8.8.8:ICMP echo request,id 2996,seq 1,长度 64
11:02:44.269581 IP 8.8.8.8 > 10.0.2.15:ICMP echo reply,id 2996,seq 1,长度 64
11: 02:45.252363 IP 10.0.2.15 > 8.8.8.8:ICMP echo request,id 2996,seq 2,长度 64
11:02:45.268126 IP 8.8.8.8 > 10.0.2.15:ICMP echo reply,id 2996,seq 2,长度 64
11:02:46.253942 IP 10.0.2.15 > 8.8.8.8:ICMP echo request,id 2996,seq 3,长度 64
11:02:46.270469 IP 8.8.8.8 > 10.0.2.15:ICMP echo reply,id 2996,seq 3,长度 64

成功 !
更重要的是,我们看到 tcpdump 显示了经过 NAT 处理的地址!

在您的输出中,捕获的 IP 是“172.16.1.6”——清楚地表明为什么没有返回流量。
您的 ISP(或某些 Internet 路由器)一看到私有地址就会丢弃流量。

正如另一条评论所提到的,检查您的 NAT 配置 -或者在您触摸 OpenVPN 之前尝试让 NAT 像我上面所做的那样工作。

干杯!

编辑:刚刚用 tshark 进行了测试,它的行为与 tcpdump 相同,因为它显示了 NAT 后的源 IP 地址:

[root@localhost ~]# tshark -ni eth0 'icmp'
以用户“root”和组“root”运行。这可能很危险。
捕获 eth0
0.000000000 10.0.2.15 -> 8.8.8.8 ICMP 98 Echo (ping) 请求 id=0x0bbb, seq=1/256, ttl=63
0.015220791 8.8.8.8 -> 10.0.2.15 ICMP 98 Echo (ping) 回复 id= 0x0bbb, seq=1/256, ttl=54

更仔细地查看您的 iptables 配置...

iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT

第一行将执行 NAT 的“外部网络设备”指定为 tun0。
第二行与转发无关,因为 INPUT 链关注的是发往本地服务器本身的流量,而不是通过 iinm 的流量。
第三行指定 tun0 是“内部/内部”接口。

在我看来,
1)您的 NAT 接口应该是 eth0,而不是隧道接口,以及
2)您需要在同一行上使用“-o eth0 -j ACCEPT”之类的选项指定外部接口(eth0)你指定你的内部接口(tun0),
3)不要忘记一个单独的 iptables 语句来返回流量,就像我上面的例子一样!

我感觉你的流量没有被正确地 NAT,所以当(或者我真的希望很久以前)它到达谷歌的 DNS 服务器时,它作为一个无效的公共可​​路由前缀被丢弃。将嗅探器连接到 VPN 服务器的 Internet 端,并查看 VPN 服务器发送流量的 IP 地址。