SoftEtherカスケード：二つの仮想ハブを意図的につなぐ

カスケードで結ばれた二つのSoftEtherハブは一つのブロードキャストドメインを共有するため、ループや二台目のDHCPサーバーはローカルの誤りではなく共有の誤りになります。これがリスクモデルの全体です。カスケード自体は設定されたクライアント関係であり、ローカルの仮想ハブが、そのサーバーが許可するアイデンティティのもとで遠隔サーバーのハブへ外向きに接続します。より大きな仮想ネットワークの構成要素であり、インターネットの出口にはなりません。

1. リンクが何を運ぶべきかを決める

機能ではなく要件から始めます。カスケードはハブ間でデータリンク層のフレームを運び、二つの拠点が一つのEthernetセグメントのように見える必要があるときに、これが求められます。必要が一部のサブネットへのルーティングされたアクセスだけなら、ルーティング経路のほうが単純で、失敗も見えやすい形になります。カスケードを選ぶことは、共有ブロードキャスト、共有ディスカバリ、そして一つのループトポロジーを受け入れることです。

サーバーに触る前に、要件を一行で書きます。どのシステムが同じ回線上に見える必要があり、どれが経路だけを必要とするのか。「経路」と答えるものはカスケードの外に置きますが、この一文が、アドレスサービスの重複で終わる設計のほとんどを防ぎます。

2. 認可するアイデンティティの範囲を定める

サーバーを管理する資格情報と、カスケードが接続に使うアイデンティティは別の秘密であり、それらを混ぜるのは長い影響を伴うよくある近道です。遠隔ハブには、このカスケードの接続を許可するユーザーまたはポリシーの項目が必要です。その項目が認可であり、ログインの成功は遠隔ハブの背後に何があるかを何も語りません。

どのハブが開始し、どの遠隔ハブに参加し、遠隔のアイデンティティが何に到達できるかを記録したうえで、コミットする前に二つのアーキテクチャを比較します。

両端の資格情報と復旧手順を最新に保ちます。遠隔ハブでのパスワード変更やポリシー編集は、ローカルのユーザーに触れずにカスケードを壊し、その障害は通常、稼働しているのに空のリンクとして現れます。

3. ハブがすでに運んでいるものを調べる

ハブが孤立していることはまれです。すでに物理アダプターへブリッジし、仮想ルーター経由でルーティングし、あるいは別の場所へカスケードしているかもしれず、それらの接続はすべて新しい関係に持ち込まれます。「二つのハブをつないだだけ」が「なぜこの二つの拠点が今一つのセグメントなのか」に変わるのはそのためです。

同じ物理セグメントにブリッジされ、その後に互いにカスケードされた二つのハブはループを作ります。スパニングツリーを追加するか、構築しないでください。同じテストは、すでに別のカスケードで目標に到達しているハブにも当てはまり、二本目のリンクは容量を増やさず、経路を増やします。

経路が一つ欠けているからといってリンクを追加せず、経路を直します。まずトポロジーを紙に描き、図は二分で描けて、すべてのブリッジとカスケードを含めればほとんどのループを存在する前に捕まえることを覚えておいてください。

4. 参加前にアドレッシングを片づける

結合されたセグメントは重複したサブネットを持ち込み、重複したDHCPサーバーが典型的な症状です。クライアントは最初に応答したサーバーからリースを取るため、動作はランダムに見え、再起動の間に移り変わります。どちら側がアドレス割り当てを持つかを事前に決め、遠いセグメントにはローカルと重ならない範囲を与え、カスケードがオンラインになる前に、最初の苦情の後ではなく、もう一方のDHCPサービスを無効にします。

DNSは別の問いであり、カスケードはフレームを運ぶもののリゾルバーは設定しません。ローカル側で解決する名前が、リンクの向こうで解決しないこともあります。動くpingは二つのうち一つしか証明しないため、名前解決はIP経路とは別にテストしてください。

5. 実際のリソースで証明する

目的の遠隔セグメント上で許可されたサービスを選び、応答がカスケードを通って戻ることを確認します。次に名前解決についても繰り返します。目標がブロードキャストによるディスカバリに依存するなら、単一の回線よりブリッジされたリンクで異なる挙動を想定し、不具合として記録するのではなく計画に組み込みます。

最後に、どのハブがどこへカスケードするか、どのアイデンティティがそれを認可するか、どのセグメントがブリッジされているか、それぞれで誰がアドレス割り当てを持つかを書き留めます。そのメモが、存在を知らなかったセグメントを落とさずに次の人がポリシーを変えられるようにします。