@@ 79行目: / 79行目: @@
 == SOCKSプロキシサーバー ==
-ここにあげたものは特に注記がなければUDPに対応している。
+ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。
 <span id="dante"></span>
@@ 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関連ライブラリでは一番メジャーか。
 クライアントもある。
@@ 180行目: / 180行目: @@
 同じくWireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。
-=== tun系 ===
-==== tun2proxy ====
-[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]
 <span id="透過socksプロキシクライアント"></span>
@@ 192行目: / 186行目: @@
 [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のレイヤで透過プロキシを行うもの。VPNと同等の動作で、基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。
+以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。
 ==== redsocks ====
@@ 199行目: / 195行目: @@
 &#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行目: / 204行目: @@
 [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>
@@ 213行目: / 209行目: @@
 [https://www.proxifier.com/ https&#58;//www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。
+<span id="vpntun"></span>
+== VPN(tun) ==
+上記と似ているが、VPNとして動作するもの。プロセスが特定しづらい場合・特定のIPアドレス範囲だけで十分な場合などに効果を発揮する。
+以下は特筆しない限りUDP Associateに対応。もちろん、pingなどは通らない。
+==== tun2proxy ====
+[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]
+Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。
+==== hev&#45;socks5&#45;tunnel ====
+[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]
+hev&#45;socks5&#45;tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。
 == ライブラリ関数ハック系 ==
@@ 272行目: / 287行目: @@
 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関連の話題 ==
+<span id="natが介在する場合などのudp-associateの動作"></span>
+==== NATが介在する場合などのUDP Associateの動作 ====
+OpenSSHの項目でも関連することを述べたが、UDP&#45;over&#45;TCPの性能劣化を避けるため、UDP Associateは「サーバー側がクライアント側に対してUDP通信で使うための中継ポートを通知する」という動作を伴う。この際、ネットワーク上でクライアント側からサーバーが直接見えていればよいが、NATを介している場合、クライアントから見たときのサーバーのIPとサーバー自身から見たときのサーバーのIP（中継ポート通知に含まれるのはこれ）が異なることがあり、通信が成立しなくなってしまう（SSHのポート転送を普通に使うだけではUDP Associateが使えないのも直接にはこれが原因）。
+ただし、[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]にも書いた通り、Proxifyreやhev&#45;socks5&#45;tproxyなどは中継ポート通知のIP部分を無視するため、ポート番号が変わらないNATであれば問題なく動作する（redsocksはダメ）。
 <span id="socks5によるドメイン解決"></span>
@@ 280行目: / 378行目: @@
 SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。
-Proxifyreやredsocksを普通に使う場合、TCP/UDPレイヤでのプロキシとなるので、この機能が使われることはない（[https://turgenev.hatenablog.com/entry/2025/03/25/171736 squidで透過プロキシ（intercept, tproxy）を動かす - 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共に）ドメイン解決は基本的にプロキシサーバー側で行われる。
@@ 297行目: / 395行目: @@
 ** 新しめの包括的なバグレポート [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>
@@ 312行目: / 410行目: @@
 * txthinking/socks5…[https://github.com/txthinking/socks5/issues/15 https://github.com/txthinking/socks5/issues/15]で修正済み。
 * things&#45;go/go&#45;socks5…これはサーバー側。[https://github.com/things-go/go-socks5/issues/29 https://github.com/things-go/go-socks5/issues/29]の通り、クライアントが必ずアドレス・ポートを通知してくれる（ゼロ埋めしない）と仮定していたが、修正された。
-<span id="vpntun"></span>
-== VPN(tun) ==
-<span id="tun2proxy-1"></span>
-==== tun2proxy ====
-[https://github.com/tun2proxy/tun2proxy https://github.com/tun2proxy/tun2proxy]
-Rust製。starは700ほど。SOCKSとHTTPをtunにしてくれる。
-==== hev&#45;socks5&#45;tunnel ====
-[https://github.com/heiher/hev-socks5-tunnel https://github.com/heiher/hev-socks5-tunnel]
-hev&#45;socks5&#45;tproxyの作者による。Androidアプリの[https://github.com/heiher/sockstun https://github.com/heiher/sockstun]もここから。
 == プロキシプロトコル間の変換 ==
@@ 418行目: / 500行目: @@
 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}}

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