VPNクライアントをサーバー側のイントラに参加させたい

Question

前提・実現したいこと

SoftEther VPN Serverを利用して外部から自宅サーバー側のローカルネットワークにアクセスしたいと考えています。
サーバーのOSにはCentOS7でL2TP/IPsecを使用しています。

自宅ルーター : 192.168.0.1/24
VPNサーバー : 192.168.0.3/24(物理nicは一つ)

VPNクライアントはインターネット上にあり、windows(主に10)を想定しています。

仮想ハブとサーバーの物理nicをローカルブリッジ機能によって繋げています。

クライアントに割り振られるIPが192.168.0.0/24でサーバーやルータと同一セグメント(同一サブネット)であり、pingでそれぞれ
・VPNサーバー → VPNクライアント
・VPNクライアント → VPNサーバー
・サーバー側ローカルPC → VPNクライアント
・VPNクライアント → サーバー側ローカルPC　
といったように相互でアクセスできるようになるのが理想です。
また、クライアント側での追加設定はできるだけ避けたい考えております。

現状でクライアントが接続した時のipconfigの出力は例として
IPv4アドレス:192.168.0.8
サブネットマスク:255.255.255.255
デフォルトゲートウェイ:0.0.0.0

pingでの応答確認は
・サーバー側ローカルPC → VPNクライアント
・VPNクライアント　→　サーバー側ローカルPC
・VPNクライアント → 自宅ルーター

のようにVPNクライアント ←→ VPNサーバーの相互アクセスができません。

試したこと

仮想ハブ設定の「仮想DHCP」の設定を
配布IPアドレス: 192.168.0.100 ~ 192.168.0.200
サブネットマスク : 255.255.255.0
デフォルトゲートウェイ : 192.168.0.1
にそれぞれ変更してクライアント側から再接続してipconfigを実行すると

IPv4アドレス 192.168.0.100
サブネットマスク: 255.255.255.255
デフォルトゲートウェイ: 0.0.0.0

と表示され、設定したIPアドレスの範囲通りにIPアドレスは変わっているのですが、サブネットマスクとゲートウェイに変化がありませんでした。
DHCPが完全に機能していないということではないと思います。

また、クライアント側のネットワークアダプタのIPv4の詳細設定で「リモートネットワークでデフォルトゲートウェイを使う」にチェックを入れたり、
インターフェイスメトリックを優先的(1)に設定したりして再接続を試みたりましたが、変化はありませんでした。

補足

繰り返しとなりますが、VPNクライアントをサーバー側ローカルPCであるかのように見せたいです。
また、何かと足りない情報があると思いますので指摘して頂ければ幸いです。
VPNクライアント → ルーターのアクセスができているのでクライアントのデフォルトゲートウェイをルーターにできれば解決するのではないのかと考えているのですが、あまり関係ないのでしょうか？

ネットワークに苦手意識があるので、わかりやすく解説して頂けると助かります。

Comments

[TaichiYanagiya]

VPNクライアントから見たデフォルトゲートウェイは VPNサーバー(192.168.0.3)になるのでは？ あるいは、0.0.0.0 のまま、ppp0 などデバイス指定になるのでは？

[Borisu]

VPNクライアントからサーバー側ローカルPCなどにアクセスしようとした時に、
VPNクライアント→VPNサーバ→サーバー側ローカルPC　というルートで通信を行うということだからですか？

クライアント側で確認するとデフォルトゲートウェイが0.0.0.0・サブネットマスクが255.255.255.255になってしまうのは何故でしょうか？
クライアントからサーバーにアクセスできない要因はなんでしょうか？
わからないことばかりですいません。

[TaichiYanagiya]

> VPNクライアント→VPNサーバ→サーバー側ローカルPC　というルートで通信を行うということだからですか？

はい。

> クライアント側で確認するとデフォルトゲートウェイが0.0.0.0・サブネットマスクが255.255.255.255になってしまうのは何故でしょうか？

Windows については、よく知らないのですが、ネットワークインターフェースが VPN のものになっていませんでしょうか。
また、192.168.0.0/24 宛のゲートウェイが 192.168.0.3 に設定されていませんでしょうか。

> クライアントからサーバーにアクセスできない要因はなんでしょうか？

おそらく、VPNサーバー側で、IPアドレスが 1つだと、トンネリング＆ルーティングできないのではないかと。

[Borisu]

> ネットワークインターフェースが VPN のものになっていませんでしょうか
Windows標準のVPN接続機能を使用しております。VPN専用のPPPアダプタが追加されている感じです。アダプタのプロパティでゲートウェイの設定などはできません。

