STUN: узнать свой публичный адрес
Session Traversal Utilities for NAT (STUN), описанный в RFC 8489, устроен как лёгкий протокол типа «запрос-ответ». Устройство отправляет STUN-серверу binding-запрос, а в ответе получает публичный адрес и порт, с которых пришёл запрос. Это так называемый server-reflexive адрес. STUN помогает двум устройствам попробовать прямое соединение, но саму сессию не переносит, поэтому STUN-серверу нужно совсем немного трафика.
TURN: пересылка, когда прямой путь не удался
Traversal Using Relays around NAT (TURN), описанный в RFC 8656 как расширение STUN, выделяет адрес на relay-сервере. Обе стороны отправляют трафик на relay, а тот пересылает его дальше. TURN работает, когда не работает ничего другого, но каждый байт сессии проходит через relay. Это добавляет задержку и обходится оператору в трафик.
ICE: выбор между ними
Interactive Connectivity Establishment (ICE), RFC 8445, связывает их вместе. Каждая сторона собирает кандидатов (локальные адреса, server-reflexive адреса от STUN и relay-адреса от TURN), обменивается ими, проверяет пары и оставляет лучшую рабочую, отдавая предпочтение прямым путям. Именно так ICE, STUN и TURN используются в WebRTC.
Как это устроено в Vexaro Desk
Vexaro Desk не использует TURN. Если сеть не допускает прямого соединения, сессия идёт через собственные ретрансляторы Vexaro, и клиент подключается только к тому ретранслятору, подлинность которого может проверить.
Прямые сессии защищены сквозным шифрованием. Если сеть вынуждает использовать ретранслируемое соединение, трафик остаётся зашифрованным при передаче через ретрансляторы, которыми управляет Vexaro.