Web スクレイピング向け外向きアクセス秘匿設計

article technology medium #network#privacy#vpn#tor#web-scraping#security
Created: 2026-05-02 Updated:

Web scraping で「対象サイトに自宅 IP を見せない」「LAN 管理側から個別宛先を見えにくくする」 2 要件に対し、 Full Tunnel + 出口分離を中核に、補助技術 (DoH/ECH/ODoH) と Tor 簡略構成も含めた設計案。

Web スクレイピング向け外向きアクセス秘匿設計

Web scraping で 2 つの秘匿要件 — (a) 対象サイトに自宅・社内回線のグローバル IP を見せない、 (b) 内部 LAN の管理レイヤーから個別接続先を見えにくくする — を同時に満たすには、 単体 Proxy ではなく常時有効な Full Tunnel 型の出口分離 を選ぶのが適している。中核は Full Tunnel + DNS の トンネル内収容、補助は ECH / ODoH、簡略案として Tor exit を使う構成も成立する。これは「完全匿名」ではなく「送信元を別出口にし、 LAN 側からは 1 本の暗号化トンネル先だけが見える」状態への寄せ込みである。

推奨アーキテクチャ — 構成 A と B

構成 A: ローカル端末 + Full Tunnel + 外部出口

《専用スクレイピング端末》
  → 《常時有効の Full Tunnel》
  → 《外部 Exit Node / VPS / 管理対象 Egress Gateway》
  → 《対象サイト》

要素:

  • スクレイピング専用の端末 / VM / 専用コンテナで分離
  • 専用 VLAN またはセグメントに配置
  • 外向きは常時有効 Full Tunnel に固定 (WireGuard 0.0.0.0/0 + ::/0、 Cloudflare WARP の MASQUE / WireGuard、 Tailscale Exit Node)
  • DNS は DoH / DoT またはトンネル内 resolver に固定
  • トンネル断時は直接インターネットへ出ないよう default-deny の egress 制御

構成 B: ローカル制御 + Remote Runner

《ローカル制御端末》
  → 《1 本の暗号化管理チャネル》
  → 《外部の Remote Runner》
  → 《対象サイト》

実際のスクレイピング処理を外部実行ノードで動かし、ローカルはジョブ投入・監視・成果物回収のみ。 LAN 側からは Remote Runner との管理チャネルだけが見える。要件 b に対しては構成 A よりさらに分離しやすい。

最初は構成 A で十分。対象が多くブラウザ自動化や大量取得を行うなら、将来は構成 B が運用しやすい。

何が誰に見えるか — Visibility 分析

構成 A

観測者見えるもの
対象サイト出口ノード側のグローバル IP、 TLS 指紋、 User-Agent、 Cookie、アクセス頻度 (IP 隠蔽だけではブラウザ指紋とセッション相関は別途対策必要)
内部 LAN ルーターVPN / Exit Node / WARP の接続先 IP、通信量、時間帯、接続継続時間 (個別宛先ドメインや内容は通常見えにくい)
出口ノード運用者多くの場合、実際の接続先ドメインまたは IP (可視性が「LAN 管理者」から「出口運用者」に移動)

構成 B

観測者見えるもの
対象サイトRemote Runner 側のグローバル IP
内部 LAN ルーターRemote Runner との管理用暗号化チャネル、通信量、時刻 (各対象サイトへの直接通信は通常発生しない)
Remote Runner 運用側実際のアクセス先、実行ログ、取得データ

なぜ単体 Proxy では足りないか

HTTP / SOCKS Proxy 単体でも対象サイトから見える IP は置き換えられる。しかし要件 b には弱い:

  1. DNS がローカル側から外へ漏れる 設計だと、ルーター側に宛先の痕跡が残る
  2. 一部のアプリ・ライブラリが Proxy を経由しない と直接接続が混ざる
  3. トンネル断時に直結へフォールバック すると送信元 IP が露出する

「Proxy を各アプリへ個別設定」より「OS / 実行環境レベルで Full Tunnel に閉じ込める」方が要件に合う。

最初の推奨実装

最もバランスの良い初期設計:

  • ローカルに スクレイピング専用 VM を 1 つ作る
  • VM の外向きは 常時有効の Full Tunnel だけ
  • 出口は 自前 VPS または 信頼できる VPN / Exit Node サービス
  • DNS はトンネル内 resolver へ固定
  • トンネル断時は VM からの外向き通信を停止
  • 日常ブラウジングや個人アカウントと混ぜない

これで対象サイトからはローカル回線 IP が見えず、内部 LAN 側からは対象サイト群ではなく 1 つのトンネル先が主に見える。

将来的に秘匿性を上げる場合は構成 B に移行 (実行を Remote Runner に集約、ローカルは制御のみ)。

補助技術の位置づけ

技術役割位置づけ
DoH / DoTDNS 問い合わせを暗号化DNS をトンネル外へ平文で出さない基本部品
ECH (Encrypted Client Hello、 RFC 9849)TLS 初期ハンドシェイクのホスト名露出を減らすクライアント・サーバ双方の対応必要、補助要素
ODoH (RFC 9230)DNS resolver にクライアント IP と DNS 内容を同時に見せないDNS プライバシーの補助、 Web アクセス全体は隠せない

