OpenVPNでLAN間接続がうまくいかない。

前提・実現したいこと

Raspberry Pi3 Model B同士でOpenVPNを用いたLAN間接続。

トポロジ図(抜粋)

接続構成としては、Site AにあるRaspberry PiがOpenVPNのサーバとなっており、
Site BにあるRaspberry Piがクライアントになっております。
Site Aのルータ(Cisco 841M)には、あらかじめ以下のように、192.168.5.0へのルーティングが入っています。

ip route 192.168.5.0 255.255.255.0 192.168.0.yyy

Site B側は諸事情でルータではなく、端末にroute addで追加しています。

route add 192.168.0.0 mask 255.255.255.0 192.168.5.yyy

該当のソースコード

server.conf

port 1194
proto udp
dev tun

ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem

server 10.8.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 192.168.0.0 255.255.255.0"

keepalive 10 120

cipher AES-256-CBC

comp-lzo

user nobody
group nogroup

persist-key
persist-tun

status /var/log/openvpn-status.log

log /var/log/openvpn.log
log-append /var/log/openvpn.log

verb 3

explicit-exit-notify 1

client.conf

client

dev tun

proto udp

remote xxx.xxx.xxx.xxx nnnn

resolv-retry infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key

remote-cert-tls server

ns-cert-type server

cipher AES-256-CBC

comp-lzo

verb 3

ipp.txt

client,10.8.0.6

サーバ側のルーティングテーブル

カーネルIP経路テーブル
受信先サイト    ゲートウェイ    ネットマスク   フラグ Metric Ref 使用数 インタフェース
default         gateway         0.0.0.0         UG    202    0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

クライアント側のルーティングテーブル

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.5.1     0.0.0.0         UG    202    0        0 eth0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.0.0     10.8.0.5        255.255.255.0   UG    0      0        0 tun0
192.168.5.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

気になることとしては、以下があります。
（１）サーバ側にクライアントへ渡すルートがないため、手動で登録しようとしてもDestination Unreachableになること。
（２）クライアント側のルーティングテーブルに見覚えのない10.8.0.5がゲートウェイとして登録されている。
ちなみに、消して正しいルートを入れようとしても（１）同様にDestination Unreachableで登録できませんでした。
※（２）については、10.8.0.5へはPINGは通りませんでした。

IPアドレスとしてはサーバ側が10.8.0.1でクライアント側が10.8.0.6になります。

試したこと

サーバ側とクライアント側にルートを追加したが、Destination Unreachableになる。
しかし、正しいIPへのPINGが正常に通る。

行動規範の内容に同意します

回答1件

ベストアンサー

VPNはネットワーク接続しているサーバと端末との間で、仮想的なネットワークを作成する仕組みです。なので、192.168.5.yyyから192.168.0.yyyへのネットワーク接続はできることが前提になりますが、質問の記述内容からは、VPNを使用して192.168.5.0/24と192.168.0.0.0/24のネットワークを接続しようとしているように見受けられます。

192.168.5.yyyから192.168.0.yyyへのネットワーク接続が出来る状態の場合、10.8.0.0/24のプライベートネットワークが構築されます。

+----------------+    +-----------------+
|  192.168.0.yyy |----| 192.168.5.yyy   |
|                |    |                 |
|  +----------+  |    |  +----------+   |
|  | 10.8.0.1 |----------| 10.8.0.6 |   |
|  +----------+  |    |  +----------+   |
+----------------+    +-----------------+

ルーティング情報はそれぞれ以下の通り。（proto kernelはカーネルが自動生成するルート）

sh
1# VPNサーバ
2$ ip route
3default via 192.168.0.1 dev eth0 proto static metric 100
410.8.0.0/24 via 10.8.0.2 dev tun0
510.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
6192.168.0.0/23 dev eth0 proto kernel scope link src 192.168.0.yyy metric 100

shoute
1# VPNクライアント
2$ ip r
3default via 192.168.5.1 dev eth0 onlink
410.8.0.1 via 10.8.0.5 dev tun0
510.8.0.5 dev tun0  proto kernel  scope link  src 10.8.0.6
6192.168.5.0/24 dev eth0  proto kernel  scope link  src 192.168.5.yyy

10.8.0.2、10.8.0.5 は仮想ネットワークのネットワークアドレスとして設定されているようで、OpenVPNが設定するデフォルト値のようです。

【参考】

VPNが正常に接続できてる状態のログです。

VPNサーバ側ログ（CentOS 7）

