mirror of https://github.com/ospab/ostp.git
ospab
b673219894
Reported: with an upstream proxy configured, Google flags the session because
the server's address and the proxy's exit address differ, and YouTube
geolocates to the server rather than the proxy exit. Both follow from the same
defect in three places — an outbound rule that says Proxy was being satisfied
by connecting DIRECTLY whenever the proxy could not be used:
- router.rs, UdpSessionRouter::send_to: action Proxy with no UDP proxy
established fell through to the direct socket.
- outbound.rs, connect_target: any protocol string other than exactly
"socks5"/"http" hit a `_ =>` arm that connected directly. A typo, or just
"SOCKS5", silently un-proxied ALL TCP.
- outbound.rs, connect_udp_target: non-socks5 upstream returned
UdpProxySocket::Direct, with a comment noting HTTP cannot carry UDP —
correct in itself, but the chosen fallback leaks.
The visible symptom is precisely what these produce: TCP goes through the
proxy while UDP (QUIC — which is what YouTube uses) leaves from the server,
so one session presents two exit addresses.
All three now fail closed. A rule asking for the proxy is never honoured by
sending in the clear: a dropped flow is visible and debuggable, a
deanonymising leak is neither. Protocol matching is also case-insensitive
now, and the SOCKS5 UDP ASSOCIATE failure warns unconditionally rather than
only under `debug`, which is why this could go unnoticed.
Behaviour change: with an HTTP upstream, or a broken SOCKS5 UDP ASSOCIATE,
UDP now fails instead of leaking. Where that is genuinely wanted, it must be
stated in the config as an explicit udp rule with action "direct".
Also carries the relay key-sync diagnostics: a 404 there means the URL is
missing the panel's secret webpath (the API is nested under it, not at /api),
which the previous bare "HTTP 404" gave no way to work out.
|
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||