中核はあくまで Full Tunnel + DNS のトンネル内収容。 ECH / ODoH は「あると良い」補助。

できること / できないこと

できること

  • 対象サイトから自分の元回線 IP を見えなくする
  • 内部 LAN ルーター側から個別宛先を見えにくくする
  • DNS の平文露出を減らす
  • 実行環境を業務用・日常用から分離

できないこと

  • 出口ノード運用者に対する完全秘匿
  • 対象サイト側のブラウザ指紋、 Cookie、アカウント相関の自動消去
  • 端末そのものを管理している主体に対する完全秘匿

最後の点は重要。ネットワーク経路だけ秘匿しても、端末上のエージェント、ブラウザ設定、 EDR、 MDM、証明書注入型検査などで観測されうる。本設計は「ルーター・回線側からの見え方を弱める」ためのもので、「端末管理者からの不可視化」を保証しない。

採用順序

  1. 専用 VM または専用端末を分ける
  2. Full Tunnel を常時有効化
  3. DNS をトンネル内へ固定
  4. トンネル断時の直結を止める
  5. 必要なら外部 Remote Runner へ移行
  6. 専用出口を省きたい場合は Tor 利用を別案として検討
  7. 補助的に ECH / ODoH を使う

Tor を出口として使う簡略構成

専用 tunnel server を持たない代替として Tor network を出口に使う構成も成立する。通常の Web サイト対象なら:

《Remote machine / script》→《local Tor client / SOCKS proxy》
  →《Tor entry guard》→《middle relay》→《exit relay》→《対象サイト》

対象サイトからは exit relay の IP が見える。 Web サイト自体を Tor 内に置く場合は別途 .onion Onion Service を用意する。

LAN 内プライバシーへの効き方

Tor client をどこで動かすかで LAN からの見え方が変わる:

  1. LAN 内 local machine で Tor client → LAN 管理者・ ISP には対象 Web サイト名は見えにくいが、 Tor network への接続 自体・通信量・時刻・ entry guard への接続は見える
  2. LAN 外の remote machine / VPS で Tor client → LAN から見えるのは local → remote の SSH / HTTPS 管理チャネルだけ。 Tor 利用も LAN からは見えにくい (推奨)
  3. 同じ LAN 内の別 machine で Tor client → LAN プライバシー観点では効果限定的

「Tor 利用自体も LAN から見えにくくしたい」なら 2 の構成 (LAN 外の remote machine で Tor + crawler) が適切。

Full Tunnel 構成との trade-off

観点Full Tunnel + 自前 ExitTor exit
出口 IP 制御自分で管理自分の管理下にない
DNS / routing / log / rate limit自分で制御Tor 任せ
速度・安定性安定VPN/VPS より落ちやすい
対象サイト側の block 可能性低いexit relay が block されることあり
exit relay 運用者の観測—HTTPS でない通信内容は観測しうる
専用 tunnel server必要不要

Tor は「自分の hosted website への secure connection test」「少量取得経路テスト」向き。安定した定期 crawler や出口 IP / ログを管理したい用途では自前 VPS / Exit Node / Remote Runner の方が運用しやすい。

Crawler / Fetcher での実装方針

script から Tor を使う場合は Tor client の SOCKS proxy へ明示的に流すのが基本。 torsocks で多くのアプリを Tor 経由化でき、 DNS 安全化と TCP 以外 traffic の拒否ができる。

実装上の重要な方針:

  • 対象は自分の hosted website の allowlist のみ に限定
  • https:// のみ許可
  • DNS を local LAN resolver に漏らさない
  • Tor 経由でない direct connection を firewall または network namespace で停止
  • request rate を低くする
  • request id header を付け、 Web server log と local log を照合可能に
  • Tor exit relay から来ていることを server log で確認

最初の milestone は 「10 URL 程度を Tor 経由で取得し、対象 Web サイト側の access log で Tor exit から来ていることを確認」 くらいが適切。

最終提案

要件に対する最初の最適設計:

  • ローカルの専用 VM
  • VM に対する常時有効の Full Tunnel
  • 出口は自前 VPS か信頼できる Exit Node
  • DNS はトンネル内
  • 取得処理はその VM の中だけで実行

これで (a) 対象サイトから見える IP は外部出口側へ置き換わり、 (b) 内部 LAN 管理レイヤーからは各対象サイトではなく主としてトンネル先だけが見える。

より強く分離したい段階で 「ローカルは制御のみ、実処理は Remote Runner」 に移行。

専用 tunnel server を省く場合は Tor exit を使う簡略案 も成立。ただし local LAN 内で Tor client を動かすと LAN 側から Tor network への接続は見えうるため、「Tor 利用自体も LAN から見えにくくしたい」なら LAN 外の remote machine 上で Tor client + crawler を動かす構成にする。

参考資料

  • WireGuard 公式 (wireguard.com)
  • Cloudflare WARP / WARP modes / 1.1.1.1 DNS-over-TLS
  • Tailscale Exit Nodes
  • RFC 9849 Encrypted Client Hello
  • RFC 9230 Oblivious DNS over HTTPS
  • Tor Project (Tor Browser, Onion Services, Torsocks)

Backlinks

Local graph