This file has been unsafe to deploy for two separate reasons. Both are fixed here,
and the result is now byte-identical in effective config to what actually runs on
the client-02 host (verified by diffing `docker compose config` on both).
1. ts-vpn + ikev2 were missing entirely.
The IKEv2 VPN front has run on the host since 2026-09-05, but was never mirrored
here — this file defined only ts-proxy, proxy and telemt. Deploying it as-is would
have taken the VPN down for the Windows and iOS clients. Added both services, plus
ikev2-egress.sh, which the ikev2 service mounts and cannot start without.
ts-vpn is a SECOND Tailscale node in kernel/TUN mode (unlike ts-proxy, which is
userspace): it forwards raw IP packets rather than TCP streams, so a userspace
SOCKS5 is useless for it. It owns the network namespace that ikev2 joins via
network_mode, which is also why the ports and sysctls live on ts-vpn and not on
ikev2 — Docker forbids net.* sysctls on a network_mode:service container.
2. ts-proxy still pointed at the pre-migration exit node.
TS_EXTRA_ARGS --exit-node=100.121.234.85 -> --exit-node=100.106.197.99
TS_HOSTNAME / hostname technohim-lan-proxy -> 02-tekhnohim-lan-proxy
100.121.234.85 has not existed since the 2026-08-27 tailnet migration. This is
worse than a dead setting: with the exit node absent this stack does NOT fail
closed — it silently egresses through the local ISP, so a redeploy from this repo
would have turned a censorship-avoiding proxy into a plain local-egress one while
still reporting healthy. This drift was recorded as an open issue in the migration
write-up on 2026-08-27; these are the exact substitutions it prescribed.
Not included, deliberately: ts-vpn.env and ikev2.env, which hold TS_AUTHKEY and the
VPN credentials. Like every other config in this stack they are staged on the host
by hand — a git push does not deploy config here, and these must never enter git.
Both extracted files were scanned for secrets before being added.
Completes the pair started in e41b55c, which deliberately left the proxy service
out because it was still on a runtime prlimit only and had not yet had its
maintenance window.
ts-lan-proxy was subject to the same Docker default soft limit of 1024 that took
Telemt down on 2026-09-09 — 3proxy does not raise its own limit either, and the
container's HostConfig.Ulimits was null. Steady state is ~22 descriptors, so the
ceiling was ~2% used in normal operation.
Applied on the client-02 host at 22:45 MSK with
docker compose up -d --no-deps --force-recreate proxy
never a whole-stack up -d, which would also recreate ts-vpn and leave
ts-lan-ikev2 holding a stale namespace. Verified afterwards: HostConfig.Ulimits
now 65536/524288, container IP unchanged (172.31.0.4), egress through the proxy
still measures the exit node 89.167.72.79 against a direct-egress control of
212.116.102.42, 3proxy.cfg untouched so the conditional-auth behaviour is
unchanged, and the syslog log driver still emits access lines (confirmed on the
wire).
This file is STILL missing ts-vpn and ts-lan-ikev2, which have run on the host
since 2026-09-05 — deploying it as-is would take the IKEv2 VPN down. That drift
is unrelated to this commit and still needs its own.
Mirrors what is now running on the client-02 docker host, so a "pull and
redeploy" from this repo can no longer silently revert it.
On 2026-09-09 a connection flood against the public :1080 (peak 4,301
connections/minute, ~100% failing the Fake-TLS handshake) exhausted the Telemt
container's file-descriptor table, which sat at Docker's default soft limit of
1024. accept() then failed for every caller — real Telegram clients and the
monitoring collector alike — until the burst drained. Steady state needs only
45-73 descriptors, so the ceiling was ~7% used in normal operation.
ulimits: nofile 65536/524288 on the telemt service
The host was mitigated at runtime with prlimit on the day, but that is lost on
any recreate, and this compose is exactly what a redeploy would restore. The
proxy (3proxy) service deliberately does NOT get the block in this commit — it
is still on the runtime limit only and is scheduled for its own window, so
adding it here would make the repo claim something that is not yet true.
rst_on_close = "errors" in telemt.toml.example
Scanners and DPI probes that never complete the handshake leave orphaned sockets
in FIN-WAIT-1. "errors" sets SO_LINGER(0) at accept() and clears it once a client
authenticates, so real sessions still close gracefully with FIN and only pre-auth
closes are aborted. Verified on the wire on the host: a failed handshake now ends
FIN then RST, while authenticated sessions in the same capture closed FIN-only.
Applied on the host at 22:17 MSK via telemt-safe-restart: healthy in 10s,
container IP unchanged, bad-handshake delta 0 over a 5-minute recheck, no EMFILE
since.
NOTE for whoever deploys this stack from this repo: it is still missing the
ts-vpn + ts-lan-ikev2 services that have been running on the client-02 host since
2026-09-05. Deploying this file as-is would take the IKEv2 VPN front down. That
drift is untouched here and needs its own commit.
pipistrello