VPN SERVERがOPEN VPN CLIENTから接続された時のDHCP TIMEOUT

[hiura]

OPEN VPN CLIENTがVPN SERVERに接続して来た時、VPN SERVERがDHCP DISCOVER送信後のDHCP SERVERからの応答メッセージ
を受信するまでの時間は、このログからわかるでしょうか？

ログでは12秒程度遅れが発生していますが、これはDHCP CLIENTの再送信機能修正でなおるものでしょうか？
https://github.com/SoftEtherVPN/SoftEth ... g%20GMS%3A

また、セッションが確立した状態で、DHCP送信タイムアウト発生（5秒以上経過）した場合、DHCP でのIP 再取得処理は動くのでしょうか？

DHCP SERVERはオンデマンド方式だそうです。
DHCP SERVERが5秒以内に応答しないようなのですが、こんなSERVERあるのでしょうか？

[cedar]

DHCPパケットのタイミングはパケットログを見てみないと分かりません。
たしか、OpenVPN クライアントは、DHCP で IP アドレスを取得できなかった場合セッションは確立せずエラーで切断されるはずです。
また、たしか、OpenVPN が TUN モードで接続した場合、DHCP で取得される IP アドレスは所定の条件を満たすまで以前のものを保留して連続で要求を送信する仕様になっていたような気がします。問題が起きているとしたらタイムアウトではなく、そちらのほうかも知れません。

[hiura]

IP ALLOCATIONがDEVELOPER EDITIONとSTABLE EDITIONで違うみたいです。

開発版は　IPCDhcpAllocateIP()が
安定版は　IPCDhcpAllocateIPEx()に拡張されています。

安定版ソースコードのコメント
// If the offered IP address is not used, place the address
// in release memo list to release at the end of this function

①複数のipアドレスを調べて何がしたいのか不明です。
　意味が分かりません。

② TUNモードはLINUX用ですよね。VPN SERVERをWINDOWSで動かす場合は無関係と理解します。

③ TUNモードはVPN SERVERが実行されているPC内部処理の話ですよね。

④OPENVPN CLIENTは接続要求時モードを指定できる。ということですか？
　TUNモードまたはTAPモード？　　要はLAYER3接続かLAYER2接続をCLIENTが選択できるという意味ですか？

以上よろしくお願いします。

[cedar]

1． OpenVPN の IP 通信をイーサネットに接続するために IPC モジュール内で仮想的なルーターを動作させるために最下位オクテットのビットの組み合わせが条件を満たす IP アドレスが出るまで DHCP 要求を繰り返す仕様です。

2．TUN モードは OpenVPN の L3 で通信するモードで、OS とは関係ありません。

3．OpenVPN プロトコルの種別の話です。

4．はい、その通りです。
https://www.reddit.com/r/OpenVPN/commen ... _is/?tl=ja

[hiura]

>1． OpenVPN の IP 通信をイーサネットに接続するために IPC モジュール内で仮想的なルーターを動作させるために最下位オクテットのビットの組み合わせが条件を満たす IP アドレスが出るまで DHCP 要求を繰り返す仕様です。

⑤VPN SERVERに複数のNICがある場合、仮想ルータの接続構成は

OPENVPN CLIENT--->HUB--->仮想ルータ--->物理NIC（選べる）
OPENVPN CLIENT--->HUB--->仮想ルータ--->ブリッジした物理NIC

どちらでしょうか？

⑥DEVELOPER EDITIONではTUNモード接続機能は無いとの理解でいいでしょうか？

⑦OPENVPN CLIENTがVPN SERVERにTAPモードで接続した場合、VPN SERVERがDHCP 要求を繰り返す処理は通らないと理解していいでしょうか？

⑧OPENVPN CLIENTがVPN SERVERにTUNモードで接続した場合、VPN SERVERのDHCP 要求は仮想ルータのDHCP SERVERが応答する（IPアサイン）？

⑨OPENVPN CLIENTがVPN SERVERにTUNモードで接続した場合、VPN SERVERのDHCP 要求IPアドレスが飛び飛びの理由？。先頭から３個使用する？

例：1,5,9,13,17

最下位バイト=1+4i　　（i=0,(254-1)/4）

ソースコード：
// Identify whether the IP address is compatible to the tun device of OpenVPN
bool OvsIsCompatibleL3IP(UINT ip)
{
IP p;

UINTToIP(&p, ip);
if ((p.addr[3] % 4) == 1)
{
return true;
}

return false;
}

[cedar]

5．IPCの仮想ルーターは、OpenVPN クライアントと仮想 HUB を繋ぐもので、仕組みとしては存在しますが外部からは見えません。

6．DEVELOPER EDITION については分かりません。

7．TAP モードでは、OpenVPN クライアント自体がイーサネットを喋るので、このプロトコル変換は使用されません。

8．IPC が発生する DHCP 要求を仮想 DHCP サーバーが受け取る場合もあると思いますが、仮想 HUB 上のイーサネットを介してしかこれらの機能は接続していないので、必ずしもそうとは限りません。

9．あまり実装には詳しくはないのですが、挙動からすると IPC の仮想ルーターは、/30 のサブネットを作るために下位 2bit が 00 から始まる 4 個の連続した IP アドレスを使っているのではないかと思います。
そのうち、外から見える可能性がある 2 つの IP アドレスだけ、DHCP で確保するのだと思います。

[hiura]

⑤についての確認

目に見えないのは理解しますが、見えないネットワークを書くとすれば仮想ネットワークは
OPENVPN CLIENT------HUB------仮想ルータ------ブリッジした物理NIC
は間違いで

OPENVPN CLIENT(a)---(b)仮想ルータ(c)---HUB---ブリッジした物理NIC
が正解である。
と理解しました。

SECURE NATの場合もVPN CLIENTとHUB間にNATルータが存在して
VPN CLIENT (d)---(e)NATルータ(f)---HUB---自動で選択した物理NIC
である。？


⑩基本的なことですが、(b)(c)のIP アドレスはマニュアル設定で、
　(a)のIP アドレス割り当てをIPCDhcpAllocateIPEx()で行うのですよね。？

[cedar]

それぞれの機能は独立して機能するので、切り離して考えたほうがわかりやすいと思います。

OpenVPN の TUN モード用の IPC 内仮想ルータ
OpenVPN Client -- IPCルータ -- 仮想HUB

ローカルブリッジ
仮想HUB -- 接続先LAN

SecureNAT の仮想 NAT 機能(ユーザーモード)
仮想 HUB -- 仮想NAT -- OS のルーティング機能 -- 他のネットワーク

SecureNAT の仮想 NAT 機能(カーネルモード/RawIP モード)
仮想 HUB -- 仮想NAT -- SecureNATの仮想ルータ -- いずれか1つの自動選択されたネットワーク

⑩： 外から見えるのは (c)=(a) だけですが、(b) に相当する IP アドレスを他のホストが使用すると衝突して問題が起きてしまうので (b) と (c) をIPC が DHCP で取得するという理解です。 (正しいかどうか、あまり自信がありません。)