Как сервер TURN отправляет данные пирам за NAT?

Question

Я понимаю, что в TURN есть client, TURN server и peer(s).Клиент сам создает распределение на сервере TURN, после чего relayed transport address возвращается клиенту для отправки данных одному или нескольким узлам.

Я понимаю, как клиент может обойти свой NATОднако в RFC5766 я ничего не видел о том, как сами равноправные узлы могут принимать UDP через свои NAT от сервера TURN (в противном случае через TURN или нет, это было бы нежелательным UDP).Сначала одноранговые узлы должны обратиться к серверу TURN.

Есть ли пропущенный шаг?Отправляется ли relayed transport address одноранговому узлу, чтобы пробивание UDP-дырок могло начаться до того, как связь между сервером TURN и его одноранговыми узлами может начаться?

Answer 1

Клиент создает распределение на сервере TURN, например, с портом 3478 8.8.8.8. Для этого он отправляет пакеты STUN из локального сокета на этот адрес.Все NAT (без учета сетей, которые блокируют UDP) позволят серверу TURN отправлять данные UDP обратно по этому соединению (иногда это называется привязкой NAT).Сервер TURN также может отправлять любые другие данные, которые он хочет, через это соединение.

Узел не знает об этом распределении.Он знает только адрес ретранслятора, который сервер TURN сообщает клиенту, например, 8.8.8.8 порт 61468. Клиент должен отправить этот адрес одноранговому узлу, например, как часть сигнализации в процессе ICE (см. https://tools.ietf.org/html/rfc5245).

Узел может затем отправить 8.8.8.8 порт 61468 (иногда клиент должен также сообщить серверу TURN ips, на которые может отправлять узел; см. Разрешения в https://tools.ietf.org/html/rfc5766). Затем сервер TURN будет пересылать любой трафик, который он получаетна этом порту в качестве индикации данных STUN (или через привязку канала, см. RFC 5766). NAT в порядке с этим, так как он поступает с 8.8.8.8 порта 3478.

Клиент также может отправлять данные наодноранговый узел с помощью индикации отправки STUN Сервер TURN развернет эти данные и отправит их с ретранслируемого адреса (порт 814.8.8 61468)

Что касается NAT с обеих сторон, они видят только связьс ips и портами, куда их клиент отправил пакеты первыми.