「HTTP・SOCKS・透過プロキシ・UDP」の版間の差分

← 古い編集

ビジュアルウィキテキスト

@@ 124行目: / 124行目: @@
 [https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]
-starは700前後。hysteriaやtrojan&#45;goなどいくつかの大きなプロジェクトで使われており、go製のSOCKS5関連ライブラリでは一番メジャーか。
+starは700前後。hysteriaやtrojan&#45;goなどいくつかの大きなプロジェクトで使われており、現在もメンテされているgo製のSOCKS5関連ライブラリでは一番メジャーか。
 クライアントもある。
@@ 192行目: / 192行目: @@
 [https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。
-バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（最低でもCAP_NET_ADMIN）が必要。
+バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。
+以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。
 ==== redsocks ====
@@ 199行目: / 201行目: @@
 &#42;nix対応。BSD系で動かすことができたという話は[https://turgenev.hatenablog.com/entry/2024/06/10/134017 FreeBSD/OpenBSD/NetBSDで透過プロキシのredsocksを動かしてみる - turgenev’s blog]に書いた。
+==== hev&#45;socks5&#45;tproxy ====
+[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。
 <span id="proxifyre"></span>
@@ 204行目: / 210行目: @@
 [https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。
-==== hev&#45;socks5&#45;tproxy ====
-[https://github.com/heiher/hev-socks5-tproxy https://github.com/heiher/hev-socks5-tproxy] Linux向け。redsocksより若干知名度は下がるものの、きちんとメンテされている。
 <span id="proxifier"></span>
@@ 272行目: / 274行目: @@
 Squidには透過プロキシ機能があるが、redsocksなどとは動作の細かい部分が異なる。[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - turgenev’s blog]に書いた。
+<span id="localhostlanなどへのアクセス制限"></span>
+== localhost・LANなどへのアクセス制限 ==
+典型的な設定例として、localhostやプライベートIPへのアクセスを制限する設定をSquid・Dante・3proxyそれぞれに関して紹介しておく。
+==== squid ====
+<code>to_localhost</code>はbuilt&#45;inとして定義されていて、<code>localnet</code>（&#61;srcがlocalnet）についてもUbuntuパッケージで提供されるsquid.confには入っているのだが、localnetがdstであるものとなるとACLが定義されていない。
+<code>deny to_localhost</code>と<code>deny to_linklocal</code>は定義済みという前提で、以下のように書くとよい。
+<syntaxhighlight lang="go">acl to_localnet dst 0.0.0.1-0.255.255.255
+acl to_localnet dst 10.0.0.0/8
+acl to_localnet dst 100.64.0.0/10
+acl to_localnet dst 172.16.0.0/12
+acl to_localnet dst 192.168.0.0/16
+acl to_localnet dst fc00::/7
+http_access deny to_localnet</syntaxhighlight>
+<span id="3proxy-1"></span>
+==== 3proxy ====
+IPv4のみ対応。
+<syntaxhighlight lang="go">deny * * 127.0.0.0/8,0.0.0.1-0.255.255.255,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16 * * * *
+allow *</syntaxhighlight>
+<span id="dante-1"></span>
+==== dante ====
+IPv4のみ対応。squid・3proxyの場合と違って0.0.0.0もblockしてしまっているが、そもそも使わないので問題ないはず。
+<syntaxhighlight lang="go">client pass {
+  from: 0/0  to: 0/0
+}
+socks block {
+    from: 0/0 to: 127.0.0.0/8 # localhost
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 0.0.0.0/8 # RFC 1122 "this" network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 10.0.0.0/8        # RFC 1918 local private network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 100.64.0.0/10     # RFC 6598 shared address space (CGN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 169.254.0.0/16    # RFC 3927 link-local (directly plugged) machines
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 172.16.0.0/12     # RFC 1918 local private network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks block {
+    from: 0/0 to: 192.168.0.0/16        # RFC 1918 local private network (LAN)
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}
+socks pass {
+    from: 0/0 to: 0.0.0.0/0
+    protocol: tcp udp
+    command: bind connect udpassociate bindreply udpreply
+}</syntaxhighlight>
 <span id="socks関連の話題"></span>
 == SOCKS関連の話題 ==
@@ 287行目: / 365行目: @@
 SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。
-Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。
+透過SOCKSプロキシの場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]）（さらに、繰り返しになるが付け加えておくと、普通にセットアップした場合はDNSにプロキシは使われない）。一方、HTTPのレイヤで動作するWebブラウザでは、この機能が使われる場合がある。2018年時点での[https://github.com/FelisCatus/SwitchyOmega/issues/1379 https://github.com/FelisCatus/SwitchyOmega/issues/1379]によれば、Chromeでは必ずSOCKS5サーバー側でドメイン解決が行われる（これは[https://github.com/FelisCatus/SwitchyOmega/wiki/FAQ FAQ]にも書いてある）一方、Firefoxではそうでなかったようである。現在のFirefoxでは「SOCKS v5 を使用するときは DNS もプロキシーを使用する（Proxy DNS when using SOCKS v5）」（v4についても同様のオプションがあるが、SOCKS4aではないSOCKS4でどうなるかは未検証）というオプションがあってデフォルトで有効になっているため、やはり基本的にはSOCKSサーバー側でドメイン解決が行われる。AndroidのFirefox（この設定項目がない）にProxy SwitchyOmegaを入れた場合もそのように動作した。
 なお、HTTPプロキシについても、ブラウザで普通に使う分には、（HTTP/HTTPS共に）ドメイン解決は基本的にプロキシサーバー側で行われる。
@@ 304行目: / 382行目: @@
 ** 新しめの包括的なバグレポート [https://bugzilla.mozilla.org/show_bug.cgi?id=1947229 https&#58;//bugzilla.mozilla.org/show_bug.cgi?id&#61;1947229]
-従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことになる。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。
+従って、ブラウザのWebRTCをプロキシさせたい場合はVPNや透過プロキシなどroot/管理者権限が必要な手法を使うことが多くなるだろう。ただしLinux+Firefoxの場合はsocksifyが使えるのでrootが無くても可能。
 <span id="udp-associateリクエストのdstaddrとdstport"></span>
@@ 425行目: / 503行目: @@
 udp&#45;reverse&#45;tunnelしてHysteria？かな
+== その他の話題 ==
+==== ドメインごとにプロキシを変更できるブラウザ拡張のiframeにおける動作 ====
+FoxyProxyやSwitchyOmega(ZeroOmega)など、ドメインごとに自動でプロキシを切り替えてくれるブラウザ拡張はChromium系にもFirefoxにもいくつかあるが、これらはあくまでコンテンツのオリジンを元にプロキシを適用しており、ブラウザのタブを見ているわけではない。つまり、foo.comのページを開いていて、そこにbar.comのコンテンツがiframeで埋め込まれている場合、iframeの内部は、bar.comに対して使用するものと指定されたプロキシを使用して処理される。
+一応、[https://superuser.com/questions/250172/disable-enable-the-proxy-on-a-tab-by-tab-basis-in-firefox Disable/enable the proxy on a tab by tab basis in Firefox]によると、Firefoxのcontainer&#45;proxyというのがこれに近い機能を実質的に実現してくれるらしい。
 [[Category:IT]]{{#seo:|title={{FULLPAGENAME}} - Turgenev's Wiki}}