Meshnet、Docker、そしてその間にある許可

二つの URL はピアのブラウザからは同じに見えても、ファイアウォールにとってはまったく別の意味を持ちます。一方はホスト自体で待ち受けるサービスを指します。もう一方は、ポートがコンテナネットワークに公開されたホストアドレスを指し、そこで変換の段階が接続を別の IP に引き渡します。ピアごとの許可でローカルネットワークへのアクセスを制御するピアツーピアのメッシュでは、その違いがレビューのすべてです。

許可はホストのエンドポイントについてであり、変換は Docker についてであり、ログインはアプリケーションについてです。三つの判断、三つの見るべき場所。

公開後の宛先を追う

コンテナのポート 80 をホストのポート 8080 に公開する Linux の Docker ホストを考えます。ピアは 8080 でホストのメッシュアドレスに接続し、ホストが接続を受け入れ、宛先の変換がそれをコンテナのブリッジアドレス、通常は 172.17.0.2 のポート 80 のようなものへ書き換えます。

ルールがそのフローを検査する時点で、関心のある宛先はホストではなくコンテナです。「このマシン上のサービス」だけを論じるポリシーは、間違った対象を論じています。リクエストはホストに着地しましたが、別の場所へ配信されています。

だからこそメッシュのドキュメントは、Linux でローカルネットワークの許可が統制するリソースの中に Docker コンテナを挙げています。許可は通常の VPN 許可リストの項目の同義語ではなく、二つの制御は互いの代わりにはなりません。一方はピアがそもそもローカルリソースに到達できるかを決め、もう一方はトンネル経路がどの宛先を運ぶかを決めます。

許可がどれだけのローカルアクセスを与えるかを決める

ピアにローカルネットワークへのアクセスを与えることは、単一のコンテナについての判断ではありません。同じホスト上の他の公開サービスを露出させる可能性があり、ホストがどう転送するかによってさらに遠くまで届くことがあります。一つのダッシュボードのためにスイッチを押す前に、実際の範囲を確認してください。

次に、Docker がどこでポートを公開するかを見ます。0.0.0.0 での公開はすべてのホストアドレスにリスナーを作り、メッシュの項目と並んで通常の LAN の項目を追加することがあります。要件がメッシュのみなら、公開を意図した特定のアドレスやインターフェースに束縛し、より広い束縛は便利さではなく別の所見として扱ってください。

ホストの転送ポリシーとアプリケーション自身の認証を、サービスに必要なだけ狭く保ってください。私的に見える URL はアクセス制御ではなく、ブリッジネットワーク上のあらゆる送信元を信頼するコンテナは、メッシュのピアが承認されたという事実では守られません。アプリケーションの認証が三つ目の判断であり、ユーザーが誰かを知る唯一のものです。ホストレベルの許可はその知識を提供できません。

許可をテストし、URL だけを試さない

承認されたピアから正確なサービスを開き、動作することを確認します。次に、拒否されたままであるべき宛先を試し、動作しないことを確認します。幸せな経路だけを試すと許可が与えられたことは分かりますが、境界が思っている場所にあるかは分かりません。

ホスト固有のサービスを別に比較します。データベースがホストで待ち受け、ダッシュボードがコンテナで動いている場合、同じ許可を通る別の経路をたどり、ホストの転送ポリシーによって同じようには統制されないかもしれません。レビューのメモを書く前に、どちらがどちらかを記録してください。

アクセスを「リセット」するために Docker のテーブルやメッシュクライアントのルールを消去しないでください。どちらの製品も独自のポリシー統合を導入しており、それを消すと、評価を求められた制御を迂回しながら動作しているように見えるホストができます。ルールが間違って見えるなら、それを読み、そのルールだけを変更してください。ルールが何をするのか説明できないなら、それが所見であり、削除する理由ではありません。

所見をシステム自身の言葉で書く

重要なのは、レビューのテンプレートにある区別ではなく、製品が実際に強制する区別です：ホストのエンドポイントに到達する許可、ルーティングされたプライベートリソースに到達する許可、アプリケーションを使う許可。ポートを公開しても、これらの三つの判断はそのままの場所に残り、それらを一つとして扱うレビュアーは誤った範囲を承認します。

ホストのアドレス、公開されたポート、コンテナの宛先、ピアの許可を同じ文に書いてください。その文は他の人が検証でき、だからこそ意見ではなく所見になるのです。