☰

OpenVPN：流量重定向不起作用

tag-icon • tag-icon openvpn route tunneling traffic
OpenVPN：流量重定向不起作用

太長了；博士（使用 @krisFR 進行數小時除錯後）：至少在 Debian 8 下，切勿對 OpenVPN 使用虛擬介面 (eth0:1)，而是套用iproute2此處所述的新 debian 方法（手動方法）：https://wiki.debian.org/NetworkConfiguration#iproute2_method。它將很好地引導交通。

我試圖在一台機器上設定 OpenVPN，所有客戶端流量都應透過隧道發送，所以這是我的伺服器設定的一部分：

local x.x.x.243
port 443
proto udp
dev tun
server 172.31.1.0 255.255.255.0 
push "redirect-gateway def1 bypass-dhcp"

我的客戶端配置：

pull
resolv-retry infinite
mute-replay-warnings 
redirect-gateway def1
script-security 1

客戶端能夠連接到 VPN，並且可以 ping VPN 主機172.31.1.1，但是如果我嘗試透過網域或 IP ping google.com，我會收到一條Request timeout for icmp_seq 0訊息...

可能是什麼原因造成的？旁注，我已經卸載了所有防火牆，並且目前將 IPTables 設定為：

iptables -A INPUT -i eth0:1 -m state --state NEW -p udp --dport 443 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0:1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0:1 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.31.1.0/24 -o eth0:1 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT

謝謝。

所以我嘗試 ping 客戶端213.30.5.46（Google 的 IP 之一），但沒有成功，但我得到了以下結果：

偵聽傳出 VPN IP (eth0:1)：tcpdump -i eth0 -t host x.x.x.243

IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 113
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP vpn.exampledomain.com.https > [CLIENT_IP x..].51060: UDP, length 81
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145

同時，在 tun0 上監聽，我得到了這個：tcpdump -i tun0

23:40:39.864798 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 0, length 64
23:40:40.925951 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 256, length 64
23:40:41.886679 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 512, length 64
23:40:42.906125 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 768, length 64

這是輸出iptables -L -n -v：

Chain INPUT (policy ACCEPT 34772 packets, 2265K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth0:1 *       0.0.0.0/0            0.0.0.0/0            state NEW udp dpt:443
   13  1092 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1437 96985 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun+   eth0:1  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth0:1 tun+    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 32574 packets, 7919K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   13  1092 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0

筆記： /proc/sys/net/ipv4/ip_forward被設定為1。

tcpdump -i eth0:1 -t host 213.30.5.46ping 目的地時有針對性：

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0:1, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 0, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 256, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 512, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 768, length 64

客戶端上沒有顯示任何內容，最終 ping 逾時。

OpenVPN 使用的IP 位址local x.x.x.243設定\etc\network\interfaces如下eth0:1：eth0

 auto eth0:1
  iface eth0:1 inet static
   address x.x.x.243
   gateway x.x.x.129
   netmask 255.255.255.128
   dns-nameservers x.x.x.4 x.x.x.104

答案1

正如你所說，我們花了幾個小時一起調試這個...

關於我們所做的所有測試和檢索到的所有跟踪，最終看來我們在虛擬介面方面遇到了一些奇怪的行為eth0:1。

例如：http://lartc.org/howto/lartc.iproute2.html

大多數 Linux 發行版和大多數 UNIX 發行版目前都使用古老的 arp、ifconfig 和 Route 指令。雖然這些工具可以運作，但它們在 Linux 2.2 及更高版本下會表現出一些意外的行為。例如，GRE 隧道如今已成為路由不可或缺的一部分，但需要完全不同的工具。

對於 iproute2，隧道是工具集的一個組成部分。

我們決定切換到iproute2（至少嘗試一下）修改/etc/network/interfaces檔案來更改為介面分配多個 IP 的方式eth0。

之後一切都很順利並且工作正常！

iproute2例 ：

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 192.168.1.42
    netmask 255.255.255.0
    gateway 192.168.1.1

iface eth0 inet static
    address 192.168.1.43
    netmask 255.255.255.0

有關此處的更多資訊iproute2：

相關內容