Nebulaのadvertise_addrsとstatic_host_map：所有者で選ぶ

static_host_map と advertise_addrs はどちらもpeerの前にアドレスを置きますが、答える問いが違います。一方はoverlayアドレスと接続先のunderlayエンドポイントを並べたローカルファイルです。もう一方は、ホストが自分の灯台に、どの追加エンドポイントから到達できるかを伝えるものです。本当の違いは所有権です：マップは必要とする全員が保守し、広告はホスト自身が行います。

情報を誰が持つかで決める

各peerの静的ファイルに載る変化するpeerは、艦隊の二乗で増える保守作業です。ホスト自身が答えを知っているなら別の設定に手を伸ばすべき、という実務的な理由がここにあります。

所有権の問いは、アドレスが変わったときに何が起きるかも予測します。静的マップでは、古いエントリを持つ全peerを誰かが覚えておかなければなりません。広告なら、ホストが新しいエンドポイントを公開し、灯台がそれを伝えるので、変更は移動したマシンの中にとどまります。

ブートストラップには静的エントリが要る

クライアントは他のpeerについて誰かに尋ねる前に、少なくとも一つの灯台に到達しなければなりません。その最初の一跳びは発見からは来ないので、クライアント設定の静的なエントリ に頼ります。その一つのエントリを正しくすれば、残りのoverlayは学習できます。

マップのエントリは、Nebulaアドレスを一つ以上の到達可能なIPまたはDNSエンドポイントとポートに結び付けます。灯台をそこに置くのは普通ですが、すべてのpeerをそこに置くのは古びていくやり方で、新しいpeerのたびに、管理していないかもしれないマシンのファイルを編集することになるからです。人が読んで検証できる程度に短く保ちましょう。

ホストがエンドポイントを知っているなら広告する

ポート転送の後ろにいるホストは、自分のどのインターフェースにも割り当てられていない公開アドレスで到達できます。自分自身を見てもそのアドレスは発見できません。advertise_addrs を使えば、灯台を通じてエンドポイントを公開でき、他のpeerは実際に機能する経路を学べます。この設定があるのは、マッピングが作られたことを知っているのがホストだけだからです。

他のpeerが本当に到達できるアドレスとポートを使います。同じ理屈は複数のネットワーク経路を持つホストにも当てはまり、特定のネットワーク上のpeerには一方の経路が適します。広告はunderlayについての表明であり、何かを要求するものではありません。マッピングが変わったら、ホスト側の広告を更新し、艦隊全体の静的ファイルを編集するのではなく、発見に運ばせます。

広告は到達性ではない

エンドポイントを公開しても、ルーターの転送ルールができるわけでも、上流のファイアウォールが開くわけでも、DNS名が解決するわけでもありません。それらは別の作業であり、ポート転送が欠けたまま正しい広告を出せば、直そうとしていた障害がそのまま起きます。広告は到達性についての主張であって、それを確立する仕組みではありません。

発見を責める前に、外から経路を確認します。エンドポイントを学んでもハンドシェイクを完了できないpeerは、underlayでのルーティングかフィルタリングの問題を抱えており、両方の設定に同じアドレスを書いても変わりません。

overlayアドレスはエンドポイントと別に保つ

ノードの証明書はそのNebulaアドレスを識別します。広告されたアドレスは下位のネットワークに属し、証明書に触れずに変えられます。別のoverlay IPで新しい証明書を発行すること は別の操作であり、古い方を固定したすべての信頼関係にそれぞれの影響があります。runbookで二つの変更を分けておかないと、エンドポイントの移動が再発行として記録されます。

トリアージが行き詰まったら、発見は期待どおりのエンドポイントを返しているか、ハンドシェイクはそこに届くか、という二つの層に明示的に分けます。発見が正しくパケットが失敗するなら、問題はoverlayの下にあります。発見が誤っているなら、問題はマップか広告にあり、修正もそこに属します。