SoftEtherのローカルブリッジとSecureNAT、どちらを有効にするか

ローカルブリッジはハブを実際のイーサネットセグメントに置き、SecureNATは独自のアドレスを作ります。どちらか一方を選び、ゲートウェイとリゾルバーを確認してください。

SoftEther Managerを開くと、ハブについて最初の本当の判断はチェックボックスではなくトポロジーの問題です。ローカルブリッジはそのハブを物理アダプターに接続して既存のセグメントにアドレス指定を任せ、SecureNATはハブに独自の仮想ルーター、NAT、DHCPを与えます。どちらを選ぶかで、アドレスがどこから来るのか、どの機器がそれに応答するのかが変わります。両方を有効にして片方が勝つことに期待するのは、動いていた検証環境がサポートスレッドになる道です。

実際に編集しているハブから始める

Managerはサーバーとハブのツリーを表示しますが、クライアントが別名のハブに接続しているのに既定のハブを設定してしまうのは簡単です。ハブをクリックし、その名前を読み、下に並ぶセッションが提供したいクライアントであることを確認してください。この一つの確認が、後でプロトコルのせいにされる混乱の大半を防ぎます。

次に、クライアントが遠端に何を求めるかを決めます。ブロードキャストとLANサービスを伴う共有イーサネットの挙動はブリッジを指し、小さなアドレス範囲へのルーティングされたプライベートアクセスはSecureNATを指し、インターネット出口はどちらの構成でも下手に扱えるルーティングの判断です。

何かをクリックする前に答えを書き留めてください。二つの設定は交換できず、元に戻すほうが決めるより時間がかかり、二分の記述が一時間の再接続を節約します。

ローカルブリッジがアドレス指定に何をするか

ローカルブリッジはハブを物理アダプターに接続するので、ハブはそのイーサネットセグメントの一部になります。クライアントは既にそのセグメントを担っているものからアドレスを受け取り、ゲートウェイはそのセグメントのルーターになります。クライアントから見ればオフィスのLANに加わったことになり、それに伴う到達性と露出のすべてを引き受けます。

つまりブリッジには適切なドライバー対応のある実在のアダプターが必要で、管理者はそのセグメントを拡張する権限を持っている必要があります。VPNのログインは認証を証明するもので、本番VLANにホストを置く権利ではありません。ドライバー名が意図したアダプターと一致するか確認してください。誤ったポートをブリッジするとセグメントはすぐ落ち、アダプター一覧が空だったりブリッジが失敗を報告したりする場合の原因は通常ドライバーか権限であり、暗号の話ではありません。

グラフィックのツリーが曖昧なときはコマンドラインでブリッジテーブルを読んでください。出力はアダプター名を示しますが、ツリーは必ずしもそうしません。

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

セッションが接続されたままブリッジ一覧が空というのは、クライアントが仮想ハブの内側にいてまだ何もそれをセグメントに広げていない、という有用な絵です。

SecureNATが加えるもの、隠すもの

SecureNATはハブに仮想ルーター、NAT機能、DHCPサービスを与え、すべてSoftEtherプロセスの内側にあります。クライアントは仮想DHCP範囲からアドレスを得て、仮想ルーターが既定ゲートウェイに応答し、外に出る必要のあるトラフィックは変換されます。物理アダプターは関与しないため、NICが一つでスイッチ設定のないホストでも動きます。

代償は、仮想アドレスがハブに属し、他の何にも属さないことです。オフィスLAN上のマシンは助けなしにクライアントのSecureNATアドレスへルーティングできず、送信元アドレスを記録するものはすべてSoftEtherホストの変換後のアドレスを見ます。アクセス規則や監査証跡がクライアントの実アドレスに依存しているなら、それは細部ではなく設計の変更です。送信元アドレスの規則がクライアントをそもそも見るのかどうかも、これで決まります。

またDHCPサーバーでもあります。既に一つあるセグメントで動かしたり、同じときにそのセグメントをブリッジしたりすると、応答者が二人になりリースが予測できなくなります。マニュアルが二つの機能を別々の選択として扱うのはまさにこの理由です。

何か他のものを有効にする前に、ハブがいま何を提供しているかを調べてください。各コマンドは意図ではなく現在の状態を出力します。

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

片方を壊さずにもう片方を有効にする

構成を選び、有効にして、もう片方は切ったままにします。ブリッジとSecureNATの両方が有効なハブは、同じ問いに二つの答えがあり得るハブで、クライアントは先に届いたほうを信じます。一方から他方へ移行するときは、新しい設定が既存のセッションに効くと仮定せず、古い機能を無効にしてクライアントを再接続してください。

クライアントプールがLANの範囲と重ならないように変更を順序立ててください。重複するサブネットは、接続はできるが何にも届かないトンネルの二番目に多い原因で、二つのアドレス計画を並べて比べるまで見えません。

そしてクライアントから再接続し、何を受け取ったかを読んでください。ハブから見たセッションとクライアントから見た自分のネットワークは同じではなく、新しいリースを強制する確実な方法は再接続だけです。

クライアントでゲートウェイとリゾルバーを確認する

認証が成功したというのは、資格情報が機能し、ハブがセッションを受け入れたということです。何かに到達できるかは何も語らず、それは与えられたアドレス、マスク、ゲートウェイ、DNSサーバーに依存します。サーバー設定に再び触れる前に、クライアントでその四つの値を読んでください。

Windowsではアダプターの詳細がリースとリゾルバーを示し、ルートテーブルがトンネルが本当に既定の経路かどうかを示します。

ipconfig /all
route print -4
nslookup intranet.corp.internal

Linuxクライアントでは同じ情報がアドレス、ルート、リゾルバーのファイルから得られます。既定ルートが、トラフィックがそもそもトンネルを通って出るかを決める値です。ゲートウェイがオフィスのルーターを指しているのにトンネルがトラフィックを運ぶ想定なら、トポロジーは名前の上でブリッジされ、実際には壊れています。まずアドレスの供給元を直し、次にアプリケーションを再試験し、それから初めてもう一方のモードの変更を検討してください。

関連記事