HTTP・SOCKS・透過プロキシ・UDPのソースを表示

SOCKS・透過プロキシ・UDP&#45;over&#45;TCPなどを中心に、ネットワークの変更に使えるプロキシ関連の各種技術を雑にまとめた。

近年はGo製のものが多い。また検閲に対抗するためか、中国系（中国語でissueが投稿されているなど）のものが多い。gost, go&#45;proxy, hysteria, txthinking/socks5, things&#45;go/socks5などはいずれもその2つに当てはまる。たまにロシア系もある。

<span id="大規模多機能系"></span>
== 大規模・多機能系 ==

以下のものは機能が多くて分類できないのでソフトウェアごとに紹介する。

==== gost ====

GO Simple Tunnelの略らしい。安定版のv2系（[https://github.com/ginuerzh/gost https://github.com/ginuerzh/gost], [https://v2.gost.run/ https&#58;//v2.gost.run/]）と開発中のv3系（[https://github.com/go-gost https&#58;//github.com/go&#45;gost], [https://gost.run/ https&#58;//gost.run/]）で大きく仕様が異なる。v3は開発中と言いつつv2系のページを見るとかなりv3推しに見える。

starはバージョン2が16k、バージョン3が5kほど。

イメージとしては、TCPによるシンプルなトンネルプロトコル（これがgost）（暗号化無し）と他の大量のプロトコルの間の相互変換を実装しているような感じと思われる。

非常に多機能で、このページで紹介している多くソフトウェアの基本機能をカバーしていると言ってもいいくらい。UDP&#45;over&#45;TCP系は基本これ1つで十分。機能の豊富さに比して明らかにドキュメントが不足しており、エラーメッセージも親切ではない（起動時ではなく実際にパケットが来てからエラーが出るような感じ）。

<ul>
<li><p>connectorとしてはsocks5も用意されているが、相手がgostでない限りUDP Associateは動かない模様。具体的には</p>
<syntaxhighlight lang="javascript">gost -L "auto://:8480?udp=true&relay=udp" -F socks5://192.168.1.13:3129</syntaxhighlight>
<p>などとしても、 05f3 0001 0000 0000 0000みたいなよくわからんリクエストが送られてしまう。このf3のところは下記の独自拡張っぽい。</p>
<p>[https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17 https://github.com/go-gost/x/blob/04d1587a77964636d8e50f5cce475ee8621bece7/internal/util/socks/socks.go#L17]</p></li></ul>

==== go&#45;proxy ====

[https://github.com/snail007/goproxy https://github.com/snail007/goproxy]

これも見た感じgostと同じくらいか一部では上回るくらい多機能に見えるが、この雰囲気にしては珍しく有料版があり、無料版だと一部機能が制限されているようなので、あまり使ったことはない。

<span id="gfw回避"></span>
== GFW回避 ==

中国政府の検閲システムであるグレート・ファイアウォール（GFW）に対抗することを主な目的とするもの。

==== shadowsocks ====

SOCKSに暗号化を施した独自プロトコルで、いくつかの実装がある。[https://github.com/shadowsocks/shadowsocks-rust https://github.com/shadowsocks/shadowsocks-rust]などが主流とみられる。

VPN以外のGFW回避ソフトウェアだとおそらくもっともメジャー。

サーバーとクライアントに分かれていて、クライアント側では透過プロキシにも対応している。

<span id="hysteria"></span>
==== Hysteria ====

通信路がHTTP/3に偽装した形で暗号化される。shadowsocksの次世代に位置付けられるソフトウェアのように見える。

SOCKS5サーバー部分にはtxthinking/socks5を使っている。

<span id="sni-proxy"></span>
== SNI Proxy ==

HTTP・HTTPSのリバースプロキシで、host（HTTPの場合）あるいはsni（HTTPSの場合）に基づいてアクセスを振り分けるものをSNI Proxyと呼ぶことがあるらしい。<strong>Nginx</strong>や<strong>HAProxy</strong>のような汎用のプロキシサーバーでも使える機能だが、これを専門とするソフトウェアもある。

* こんな使い方もある（自分の記事）→ [https://turgenev.hatenablog.com/entry/2025/03/21/020550 【Android】NextDNSをアプリごとに有効無効切り替え+Tailscale経由の自宅鯖を使ってControl D風のトラフィック転送 - turgenev’s blog]

<span id="dlundquistsniproxy"></span>
==== dlundquist/sniproxy ====

[https://github.com/dlundquist/sniproxy https://github.com/dlundquist/sniproxy]　starは2.6kほど。2024年に更新あり。非推奨である理由（HTTP/2とかQUICでうまくいかないとか）も書いてある。

==== tcpproxy ====

[https://github.com/inetaf/tcpproxy https://github.com/inetaf/tcpproxy]　starは1.3kほど。ライブラリ用途がメインか。

<span id="ameshkovsniproxy"></span>
==== ameshkov/sniproxy ====

[https://github.com/ameshkov/sniproxy https://github.com/ameshkov/sniproxy]　starは70ほど。上流のSOCKS5, HTTPプロキシへの転送機能がある。

<span id="puxxustcsniproxy"></span>
==== puxxustc/sniproxy ====

[https://github.com/puxxustc/sniproxy https://github.com/puxxustc/sniproxy]　starもほぼなく更新も9年前。

<span id="socksプロキシサーバー"></span>
== SOCKSプロキシサーバー ==

ここにあげたものは特に注記がなければUDP（ただし筆者が念頭に置いているのはAssociateのみで、Bindに関してはほぼ調べていない）に対応している。

<span id="dante"></span>
==== Dante ====

[https://www.inet.no/dante/index.html Dante - A free SOCKS server]

企業（Inferno Nettverk A/S）によるオープンソースなSOCKS5実装で、有償サポートまであるらしい。見るからに古臭いHPで、メンテされているかどうか不安になるが、つい最近2024年末にもアップデートがあり、次期バージョンの計画についても記載されている。

Cで書かれていて、おそらく最も正確なSOCKS5実装だろう。コメントも親切で、リファレンス実装のような雰囲気がある。他の透過プロキシクライアントなどをテストする際はDanteでテストして動けば安心感がある。

<span id="openssh"></span>
==== OpenSSH ====

現実的に最もよく使われているSOCKSサーバーは間違いなくOpenSSHだろう。しかし、UDP&#45;over&#45;TCPの問題があるため、UDPはサポートされていない。

ssh &#45;Dでforward方向のプロキシを建てるのが有名だが、OpenSSH 7.6からは&#45;Rでreverse方向にも建てられるようになった。クライアント側が7.6以上であればよい。

* 参考&#58; [https://www.openssh.com/txt/release-7.6 OpenSSH 7.6] （<code>ssh(1)&#58; add support for reverse dynamic forwarding</code>）

==== socks&#45;with&#45;udp&#45;over&#45;ssh ====

[https://github.com/ge9/socks-with-udp-over-ssh https://github.com/ge9/socks-with-udp-over-ssh]

これ自体はSOCKS5サーバーではなく、TCP接続（あるいは任意のバイトストリーム）の上にUDP付きのSOCKS5を通すために自分が実装したツール。サーバー側とクライアント側に分かれている。しかし実装した後にgostで同じことができることに気付いた。

経緯・使い方などは[https://turgenev.hatenablog.com/entry/2024/05/12/231208 root権限のないssh上にUDPを通す方法について（ポートフォワード、SOCKS5プロキシなど） - turgenev’s blog]に書いてある。

==== 3proxy ====

[https://3proxy.ru/ 3proxy tiny free proxy server for Windows, Linux, Unix: SOCKS, HTTP, FTP proxy]

[https://github.com/3proxy/3proxy https://github.com/3proxy/3proxy]

ロシア系。SOCKS・HTTP・POP3・SMTPなどいくつかのプロキシを含む。エラーメッセージなどがかなり不親切だが、結構多機能で、ちゃんと動くソフト。<code>3proxy</code>というメインの実行ファイルとあわせて、各プロキシに対応した<code>socks</code>や<code>proxy</code>といった検索性の低い名前の実行ファイルがいくつか含まれているちょっと謎の構成。

==== fast&#45;socks5 ====

[https://github.com/dizda/fast-socks5 https://github.com/dizda/fast-socks5] Rust製では最も有名か。starは500ほど。使ったことなし

<span id="txthinkingsocks5"></span>
==== txthinking/socks5 ====

[https://github.com/txthinking/socks5 https://github.com/txthinking/socks5]

starは700前後。hysteriaやtrojan&#45;goなどいくつかの大きなプロジェクトで使われており、現在もメンテされているgo製のSOCKS5関連ライブラリでは一番メジャーか。

クライアントもある。

自分のfork（[https://github.com/ge9/socks5 https://github.com/ge9/socks5]）ではFull Cone NATを追加した

<span id="armongo&#45;socks5"></span>
==== armon/go&#45;socks5 ====

[https://github.com/armon/go-socks5 https://github.com/armon/go-socks5]

starは2kだが、最終更新2016年でUDP Associateも無し。Wireproxyで以前使われていたが使われなくなった（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）。

ここからフォークされたものが複数ある。

<span id="things&#45;gogo&#45;socks5"></span>
==== things&#45;go/go&#45;socks5 ====

[https://github.com/things-go/go-socks5 https://github.com/things-go/go-socks5]

armon/go&#45;socks5からのフォーク（GitHub上ではfork扱いではない）。starは400個ほど。UDP Associateはサポートしているがバグあり（自分のPRが採用されるかどうかで揉めてる[https://github.com/things-go/go-socks5/pull/63 https://github.com/things-go/go-socks5/pull/63]）。

Wireproxyで使われている。

自分のフォーク [https://github.com/ge9/go-socks5 https://github.com/ge9/go-socks5] ではFull Cone NATを追加した

<span id="haxiisocks5"></span>
==== haxii/socks5 ====

[https://github.com/haxii/socks5 https://github.com/haxii/socks5]

armon/go&#45;socks5からのfork。UDP Associate対応。starは50個前後。最終更新2019年。

<span id="wzshimingsocks5"></span>
==== wzshiming/socks5 ====

[https://github.com/wzshiming/socks5 https://github.com/wzshiming/socks5]

クライアントもある。

starは90個ほど。最終更新2024年。

とりあえずredsocksと組み合わせでUDP透過プロキシ動作確認済。

Wireproxyで使用が検討された（[https://github.com/whyvl/wireproxy/issues/15 https://github.com/whyvl/wireproxy/issues/15]）が結局使用されず。

<span id="haochen233socks5"></span>
==== haochen233/socks5 ====

[https://github.com/haochen233/socks5 https://github.com/haochen233/socks5]

クライアントもある。

UDP Associateはサポートしているが、starは49とさらに少なく、最終更新も2021年。

同じく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>
== 透過SOCKSプロキシクライアント ==

[https://turgenev.hatenablog.com/entry/2024/03/25/160556 透過プロキシを用いて特定アプリケーションのTCP・UDP通信をSOCKS5経由にする方法（Windows・Linux（iptables TPROXY）・Androidなど） - turgenev’s blog]で扱った内容。

バックにSOCKS(SOCKS5)プロキシを用いてTCP・UDPのレイヤで透過プロキシを行うもの。基本的には管理者権限（Linuxの場合、最低でもCAP_NET_ADMIN）が必要。

以下のいずれも、ドメイン解決にはプロキシが適用されない（Linux向けの2つはできなくはないかもしれないが、しづらい）ことに注意。

==== redsocks ====

[https://github.com/semigodking/redsocks semigodking/redsocks] （fork元の[https://github.com/darkk/redsocks darkk/redsocks]はメンテされておらず、TCPのTPROXYに非対応）

&#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>
==== ProxiFyre ====

[https://github.com/wiresock/proxifyre https://github.com/wiresock/proxifyre] Windows用の透過SOCKSクライアント。管理者権限必要。TCP/UDP両方対応。インストールも簡単で、よくできている。

<span id="proxifier"></span>
==== Proxifier ====

[https://www.proxifier.com/ https&#58;//www.proxifier.com/] 見た感じ機能は十分そうだが、有料なので試していない。

== ライブラリ関数ハック系 ==

ライブラリ関数レベルでの置き換えになるため厳密性・安定性に欠ける（異常終了する場合もある）ものの、root権限がない場合に有効な手法。

<span id="linuxld_preload"></span>
=== Linux（LD_PRELOAD） ===

libc依存でないプログラム（Go製のものなど）には効かない。

==== socksify ====

後述のDanteの一部。UDP/TCP両対応。唯一のUDP対応のものである。

<syntaxhighlight lang="go">route {
  from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.168.1.1 port = 1080
}</syntaxhighlight>
こんな感じの<code>/etc/socks.conf</code>を作るか、<code>SOCKS5_SERVER&#61;192.168.1.1&#58;1080 socksify curl http&#58;//ipv4.icanhazip.com</code> とかでもよい。

Macでも動くはずだが、筆者が唯一試したMac環境ではcurlに対してさえうまく動作しなかった（socksifyを使わないのと全く同様に動作するだけだった）（<code>DYLD_FORCE_FLAT_NAMESPACE&#61;1</code>は指定している）。

<span id="proxychains&#45;ngproxychains"></span>
==== proxychains&#45;ng(proxychains) ====

ngはnew generationの略で、proxychainsの後継である。ただしコマンド名はproxychains4である。

多段プロキシを構成するためのソフトウェア。

UDP非対応（[https://github.com/rofl0r/proxychains-ng/issues/336 https://github.com/rofl0r/proxychains-ng/issues/336]）。ただしDNSに対応したproxy_dnsというオプションがあり、これを有効にするとDNS以外のUDP通信が正常に機能しなくなる副作用がある（[https://github.com/rofl0r/proxychains-ng/issues/103 https://github.com/rofl0r/proxychains-ng/issues/103]）。

<span id="torsockstsocks"></span>
==== torsocks(tsocks) ====

多分、メンテされていないtsocksがTorに取り込まれてtorsocksになったような感じ。tsocksは非常に古く、多分2010年以降には更新されていないが、知名度は高く、今でも多分そこそこ使われてそう。

torsocksはアクティブなはず。ただし、Torでない普通のSOCKS5を指定しても動かないようである（やり方が悪いかも）。

tsocksはUDPには対応していない。torsocksもそうだが、まずそもそもTor自体がUDPに対応していない。

<span id="windowsdll-hijacking"></span>
=== Windows（DLL Hijacking） ===

どのDLLを置き換えたらいいか自明ではなさそうなので、LD_PRELOADと違って対象とするソフトウェアごとに実装が必要そう。そもそも不可能なソフトウェアもLD_PRELOADの場合より多そう。よく見かけるのはDiscordを対象にしたもので、ロシア系のものが多い。筆者は使ったことがない。

==== discord&#45;drover ====

[https://github.com/hdrover/discord-drover https://github.com/hdrover/discord-drover]

==== discord&#45;voice&#45;proxy ====

[https://github.com/runetfreedom/discord-voice-proxy https://github.com/runetfreedom/discord-voice-proxy]

<span id="httpプロキシ"></span>
== HTTPプロキシ ==

Squid, Privoxyなどが有名。

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>
==== SOCKS5によるドメイン解決 ====

SOCKS5（SOCKS4aも？）では、クライアントがCONNECTなどの要求をする際、接続先をIPアドレスではなくホスト名（ドメイン名）で指定することができる仕様になっている。これによりクライアント側ではなくSOCKS5サーバー側でドメイン解決が行われる。

透過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共に）ドメイン解決は基本的にプロキシサーバー側で行われる。

* 拡張機能などではうまく動作しない場合がある模様。 [https://github.com/FelisCatus/SwitchyOmega/issues/2304 https://github.com/FelisCatus/SwitchyOmega/issues/2304]

<span id="ブラウザのsocks5プロキシのwebrtc対応"></span>
==== ブラウザのSOCKS5プロキシのWebRTC対応 ====

基本的に現在主流のブラウザ（Firefox, Chrome）のSOCKS5プロキシ機能（拡張機能で設定する場合を含む）はUDPには対応していないため、Discordの通話などWebRTC関係の機能を使うと生IPが漏洩する（またはそれを防ごうとすると単にその機能が使えない）。これは原理的に実装が不可能なわけではなく、単に需要が少ないから実装されていないだけである。

* Chromeではどれが最新か不明（最近の物は少ない）。このへんとか？[https://issues.chromium.org/issues/41180783 Chromium]
* torのバグ報告 [https://gitlab.torproject.org/tpo/applications/mullvad-browser/-/issues/151 https&#58;//gitlab.torproject.org/tpo/applications/mullvad&#45;browser/&#45;/issues/151]
* firefoxの [https://bugzilla.mozilla.org/show_bug.cgi?id=1808692 https&#58;//bugzilla.mozilla.org/show_bug.cgi?id&#61;1808692]
** QUIC関連 [https://bugzilla.mozilla.org/show_bug.cgi?id=1882071 https&#58;//bugzilla.mozilla.org/show_bug.cgi?id&#61;1882071]
** 新しめの包括的なバグレポート [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が無くても可能。

<span id="udp-associateリクエストのdstaddrとdstport"></span>
==== UDP AssociateリクエストのDST.ADDRとDST.PORT ====

クライアントがサーバー側にUDP Associateリクエストをするとき、この2フィールドには通信したい宛先ではなく（←というかそもそもそれが複数ある場合もある）、<strong>クライアント側がUDP Associateに使用する予定のポート</strong>を入れる。指定しない場合（例えばNATがある場合、これを予測するのは難しくなる）は、全ビットを0に設定する必要がある。

これによってサーバー側は、UDPパケットが送られてきたタイミングでそれが事前に通知されたものと一致するかどうか確認できるというわけである。

この部分に誤って<strong>クライアント側が通信したい宛先ポート</strong>を入れるよう実装していたSOCKS5クライアントがいくつかある。

* semigodking/redsocks…自分の[https://github.com/semigodking/redsocks/issues/210 https://github.com/semigodking/redsocks/issues/210]で修正済み。
* gost…[https://github.com/ginuerzh/gost/issues/96 https://github.com/ginuerzh/gost/issues/96]で修正済み。
* 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]もここから。

== プロキシプロトコル間の変換 ==

==== socks&#45;to&#45;http&#45;proxy ====

[https://github.com/KaranGauswami/socks-to-http-proxy https://github.com/KaranGauswami/socks-to-http-proxy]

名前の通り、socksをhttpにしてくれる。starは250ほど。

==== privoxy ====

基本的にはHTTPプロキシソフトウェア。socksプロキシをhttpプロキシとして使えるようにする機能はあるが、より大がかり（一般ユーザーでの実行がしづらい）

<span id="udpwireguard関連"></span>
== UDP・Wireguard関連 ==

<span id="udpでサーバークライアントにデータ送信"></span>
==== UDPでサーバー→クライアントにデータ送信 ====

[https://github.com/prof7bit/udp-reverse-tunnel https://github.com/prof7bit/udp-reverse-tunnel]

これを使うと、<strong>サーバー側だけでポートが開けられるとしても事実上クライアント側で開けられるのと同等</strong>になるのでreverseをするのが楽になる

* [https://superuser.com/questions/1737943/how-to-create-a-reverse-udp-tunnel https&#58;//superuser.com/questions/1737943/how&#45;to&#45;create&#45;a&#45;reverse&#45;udp&#45;tunnel]
* どっちも開放できない場合、UDPホールパンチングで何とかするしかない

==== wgslirpy ====

[https://github.com/vi/wgslirpy https://github.com/vi/wgslirpy]

Slirp（ユーザーランドで動くPPPサーバーのようなもの）のような形で実装されたWireguardサーバー。rootなしでWireguardサーバーとして動作する。

==== wireproxy ====

[https://github.com/whyvl/wireproxy https://github.com/whyvl/wireproxy]

wgslirpyの逆のような（？）ツール。Wireguardクライアントであるが、SOCKSサーバーとして動作する。

依存ライブラリのUDP Associate対応が不完全（自分がプルリクを送っている）だが、クライアントによってはうまくUDP Associateが動く（[https://github.com/whyvl/wireproxy/issues/30 https://github.com/whyvl/wireproxy/issues/30]）。

<ul>
<li><p>自分でカスタマイズしてCone NATを加えたthings&#45;go/go&#45;socks5を使えば（<code>go.mod</code>で<code>replace github.com/things&#45;go/go&#45;socks5 &#61;&gt; ../../go&#45;socks5</code>などとする）、以下のようなコードをroutine.goのsocks5.Optionのところに追加することでCone NATにできる。</p>
<syntaxhighlight lang="go">socks5.WithDialUDP(func(laddr, raddr *net.UDPAddr) (net.PacketConn, error) { return vt.Tnet.DialUDP(laddr, raddr) }),</syntaxhighlight></li></ul>

<span id="wireguard通信の確立&#58;-各パターンでのやり方"></span>
=== Wireguard通信の確立&#58; 各パターンでのやり方 ===

各状況に応じて、2端末間でUDPの暗号化された通信路を確立するための方法を書いた。

* forwardは「クライアント→サーバー」、reverseは「サーバー→クライアント」という意味。「サーバー」は、「ポートが開放できる方」という意味合い。

==== どっちもrootあり ====

普通にWireguardを使う

==== サーバーのみrootあり ====

<strong>forward</strong>

サーバーはWireguard、クライアントは普通にWireproxyでいける

<strong>reverse</strong>

udp&#45;reverse&#45;tunnelで頑張って逆にする（あるいはホールパンチング）。

その上で、wgslirpyを使うか、Hysteriaを使うか

==== クライアントのみrootあり ====

↑さっきと逆

<strong>forward</strong>

wgslirpyを使うか、Hysteriaを使うか

<strong>reverse</strong>

udp&#45;reverse&#45;tunnelで頑張ったうえで普通にWireguardとWireproxy

==== どっちもrootなし ====

この場合そもそもWireguardを使うメリットはあまりないかも。というのとrootがないならポート開放も無理そう

<strong>forward</strong>

Hysteriaでいけそう。

<strong>reverse</strong>

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}}