【OpenVPN】VPNサーバからクライアントの先にあるLAN内に接続する方法

2024年8月16日

URLをコピーしました！

はじめに

こんにちは。ネットワークエンジニアの「だいまる」です。

今回はOpenVPNにまつわるトラブルについてまとめていきたいと思います。

今回解決したいトラブル内容は？

今回のトラブルは、VPNの拡張のためにVPNサーバからVPNクライアント先のネットワークにアクセスする方法です。

今まではVPNネットワーク内の通信のみ考えていたのですが、ネットワーク設計の変更に伴い、VPNネットワーク内外の通信を行いたいと思い、対応したのが背景です。

以下の記事の設定では、上記の図のような通信は成立しません。

あわせて読みたい

【WordPress・ブログ構築】AWS（EC2）をリバースプロキシとして構築してみた（NGINX/OPENVPN構築）【はじめに】こんにちは。ネットワークエンジニアの「だいまる」です。前回の「【WordPress・ブログ構築】初めてのブログ構築はレンタルサーバ・自前環境どっちがお得…

サーバ1では、10.1.0.0/24向けの経路を「sudo ip route add 10.1.0.0/24 via 10.8.0.2 dev tun0 metric 10」コマンドで追加しました。

daimaru@Server1:~$ sudo ip route add 10.1.0.0/24 via 10.8.0.2 dev tun0 metric 10
daimaru@Server1:~$ ip route
default via 192.168.XX.YY dev ens192 proto dhcp metric 100
10.1.0.0/24 via 10.8.0.2 dev tun0 metric 10
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
192.168.XX.0/24 dev ens192 proto kernel scope link src 192.168.XX.ZZ metric 100

その上で、サーバ1からサーバ2の「10.1.0.1」宛にPingを飛ばした際は、サーバ1のTun0（VPN IF）からは出力されていますが、物理IFからは出力されていないことがわかります。

daimaru@Server1:~$ ping 10.1.0.1
PING 10.1.0.1 (10.1.0.1) 56(84) bytes of data.

--- 10.1.0.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4078ms

daimaru@Server2:~$ sudo tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes

daimaru@Server1:~$ sudo tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
20:09:39.669153 IP 10.8.0.1 > 10.1.0.1: ICMP echo request, id 64732, seq 1, length 64
20:09:40.675189 IP 10.8.0.1 > 10.1.0.1: ICMP echo request, id 64732, seq 2, length 64
20:09:41.699199 IP 10.8.0.1 > 10.1.0.1: ICMP echo request, id 64732, seq 3, length 64
20:09:42.723195 IP 10.8.0.1 > 10.1.0.1: ICMP echo request, id 64732, seq 4, length 64
20:09:43.747194 IP 10.8.0.1 > 10.1.0.1: ICMP echo request, id 64732, seq 5, length 64

daimaru@Server1:~$ sudo tcpdump -i ens192 -n 
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes

一方、10.8.0.6宛にPingを飛ばした際には、サーバ1のTun0（VPN IF）から出力され、物理IFからはカプセル化された状態で出力されています。

以下ログではServer1から10.8.0.6向けのPing疎通ができていることがわかります。

daimaru@Server1:~$ ping -s 1400 10.8.0.6
PING 10.8.0.6 (10.8.0.6) 1400(1428) bytes of data.
1408 bytes from 10.8.0.6: icmp_seq=1 ttl=64 time=0.294 ms
1408 bytes from 10.8.0.6: icmp_seq=2 ttl=64 time=0.200 ms
1408 bytes from 10.8.0.6: icmp_seq=3 ttl=64 time=0.249 ms
1408 bytes from 10.8.0.6: icmp_seq=4 ttl=64 time=0.383 ms
1408 bytes from 10.8.0.6: icmp_seq=5 ttl=64 time=0.230 ms
1408 bytes from 10.8.0.6: icmp_seq=6 ttl=64 time=0.222 ms
^C
--- 10.8.0.6 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5118ms
rtt min/avg/max/mdev = 0.200/0.263/0.383/0.060 ms

次にServer1のIF tun0とensでのパケットキャプチャをみてみたいと思います。

daimaru@Server1:~$ sudo tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
20:12:40.581385 IP 10.8.0.1 > 10.8.0.6: ICMP echo request, id 59082, seq 1, length 1408
20:12:40.581671 IP 10.8.0.6 > 10.8.0.1: ICMP echo reply, id 59082, seq 1, length 1408
20:12:41.603192 IP 10.8.0.1 > 10.8.0.6: ICMP echo request, id 59082, seq 2, length 1408
20:12:41.603376 IP 10.8.0.6 > 10.8.0.1: ICMP echo reply, id 59082, seq 2, length 1408

daimaru@Server1:~$ sudo tcpdump -i ens192 -n | grep 192.168.1.44
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:12:40.581449 IP 192.168.1.43.1194 > 192.168.1.44.51005: UDP, length 1452
20:12:40.581636 IP 192.168.1.44.51005 > 192.168.1.43.1194: UDP, length 1452
20:12:41.603227 IP 192.168.1.43.1194 > 192.168.1.44.51005: UDP, length 1452
20:12:41.603349 IP 192.168.1.44.51005 > 192.168.1.43.1194: UDP, length 1452