>192.168.0.0/24 宛のゲートウェイが 192.168.0.3 に設定されていませんでしょうか
仰るとおり、サーバーでip routeコマンドを実行したところ、 "192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.3 metric 100" となっていました

[Borisu]

PC版だと解決済みを解除できることに今気付きました。
すいません。
引き続きこちらのページで回答して頂けると助かります。

[over]

ルータでは必要なポートを開放し、かつポートフォワーディングはされているのでしょうか。インターネットルータは、外向けの通信は制限をかけず、内向け通信はパケットフィルタを実装して販売しているのがほとんどです。その場合、VPNセッションは成功したように見えるが、片系の通信ができないという状況が発生することもあります。

[Borisu]

ポートの解放はされています
ルータのパケットフィルタを確認しましたがLANでのフィルタは一切ありませんでした。
実際ローカルPCへの通信はできています

[over]

ポートフォワーディングもされているのですか?

[Borisu]

はい

[over]

そうですか。ではルータが原因ではないようですね。

Answer 1

ローカルサブネットとリモートサブネットを同じにすることはできません。
VPNクライアントのサブネットを 192.168.1.0/24 などの別のアドレスに変えて下さい。

まずVPNは無い想定で、2つのサブネットをゲートウェイで接続する例を考えてみましょう。
ローカルサブネットとリモートサブネットが同じアドレスの場合、ローカルノード(例えば192.168.0.8)はリモートノード(例えば192.168.0.3)がローカルサブネット内に存在すると認識してしまうため、通信するためにゲートウェイを越える必要があることを認識できずゲートウェイにパケットが送信されません。
このような場合、通常は両端をNATすることで解決させますが、質問者様のケースではVPNクライアント側が不特定多数（DHCP）となるため、仮にNATと使ったとしてもVPNクライアント → VPNサーバーの片方向しか通信できないと思います。

Comments

[TaichiYanagiya]

Network-to-Network の VPN であれば、別のサブネットである必要がありますが、今回の場合は違うのではないでしょうか。
VPNクライアントの実IPアドレスが別にあって、VPN接続時に内部ネットワークのIPアドレス(トンネリング用)が割り振られることはあり得ることだと思います。

[Borisu]

現状で疎通を確認できていないのは
「VPNクライアント→VPNサーバー」となります

SecureNAT機能で仮想インターフェースに192.168.0.10などをサーバーに割り当て(?)をしてVPNクライアントから192.168.0.10にpingを飛ばすと応答は帰ってくるのですが、WebサーバーやSSHでの接続・閲覧などはできませんでした。
関係あるかはわかりませんが、firewalldを一時的に停止してみたいりしても変化ありませんでした。

[fusechi]

すみません。私の指摘点はすでにSoftEther VPN Serverのローカルブリッジ機能を使ってクリアされてると認識しました。

興味があったので私も同じ環境を組んでみましたが、とくに問題なく全ノード間で相互通信できました。
今回の構成にSecureNAT機能は必要ないので問題を切り分けるために一旦OFFにしたほうが良いです。（試してもらった 192.168.0.10 はSecureNAT機能による仮想的なノードなのでpingは通ってもWebサーバーやSSHは通りません。）

VPNクライアント　←→　サーバー側ローカルPC　はpingが通って
VPNクライアント　←→　VPNサーバー　が通らないというのは
やはりVPNサーバーのルーティングかFirewallに問題がある可能性が高いです。

VPNサーバー側のIPアドレスは1つでよく、
　IP：192.168.0.3/24
VPNサーバー側のルーティングはデフォルトGWのみでよいです。
　デフォルトGW：192.168.0.x <- 自宅ルーターのIP

不要なNICやルーティングが登録されていないか確認して下さい。
また firewalld の停止済みとのことですが停止方法が間違っていないか今一度確認してみて下さい。

[Borisu]

なるほど。通常はローカルブリッジで解決するはずなのですね。

VPNサーバー→VPNクライアント　は通っていて
VPNクライアント→VPNサーバー　が通っていない状況です。

