experiment: probe direct TURN egress without VPS

[Regstar2]

Prototype-only direct TURN egress experiments.

Goal: determine whether VK/OK TURN can reach external peers directly, without wdtt-server or a user-owned VPS, and whether that is enough for ordinary Telegram MTProto traffic.

Confirmed manually

TCP / RFC 6062

• control/auth path reaches both tested VK/OK TURN endpoints;
• both reject AllocateTCP() with:
  442: TCP Transport is not allowed by the TURN Server configuration;
• standard TURN TCP relay is therefore disabled on the tested endpoints.

UDP direct egress

• UDP Allocate() succeeds;
• DNS to 1.1.1.1:53 timed out;
• public STUN control succeeded bidirectionally through the TURN relay;
• therefore external bidirectional UDP egress without wdtt-server/VPS is confirmed for the tested TURN endpoint and peer.

Protocol-neutral raw UDP probe

Added cmd/turn-udp-raw-probe:

• accepts an arbitrary UDP host:port plus exactly one caller-supplied text or hex datagram;
• caps payload at 1200 bytes and sends one datagram per TURN endpoint;
• reports Allocate, Send and Receive as separate stages;
• a receive timeout preserves successful allocation/send diagnostics instead of collapsing everything into one failure;
• exit code 0 = response received, 3 = send succeeded but no response, 1 = allocation/send not confirmed.

Example:

Set-Location "C:\base\projects\PWDTT"
$vk = Read-Host "VK call hash or full join link"

