SoftEther VPN ブリッジ機能が動作しない

[Alvin]

移転失敗の具体的な兆候は
aサーバーIP: 192.168.2.1
bサーバーIP: 192.168.3.1
両方のサーバーにSoftEther VPNサーバーがインストールされている
サーバー a によって作成された HUB のユーザー名とパスワードは、新しく作成されたサーバー b の HUB の下のサーバー a の HUB のユーザー名とパスワードに接続されます。接続は成功しているように見えますが、クライアント側でサーバー B の IP 接続を使用すると、サーバー A の IP を正常に取得できません。
同様に、サーバー B をローカル サーバーに変更しても、クライアントはサーバー A の IP を正常に取得できません。 10月24日にはまだ正常でしたが、それ以降は新旧すべてのバージョンでブリッジを正常に転送できなくなりました。転送ブリッジ機能を確認し、すぐに修正されることを願っています

[cedar]

質問の意味がよく分かりません。
IPを取得するとはどういう意味でしょうか？

[Alvin1986]

具体的な性能は、
サーバーAとBの両方にVPNサーバーがインストールされている
aサーバーIP: 192.168.2.1
新しい仮想ハブを作成し、ユーザー名とパスワードを作成し、securenat機能を有効にします

bサーバーIP: 192.168.3.1
新しい仮想ハブを作成し、ユーザー名とパスワードを作成します。仮想ハブの下のカスケードに接続し、サーバー a のハブにログインします。ユーザー名とパスワードのプロンプトが正常に接続され、securenat 機能が有効になります。
上記は、サーバーaがサーバーbを介して転送されることを意味します

cはサーバbのIPアドレス192.168.3.1に接続するクライアントです。
仮想ハブのユーザー名とパスワードを入力すると接続は成功しますが、サーバー B の IP アドレス 192.168.3.1 が引き続き反映されます。転送機能は実装されていません。
クライアントはサーバaのIPアドレス192.168.2.1を取得できず、データトラフィックは

調査の結果、VPN サーバーの securenat 機能にバグがあり、TCP 接続とデータ転送を正しく確立できないことが判明しました。 securenat ルーティング テーブルに問題がある可能性があります。以前は正常にデータを転送できましたが、現在は古いバージョンと新しいバージョンの両方で secureNAT データ転送を完了できません。

[cedar]

SecureNAT は､その VPN サーバーからインターネットにアクセスさせる機能です｡
転送させたいならSecureNATは無効にしてください｡

[Alvin1986]

NAT を無効にしてみましたが、それでも A から B に転送できません。また、UDP トラフィックが通過できないこともわかりました。ここに問題があるのか​​もしれません。試してみて確かめてみてください。実際に転送することは不可能であることがわかります。

[cedar]

これは奇妙ですね｡
ローカルブリッジもSecureNATも無効の状態では､仮想HUBを通してそのホストと通信することすら不可能のはずです｡
なにか意図しない VPN 接続が存在する可能性も考えられます｡

VPNクライアントの仮想 LAN カードには､どんなIPアドレスが割り当てられていますか？
また､インターネット上のホストへの tracert を行うと､どんな結果になりますか？

[Alvin1986]

aの仮想NATのIPは192.168.31.9です
bの仮想NATのIPは192.168.30.xです
tracert の結果は、b が a に接続できるということです。
それでグループ対応をお願いしに来たんです。接続は確立されていますが、a の トラフィックが b に到達できず、データが a に応答できないという非常に異常な状態です。
トラフィックデータのIP転送を再度注意深く確認しました。仮想 NAT およびカスケード接続は TCP 接続によって転送されるトラフィックです。 Sofether VPN サーバーでは、カスケード接続と仮想 NAT ルーティング テーブルは、デフォルトでは udp トラフィックが tcp 経由で送信され、データを返すことができないため、ここにバグがある可能性があります。以前は、TCP プロトコル データは正常に認識され、フィードバックされていました。この問題は3月から発見されており、当初は運営者による制限だと思っていました。仮想 NAT とカスケード接続のプロトコル転送コードに競合がないか確認してみてください。

