☰

如何查明是什么阻止了我的 OpenVPN 流量

tag-icon • tag-icon networking firewall openvpn
如何查明是什么阻止了我的 OpenVPN 流量

我在使用 OpenVPN 推送路由时遇到问题。

我的设置如下

网络

  • 霍姆兰：10.0.0.0/24
  • 开放VPN：10.8.0.0/24
  • 互联网中的 VPS

服务器（所有 Linux）

  • 服务器1：10.0.0.13 + 10.8.0.1（OpenVPN 服务器）
  • 服务器2：10.0.0.11（DHCP+DNS）
  • VPS：互联网IP + 10.8.0.X（来自OpenVPN的随机IP）

OpenVPN 服务器配置

..snip..
push "route 10.0.0.0 255.255.255.0"
push "dhcp-option DNS 10.0.0.11"
..snip..

IP转发已激活

cat /proc/sys/net/ipv4/ip_forward
1

路由VPS

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         www.xxx.yyy.1    0.0.0.0         UG    0      0        0 eth0
10.0.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
10.8.0.0        10.8.0.5        255.255.255.0   UG    0      0        0 tun0
10.8.0.5        *               255.255.255.255 UH    0      0        0 tun0
www.xxx.yyy.1    *               255.255.255.255 UH    0      0        0 eth0

路由服务器1

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.0.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.0.0        *               255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        *               255.255.255.255 UH    0      0        0 tun0

尝试从 VPS ping openvpn-server (10.8.0.1)

ping 10.0.0.13
ping 10.0.0.13 -I tun0;#gives same result

VPS 的 tcpdump

tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
19:05:22.049141 IP 10.8.0.6 > 10.8.0.1: ICMP echo request, id 17966, seq 1, length 64
19:05:22.101397 IP 10.8.0.1 > 10.8.0.6: ICMP echo reply, id 17966, seq 1, length 64

tcpdump 服务器1

tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
18:05:22.064139 IP 10.8.0.6 > 10.8.0.1: ICMP echo request, id 17966, seq 1, length 64
18:05:22.064399 IP 10.8.0.1 > 10.8.0.6: ICMP echo reply, id 17966, seq 1, length 64
18:05:23.065687 IP 10.8.0.6 > 10.8.0.1: ICMP echo request, id 17966, seq 2, length 64
18:05:23.065886 IP 10.8.0.1 > 10.8.0.6: ICMP echo reply, id 17966, seq 2, length 64

不工作的是从 VPS 到服务器 1 的内部 IP 的连接

尝试从 VPS ping openvpn-server (10.0.0.13)

VPS 的 tcpdump

19:12:24.847216 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 1, length 64 
19:12:25.876441 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 2, length 64 
19:12:26.900408 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 3, length 64 
19:12:27.924476 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18136, seq 4, length 64 
19:12:39.964724 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18137, seq 1, length 64 
19:12:40.980446 IP vps.hoster.tld > 10.0.0.13: ICMP echo request, id 18137, seq 2, length 64

Server1 的 tcpdump

#stays empty

所以我真的很想知道这里出了什么问题。下一步要做什么来找出是什么阻止了我从 VPS 到内部 IP 10.0.0.0/24 的流量？也许家乡的防火墙阻止了流量？如何找出？

答案1

到达内部接口，无路由
默认情况下，Linux 将响应任何接口上的任何 IP，甚至会响应“错误”接口上的 ARP 请求。这是非常不安全的，所以大多数防火墙会使用 iptables 和 proc/arp_filter 来阻止这种行为。

您可能有阻止路由的防火墙规则：
server1> iptables -L -n -v
server1> iptables -t nat -L -n -v

server1> iptables -A FORWARD -j LOG将记录 (dmesg) 通过 server1 在 10.8 和 10.0 之间路由的所有数据包。它可能会给你一些信息。
$server1> iptables -D FORWARD -j LOG删除规则。

以下将在任何防火墙规则之前插入路由规则。
server1> echo 1 > /proc/sys/net/ipv4/ip_forward
server1> iptables -I FORWARD 1 --in-interface tun0 --source 10.8.0.0/24 -j ACCEPT
server1> iptables -I FORWARD 1 --in-interface eth0 --source 10.0.0.0/24 -j ACCEPT

我不希望VPS> ping 10.0.0.11它能工作，但如果它能工作，那么问题几乎肯定出在 server1 的 iptables 中。

您正在点对点地通过 server1 进行路由，因此它不应该执行 ARP，但如果其中任何一个设置为 1，则可能是由防火墙脚本完成的，问题将出现在 server1 的 iptables 中。
server1> cat /proc/sys/net/ipv4/conf/all/arp_filter
server1> cat /proc/sys/net/ipv4/conf/tun0/arp_filter

路线
您的路线看起来不错，但通过此设置，您不需要其中的 10.8.0.0/24 路线。 10.8.0.1 到 10.8.0.5 是点对点的。

VPS 应该有default gw、10.8.0.1 via tun0、 和10.0.0.0/24 via gw 10.8.0.1。
server1 应该有一个default gwand 10.8.0.5 via tun0, and 10.0.0.0/24 via eth0。

相关内容