go run ./cmd/turn-udp-raw-probe `
  -hash $vk `
  -target "host.example:12345" `
  -payload-text "ping"

This is the protocol-neutral control for testing additional UDP peers without depending on DNS, STUN, Telegram VoIP, or MTProto framing.

Primary ordinary-Telegram experiment

Added cmd/turn-telegram-mtproto-udp-probe:

• sends unauthenticated req_pq_multi to a Telegram DC through VK/OK TURN UDP;
• tries raw, abridged, intermediate, padded-intermediate and full framing candidates;
• SUCCESS requires a real resPQ#05162463 with the matching nonce.

Added cmd/turn-no-vps-probe as the recommended Telegram runner:

1. proves current bidirectional external UDP with a STUN control exchange;
2. probes all built-in production IPv4 Telegram Desktop DC targets;
3. prints a conservative final verdict.

Default Telegram targets:

• 149.154.175.50:443
• 149.154.167.51:443
• 95.161.76.100:443
• 149.154.175.100:443
• 149.154.167.91:443
• 149.154.171.5:443

Manual run:

Set-Location "C:\base\projects\PWDTT"
$vk = Read-Host "VK call hash or full join link"
go run ./cmd/turn-no-vps-probe -hash $vk

The runners accept either the raw VK hash or the full https://vk.com/call/join/... URL.

Verdict rules:

• STUN fails -> UDP egress not confirmed; Telegram stage is not tested.
• STUN passes, all Telegram probes fail -> general UDP works, but direct ordinary Telegram messaging is not confirmed.
• matching resPQ received -> direct ordinary MTProto over TURN UDP is confirmed at protocol-probe level.

Telegram VoIP/reflector experiments were removed from this PR because they do not answer the original ordinary-messaging goal.

This remains a draft diagnostic experiment. It does not change normal PWDTT runtime, GUI, WireGuard flow, or default networking behavior.

[Regstar2]

Manual experiment result (Windows, 2026-09-07):

Command:

go run ./cmd/turn-tcp-probe -hash "<VK_HASH>" -target "example.com:80" -mode http

VK Calls credential chain succeeded and returned two TURN endpoints:

• 91.231.135.154:19302
• 90.156.236.108:19302

Both endpoints rejected RFC 6062 TCP allocation with:

AllocateTCP: Allocate error response (error 442: TCP Transport is not allowed by the TURN Server configuration)

Conclusion: the tested VK/OK TURN configuration allows the control/auth path but explicitly disables TCP relay allocation. Therefore the no-VPS TURN TCP -> arbitrary TCP peer hypothesis is not supported by these endpoints. This does not invalidate existing UDP TURN behavior used by WDTT.

[Regstar2]

Second manual run (UDP probe) did not reach TURN and therefore is inconclusive.

Observed failure:

step2 messages.getCallPreview -> VK returns error: Invalid join link (error_code=954)
FAILED: get VK TURN credentials

Interpretation: the supplied VK call hash/link was invalid or no longer usable. No UDP Allocate(), peer permission, DNS send, or DNS receive step was executed. A fresh/known-working VK call hash is required before drawing any conclusion about UDP direct egress.

[Regstar2]

Manual UDP probe result with a known-working VK hash:

Credential flow succeeded and returned the same two TURN endpoints.

For both endpoints:

• UDP TURN Allocate() succeeded;
• sending the DNS query via the relay did not return an immediate permission/send error;
• waiting for the DNS response timed out.

Observed errors:

91.231.135.154:19302: read DNS response through TURN: i/o timeout
90.156.236.108:19302: read DNS response through TURN: i/o timeout

Interpretation: this is not equivalent to a failed UDP allocation. The tested endpoints accepted the UDP allocation and the client-side send path. What remains unresolved is whether:

1. outbound packets to arbitrary peers are silently filtered;
2. return traffic from arbitrary peers is filtered;
3. DNS/UDP port 53 specifically is filtered;
4. the selected public DNS peer is unreachable from the TURN environment.

A second control probe using a STUN Binding request to a public STUN endpoint is needed to distinguish general UDP egress from DNS-specific filtering.

[Regstar2]

Manual UDP STUN control result: SUCCESS.

Observed:

TURN endpoint: 91.231.135.154:19302
Relayed address: 91.231.135.154:42880
Target: 162.159.207.0:3478 (stun.cloudflare.com)
Response source: 162.159.207.0:3478
STUN mapped address: 91.231.135.154:42880
Response bytes: 32

Conclusion:

• VK/OK TURN UDP allocation succeeds;
• a packet can be sent from the TURN relay to an unrelated external UDP peer;
• the external peer's response returns through the TURN relay;
• therefore bidirectional direct UDP egress without wdtt-server/VPS is confirmed for the tested TURN endpoint and peer.

The previous 1.1.1.1:53 DNS timeout is therefore not evidence that arbitrary UDP egress is blocked globally; it is more likely specific to DNS/53, the selected peer, or provider filtering.

This does not establish TCP relay support: RFC 6062 TCP allocation remains explicitly rejected with TURN error 442.

[Regstar2]

Refocused the experiment on the original goal: ordinary Telegram traffic without a VPS.

New head: db3dde8

Changes:

• removed Telegram VoIP reflector/discovery side experiment from this PR;
• added cmd/turn-no-vps-probe;
• runner first validates bidirectional external UDP through STUN;
• then probes all built-in production IPv4 Telegram Desktop DCs with the existing MTProto UDP framing candidates;
• final verdict distinguishes general UDP failure from Telegram-transport failure;
• full VK join URL is accepted and normalized to the hash;
• added target/hash parsing tests and updated experiment docs.

PR remains draft.

[Regstar2]

Implemented protocol-neutral raw UDP egress diagnostics in commit 1223d39.

Added:

• core/turn_udp_raw_probe.go + tests;
• cmd/turn-udp-raw-probe + CLI tests;
• docs/turn-udp-raw-probe.md.

The probe sends exactly one caller-supplied UDP datagram per VK/OK TURN endpoint (payload capped at 1200 bytes) and reports Allocate, Send, and Receive independently. A receive timeout no longer obscures a successful allocation/send path.

Suggested manual control:

Set-Location "C:\base\projects\PWDTT"
git fetch origin
git switch experiment/turn-tcp-rfc6062
git reset --hard origin/experiment/turn-tcp-rfc6062

$vk = Read-Host "VK call hash or full join link"

go run ./cmd/turn-udp-raw-probe `
  -hash $vk `
  -target "stun.cloudflare.com:3478" `
  -payload-hex "000100002112a4420102030405060708090a0b0c"

The hex payload is a minimal STUN Binding request used only as a convenient known-responsive UDP peer. The raw probe itself performs no STUN validation; it only confirms whether a UDP response returns.

PR remains draft.