[cedar]

あなたの言っている意味が分かりません。
カスケード接続はL2で動作しているため、UDPとTCPを識別しません。
VPNサーバーの運営者はあなたです。(おそらくは)

仮想ホストのIPアドレスについては聞いていません。(そもそもBの仮想NATは無効になっているはずです。)
VPNクライアントの仮想 LAN カードには､どんなIPアドレスが割り当てられていますか？
また､インターネット上のホストへの tracert を行うと､どんな結果になりますか？

[Alvin1986]

それは間違っています。 b の NAT が無効になっている場合、クライアントは b の softether VPN サーバーに正常に接続できません。
つまりこれは間違いです。具体的な問題は、A が仮想 NAT を介して UDP トラフィックを B に送信しないことです。問題はこのレベルで発生します。自分でテストすることができます。以前はそこにテレポートすることが可能だったとも言いましたが、3月以降は不可能になっています。
私の図には、a と b でマークされたパブリック IP と仮想 NAT IP があります。クライアントが b に正常に接続する場合、a の IP とトラフィックが取得されます。これで、a の IP は取得されませんが、仮想 IP アドレスは b の仮想 IP アドレスになります。
aからbのパブリックIPへのtraceroute
root@Ubuntu24:~# traceroute 43.156.47.254
traceroute to 43.156.47.254 (43.156.47.254), 30 hops max, 60 byte packets
1 153.121.32.2 (153.121.32.2) 1.094 ms 1.238 ms 1.552 ms
2 10.101.103.101 (10.101.103.101) 0.869 ms 1.001 ms 1.206 ms
3 tkgrt3b-vps-tk1a-rt101-2.bb.sakura.ad.jp (157.17.131.181) 0.806 ms 1.045 ms 1.031 ms
4 tkwrt301s-grt3b.bb.sakura.ad.jp (157.17.131.209) 0.293 ms 0.290 ms 0.265 ms
5 tkort4-wrt301s.bb.sakura.ad.jp (157.17.131.165) 0.796 ms tkbrt1-wrt301s.bb.sakura.ad.jp (157.17.130.13) 0.812 ms 0.787 ms
6 tkort4-brt1.bb.sakura.ad.jp (157.17.130.6) 0.731 ms 0.979 ms tkort4-ert1.bb.sakura.ad.jp (157.17.130.113) 0.661 ms
7 210.171.224.126 (210.171.224.126) 5.177 ms 5.179 ms 5.062 ms
8 * 203.208.166.174 (203.208.166.174) 5.666 ms *
9 203.208.153.66 (203.208.153.66) 81.052 ms 203.208.183.145 (203.208.183.145) 69.569 ms 203.208.158.161 (203.208.158.161) 89.794 ms
10 203.208.153.66 (203.208.153.66) 80.995 ms 80.970 ms 203.208.147.126 (203.208.147.126) 75.462 ms
11 * * 203.208.147.126 (203.208.147.126) 76.254 ms
12 * * *
13 * * *
14 * * *
15 43.156.47.254 (43.156.47.254) 82.048 ms !X 81.909 ms !X 81.859 ms !X
root@Ubuntu24:~#
bからaのパブリックIPへのtraceroute
[root@centos7 ~]# traceroute 153.121.32.114
traceroute to 153.121.32.114 (153.121.32.114), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 10.196.7.69 (10.196.7.69) 3.781 ms 1.378 ms 10.200.162.77 (10.200.162.77) 1.520 ms
5 10.200.163.202 (10.200.163.202) 4.218 ms 3.200 ms 10.200.17.30 (10.200.17.30) 1.505 ms
6 203.208.169.49 (203.208.169.49) 0.899 ms 0.906 ms 0.815 ms
7 203.208.151.49 (203.208.151.49) 1.749 ms 203.208.153.65 (203.208.153.65) 7.741 ms 2.043 ms
8 203.208.151.38 (203.208.151.38) 1.755 ms 203.208.183.146 (203.208.183.146) 69.732 ms 203.208.151.38 (203.208.151.38) 1.704 ms
9 203.208.158.161 (203.208.158.161) 2.028 ms 203.208.182.234 (203.208.182.234) 79.535 ms 203.208.166.173 (203.208.166.173) 70.576 ms
10 203.208.166.181 (203.208.166.181) 79.339 ms 210.171.224.113 (210.171.224.113) 82.348 ms 203.208.172.41 (203.208.172.41) 74.467 ms
11 210.171.224.113 (210.171.224.113) 85.528 ms 82.952 ms tkwrt301s-ort4.bb.sakura.ad.jp (157.17.131.166) 73.904 ms
12 * 210.171.224.113 (210.171.224.113) 101.734 ms tkgrt1s-ort4.bb.sakura.ad.jp (157.17.130.250) 78.175 ms
13 210.171.224.113 (210.171.224.113) 78.473 ms * 76.037 ms
14 tkgrt1s-ort4.bb.sakura.ad.jp (157.17.130.250) 70.697 ms vps-tk1a-rt101-grt3b-1.bb.sakura.ad.jp (157.17.131.178) 81.106 ms tkgrt1s-ort4.bb.sakura.ad.jp (157.17.130.250) 70.962 ms
15 tkgrt3b-grt1s.bb.sakura.ad.jp (157.17.130.142) 72.506 ms tkgrt4b-grt1s.bb.sakura.ad.jp (157.17.131.22) 77.111 ms *
16 * vps-tk1a-rt101-grt3b-1.bb.sakura.ad.jp (157.17.131.178) 77.726 ms vps-tk1a-rt102-grt3b-2.bb.sakura.ad.jp (157.17.131.198) 1870.969 ms
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@centos7 ~]#
A から B への仮想 NAT イントラネット IP へのトレースルート
root@Ubuntu24:~# traceroute 192.168.30.3
traceroute to 192.168.30.3 (192.168.30.3), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * 192.168.30.3 (192.168.30.3) 121.798 ms *
B から A への仮想 NAT イントラネット IP へのトレースルート
traceroute to 192.168.30.1 (192.168.30.1), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[root@centos7 ~]#
Sofether は元々 TCP プロトコルに基づいて送信されていましたが、現在は UDP プロトコルを使用して IP を転送していることが原因と考えられます。
これは、プロトコル変換と自動識別の問題、および UDP プロトコルと TCP プロトコルを相互に直接変換できないことが原因であると考えられます。また、a のハブ機能 IP を使用して b に転送することもできます。 b のハブ レベルの接続を使用して、a との接続を確立します。レベルの接続も成功していることがわかります。次に、b を使用してサービスを確立し、クライアントを使用して b の IP に接続して接続します。接続によって取得された内部ネットワーク IP は b の仮想 NAT であることがわかります。接続も成功しました。これは正しいです。問題は、a の IP とトラフィックを取得できないことです。ここでの問題は、a と b 間の NAT レベルの接続が UDP プロトコルを NAT 経由で b に転送しないため、クライアントが b に接続しても、転送された a の IP とトラフィックを正常に取得できないことです。

