OpenVPN を介した 2 枚のボード間の分離 TAP ブリッジ

二枚の開発ボードが 一つの Ethernet セグメントを共有する必要がありますが、ベンチは別々の建物にあります。トンネルはすでに存在し、すでに Ethernet を運んでいるため、残りの作業は 三つのコマンドに見えますが、そうではありません。ホストがブリッジされたフレームをどう扱うか、PC 自身のアドレスがどこに属するか、ブリッジが作らない境界は何かは 三つの別々の事実であり、二番目を間違えるのが、ラボが断続的に動き、その管理アクセスが静かに劣化する通常の理由です。これら 三つの事実はどれもトポロジー図には現れません。

以下の手順は、二台の Linux PC 間の認証済み TAP 接続、ベンチごとに 一つの専用有線ポート、実験の一部ではない管理インターフェースを前提としています。順序が重要です。まずフレーム、次にアドレス、最後に境界です。

ブリッジが実際に運ぶもの

ブリッジはソフトウェアで実装されたスイッチです。どの MAC アドレスがどのメンバーポートの背後に現れるかを学習し、IP ルーティングテーブルを参照せずにメンバー間でフレームを転送します。その説明にはサブネット、ゲートウェイ、デフォルトルートは含まれないため、IP 転送を有効にしてもこの接続は生まれず、ping が成功しても他のトラフィックが失敗し続けることがあります。ボードはデフォルトルートを一切設定しなくても相手に到達でき、レイヤー二 がレイヤー三 のように振る舞うと期待する人を驚かせます。

各 PC は有線ポートを 一つブリッジに、TAP デバイスを同じブリッジに提供するため、ボードからのフレームはローカルポートに入り、TAP デバイスに転送され、トンネルを越え、相手の TAP デバイスに届き、相手のボードへ転送されます。トンネルは他のメンバーポートと同じであり、ブリッジは背後に VPN があることを知りませんし気にもしません。この対称性が例を考えやすくします。各側にラボ向きのポートが 一つとトンネルポートが 一つあり、どちらの側も特別ではありません。

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

両方の PC で同じ名前はローカル名であり、共有オブジェクトではありません。ベンチ間には 一本の Ethernet 経路があり、二本目のケーブルもループを閉じる 二本目のトンネルもありません。同じ MAC が 二つのポートに現れるのを見たブリッジは喜んで輪になって転送します。

メンバーポートではなくブリッジにアドレスを付ける

ラボセグメント上の PC の ID はブリッジデバイスに属します。メンバーポートは番号なしのままです。ポートは転送メンバーであり、そこにアドレスを置くと同一セグメントの 二人目の競合する所有者ができるからです。これは手作りのレシピのほとんどが間違える修正点です。TAP デバイスとブリッジの両方にアドレスを付け、どちらに相手が実際に到達するのかと悩みます。

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

相手は別のホストアドレスで同じ形を使い、ボードは必要なら PC のブリッジアドレスを次のホップとして同じ範囲のアドレスを取ります。計画が合意されるまでドキュメント用の範囲を使い、オフィスがすでにルーティングしているものと衝突しないよう範囲を予約してください。実行する前に、メンバーポートに残存アドレス、DHCP クライアント、別のブリッジへの所属がないことを確認し、TAP デバイスのアドレス指定をトンネル設定を所有するものを通じて整合させ、後でアドレスを復元しないようにしてください。

ベンチごとに専用ポートを 一つ使う理由

専用の有線ポートが、実験をオフィス全体の変更にしないためのものです。管理インターフェースは SSH、デフォルトルート、外部 VPN 接続を運び、そのどれもラボのフレームを運ぶことを目的とするブリッジに属しません。

管理アダプターを接続すると、オフィスの LAN が開発ボードから転送判断 一つ分の距離に置かれます。レイヤー二 で問題を起こすボードは、そのセグメントに置きたくないまさにその種のデバイスです。Wi-Fi アダプターはさらに悪く、インフラストラクチャモードの無線インターフェースのブリッジは Ethernet のブリッジのようには振る舞わず、障害はきれいではなく混乱を招きます。

ラボの範囲はどの本番 DHCP スコープからも外してください。ボードに後で動的アドレス指定が必要なら、一つのプールを持つ 一つの承認されたアロケーターだけが予測可能なままです。同じセグメントで応答する 二拠点の通常のルーターは、誰も説明できないアドレスを生成します。

ブリッジが作らない境界

ブリッジはルーティングではなく、分離でもありません。ブリッジを越えるフレームは、インストールされた bridge-netfilter の経路に応じて、ホストのフィルタリングフックに到達できます。したがって実効ポリシーは想定ではなく検査する必要があります。フレームが 一つ失われたからファイアウォールを無効にすると、特定のバグを一般的なバグと交換することになります。

ブリッジと各管理またはアップリンクインターフェース間の IP 転送はオフのままにするか明示的に拒否すべきで、これはブリッジのメンバーシップとは別の制御です。PC のラボアドレスをゲートウェイに選ぶボードはまさにこれを試します。管理の通過が成功するなら、意図した境界はそもそも存在しませんでした。

さらに 二つのファミリーには明示的な決定が必要です。アドレス計画はブリッジを IPv4 専用にしないため、IPv6 と他の EtherType には独自の計画かフィルターが必要です。また、ping が成功しても、ボードの検出ブロードキャスト、マルチキャストグループ、ジャンボフレームが経路を通るかはわかりません。これらは異なる既定値を持つ異なるトラフィッククラスだからです。

最後に、転送と機密性は別の買い物です。TAP は Ethernet を運び、OpenVPN サービスがその周りの保護を提供します。VXLAN オーバーレイも Ethernet を運び、それ自体では機密性を提供しません。したがって一方を他方に置き換えると、トポロジー図が同一に見えてもセキュリティ特性が変わります。

永続性とそれを証明するテスト

接続後に 一回入力したコマンドは設定ではありません。ブリッジ、ポートのメンバーシップ、単一のホストアドレスを PC の既存のネットワークマネージャーを通じて永続化し、接続を TAP デバイスの出現に結び付けて、再接続でメンバーが消えたブリッジが残らないようにしてください。

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

次に、ボードが両方向で実際に必要とするものをテストし、トンネルを再接続し、承認された復旧計画に従って PC を 一台再起動します。その後 三つを確認します。管理アクセスが独立して機能し続けること、重複したラボアドレスが現れないこと、予期しない本番インターフェースがブリッジに参加していないことです。この組み合わせが、実験がベンチ内にとどまった証拠です。