Nebula static_host_map：灯台が渡せないアドレス

灯台は、灯台自身がどこにいるかを除いて、他のあらゆるピアについてホストに伝えられる。オーバーレイが存在する前に何かが既知でなければならず、Nebula はその何かを一つの小さなマップに置く。マップはオーバーレイの識別子を、通常のネットワークで機能するアドレスと対にする。後から学ぶことすべては、その対が正しいことに依存する。

二つの役割を持つ二つのアドレス

すべての Nebula ホストは、デバイスがネットワーク間を移動しても固定のままのオーバーレイアドレスを持つ。そのアドレスは証明書、ファイアウォール規則、ピア関係が使う識別子であり、単体ではどこにもルーティングしない。到達可能なエンドポイントは別物で、下位ネットワーク上のホスト名かアドレスに UDP ポートを加えたもので、マシンが場所を変えるたびに変わる。静的マップはその二つをつなぐ継ぎ目である。

マップに入るのは冷たい状態でダイヤルする必要があるホストだけで、通常は灯台と、おそらく一つのリレーを意味する。その一覧を短く保つことが設計目標で、手作業の登録はどれも誰かが保守すべき事実になる。二種類のアドレスを混同するのがよくある設定ミスで、灯台の一覧に公開アドレスを置いてもディスカバリは始まらない。

識別子は識別子が期待される場所へ。到達性はマップへ。

static_host_map:
  "10.42.0.1": ["lighthouse-01.example.net:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "10.42.0.1"

マップ項目の解剖

キーは引用符で囲んだ文字列として書くオーバーレイアドレスで、値はエンドポイントの一覧なので、一つの識別子に複数の入口を持たせられる。各エンドポイントはホストとポートを持ち、ポートは相手側が実際に待ち受けているものと一致しなければならない。Nebula の既定値は UDP 4242 で、これは出発点であり、あなたの配備についての約束ではない。

複数のエンドポイントは、公開アドレスと同じセグメントのホスト向けのプライベートアドレスのように、灯台への入口が複数あるときに役立つ。クライアントは順に試すので、最も信頼できるものを先頭に置く。IPv6 ではポートを付ける前にアドレスを角括弧で囲むが、間違えると誤った行を指す解析エラーになる。

UDP には拒否するハンドシェイクがないため、間違ったポートはエラーではなく沈黙を生む。だから項目の書式は記憶ではなく Nebula の static_host_map リファレンス で確認する価値がある。リファレンスはエンドポイント一覧と DNS 更新の挙動も扱っている。

ブートストラップはオーバーレイより先に動く必要がある

マップ内の DNS 名は、トンネルが存在する前にホストが持つリゾルバ、つまり通常のシステムリゾルバで解決されなければならない。同じマシンから、起動時に、オーバーレイを止めた状態で試すこと。オーバーレイ自身の DNS でしか解決できない名前はオーバーレイをブートストラップできない。同じ試験は経路にも当てはまり、オーバーレイを許可しても最初の UDP 交換を許可しないファイアウォール規則は最初のパケットを遮断する。

ポートが開いていると仮定せず、UDP の道具で調べる。経路上のポート転送が正しい内部ホストを指していること、戻り経路があることを確認する。ホスト名が複数のアドレスに解決されるなら、クライアントはあなたが確認していないアドレスを選ぶことがあるため、それぞれを試す。

静的項目は直接ダイヤルされ、灯台に問い合わせることは決してない。だからここでの失敗はピアが関与しない普通のタイムアウトに見える。

最初のハンドシェイクの後に何が起きるか

ホストが灯台に到達すると、追加の手作業なしにピアとその到達可能なアドレスを学ぶ。前回の接続以降に移動したホストは、その経路を通じて発見可能になる。これが手作業のマップを小さく保つ見返りである。

ホストは自身の追加の到達可能なアドレスを広告することもできる、こうして既知の公開アドレスの背後にいるピアが、他のホストの探索を助ける。その広告は学習されるもので、静的マップに書き込まれるものではない。

DNS 名として書かれたエンドポイントでは更新の挙動が重要で、プロセスが動き続ける間に解決済みのアドレスが変わりうる。Nebula の設定はその照会がどう行われるか、どのリゾルバを使うかまで制御するので、システムの既定を仮定せずに読むこと。トンネルが上がるとリゾルバが変わるホストでは、誤った設定が、動いていたブートストラップをセッション途中で解決しなくなる名前に変えうる。照会を安定したリゾルバに固定することが、信頼できるオーバーレイと途切れるオーバーレイの違いであることが多い。

ディスカバリは動くのに一つのピアだけ動かないとき

灯台に到達でき、ほとんどのピアが接続するなら、ブートストラップは問題ではない。残った組は互いに使える経路を見つけられないか、到達性より上の層で失敗している。灯台アドレスの別の書き方を足しても、どちらの場合も直らない。

他のすべてがすでに依存しているマップを編集する前に、その組を確認する。マップの変更はすべてのホストを乱すので、最初ではなく最後に触るものだ。

拒否されたハンドシェイクは遠目には到達不能なピアに見えることがあるため、同じ認証局の証明書から始める。次に、その組が直接経路を確立できるか、直接通信を拒むネットワーク向けにリレーが設定されているかを確認する。リレーはホップと依存を一つ増やすが、対応済みの答えであり、組の経路を直すのはディスカバリを直すとは別の作業だ。