NetBird 上の 2 つの LAN：どのピアが経路を担い、誰が通信できるか

西側 LAN のワークステーションでブラウザを開き、東側 LAN にあるアプリケーションのアドレスを入力して、タイムアウトするまで待ちます。NetBird のどの画面を見てもピアは接続済みと表示されますが、それは事実であって要点ではなく、ひとつのオーバーレイネットワークに入っていることは二つのローカルサブネットを一つのネットワークに収めることとは違います。以下の道筋はそのワークステーションから始まり、設計が意図的に拒否する要求で終わります。どの停止点も推測ではなくデバイスから読み取れるものであり、足りないのはオーバーレイではなくルートかポリシーだと見込んでください。

まずワークステーションから障害を読む

管理コンソールを開く前に、ワークステーションが実際に何を送っているかを確かめます。宛先をサイトのゲートウェイに送るか、ローカルインターフェースに送るか、どこにも送らないかは、そのマシン自身のルーティングテーブルが決めており、この判断はオーバーレイのツールなしで見えます。遠いプレフィックスへのルートがないマシンは、ピア一覧がどれほど健全に見えても失敗します。オーバーレイの範囲とサイト自身のプレフィックスは別のアドレス空間であり、登録が設定したのはそのうちの一方だけです。

次に、ブラウザがどちらも同じタイムアウトとして報告するため、名前解決と到達性を切り分けます。NetBird クライアントが動くマシンからアドレスで要求を繰り返し、次にクライアントのない通常のワークステーションから繰り返します。登録済みのマシンが成功して通常のマシンが失敗するなら隙間はローカルルーティングにあり、両方失敗するならルートを変える前に読み進めてください。

サイトごとにルーティングピアを一台選ぶ

ルーティングピアはオーバーレイ上で自分の LAN を代表するホストなので、誰かの机のワークステーションではなく、サブネットへの安定した到達性を持つ Linux マシンを選びます。通常の手順で登録し、ネットワークリソースとポリシーの両方がそのグループを参照するため、役割の名前を付けたグループに入れます。サイトごとに代表が一台なら読みやすく保てますが、同じプレフィックスを広告する有志の群れは、その後のあらゆる疑問をデバッグ作業に変えます。ローカルセグメント上のピアのアドレスは、そのアドレスが通常のデバイスすべてに伝える次のホップになるため、オーバーレイ上の識別子と同じくらい重要です。

コンソールに触れる前に、名前とプレフィックスこそこうした設計がずれる場所だから、計画を書き留めます。プレフィックス、ゲートウェイ、ピアのアドレス、グループをサイトごとに書き、西は 10.52.0.0/24 で 10.52.0.5 が担い、東は 10.63.0.0/24 で 10.63.0.5 が担い、二つのグループは west-routers と east-routers で、どのプレフィックスも他方やオーバーレイの範囲、ほかのルーティング先と重なってはいけません。

リソースを作り、マスカレードは有効のままにする

展開済みのダッシュボードで、サイトごとにネットワークリソースを一つ作り、そのサイトのルーティングピアのグループを結び付けます。リソースがプレフィックスでグループがそれに応答するホストであり、何かを広告する前に両方が存在している必要があります。展開済みのセルフホスト版については、似た名前のルートオブジェクトを持つ古い画面が別の機能であるため、Networks ワークフローがあること自体を確認してください。

マスカレードは有効のままにします。NetBird のサイト間ガイドがこの構成で要求しており、元のアドレスをすべて見せるために切るのは、オーバーレイの送信元検査とポリシーが見るものを変えるため、ホップが一つ少ない同じ設計ではありません。オーバーレイの送信元検査とポリシーが見るものが変わるからです。結果は率直に言うべきで、受信側のサービスが記録する送信元はルーティングピアであり、個々のワークステーションではないため、そのサービスの許可リストや監査がワークステーションのアドレスを期待するなら、期待を変えるか、変換前にサイト境界で識別子を強制するかのどちらかです。

権限を与えるのは開始側であり、プレフィックスではない

ルートはアドレスを到達可能にし、ポリシーは誰が使えるかを決めますが、両者は別々の所有者を持つ別々のオブジェクトです。ポリシーはワークロードから逆算して書き、どのグループが開始し、どのリソースを対象にし、どの TCP サービスを必要とするかを定めます。両方のプレフィックスを登録済みの全ピアに広告するネットワークは、到達性を作っただけで何も決めていません。

次に、狭い新しい規則はその上にある広い古い規則を取り消さないため、ほかに何がすでに許可されているかを読み、東から西への接続も始める必要があるときは、その方向を独自のポリシーとして書きます。西が開いたセッションの戻りトラフィックは、東向きの新しいセッションを許可するのとは別の問いです。西側の一部のワークステーションだけが東側のアプリケーションに届くべきなら、変換前にサイト境界で選別し、アプリケーション自身の認証はそのまま残します。ルーティングピアは LAN のトラフィックをサイト全体として運び、ユーザーごとのオーバーレイ識別子としては運ばないため、ユーザーごとの計上は別の場所から取る必要があります。

各ゲートウェイに次のホップを教え、次に拒否を試す

通常のデバイスはオーバーレイを決して見ないので、それぞれのゲートウェイに、遠いプレフィックスをルーティングピアの LAN アドレスへ向ける静的ルートが必要です。ここを飛ばす人が多いのは、NetBird の中で見えるものはすでに動いており、普通のワークステーションだけがタイムアウトし続けるからです。ゲートウェイはデフォルトルートをそのまま保ち、このプレフィックスは追加であって置き換えではありません。

二つのルート記述は各サイトのゲートウェイ設定に置くもので、ホストの上書きではなく、どちらも普通の静的ルートで、デフォルトルートには触れません。

west gateway: 10.63.0.0/24 via 10.52.0.5
east gateway: 10.52.0.0/24 via 10.63.0.5

プロジェクトが本当に必要とするアプリケーションで、通常のワークステーションから試し、送信側で選ばれた次のホップ、一致したポリシー、サービスが記録した送信元アドレスの三つを記録します。拒否も試すべきで、何も拒否したことのない設計には未知の縁があり、拒否だけが、ルーティングではなくポリシーが働いている証拠になるからです。東も開始する必要があるときは、第二の方向も付いてくると決めつけず、その側から新しい接続を始めます。一つのホストがサイトの依存先になったため、ルーティングピアの再起動、更新、交換も計画してください。

プライベート名には独自のリゾルバ設計が必要で、到達性は DNS レコードを作らず、名前が壊れたまま動く IP 経路は、壊れた経路とまったく同じに読めるからです。ルーティングピアがクラウドネットワーク内で動くなら、登録は提供元の転送とファイアウォールの規則を上書きしないため、それらも確認してください。次にこれをデバッグする人は、トポロジーの説明ではなく、一致したポリシーと記録された送信元アドレスを求めるため、試験の観察結果は計画のそばに置いてください。