我有以下设置：
- 专用服务器年代使用静态公共 IP 地址
eth0运行 OpenVPN 作为服务器tun0并执行 NAT 从tun0到eth0 - 网关路由器G这是 OpenVPN 客户端，
tun0IP 为 10.8.0.16
问题是，我显然可以正常访问互联网，并且响应也正常返回，只是网关路由器完全不接受它们。
请参阅以下示例：
在 ping 1.1.1.1 时进行 TCPdumpG产量
# ping 1.1.1.1 -I tun0
PING 1.1.1.1 (1.1.1.1) from 10.8.0.16 tun0: 56(84) bytes of data.
♥
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6005ms
# 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
05:23:35.781349 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 15, length 64
05:23:35.814670 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 15, length 64
05:23:36.781452 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 16, length 64
05:23:36.826077 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 16, length 64
05:23:37.781352 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 17, length 64
05:23:37.819026 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 17, length 64
05:23:38.781321 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 18, length 64
05:23:38.818058 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 18, length 64
05:23:39.781330 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 19, length 64
05:23:39.813765 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 19, length 64
05:23:40.781333 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 20, length 64
05:23:40.813766 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 20, length 64
如你所见，ping 成功1.1.1.1，并收到回复，但输出却ping没有任何动静
G 的 Iptables：
# iptables-save | grep -v -e DOCKER -e docker
# Generated by iptables-save v1.6.0 on Sat Aug 4 06:00:09 2018
*filter
:INPUT ACCEPT [29125:29954508]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [28322:3971375]
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
COMMIT
# Completed on Sat Aug 4 06:00:09 2018
# Generated by iptables-save v1.6.0 on Sat Aug 4 06:00:09 2018
*nat
:PREROUTING ACCEPT [3840:167985]
:INPUT ACCEPT [110:29389]
:OUTPUT ACCEPT [198:66581]
:POSTROUTING ACCEPT [198:66581]
-A POSTROUTING -s 192.168.0.0/16 -o eth1 -j MASQUERADE
COMMIT
# Completed on Sat Aug 4 06:00:09 2018
tcpdump 开启年代还表明ICMP请求被正确转发：
22:39:44.983332 In ethertype IPv4 (0x0800), length 100: 10.8.0.16 > 1.1.1.1: ICMP echo request, id 5383, seq 3, length 64
22:39:44.983348 Out 00:25:90:82:12:92 ethertype IPv4 (0x0800), length 100: 91.121.133.159 > 1.1.1.1: ICMP echo request, id 5383, seq 3, length 64
22:39:44.989167 In 00:00:5e:00:01:01 ethertype IPv4 (0x0800), length 100: 1.1.1.1 > 91.121.133.159: ICMP echo reply, id 5383, seq 3, length 64
22:39:44.989184 Out ethertype IPv4 (0x0800), length 100: 1.1.1.1 > 10.8.0.16: ICMP echo reply, id 5383, seq 3, length 64
S 上的 iptables 看起来也不错：
singinwhale# iptables-save | grep -v -e DOCKER -e docker
# Generated by iptables-save v1.4.21 on Fri Aug 3 23:54:56 2018
*raw
:PREROUTING ACCEPT [134484:12309809]
:OUTPUT ACCEPT [143517:21443183]
COMMIT
# Completed on Fri Aug 3 23:54:56 2018
# Generated by iptables-save v1.4.21 on Fri Aug 3 23:54:56 2018
*nat
:PREROUTING ACCEPT [11432:503568]
:INPUT ACCEPT [3303:157660]
:OUTPUT ACCEPT [2083:317164]
:POSTROUTING ACCEPT [2083:317164]
-A POSTROUTING -s 10.8.0.0/16 -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Aug 3 23:54:56 2018
# Generated by iptables-save v1.4.21 on Fri Aug 3 23:54:56 2018
*mangle
:PREROUTING ACCEPT [134484:12309809]
:INPUT ACCEPT [112991:10911009]
:FORWARD ACCEPT [12383:1034220]
:OUTPUT ACCEPT [143517:21443183]
:POSTROUTING ACCEPT [155157:22421380]
COMMIT
# Completed on Fri Aug 3 23:54:56 2018
# Generated by iptables-save v1.4.21 on Fri Aug 3 23:54:56 2018
*filter
:INPUT ACCEPT [77764:7068235]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [107553:10768547]
-A INPUT -p tcp -m tcp --dport 45454 -j ACCEPT
-A INPUT ! -s 127.0.0.1/32 -p tcp -m tcp --dport 56845 -j DROP
-A FORWARD -i tun0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o tun0 -j ACCEPT
COMMIT
# Completed on Fri Aug 3 23:54:56 2018
顺便说一下，curl http 请求也发生了同样的情况，所以这不仅适用于 ICMP。这是怎么回事？
编辑
显然，rp_netfilter 在所有接口上都已启用（设置为 1），因此从 tun0 上的 1.1.1.1 到达的数据包被归类为 martians。这是一个开始，但我以前从未处理过 netfilter，但至少这是一个开始。
这是我的路由表：
我的路由表如下所示：
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default server.frederix 0.0.0.0 UG 100 0 0 eth1
10.8.0.0 * 255.255.0.0 U 0 0 0 tun0
link-local * 255.255.0.0 U 1000 0 0 eth0
172.29.8.236 * 255.255.255.252 U 100 0 0 eth1
server.frederix server.frederix 255.255.255.255 UGH 100 0 0 eth1
192.168.0.0 * 255.255.0.0 U 0 0 0 eth0
以下是@AB 请求的一些命令的输出：
root@gateway ~ # ip -br link
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
bond0 DOWN 8e:f6:77:ae:d0:f2 <BROADCAST,MULTICAST,MASTER>
tunl0@NONE DOWN 0.0.0.0 <NOARP>
sit0@NONE DOWN 0.0.0.0 <NOARP>
eth0 UNKNOWN c2:c5:04:7a:0c:ba <BROADCAST,MULTICAST,UP,LOWER_UP>
eth1 UNKNOWN ba:0b:a9:79:40:5b <BROADCAST,MULTICAST,UP,LOWER_UP>
wlan0 DOWN 00:08:22:4c:b3:fb <BROADCAST,MULTICAST>
tun0 UNKNOWN <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
root@gateway ~ # ip -4 -br address
lo UNKNOWN 127.0.0.1/8
eth0 UNKNOWN 192.168.0.1/16
eth1 UNKNOWN 172.29.8.237/30
tun0 UNKNOWN 10.8.0.16/16
root@gateway ~ # ip route
default via 172.29.8.238 dev eth1 proto static metric 100
10.8.0.0/16 dev tun0 proto kernel scope link src 10.8.0.16
169.254.0.0/16 dev eth0 scope link metric 1000
172.29.8.236/30 dev eth1 proto kernel scope link src 172.29.8.237 metric 100
172.30.3.254 via 172.29.8.238 dev eth1 proto dhcp metric 100
192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.0.1
root@gateway ~ # ip route get 1.1.1.1
1.1.1.1 via 172.29.8.238 dev eth1 src 172.29.8.237
答案1
您的路由表显示您没有路由任何除了 VPN 自己的 10.8.0.0/16 网络之外，还允许其他到 VPN 的流量。
如果您希望 VPN 处理流量，则需要为该流量设置适当的路由。否则，任何流量都无法通过 VPN。
例如，要通过 VPN 路由所有流量，您的服务器配置应该包含以下内容：
push "redirect-gateway ipv6 def1 bypass-dhcp"