sh
1$ grep vpn /var/log/messages | tail -n 20 | sed -r 's/(([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]).){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])/***.***.***.***/g' | sed -r 's/www[0-9]{5}[a-z]{2}/********/g'
2Apr 29 08:42:53 ******** openvpn: Sun Apr 29 08:42:53 2018 client/***.***.***.***:34457 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
3Apr 29 08:42:53 ******** openvpn: Sun Apr 29 08:42:53 2018 client/***.***.***.***:34457 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
4Apr 29 08:42:53 ******** openvpn: Sun Apr 29 08:42:53 2018 client/***.***.***.***:34457 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384,
54096 bit RSA
6Apr 29 09:42:53 ******** openvpn: Sun Apr 29 09:42:53 2018 client/***.***.***.***:34457 TLS: soft reset sec=0 bytes=37202/0 pkts=708/0
7Apr 29 09:42:54 ******** openvpn: Sun Apr 29 09:42:54 2018 client/***.***.***.***:34457 VERIFY OK: depth=1, CN=********.sakura.ne.jp
8Apr 29 09:42:54 ******** openvpn: Sun Apr 29 09:42:54 2018 client/***.***.***.***:34457 VERIFY OK: depth=0, CN=client
9Apr 29 09:42:54 ******** openvpn: Sun Apr 29 09:42:54 2018 client/***.***.***.***:34457 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
10Apr 29 09:42:54 ******** openvpn: Sun Apr 29 09:42:54 2018 client/***.***.***.***:34457 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
11Apr 29 09:42:54 ******** openvpn: Sun Apr 29 09:42:54 2018 client/***.***.***.***:34457 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
12Apr 29 09:42:54 ******** openvpn: Sun Apr 29 09:42:54 2018 client/***.***.***.***:34457 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
13Apr 29 09:42:54 ******** openvpn: Sun Apr 29 09:42:54 2018 client/***.***.***.***:34457 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384,
144096 bit RSA
15Apr 29 10:32:52 ******** yum[26376]: Updated: openvpn-2.4.5-1.el7.x86_64
16Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 TLS: soft reset sec=0 bytes=37097/0 pkts=706/0
17Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 VERIFY OK: depth=1, CN=********.sakura.ne.jp
18Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 VERIFY OK: depth=0, CN=client
19Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
20Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
21Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
22Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
23Apr 29 10:42:54 ******** openvpn: Sun Apr 29 10:42:54 2018 client/***.***.***.***:34457 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384,
244096 bit RSA

VPNクライアント側ログ（Ubuntu 16.04）

sh
1$ grep vpn /var/log/syslog | tail -n 20 | sed -r 's/(([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]).){3}([1-9]?[0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])/***.***.***.***/g' | sed -r 's/www[0-9]{5}[a-z]{2}/********/g'
2Apr 29 09:42:54 brix ovpn-client[1150]: VERIFY OK: nsCertType=SERVER
3Apr 29 09:42:54 brix ovpn-client[1150]: VERIFY OK: depth=0, CN=server
4Apr 29 09:42:54 brix ovpn-client[1150]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
5Apr 29 09:42:54 brix ovpn-client[1150]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
6Apr 29 09:42:54 brix ovpn-client[1150]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
7Apr 29 09:42:54 brix ovpn-client[1150]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
8Apr 29 09:42:54 brix ovpn-client[1150]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
9Apr 29 09:42:54 brix ovpn-client[1150]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
10Apr 29 09:42:54 brix ovpn-client[1150]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
11Apr 29 10:42:53 brix ovpn-client[1150]: TLS: tls_process: killed expiring key
12Apr 29 10:42:54 brix ovpn-client[1150]: VERIFY OK: depth=1, CN=********.sakura.ne.jp
13Apr 29 10:42:54 brix ovpn-client[1150]: VERIFY OK: nsCertType=SERVER
14Apr 29 10:42:54 brix ovpn-client[1150]: VERIFY OK: depth=0, CN=server
15Apr 29 10:42:54 brix ovpn-client[1150]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
16Apr 29 10:42:54 brix ovpn-client[1150]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
17Apr 29 10:42:54 brix ovpn-client[1150]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
18Apr 29 10:42:54 brix ovpn-client[1150]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
19Apr 29 10:42:54 brix ovpn-client[1150]: WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
20Apr 29 10:42:54 brix ovpn-client[1150]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
21Apr 29 10:42:54 brix ovpn-client[1150]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

投稿2018/04/24 15:40

編集2018/04/29 02:03

tkmtmkt

総合スコア1800

nwt487

2018/04/25 01:55

tkmtmkt 様ご回答有り難うございます。 10.8.0.2と10.8.0.5についてはこちらとして想定していないアドレスで、OpenVPNが入っているRaspberry Pi同士でもpingが疎通できない状態です。質問に記載しているのですが、10.8.0.1がホストで10.8.0.6がクライアントとなります。上記のような.2と.5の設定をした覚えがないため、設定場所の情報などあったりしますでしょうか。知識が乏しい中での質問ですが、どうかご容赦ください。

tkmtmkt

2018/04/26 16:25

IPアドレスの記述間違えていたので修正しました。 10.8.0.2と10.8.0.5はOpenVPNが作成しているネットワークアドレスのようです。設定を行わない場合のデフォルト値が10.8.0.2と10.8.0.5になっているようです。

nwt487

2018/04/28 15:08

この設定を10.8.0.1と10.8.0.6にする設定などあるのでしょうか。調べてみたのですが、どうも探し方が悪いのか見当たらないです…。

tkmtmkt

2018/04/29 02:21

VPNの設定に問題があると考えておられるようですが、回答欄に示したルーティング情報は正常に接続できている状態のものです。接続できない原因の調査はまずログを見てみたほうが良いです。回答欄の最初に書いていますが、質問欄にある環境でRaspberry PiのVPN接続を行うためには192.168.0.yyy～192.168.5.yyyが接続できていなければなりません（SiteAとSiteBのルータ間でVPNが構築されていること）。質問欄の図からServer(Linux)とClient(Windows)を接続するために、Raspberry PiでVPN構築しようと考えているように推察されますが、そのような接続を行いたいのであれば、サーバ側のRaspberry PiのVPNポートをルータの設定変更してインターネット上に公開し、クライアント側からはインターネット上に公開したポートに接続するように設定する必要があります。

行動規範の内容に同意します