SoftEther SecureNAT：DHCPとNATは二つの判断

SecureNATは仮想DHCPと仮想NATを動かし、どちらも単独で故障し得ます。ハブを責める前に、リース、次に外向きの経路とリゾルバを確認してください。

SecureNATは一つのチェックボックスで二つのサービスを有効にします。それこそが、この機能に関する混乱のほとんどを生む源です。仮想DHCPサーバーはクライアントにアドレス、マスク、ゲートウェイ、そして多くの場合リゾルバを渡します。仮想NATは、サーバーホスト自身のネットワークスタックを使って、そのゲートウェイの先へパケットを転送します。両者は設定画面で隣り合って並び、独立して故障します。クライアントが完全なリースを持ちながら動く経路がないこともあれば、経路は動いていても設定が誤ったリゾルバを指していることもあります。二つの判断として検証すれば、診断は短く済みます。

一つのチェックボックスの裏にある二つのサービス

仮想DHCPの側は設定の問いに答えます。このクライアントがこの仮想ハブの中で受け取る設定は何か。仮想NATの側は転送の問いに答えます。クライアントがハブの外のアドレスへパケットを送るとき、サーバーはそれを変換して転送するか。前者はハブに閉じており、上位のネットワークを必要としません。後者はホストに完全に依存します。

仮想ホストインターフェースは前者の判断に属し、後者ではありません。そのアドレスは、既定では192.168.30.1のようなものですが、DHCPサービスが提示するゲートウェイです。サーバーの公開待ち受けアドレスではなく、両者を混同すると、そのネットワークに存在しない機械を狙ったファイアウォール規則やクライアント設定が生まれます。

判断1：アドレスを供給するのは誰か

仮想DHCPが有効なら、クライアントは設定したプールからリースを受け取り、ゲートウェイは仮想ホストインターフェース、リゾルバは指定したものになるはずです。クライアントの状態表示ではなくリースを調べてください。「接続済み」はトンネルを表す言葉であり、アドレスの割り当てではありません。

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

ほかを調べる前に知っておくべき故障が二つあります。以前の設計で残った固定アドレスを持つクライアントはそれを使い続けてリースを無視し、DHCPが応答を拒んでいるように見えます。ブリッジされたセグメントに二つ目のDHCPがあると、同じクライアントを取り合い、アドレスが断続的に変わり、問題を再現できないサポート窓口が生まれます。

プールの重複もここに入ります。仮想DHCPのプールがホストのLANサブネットや別のハブのプールと重なると、クライアントは曖昧にルーティングされるアドレスを受け取り、その後の試験はどれも結論を出せません。

判断2：仮想ゲートウェイの先へ転送するのは誰か

仮想NATが有効なら、ハブから出る外向きの通信はサーバーが変換し、ホストのルーティングテーブルを通して送られます。つまり転送の連鎖は、クライアントから仮想ゲートウェイ、仮想NATからホストのスタック、ホストのスタックから既定の経路、という順です。どの環も他に触れずに壊れ得て、故障の兆候はそれぞれ異なります。

二つ目の判断は、ハブを出なければならないもので試してください。ハブに閉じたものでは意味がありません。仮想ゲートウェイへのpingが証明するのは最初の環だけです。

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

名前解決が通るのに公開アドレスへの接続が失敗するなら、DHCPではなく転送の連鎖にいます。両方失敗するなら、まずリゾルバを確認してください。到達不能な内部アドレスとして配られたリゾルバは、動いている経路を完全に壊れたように見せます。

SecureNATの転送を実装しているのはサーバープロセスであり、ブリッジで使うカーネルの転送経路ではありません。便利な代わりにブリッジより遅く、またホスト自身のファイアウォール規則とルーティングの判断が変換後の通信にもそのまま適用されることを意味します。仮想NATはホストの方針を迂回せず、それを使います。

ホスト自身の経路は三つ目の問題

ここまでの話はすべて、サーバーホストが宛先に到達できることを前提にしています。上位経路が動かない、外向きの方針が厳しい、あるいはそのアドレスファミリーを持たないホストは、ハブの設定がどれほど正しくても二つ目の判断で失敗します。SoftEtherのせいにする前に、ホストを単独で、トンネルの外で確認してください。

SecureNATはサーバーに接続されたすべてのネットワークへ到達する権限でもありません。届いた通信を変換して転送するだけであり、ホストが何に到達してよいかを決めるのは今もホストのファイアウォールとルーティングの仕事です。トンネルにアクセス付与を任せる設計は、誤った規則一つで与えすぎになります。

アドレスファミリーは独自の確認に値します。IPv4のDHCPが動く例は、あなたのビルドにIPv6のあらゆる能力があることを示しません。デュアルスタックの挙動を約束する前に、実際に動かしている版のマニュアルを読んでください。マニュアルのSecureNATの節は、現行リリースの仮想NATとDHCPの機能を扱っています。

各判断をそれぞれの試験で検証する

一つ目の判断はリースの確認で受け入れてください。プール内のアドレス、仮想ホストインターフェースと等しいゲートウェイ、設定したとおりのリゾルバ。二つ目はクライアントからの外向き要求と、サーバーのNATテーブルの確認で受け入れます。セッション数の増加だけが、有効になっているだけでなく変換が起きていることの直接の証拠です。

そして分離を設計メモに記録してください。どの構成要素がアドレスを供給し、どれが転送し、通信がどのホストインターフェースから出るのか。再起動で挙動が変わったとき、そのメモは三つのうちどれを見るべきかを教えてくれます。すべてを再起動して症状が移ることを願う必要はありません。

もう一つの判断も記録に残すべきです。今日決めないとしても。SecureNATとローカルブリッジは同じハブに対する別の設計であり、両方を必要とするハブは別の計画を必要とするハブです。意図して選び、理由を書き残せば、次の人は稼働中の設定から逆算せずに済みます。

関連記事