Nebula のライトハウスフィルターとファイアウォール: それぞれ何を遮断するか

Nebula のハンドシェイクを反対側から見ると、二つの仕組みは入れ替え可能に見えます。一方はノードがライトハウスに通知するアドレスと、試行するリモートアドレスを決めます。もう一方はトンネルができた後に何が通過できるかを決めます。フィルターはファイアウォールの規則が評価される前に接続を止められますが、ファイアウォールの規則はディスカバリが削除したエンドポイントを復活させられません。二つの層は異なる問いに答えており、作用する順序が鍵です。

一つの接続を四つの段階で追います。告知されるローカルアドレス、検討されるリモートエンドポイント、ハンドシェイク、そしてオーバーレイのトラフィックです。各段階には独自の設定と独自の障害の痕跡があります。

ノードが告知するローカルアドレスから始めます

local_allow_list は、このホストのローカルアドレスをライトハウスへ報告する前に絞り込みます。エントリはアドレス範囲でもよく、設定はインターフェース名のパターンもサポートします。コンテナブリッジや、ピアのエンドポイントにすべきでない追加のトンネルインターフェースがある場合に役立ちます。

ホストのインターフェースを確認し、リモートのピアが実際に到達できるのはどれかを問います。Docker ブリッジのアドレスはそのホスト内だけのもので、別のネットワークのピアには無意味です。それを告知するとディスカバリを浪費し、決して応答しないアドレスへピアを向かわせることがあります。ピアが経路を持てないものは、ライトハウスの応答におけるノイズです。

ここでは狭い許可リストのほうが広い拒否リストより安全です。許可のエントリだけがある場合、指定のない残りは除外されます。後から拒否のエントリを加えると既定の論理が変わり、独自の見直しが必要です。その変更は既定値をもう一度見る価値があります。

次にリモートエンドポイントの選択を見ます

remote_allow_list は、ハンドシェイク中にこのホストがリモートのピアに対して検討するアドレスを絞り込みます。適用されるのはアンダーレイのアドレスであり、トンネルが上がった後にピアが使うオーバーレイのアドレスではありません。

プライベート範囲は共有のオフィスネットワークでは十分に使えますが、両方のホストが 10.0.0.0/8 を使う無関係なネットワークにあると意味を失います。フィルターを使えば、経路のある道を優先し、偶然を無視できます。

ピアが接続できないときは、試行中のアドレスとそれに一致する規則を比べます。ハンドシェイクのログを有効にして、選択されたリモートアドレスを読みます。ログ行は絞り込みを生き残ったエンドポイントを示し、ピアが持つアドレスの一覧より有用です。

告知する側のインターフェース名フィルターは、受け取る側が見る前にエンドポイントを外すことがあります。片方向だけが失敗するときは両方のノードを確認します。

ハンドシェイクの後は、オーバーレイのアクセス規則が適用されます

Nebula のファイアウォール規則は、トンネルが確立した後にオーバーレイの内側で働きます。ホスト、グループ、ポート、プロトコルを照合し、パケットがローカルホストに入れるか出せるかを決めます。アンダーレイのエンドポイントは選びません。

この分離はよくある誤診を説明します。運用者がポートのファイアウォール規則を足しても接続できないのは、ライトハウスのフィルターが唯一到達できるエンドポイントを外していたからです。別の運用者がアドレスフィルターを開けてもサービスに届かないのは、オーバーレイのファイアウォールがポートを拒否するからです。

障害は正しい層で読みます。決して完了しないハンドシェイクは、ディスカバリ、エンドポイントの絞り込み、またはネットワーク経路を示します。完了したハンドシェイクの後にサービスの接続が拒否または破棄される場合は、オーバーレイのファイアウォールかアプリケーションを示します。

許可と拒否を混ぜるときは既定値を読みます

ライトハウスの設定は許可のみ、拒否のみ、混在のリストに対応し、指定のない残りに対する既定値はその形で異なります。混在のリストにはアドレスファミリの明示的な既定値が必要です。残りが以前の設定と同じように振る舞うと仮定することが、動いていたエンドポイントが静かに消える道です。

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

既定値を定型文ではなく規則の一部として扱います。ファミリの既定値が拒否なら、一覧にないすべてのアドレスが除外されます。設定を書いた後に追加された新しいオフィス範囲も含まれます。

どのアドレスを到達可能にするつもりだったかを記録し、両側から試します。一つのピアの組で機能するフィルターが、唯一の共通経路が一覧から除外されたアドレスを使う別の組では失敗することがあります。

直接のエンドポイントに到達できないときはリレーを使います

候補のエンドポイントがすべて除外されるか到達できない場合、答えは信頼しないアドレスを再び受け入れる広い許可リストではありません。直接の接続が現実的でないとき、Nebula のリレー設定が代替のピア経路を提供します。

リレーが解くのは転送とディスカバリであり、認可ではありません。リレーはファイアウォールを広げません。オーバーレイのファイアウォールはどのサービスを使えるかを引き続き決め、リレーはライトハウスの絞り込みをアクセス制御の仕組みには変えません。

直接のエンドポイントを無効にしてリレーの経路を試し、意図したサービスは動き続け、意図しないサービスは動かないことを確かめます。その一つの試験が転送の修正とポリシーの変更を分け、二つの層を正直に保ちます。