↓↓ifconfig実行結果↓↓
docker0: flags=4355<UP,BROADCAST,PROMISC,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 02:42:2d:fb:df:77 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp3s0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
inet 192.168.0.3 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 240f:65:2070:1:19f7:b3f0:ade2:2887 prefixlen 64 scopeid 0x0<global>
inet6 fe80::b0ac:826d:47f1:be8b prefixlen 64 scopeid 0x20<link>
ether d0:17:c2:85:bf:e1 txqueuelen 1000 (Ethernet)
RX packets 11119676 bytes 1176689944 (1.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17434370 bytes 5855637937 (5.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ham0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1404
inet 25.56.86.189 netmask 255.0.0.0 broadcast 25.255.255.255
inet6 2620:9b::1938:56bd prefixlen 96 scopeid 0x0<global>
inet6 fe80::7879:19ff:fe38:56bd prefixlen 64 scopeid 0x20<link>
ether 7a:79:19:38:56:bd txqueuelen 1000 (Ethernet)
RX packets 35346 bytes 9942761 (9.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 646 bytes 160591 (156.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 9720310 bytes 2046486574 (1.9 GiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 9720310 bytes 2046486574 (1.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

↓↓ip route 実行結果↓↓
default via 192.168.0.1 dev enp3s0 proto static metric 100
25.0.0.0/8 dev ham0 proto kernel scope link src 25.56.86.189
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

hamachiやdockerで仮想インタフェース(?)が作成され、ルーティング設定も加えられているのですがこれらも無効化したほうがよろしいでしょうか。

また、firewalldの停止方法は「systemctl stop firewalld」を使用してfirewalld(iptables)のサービスを停止しています。

何かルーティングの設定を加える必要があるのでしょうか？

[fusechi]

情報ありがとう御座います。
なるほど「pingが片方向しか通らない」事象ということであれば原因は限られます。
"Firewallで拒否されている"か"意図しない送信元IPが使われている" 場合が殆どです。firewalldの停止方法は正しいようですので、恐らく後者でしょう。

これは送信元と送信先に複数のNICが存在する場合に発生する問題ですので、hamachiやdockerのNICとルーティングを無効化するのは原因切り分けとして有効です。

あと直接の原因か分かりませんが、本来自動で追加されるはずの以下のルーティングテーブルが無いのが気になりました。

　192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.3

[Borisu]

・ifconfig <デバイス名> downを使用してhamachiやdockerのインタフェース(ルーティング)を無効化
・クライアント側の不要なネットワークアダプタ停止（クライアントPCのインターネット接続にはiPhoneのテザリングを使用しています）
・networkサービス, NetworkManagerサービスの再起動

などを行いVPN接続を行いましたが、変化はありませんでした。

最新の設定状況は下記です。

ifconfig(VPNサーバー)↓↓
enp3s0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
inet 192.168.0.3 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 240f:65:2070:1:ddd8:3998:ea7:bdc9 prefixlen 64 scopeid 0x0<global>
inet6 fe80::5797:319:4a97:fba0 prefixlen 64 scopeid 0x20<link>
ether d0:17:c2:85:bf:e1 txqueuelen 1000 (Ethernet)
RX packets 11313512 bytes 1210543168 (1.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17661998 bytes 5938452577 (5.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 9973881 bytes 2080952199 (1.9 GiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 9973881 bytes 2080952199 (1.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ip route(VPNサーバー)↓↓
default via 192.168.0.1 dev enp3s0 proto dhcp metric 100
192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.3 metric 100

ipconfig(VPNクライアント)↓↓
PPP アダプター Rusintranet:

接続固有の DNS サフィックス . . . . .:
IPv4 アドレス . . . . . . . . . . . .: 192.168.0.2
サブネット マスク . . . . . . . . . .: 255.255.255.255
デフォルト ゲートウェイ . . . . . . .: 0.0.0.0

イーサネット アダプター イーサネット:

接続固有の DNS サフィックス . . . . .:
IPv4 アドレス . . . . . . . . . . . .: 172.20.10.12
サブネット マスク . . . . . . . . . .: 255.255.255.240
デフォルト ゲートウェイ . . . . . . .: 172.20.10.1

これらを踏まえて考えられる原因は何かありますでしょうか？

[fusechi]

ご提示頂いてる範囲では問題は無いように見受けられます。

しかし意図しない経路で通信しようとしているのは間違いないと思いますので、両ノードでパケットキャプチャを取って、pingの往路と復路の違いを調べてみて下さい。

[Borisu]

すいません。解決いたました。
192.168.0.0/24は192.168.0.1をゲートウェイとするようにルーティングの設定を追加するだけで大丈夫だったようです。

dockerやhamachiなどのインタフェースを有効化してまた通信経路に影響を及ぼすなどの可能性はありますが、とりあえず実現したいことはできたので解決とさせていただきます。

fusechiさんここまで丁寧な説明ありがとうございました！
とても勉強になりました！