STUN / TURN — NAT traversal для VPN и P2P

Определение

STUN (Session Traversal Utilities for NAT, RFC 8489) — протокол, позволяющий хосту за NAT определить свой публичный IP и port, как их видит интернет. Клиент шлёт STUN-запрос на сервер, сервер отвечает «я вижу тебя как 1.2.3.4:54321». На этой информации строится последующий peer-to-peer обмен данными.

TURN (Traversal Using Relays around NAT, RFC 8656) — fallback-протокол. Если STUN не помог (двойной NAT, симметричный NAT), TURN-сервер выступает relay’ем — оба клиента шлют ему трафик, он пересылает. TURN дороже (двойная пропускная способность через сервер), но работает там, где STUN бессилен.

В VPN-контексте STUN/TURN — основа mesh-VPN (Tailscale, ZeroTier) и обходных систем (Snowflake, WebRTC-tunnels).

Как работает STUN

1. Клиент A за NAT шлёт UDP-пакет на stun.example.com:3478.
2. NAT клиента создаёт mapping 192.168.1.10:54321 ↔ 1.2.3.4:54321 (или новый external port).
3. STUN-сервер видит пакет от 1.2.3.4:54321 и отвечает «твой external endpoint = 1.2.3.4:54321».
4. Клиент сообщает peer’у B свой external endpoint.
5. Параллельно B делает то же → получает 5.6.7.8:38912.
6. Hole punching: оба клиента одновременно шлют UDP друг другу на external-endpoint. NAT-mapping уже открыт (от шага 2), пакет проходит.
7. После hole punching клиенты общаются прямо peer-to-peer.

NAT-типы и работоспособность STUN

• Full Cone NAT: STUN работает идеально. Любой внешний хост может слать на open external-port.
• Restricted Cone: hole punching работает, если оба пира знают endpoint друг друга.
• Port-Restricted Cone: hole punching работает с дополнительными условиями (point-to-point packets).
• Symmetric NAT: новый external port для каждого destination — STUN бесполезен, нужен TURN.

Symmetric NAT часто встречается на:

• CGNAT (carrier-grade NAT) у мобильных операторов РФ.
• Корпоративных firewall’ах.
• Некоторых ISP-роутерах с защитой от P2P.

TURN как fallback

TURN-сервер открывает «relay-aлокацию» — пара IP+port на TURN-сервере, выделенная конкретному клиенту. Все пакеты к этой паре пересылаются клиенту через установленный TCP/UDP туннель. Дорого, но универсально.

WebRTC-стек (Chrome, Firefox, Safari) сначала пробует STUN — если не работает, fallback на TURN. Это причина webrtc-leak: даже за VPN браузер шлёт STUN-запросы и узнает свой реальный public IP.

STUN/TURN в VPN-стэке

Технология	Где используется
Tailscale (Wireguard mesh)	DERP-серверы — Tailscale’s TURN-аналоги; STUN для peer-discovery
ZeroTier	Свой rendezvous-server (analog STUN) + UDP-relays
WireGuard P2P (mesh)	Не имеет встроенного STUN — нужны внешние tools
OpenVPN	Не P2P, не нуждается
Snowflake (Tor)	Использует WebRTC, STUN/TURN от Google и партнёров
Headscale (open-source Tailscale)	DERP+STUN на собственной инфре

STUN в России 2026

• Публичные STUN-серверы: stun.l.google.com:19302, stun.cloudflare.com:3478 — обычно работают (часть UDP-трафика не блокирована).
• ТСПУ ситуативно режет UDP: на мобильных операторах STUN периодически не работает. WebRTC-сервисы фолбэкают на TURN, скорость падает.
• TURN-серверы своих сервисов (Tailscale’s DERP, ZeroTier) — обычно проходят.

WebRTC leak через STUN

Браузер за VPN, открывая WebRTC-сессию (Discord voice, Google Meet, Zoom web), автоматически делает STUN-запросы. Результат: STUN-сервер возвращает реальный IP юзера (тот, что выдал VPN), плюс если STUN-запрос ушёл вне туннеля (что часто бывает у Chrome) — домашний IP. JavaScript на странице может прочитать оба адреса.

Защита:

• В about:config (Firefox): media.peerconnection.enabled = false.
• Chrome: расширение «WebRTC Leak Prevent».
• VPN с правильным kill-switch и блокировкой UDP outside туннеля.

Источники

• RFC 8489 — STUN.
• RFC 8656 — TURN.
• Tailscale blog — DERP architecture.

Связанные термины

• NAT traversal — общая концепция.
• WebRTC leak — типичная утечка через STUN.
• Tailscale — mesh-VPN, использует DERP+STUN.
• ZeroTier — конкурент Tailscale.
• Snowflake — Tor-bridges на WebRTC+STUN.