セルフホスティングは運用者の役割をあなたに与える:ソフトウェア、設定、更新スケジュール、そして自分のサービスが何を記録するかをあなたが選ぶ。それがしないのは、接続から他の関係者を外すことだ。あなたのアクセス網は今もパケットを運び、ホスティング事業者は今もマシンを動かし、リゾルバは今も問い合わせに答え、宛先は今もリクエストを受け取る。そのうちのどれを実際に変えたのかを知ることが、この演習のすべてだ。

ステップ 1:関係者を洗い出す

実際の配備にいる関係者をすべて列挙する。自分の端末、接続する網、VPN ホスト、DNS リゾルバ、そして宛先のサービスだ。それぞれについて、何を観察でき、どの設定をあなたが制御しているのかを書き留める。

その表は匿名性に関するどんな主張よりも役に立つ。制御が実際どこで変わったのかを示すからだ。あなたはホストの設定とログを制御している。アクセス網があなたの接続をどう見るかは制御できず、宛先があなたのアカウントについて何を記録するかも制御できない。

家庭の端点では、覆われた通信は通常その家のアクセス回線から出ていく。宛先が見る出口アドレスはその世帯のアドレスであり、これはトポロジーの事実であってソフトウェアの欠陥ではない。変えたかったのがそのアドレスなら、家庭のサーバーではできない。別の場所に出口が必要だ。

ステップ 2:得たものを書き出す

配備済みの設定を確認し、どの端末が参加できるかを決め、診断の方針を定め、選んだ記録を残すことができる。それらは維持してこそ本当の制御であり、セルフホスティングの正直な理由でもある。

それらには条件もある。使われていない既定値と検証していないバックアップは、プロトコルが提供する性質ではなく意図にすぎない。制御はそれを証明するテストと一緒に書く。そうでなければ数えられない。

ステップ 3:保守リストを受け入れる

リストは短く容赦がない:管理者アカウントを守り、サーバーの鍵を守り、クライアントの身元を発行して失効させ、バックアップを保ち、失った端末を外し、失敗したトンネルに依存しない復旧経路を残すことだ。

失効には独自の行が必要だ。設定から外したが一度も失効させていない端末は、まだ有効な資格情報を持っており、その差は誰かが使ったときに初めて現れる。古い材料で接続を試みて、外したことを確かめよう。

バックアップにも同じ扱いが要る。予備ホストにひとつ復元する、そして同じ身元でトンネルが上がることを確認する。一度も復元していないバックアップはファイルであり、復旧計画ではない。

ステップ 4:匿名という前提を手放す

サーバーを動かしてもブラウザーが匿名になるわけではない。サイトは今もアカウント情報とクッキーを受け取り、HTTPS はトンネルとは関係なく自分の経路でアプリのデータを守る。

さらに微妙な効果もある。あなただけが使うアドレスは、あなたの利用に結びついた安定した信号になりうる。商用の出口は見知らぬ人と共有され、それは一方でプライバシーに悪く、他方で良い。自分のアドレスは唯一であり、その取引を逆転させる。

目標が相関しにくくすることなら、セルフホスティングは難しくするどころか容易にしうる。一晩かける前に、本当に欲しい性質はどれかを決めよう。唯一性はコストであって機能ではなく、セルフホスティングの記事の大半には出てこない。ステップ 1 の関係者表に書き込めば、その取引が見えるようになる。

ステップ 5:明示した理由で選ぶ

自分の網への私的なアクセス、設定の制御、特定のルーティング要件、あるいは事業者の方針からの独立は、どれも良い理由だ。当てはまるものを書き、それが機能することを示すテストを設計する。

次に退屈な部分を確かめる。ホストは更新されているか、古い鍵は消えたか、保持は記録どおりか、障害のあとにサービスを復旧できるか。この四つの答えは、プロトコルの名前よりはるかに良く信頼モデルを語る。

ステップ 6:出口を計画する

ホストからどう移るかを前もって決める。設定がどこにあり、クライアントのプロファイルをどう再発行し、残した記録がどうなるか。出口の計画がないセルフホストのサービスは、外せない依存になる。

AWS の共有責任モデル は AWS の外でも役に立つひな形であり、同じ問いを迫るからだ。どの層があなたのもので、どの層が他人のものか。ステップ 1 の関係者ごとに答えれば、信頼モデルは標語ではなくなる。

関連記事