web-dev-qa-db-ja.com

同じマシン上のOpenVPNクライアントとサーバー-クライアントが接続されている場合、サーバーは接続を許可しません

私はこのコミュニティに初めて参加し、誰かが私を助けてくれることを期待しています。必要な情報をすべて投稿していない場合はお知らせください。

状況：

  • 有料VPNプロバイダーへのOpenVPNクライアント（tun1）として機能するLinuxサーバー（Raspberry Pi、192.168.1.2）があります。 Linuxサーバーをデフォルトゲートウェイ（192.168.1.2）として使用して、このVPN接続をローカルでLANクライアントと共有しています。これは問題なく動作しています。

  • まったく同じLinuxサーバーで、別のopenVPNインスタンス（VPNサーバー、tun0）を実行して、WANクライアントが接続できるようにします。これも問題なく動作しています。有料VPNプロバイダーへのVPNクライアント接続が確立されていません。

  • 私の最終的な目標は、別のopenVPNサーバー（tun0）インスタンスを介して接続するWANクライアントと有料VPN接続（tun1）を共有することです。

ローカルネットワークセットアップのスキーム：

enter image description here

問題：

  • OpenVPNクライアントとopenVPNサーバーインスタンスは、同時に実行しない限り問題なく動作します。 openVPNクライアントが有料VPNプロバイダーに接続するとすぐに、WANクライアントはopenVPNサーバーに接続できません。

  • ログファイルを確認したところ、WANクライアントハンドシェイクが有料VPN接続が確立されるとすぐに失敗することがわかりました。これは、この有料VPN接続がすべて確立されると、発信インターネットトラフィックはトンネル（tun1）を介してルーティングされるため、クライアントのハンドシェイク要求は未応答のままですが、これを解決する方法がわかりません。

ifconfig

pi@server:~ $ ifconfig -a
eth0      Link encap:Ethernet  HWaddr b8:27:eb:f2:c1:98
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth1      Link encap:Ethernet  HWaddr 58:82:a8:8d:9a:fa
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:203 errors:0 dropped:0 overruns:0 frame:0
          TX packets:165 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:22948 (22.4 KiB)  TX bytes:24938 (24.3 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.77.0.1  P-t-P:10.77.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.130.1.70  P-t-P:10.130.1.69  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

iptables

pi@server:~ $ Sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:1199

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  10.77.0.0/24         anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Route -n（tun0/tun1が not running＆not connected）の場合）

pi@server:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

ルート-n（tun0が実行中で接続されている場合）

pi@server:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
10.77.0.0       10.77.0.2       255.255.255.0   UG    0      0        0 tun0
10.77.0.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

ルート-n（tun1が実行中で接続されている場合）

pi@raspi-cyberghost:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.130.0.133    128.0.0.0       UG    0      0        0 tun1
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth1
10.77.0.0       10.77.0.2       255.255.255.0   UG    0      0        0 tun0
10.77.0.2       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.130.0.1      10.130.0.133    255.255.255.255 UGH   0      0        0 tun1
10.130.0.133    0.0.0.0         255.255.255.255 UH    0      0        0 tun1
107.183.241.2   192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
128.0.0.0       10.130.0.133    128.0.0.0       UG    0      0        0 tun1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

OpenVPNクライアント（tun1）が接続されているときに接続しようとすると、OpenVPNサーバー（tun0）エラーログ

Tue Mar 21 08:06:19 2017 us=593849 172.56.28.50:24844 TLS: Initial packet from [AF_INET]172.56.28.50:24844, sid=d25df6fb 2136a7cc
Tue Mar 21 08:07:19 2017 us=128339 172.56.28.50:24844 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Mar 21 08:07:19 2017 us=128603 172.56.28.50:24844 TLS Error: TLS handshake failed
Tue Mar 21 08:07:19 2017 us=129254 172.56.28.50:24844 SIGUSR1[soft,tls-error] received, client-instance restarting
iptablesraspberry-piroutingopenvpnvpn
7
khofm

私の解決策を見つけました。問題は、2つのルーティングテーブルを作成する必要があることです。1つはPi（および対応する応答）への着信トラフィックを処理し、もう1つはPi（およびその応答）からの発信トラフィックを処理します。

この2番目のルーティングテーブルは私のためにそれを解決しました：

ip rule add from 192.168.1.2 lookup 10           # Pi server
ip route add default via 192.168.1.1 table 10    # LAN router
5
khofm