N2Nオーバーレイはプロキシではない：2つの接続を描き分ける

Firefox は 127.0.0.1:8000 を指し、N2N のエッジは起動していて、ピアはオーバーレイアドレスへの ping に応答しているのに、ブラウザーはプロキシが接続を拒否したと報告し続けます。この連鎖のどこにも矛盾はありません。オーバーレイはホストにプライベートネットワーク上の到達可能なアドレスを与えますが、プロキシプロトコルを話すプロセスを作るわけではありません。ブラウザーはピアへの経路を求めていません。ローカルのリスナーを求めています。

ここでは二つの接続が混同されており、別々に描けば混乱のほとんどは一分で解消します。

接続は二つ、一つではない

一つ目の接続は、ブラウザーから loopback ポートで待ち受けている何かへ向かいます。これはローカルソケットであり、それを所有するものがなければ、一つのパケットも N2N に届く前に接続は拒否されます。二つ目は、プロキシのプロセスから取得先のオリジンへ向かいます。その経路はプロキシホストのルーティングテーブルが選び、通常のアップリンク、別のトンネル、あるいはオーバーレイとは無関係なポリシールートである可能性があります。

ピアに ping が通ることは、オーバーレイがエッジアドレス間でパケットを届けられる証拠です。ポート 8000 のリスナーについては何も証明せず、そのホストがオリジンに到達できるかどうかも証明しません。別々の障害には、別々の修正が必要です。

リスナーはどこに置くべきか

127.0.0.1 にバインドされたプロキシは意図的にローカルであり、実行されているマシンからの接続しか受け付けません。個人用プロキシには正しい既定値ですが、オーバーレイ経由で共有するには間違った形です。オーバーレイのピアにサービスを提供するには、オーバーレイインターフェース上のバインドアドレスか、loopback 接続を終端して転送するコンポーネントが必要です。いずれにせよ、共有ネットワーク上のオープンプロキシは招待状なので、どのオーバーレイ送信元が利用できるかを明示的なポリシーで決めるべきです。

実際のバインドは設定ファイルではなくソケット一覧で確認してください。オーバーレイが起動する前に起動したデーモンは、もはや存在しないアドレスにバインドされたままかもしれません。

localhost はピアではない

ブラウザーのプロキシ欄で localhost はブラウザー自身のマシンを指します。エッジでもスーパーノードでも、トンネルの遠端のホストでもありません。プロキシが別のピアで動いているなら、そのピアの到達可能なオーバーレイアドレスとポートを欄に入れ、リスナーがあなたのエッジアドレスからの接続を受け付けることを確認してください。

スーパーノードはエッジ同士が見つかるのを助けるもので、プロキシサービスではありません。スーパーノードのアドレスをプロキシの端点として扱えば、同じ拒否に余分な混乱の一段が加わるだけです。

ルートはハンドシェイクを実行できない

アドレスが正しくても、ルーティングはプロキシではありません。HTTP プロキシの接続は CONNECT 要求か絶対形式のリクエスト行で始まり、SOCKS プロキシはバージョンとメソッドの交渉で始まります。ルーターやオーバーレイはバイトを転送するだけで、そのメッセージを解析したり、代わりに次の接続を開いたりはしません。だからこそ ping と SSH で機能するルートがブラウザーのプロキシでは失敗し得ますが、ブラウザーに必要なのは協調するプロセスであり、単なる到達性ではありません。

目的が単にピア上のサービスに到達することなら、プロキシ設定を外し、そのサービスのオーバーレイアドレスを直接使ってください。

境界を順番に確認する

オーバーレイアドレスが応答することを確認し、次に設定したポートにリスナーがあることを確認して、そのバインドアドレスを記録します。制御された要求を一つ行ってプロキシのログを読み、障害がリスナー側か後続の取得側かを判断します。最後に、プロキシホストのルートとオリジン向けの DNS ポリシーを確認します。

N2N プロジェクトはエッジとスーパーノードをオーバーレイの構成要素として文書化しています。エッジをアプリケーションプロキシに変えるものではなく、誰も起動していないプロトコルハンドラーを追加するルーティング設定もありません。