[masayuki]

目的と一致しているか分かりませんが、こういうことでしょうか？


【環境】
サーバ：A
仮想HUB：A
　ローカルブリッジ：無効
　Secure NAT：有効
　仮想NATを使用する：有効
　仮想NATのIPアドレスとサブネットマスク：192.168.31.9/255.255.255.0
　仮想DHCPサーバを使用する：有効
　仮想DHCPサーバのアドレス範囲：192.168.31.10 - 192.168.31.10
　仮想DHCPサーバのサブネットマスク：255.255.255.0
　仮想DHCPサーバのデフォルトゲートウェイ：192.168.31.9
　仮想DHCPサーバのDNSアドレス：192.168.31.9
　ユーザ：サーバ(B)の仮想HUB(B)からカスケード接続を受けるためのアカウント(B)を作成


サーバ：B
仮想HUB：B
　ローカルブリッジ：無効
　Secure NAT：無効
　サーバ(A)の仮想HUB(A)に対してカスケード接続を確立
　ユーザ：クライアント(C)からVPN接続を受けるためのアカウント(C)を作成


クライアント：C
　サーバ(B)の仮想HUB(B)に対して、アカウント(C)を使用してVPN接続

[cedar]

> b の NAT が無効になっている場合、クライアントは b の softether VPN サーバーに正常に接続できません。

