Retire the generic SOCKS5 :1080 (raw SOCKS5 is blocked by TSPU/DPI for the
external Telegram use case) and add ts-lan-mtproto (alexbers/mtprotoproxy) on
:1080 instead: a Fake-TLS MTProto proxy whose Telegram-DC connections chain
through the Tailscale userspace SOCKS5 (SOCKS5_HOST=ts-proxy:1055), so egress
still rides the Hetzner exit node. Client-facing hop is domestic Fake-TLS to
test the hypothesis that TSPU bites hardest at the border. 3proxy keeps only
the HTTP front (:3128). The proxy secret lives in a host-only config.py
(0600, uid 10000, not in git); config.py.example is the secret-free template.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Retire the tinyproxy HTTP container (tinyproxy has no per-source-IP
conditional auth) and serve both the HTTP proxy (:3128) and SOCKS5 (:1080)
from a single 3proxy instance. LAN (192.168.0.0/22) stays passwordless;
any non-LAN source (i.e. external clients via the router port-forward) must
authenticate. Credentials live in a host-only /etc/3proxy/3proxy.secret
(0600, not in git), included by 3proxy.cfg. A deny rule on the gateway IP
makes the proxy fail closed if the port-forward ever SNATs to 192.168.0.1.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a LAN-facing SOCKS5 proxy alongside the existing tinyproxy HTTP proxy,
both egressing through the same Tailscale exit node.
- new service socks5 (ghcr.io/3proxy/3proxy): SOCKS5 on 192.168.0.35:1080,
auth iponly / allow 192.168.0.0/22, chained via `parent socks5 ts-proxy 1055`
to the Tailscale userspace SOCKS5, so clients exit as 89.167.72.79.
- 3proxy.cfg tracked here as source of truth; access log shipped to Loki via
the syslog log-driver (tag tailscale-socks5).
Verified: curl --socks5 / --socks5-hostname 192.168.0.35:1080 -> 89.167.72.79,
wikipedia 200. Carries TCP only (no QUIC/UDP), same as the HTTP front - README
updated to note this.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pipistrelloandClaude Opus 4.8