UT-VPNのローカルブリッジとSecureNAT

Linux(CentOS5)にUT-VPNを入れてみたの続きになるんですが、リモート元(遠隔地等の外から接続)からUT-VPN Serverを実行している物理LAN内にアクセスしたいときや、拠点間VPN通信をしたい場合は、ローカルブリッジもしくは、SecureNATの機能が有効です。

ローカルブリッジとSecureNAT(仮想NAT)がどう違うのか試してみました。

ローカルブリッジ
まずローカルブリッジは仮想HUBと物理ネットワークカード(NIC)をレイヤ2で接続するというものです。

この場合、リモート元と拠点は物理的には別ネットワークでも、論理的には同一の Ethernet セグメントに接続されていることになります。
ですので、リモート元のUT-VPN Clientで使用している仮想NICのIPアドレスは接続先の拠点と同じネットワークアドレス、サブネットにしないといけません。
これは試してませんが、拠点LANにDHCPサーバがあればリモート元のUT-VPN Clientで使用している仮想NICにもIPが割り振られると思います。

ローカルブリッジは仮想HUBと物理NIC間で接続されるので、UT-VPN Serverを稼働させているコンピュータ上に UT-VPN Client を入れて仮想HUBに参加する必要はありません。
リモート元からUT-VPN Serverを稼働させているコンピュータ上にアクセスしたい場合は、そのコンピュータの物理NICのIPにアクセスすればOKです。

こんな便利なローカルブリッジですが、いくつか難点が。。

一つはVPN Serverをサービスモードもしくは、ユーザモードの場合は管理者として起動する必要があります。(これはまぁ大した問題ではないのですが。。)

また、これは結構深刻な問題になるんですが、Linux上のUT-VPN Serverでローカルブリッジさせている場合は、VPN(仮想HUB)内から、そのLinux上の物理NICのIPアドレスに対して通信できないということです。
これはLinuxOSでの制限のようです。

対応としては、もうひとつ物理NICを追加しそれをローカルブリッジ用とするわけです。(そのNICのIPは物理LANのIP体系に合わせます。)
ローカルブリッジ用のLANカードはUT-VPN稼働させているサーバのCPU負荷を下げる効果もあるようなので、そうした方がよいようですね。

詳しい話は、PacketiX VPN 2.0 - ローカルブリッジ接続機能にあります。

ローカルブリッジの構成は下記のような感じになります。



SecureNAT
さて次に、SecureNAT(仮想NAT)の機能です。

これはVPN内に向けたNATとDHCPサーバの機能をUT-VPN Serverが提供するというものです。
マニュアルにも書いているんですが、ブロードバンドルータ機能の仮想化という感じで捉えると分かりやすいですね。(NATと言ってますが実際はNAPTつまりIPマスカレードですね)

ですので、拠点の物理LANとVPN内のIPアドレス体系は異なる必要があります。ブロードバンドルータはNAPTなので内側から外にはアクセスできますが、外側からの新規セッションは内側に通すことはできない(ルータの設定でポートフォワーディングすれば別ですが..)のと同じように、このSecureNATもVPN内部から拠点物理LANは接続できますが、拠点物理LAN側からVPN内へのアクセスはできません。ここはある意味一つの制約になりますね。
VPN内にサーバを立てて、それを拠点物理LANから使うということなどはできないわけです。

SecureNATの一部の機能としてDHCPサーバの設定もあるので、これだけ有効にして使うということもできるようです。
SecureNATを有効にして、VPN側からUT-VPN Serverを稼働しているコンピュータにアクセスしたい場合はそのコンピュータの物理NICのIPを指定すればOKです。ローカルブリッジだとLinux版はそれができませんでしたが、SecureNATだとできました。

SecureNATはユーザモードで動き、特権を必要としないので特権利用が無理なシステムでも使えそうです。

SecureNATの詳細は、VPN オンラインマニュアル - 10.11 SecureNAT 機能を用いた権限不要のリモートアクセス、PacketiX VPN 2.0 - 仮想 NAT および仮想 DHCP サーバー機能で解説されています。

SecureNATの構成は下記のような感じとなります。




ローカルブリッジ設定をして、UT-VPN Server稼働上のコンピュータでUT-VPN Clientを使ってVPNに参加させようとすると、うまく通信ができないということがありました。

しかし、よくよく考えたら原因らしき部分に気付きました。
UT-VPN Serverでローカルブリッジさせている物理NICのIPアドレスと、UT-VPN Server稼働上のコンピュータでUT-VPN ClientのIPアドレスが同じネットワークアドレス・サブネットになっていたわけです。

コンピュータは同じネットワークアドレス持つNICがあると、どっちにパケット送ったらいいのか分からなくなるので、こういうおかしな現象になったんではないかと推測しました。(しかし、Windowsだとうまく行ったんですよね。NICの優先順位の設定があるからでしょうか。)

この時の構成図はこのような感じです。


routeコマンドでどのネットワークアドレスに対するパケットはどのNICに行くのかというのを確認します。
192.168.1.0宛てのパケットは UT-VPN 用と eth0 と両方になってますね。

# route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.1.0    *               255.255.255.0   U     0      0        0 utvpn_eth1

192.168.1.0    *               255.255.255.0   U     0      0        0 eth0

default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

なかなかLinuxのネットワーク設定は難しいですね。