これは異常な動作ですね。B の SecureNAT を無効にする必要があるので、まずその問題を解決する必要があります。
正常に接続されなかった時の症状はどんなものでしょうか？

[Alvin1986]

クライアント B の SecureNAT が無効になっている場合、クライアント C がクライアント B との接続を確立できないことは明らかです。実際の問題は、UDP 送信トラフィックです。 Sofether のリスニング接続ポートは TCP 上に確立されますが、クライアントに提供されるのは実際に UDP です。 UDP と TCP は元々異なるプロトコルなので変換できません。しかし、Sofether は 3 月までに自動的に変換される可能性があります。それは A の TCP を経由して B に送られ、B はそれを TCP 経由で A に送り返します。 A は応答として元の UDP を取得します。現在、softher はプロトコルを切り替えることができなくなります。

[cedar]

ご指摘のように SoftEther VPN には TCP/UDP の接続モードが存在しますが、これらは VPN セッションの確立に使われるプロトコルであり、トンネル内で流れるユーザーのアプリケーション通信（UDP等）とは別物です。

また、SecureNAT は仮想ハブ上の「1台の仮想ホスト」であり、これが有効か無効かは、他の VPN クライアントの通信可否には直接関係しません。
クライアント B の SecureNAT が無効であっても、仮想 HUB に仮想 NIC が接続されていれば、クライアント C から B に対する通信（例えば UDP）はトンネル内で届く構成になっているはずです。
(むしろ､BでSecureNATが有効になっていると､そこからインターネットにトラフィックが流出してしまい､Aには届きません｡)

UDPによる接続モードを使用したくないのであれば､接続先ホスト名のあとに「/tcp」を付けることで接続モートを TCP に限定できます｡
SecureNAT を有効にしないと接続できないとしても､それは TCP と UDP の問題とは別のはずです｡

[hiura]

参考
> b の NAT が無効になっている場合、クライアントは b の softether VPN サーバーに正常に接続できません。

当然クライアントは b の softether VPN サーバにアクセスできません。そもそもSERVER:Bには仮想IPアドレス（仮想NIC）がないので。

それを希望されるのであれば、SERVER:BにCLIENTをインストールして、自身のHUB:Bに接続してください。
仮想NICに仮想IPアドレスがSERVER:Aの仮想DHCP SERVERにより割り当てられるでしょう。割り当てアドレス範囲は広げておく必要あり。
また、SERVER:Bの仮想NICに固定IPアドレスを設定すれば、CLIENT:Cの接続先ホスト名を固定化できます。

[hiura]

全ポストを修正、削除できないので追加しました。
「CLIENT:Cの接続先ホスト名を固定化できます。」を
「CLIENT:Cからその固定IPアドレスにアクセスできます。」に修正しました。

参考
> b の NAT が無効になっている場合、クライアントは b の softether VPN サーバーに正常に接続できません。

当然クライアントは b の softether VPN サーバにアクセスできません。そもそもSERVER:Bには仮想IPアドレス（仮想NIC）がないので。

それを希望されるのであれば、SERVER:BにCLIENTをインストールして、自身のHUB:Bに接続してください。
仮想NICに仮想IPアドレスがSERVER:Aの仮想DHCP SERVERにより割り当てられるでしょう。割り当てアドレス範囲は広げておく必要あり。
また、SERVER:Bの仮想NICに固定IPアドレスを設定しても、CLIENT:Cからその固定IPアドレスにアクセスできます。