上記ログから疎通が取れていることがわかります。

また、物理IF（ens192）よりTun0のパケット長（1408）からカプセル化されていることがわかります。

上記よりOpenVPNのサーバ側の設定に何か問題があることがわかります。

リンク

解決方法は意外と簡単！

この通信を行うために実施する手段は以外と簡単で主に２ステップとなります。

Step1：VPNサーバの設定（Server.conf）を変更

最初にVPNサーバ側の設定（Server.conf）の内容を変更していきます。

変更箇所は全部で2点あります。

１点目は「Server.conf」の中に以下２行を追加することです。

client-config-dir /etc/openvpn #ルーティング系の設定ファイルの読み込み先
route 10.1.0.0 255.255.255.0 #ルーティングテーブルに載せる経路

２点目は、「client-config-dir /etc/openvpn」で指定したディレクトリ配下に接続しているクライアント名と同じファイルを作成します。

クライアント名は作成時に指定した鍵名になりますが、不明な場合は「/var/log/openvpn/openvpn-status.log」を確認すればわかります。

daimaru@Server1:~$ sudo cat /var/log/openvpn/openvpn-status.log
OpenVPN CLIENT LIST
Updated,2024-06-28 22:01:58
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
Server2,192.168.1.44:51005,56217,56491,2024-06-28 19:23:46
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.6,Server2,192.168.1.44:51005,2024-06-28 20:12:45
GLOBAL STATS
Max bcast/mcast queue length,1
END

上記で確認した後は、「sudo vim /etc/openvpn/Server2」コマンドを実行し、以下を入力します。

daimaru@Server1:~$ sudo cat /etc/openvpn/test_client
iroute 10.1.0.0 255.255.255.0

上記の作成後、OpenVPNを再起動することで「10.1.0.0/24」宛の経路がテーブルに追加されます。

JCOMのネットを使ってみる

Step2：VPNクライアント側の設定を変更

VPNサーバ側の設定を変更した後は、VPNクライアント側の設定を変更していきます。

何を変更するか？

それは「/proc/sys/net/ipv4/ip_forward」を「1」にします。

この実行により、サーバのIF1-IF2間のIPv4ルーティングが可能となります。

#事前確認
daimaru@Server2:~$ sudo cat /proc/sys/net/ipv4/ip_forward
0

#rootアカウントで以下実行
echo 0 > /proc/sys/net/ipv4/ip_forward

#事後確認
daimaru@Server2:~$ sudo cat /proc/sys/net/ipv4/ip_forward
1

リンク

動作確認：Pingが通るようになりました！

まず、「Server1」側の状態を確認していきましょう。

ルーティングテーブルは、「10.1.0.0/24」向けの経路が追加され、想定通りとなっています。

daimaru@Server1:~$ ip route
default via 192.168.1.1 dev ens192 proto dhcp metric 100
10.1.0.0/24 via 10.8.0.2 dev tun0
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
192.168.1.0/24 dev ens192 proto kernel scope link src 192.168.1.43 metric 100

では、各IFのキャプチャを見てみましょう。

daimaru@Server1:~$ ping -s 1400 10.1.0.1
PING 10.1.0.1 (10.1.0.1) 1400(1428) bytes of data.
1408 bytes from 10.1.0.1: icmp_seq=1 ttl=64 time=0.243 ms
1408 bytes from 10.1.0.1: icmp_seq=2 ttl=64 time=0.811 ms
1408 bytes from 10.1.0.1: icmp_seq=3 ttl=64 time=0.228 ms

daimaru@Server1:~$ sudo tcpdump -i tun0 -n
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
22:15:12.727258 IP 10.8.0.1 > 10.1.0.1: ICMP echo request, id 9745, seq 1, length 1408
22:15:12.727490 IP 10.1.0.1 > 10.8.0.1: ICMP echo reply, id 9745, seq 1, length 1408
22:15:13.731150 IP 10.8.0.1 > 10.1.0.1: ICMP echo request, id 9745, seq 2, length 1408
22:15:13.731944 IP 10.1.0.1 > 10.8.0.1: ICMP echo reply, id 9745, seq 2, length 1408

daimaru@Server1:~$ sudo tcpdump -i ens192 -n | grep 192.168.1.44
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:15:12.727311 IP 192.168.1.43.1194 > 192.168.1.44.59424: UDP, length 1452
22:15:12.727470 IP 192.168.1.44.59424 > 192.168.1.43.1194: UDP, length 1452
22:15:13.731187 IP 192.168.1.43.1194 > 192.168.1.44.59424: UDP, length 1452
22:15:13.731920 IP 192.168.1.44.59424 > 192.168.1.43.1194: UDP, length 1452

上記結果から疎通ができるようになりました。

リンク