外向き制限・古い trust store のホスト (オフライン range 更新)
unmask は検証済みクローラーの IP range (Googlebot、bingbot、GPTBot、ChatGPT-User、
ClaudeBot、Amazonbot など) を HTTPS の feed で最新に保ちます。この取得ができないホストが
2 種類あります: trust store が ISRG Root X1 より古いマシン
(非常に古い企業向けディストリビューション。ログに
x509: certificate signed by unknown authority が出て、
unmask doctor が crawler IP ranges を警告します) と、
外向き HTTPS 自体が許可されていないマシンです。このページは両方の運用手順です。
同期が一切なくても動くもの
すべてのリリースは全ベンダー range の組込スナップショットを binary 内に同梱しており、
リリースパイプラインは古いスナップショットの出荷を拒否します。つまり通常のペースで
アップグレードしているだけでも range はそれなりに新しく保たれます。とはいえ鮮度は重要です:
ベンダーは range を追加しますし、アドレスでクローラーを検証する機能は、手元のデータが
30 日より古くなると (doctor の警告付きで) 自動的に停止します。
オフライン更新 (0.1.33+)
# 1) unmask.sh に到達できる任意のマシンで: curl -O https://unmask.sh/dl/feed/iprange/bypass-iprange-all.json # 2) 制限ホストへ転送 (scp でも USB でも) scp bypass-iprange-all.json restricted-host:/tmp/ # 3) 取り込み -- ネットワーク不要、一時 HTTP サーバも不要: unmask update-iprange -file /tmp/bypass-iprange-all.json # 4) native モードのみ: 再レンダリングして nginx を reload unmask render-nginx && nginx -t && nginx -s reload
稼働中の daemon は更新されたファイルを数秒以内に自動検知します (0.1.33+)。forward-auth 構成なら手順 3 まで、native 構成は nginx の map に反映するための render + reload まで、で完了です。
render-nginx の前に service unmask restart
(または systemctl restart unmask) を実行してください。さもないと次に設定を
保存した瞬間、古い range が静かに焼き直されます (これらのバージョンには -file
も無いので、代わりに loopback 限定の一時 HTTP サーバを立てて
update-iprange -url を向けます)。
自動化
# 両側に到達できる踏み台で、例えば週次:
curl -sO https://unmask.sh/dl/feed/iprange/bypass-iprange-all.json \
&& scp -q bypass-iprange-all.json restricted-host:/tmp/ \
&& ssh restricted-host 'unmask update-iprange -file /tmp/bypass-iprange-all.json \
&& unmask render-nginx && nginx -t && nginx -s reload'
feed は署名されています (0.1.33+)
すべての feed には分離署名 (bypass-iprange-all.json.sig、ed25519) が併置されます。
署名は配信ホストとは別の署名ホストで生成され、feed を配る側は鍵を一切持ちません。daemon は
署名があれば自動で検証し、一致しない文書を拒否します。転送してきたファイルは取り込み前に
手元で検証できます:
unmask sign-feed -verify /tmp/bypass-iprange-all.json # 隣に .sig が必要
これが insecure-transport の逃げ道を提供できる理由でもあります:
sync_insecure_tls: true (または update-iprange -insecure-tls) を
指定するとトランスポートの証明書検証は免除されますが、その代わり署名が必須に
なります — 無署名や署名不一致の文書は即座に拒否されます。切った検証の代わりを内容の検証が
務める、という交換です。可能なら trust store 自体の修正が今でも最善です。
「証明書検証をスキップ」スイッチが無い理由
この feed が運ぶ range は信頼データです: そこに載ったアドレスは challenge を 完全にバイパスします。検証なしの接続で取得すると、経路上の第三者が自分のアドレスをあなたの バイパスリストに注入できてしまいます — 絶対に乗っ取られてはいけない仕組みそのものの乗っ取りです。 そのため unmask はこの feed に insecure-TLS の切替を用意していません。サポートする解は上記の オフライン取り込み、または trust store 自体の修正 (ISRG Root X1 ルート証明書をシステム CA バンドルへ 追加する方法。そのホストの他のモダンな TLS 接続も同時に直ります) です。