OpenVPN: トラフィックのリダイレクトが機能しない

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 に接続でき、 の VPN ホストに ping できますが172.31.1.1、ドメインまたは IP で google.com に ping しようとすると、メッセージが表示されます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

ありがとう。


そこで、クライアント213.30.5.46(Google の IP の 1 つ) に ping を実行しようとしましたが、機能しませんでしたが、次の結果が得られました。

送信 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.46宛先にpingを送信中にターゲット設定:

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\interfaceseth0:1eth0

 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 では、トンネルはツール セットの不可欠な部分です。

インターフェースに複数の IP を割り当てる方法を変更するために、ファイルiproute2を変更する (少なくとも試してみる) ことにしました。/etc/network/interfaceseth0

その後、すべて正常に動作しました。

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こちら:

関連情報