ピアツーピア VPN には依然として中央依存がある

ピアツーピアが説明するのは、アプリケーションのパケットがどう流れるかだけである。ピア同士は依然として互いを見つけ、自分が誰かを証明し、直接経路を築けないときにはリレーに頼る必要があった。これは三つの別個のサービスであり、展開はデータについてはピアツーピアであっても、それ以外のすべてについては完全に中央集権的でありうる。設計を比較するとは、図の矢印ではなく、これらの仕事を比較することである。

中央の転送矢印のない図は、登録機関、発見サービス、リレーを隠していることがあり、どれも運用上の依存である。

直接経路と共有コントロールプレーン

パケットを直接やり取りする二台のマシンでも、証明書を発行した共通の機関と、どちらがどこにいるかを伝えたサービスに依存していることがある。どちらの役割もアプリケーションのトラフィックを転送しないため、トポロジー図からは省かれる。その機関やサービスが停止すると、既存のセッションは続けられても、新しいピアは参加できない。セッションを始めることと続けることの違いは、どんな設計にも最初に問うべき質問である。

一つのホストがすべてを担う場合でも、仕事ごとに分けて描く。そうしなければ、図は分散したデータプレーンを示す一方で、新しいピアには同じ二つのサービスが必要だという運用上の現実を隠してしまう。

発見、信頼、リレーは三つの仕事

Nebula の設計は、ドキュメントがこれらを分けているため有用な例である。ホストは身元の証明書を持ち、灯台はどこにあるかの問いに答え、NAT 越えを助け、リレーは直接経路を確立できないときにトラフィックを転送する。リレーの役割は灯台の役割と意図的に別であり、灯台に到達できても、特定の組が会話できるとは限らない。他の製品は境界を別の場所に引いており、だからこれはテンプレートではなく一例である。

提案された展開では、直接接続できない組に対するサポート済みの代替経路を書き留める。失敗したホールパンチは一つのネットワークについての一つのデータ点であり、NAT の後ろにいる二つのピアが決して出会えない証拠ではなく、直接接続が任意のポリシーの下で機能するという逆の主張も、同じだけ根拠がない。

各依存はどこで破綻するか

テスト対象の依存が使えない間、四つのケースを別々に評価する：既存のピア間トラフィック、まったく新しいピア接続、端点が変わったピア、たった今取り消されたアクセスである。それぞれ異なるサービスに依存し、異なる仕方で失敗する。既存セッションは発見の停止を生き延びても、取り消された鍵は依然として拒否され、新しいピアは転送と無関係な理由で失敗することがある。一つから結論を出すのではなく、個別に試すべきである。

一度の停止を生き延びた接続は、無期限の独立を証明しない。あなたが起こした停止がその経路を壊すものではなかった、ということを証明するだけであり、何を起こしたかを記録していれば、それでも有用な情報である。

どの停止に耐えられるかを問う

似て聞こえる要件は異なる設計に導く。単一の転送ボトルネックを避けることは、ベンダーがホストするコントロールプレーンを避けることと同じではなく、どちらもコーディネーターが停止している間も動かし続けることとは一致しない。展開がこの三つのどれを満たすべきかを名指しし、それから対応を確認する。最初を満たして二番目に失敗する設計はよくあり、誰もそれを完全な分散型と呼ばない限り、不誠実ではない。

発見、信頼、リレーを誰が運用し、それぞれがどう置き換えられるかを記録する。その記録があって初めて、次の人は実際の問いに答えられる：このネットワークはどの障害に耐えるのか、共有されたままの状態を誰が維持するのか。

分散型という言葉は、それらの障害を名指しするときにこそ値を持つ。その一覧がなければ、それはシステムではなく図を説明している。