追加
①masayukiさんがまとめられているネットワーク構成を正としています。
②別の方法です。SERVER:Bにアクセス専用のNICを一枚挿入する。HUB:BとそのNICをブリッジ接続してもOKのはず。

[hiura]

bからaのパブリックIPへのtracerouteについて、SAKURA Internet Inc.内のルーティングが機能していないように見えます。

本来であれば⑯、⑰、⑱とルーティングされるはずです。しかし、⑯からルーティングがされていません。
また、⑪、⑫、⑬は同じIPアドレスになっています。ループしているのでしょうか。
「SAKURA Internet Inc.」内のルーティング障害だと思います。「SAKURA Internet Inc.」に確認されてはどうでしょうか。


bからaのパブリックIPへのtraceroute
[root@centos7 ~]# traceroute 153.121.32.114
traceroute to 153.121.32.114 (153.121.32.114), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 10.196.7.69 (10.196.7.69) 3.781 ms 1.378 ms 10.200.162.77 (10.200.162.77) 1.520 ms
5 10.200.163.202 (10.200.163.202) 4.218 ms 3.200 ms 10.200.17.30 (10.200.17.30) 1.505 ms
6 203.208.169.49 (203.208.169.49) 0.899 ms 0.906 ms 0.815 ms <-----⑥https://www.singtel.com/
7 203.208.151.49 (203.208.151.49) 1.749 ms 203.208.153.65 (203.208.153.65) 7.741 ms 2.043 ms <-----⑦https://www.singtel.com/
8 203.208.151.38 (203.208.151.38) 1.755 ms 203.208.183.146 (203.208.183.146) 69.732 ms 203.208.151.38 (203.208.151.38) 1.704 ms
9 203.208.158.161 (203.208.158.161) 2.028 ms 203.208.182.234 (203.208.182.234) 79.535 ms 203.208.166.173 (203.208.166.173) 70.576 ms
10 203.208.166.181 (203.208.166.181) 79.339 ms 210.171.224.113 (210.171.224.113) 82.348 ms 203.208.172.41 (203.208.172.41) 74.467 ms<-----⑩https://www.singtel.com/
11 210.171.224.113 (210.171.224.113) 85.528 ms 82.952 ms tkwrt301s-ort4.bb.sakura.ad.jp (157.17.131.166) 73.904 ms<-----⑪ 210.171.224.113
12 * 210.171.224.113 (210.171.224.113) 101.734 ms tkgrt1s-ort4.bb.sakura.ad.jp (157.17.130.250) 78.175 ms <-----⑫ 210.171.224.113
13 210.171.224.113 (210.171.224.113) 78.473 ms * 76.037 ms <-----⑬ 210.171.224.113
14 tkgrt1s-ort4.bb.sakura.ad.jp (157.17.130.250) 70.697 ms vps-tk1a-rt101-grt3b-1.bb.sakura.ad.jp (157.17.131.178) 81.106 ms tkgrt1s-ort4.bb.sakura.ad.jp (157.17.130.250) 70.962 ms
15 tkgrt3b-grt1s.bb.sakura.ad.jp (157.17.130.142) 72.506 ms tkgrt4b-grt1s.bb.sakura.ad.jp (157.17.131.22) 77.111 ms *
16 * vps-tk1a-rt101-grt3b-1.bb.sakura.ad.jp (157.17.131.178) 77.726 ms vps-tk1a-rt102-grt3b-2.bb.sakura.ad.jp (157.17.131.198) 1870.969 ms<-----⑯SAKURA Internet Inc.
17 * * * <-----⑰SAKURA Internet Inc.
18 * * * <-----⑱153.121.32.114
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * * <-----㉚タイムアウト発生しています。15回程度で終了していないので異常と思われます
[root@centos7 ~]#