LINUX.ORG.RU

Принцип работы webrtc?

 


3

1

Где можно найти подробное описание?
Вот браузер отправляет запрос к серверу по tcp.
Ответ идет с ip stun сервера к которому браузер подключается по udp, чтобы получить свой внешний ip?
Что потом?

Ответ на: удаленный комментарий

Вы как-то невнятно описываете вашу проблему. «подмену ip webrtc в linux» - конкретно что вы под этим имеете в виду?
IP в WebRTC может быть:
- Локальный (сетевого интерфейса).
- mDNS имя узла.
- Внешний вашего провайдера (посредством STUN).
- Внешний другого узла (посредством TURN).

Что из этого вы подменять собрались?

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 2)
Ответ на: комментарий от sanwashere

Ты что, ты как царю челобитную подаёшь?! Он же сказал, rfc - вода и мозго2.7бство. такому сразу решение вынь да полож, а ты тут с вопросами…. ;)

aol ★★★★★ ()
Ответ на: комментарий от yoholo

Объясняю «на пальцах».
Для клиента определяются 3 (иногда 4) вида адресов. За это отвечает ICE (Interactive Connectivity Establishment):
1. Локальный (host). Адрес на локальном сетевом интерфейсе.
2. Локальный внешний (server reflexive). Определён, если вы за NAT, посредством запроса на сервер STUN. Сервер просто говорит, с какого адреса пришёл запрос.
3. Удалённый (relayed). Адрес на удалённой машине. Определён, если настроено использование сервера TURN. Сервер создаёт у себя точку подключения и отдаёт её адрес.
4. Локальный внешний №2 (peer reflexive). Определён, если при проверках связности для собранных адресов одна из сторон-клиентов отвечает с нового адреса.

Первые 3 адреса одна сторона отдаёт другой в виде кандидатов ICE. Другая сторона делает то же самое для своих адресов.
После обмена стороны начинают стучаться (проверка связности) по этим адресам, оставляя те, которые успешно ответили. Адреса из п.4 могут появиться на данном этапе, и они тоже пересылаются и проверяются.

Вы хотите подменить адрес из п.2. Если он будет левый, то проверка не пройдёт и ваш подменённый адрес не даст никакого эффекта.

P.S. Проблему стоит всё-таки сформулировать более внятно.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 4)
Ответ на: комментарий от sanwashere

Идея в том, чтобы обращаться к локальному stun серверу от локального интерфейса из одного ip. Пробовал ставить

stun-server/oldstable 0.97~dfsg-2.1+b1 amd64
  Server daemon for STUN
stuntman-server/oldstable 1.2.7-1.1 amd64
  Server daemon for STUN
coturn/oldstable,oldstable 4.5.0.5-1+deb9u1 amd64
  TURN and STUN server for VoIP

Результат

linux@linux:~$ ps aux | grep stun
linux     5010  0.0  0.0  12780  1012 pts/0    S+   04:10   0:00 grep stun
linux@linux:~$ ps aux | grep turnserver
linux     5027  0.0  0.0  12780   968 pts/0    S+   04:11   0:00 grep turnserver
linux@linux:~$ ps aux | grep coturn
linux     5030  0.0  0.0  12780  1012 pts/0    S+   04:11   0:00 grep coturn
netstat -anp | grep stun
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)

Не вижу stun сервера в процессах(

yoholo ()
Ответ на: комментарий от yoholo

На сегодня нормально работает только coturn, если что. А нет его в процессах возможно из-за того, что после установки он обычно в отключённом состоянии («systemctl enable coturn», «service coturn enable», и т.п.).
Конфигурация по умолчанию должна обеспечить базовый STUN.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 4)
Ответ на: комментарий от sanwashere

Нет возможности использовать по умолчанию 3478/TCP? (firefox)
Тогда можно было бы обращаться к stun через socks.
На 3478 ничего не висит.

linux@linux:~$ systemctl status coturn
● coturn.service - LSB: coturn TURN Server
   Loaded: loaded (/etc/init.d/coturn; generated; vendor preset: enabled)
   Active: active (exited) since Fri 2020-03-06 05:09:37 CST; 27s ago
     Docs: man:systemd-sysv-generator(8)
linux@linux:~$ sudo netstat -ntulp | grep 3478
linux@linux:~$ 
yoholo ()
Последнее исправление: yoholo (всего исправлений: 2)
Ответ на: комментарий от yoholo

Можно, но нужно в вашем целевом web приложении дописывать в адреса вашего сервера STUN суффикс "?transport=tcp" (будет что-то типа «stun:server_host:3478?transport=tcp»).
Можно ещё указывать в адресе вместо «stun:», схему «stuns:». Тогда оно будет использовать TLS на 3479/TCP (если порт не указан).

По поводу отсутствия порта: судя по состоянию, процесс уже завершился. Стоит проверить логи (в /var/log/turnserver/* вроде) на предмет ошибок при старте.

sanwashere ★★ ()
Ответ на: комментарий от yoholo

Вы хотите через TOR похоже пустить всё? Могу предложить использовать внешний сервер TURN и внести следующие настройки в Firefox:

media.peerconnection.default_iceservers=['turn:my.custom.server:3478?transport=tcp']
media.peerconnection.use_document_iceservers=false
media.peerconnection.ice.tcp=true
media.peerconnection.ice.relay_only=true

Это обеспечит туннель через TCP до указанного сервера. Сам сервер будет видеть адрес только вашего выходного узла SOCKS. Приложение на странице тоже будет получать только его.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 5)
Ответ на: комментарий от yoholo

STUN, даже через TCP, посредством SOCKS не получится пустить, так как SOCKS прокси (да и TOR вроде тоже в нормальном виде) не допускает приёма входящих подключений. Так что для скрытия адреса остаётся только TURN.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)
Ответ на: комментарий от sanwashere

С этим:

media.peerconnection.default_iceservers=['turn:my.custom.server:3478?transport=tcp']
media.peerconnection.use_document_iceservers=false
media.peerconnection.ice.tcp=true
media.peerconnection.ice.relay_only=true

webrtc тест не показывает внешний ip прокси.
Внутренний ip тоже не показывает.
Чем плоха идея с локальным stun сервером, кроме того что реализацию в паблике найти не удалось?

yoholo ()
Последнее исправление: yoholo (всего исправлений: 1)

WebRTC – это NAT forwarding для браузера, если не ошибаюсь. И в хол-панчинг и в небезопасный UPnP/NAT-PMP он не умеет, а только TURN (a’k’a proxy) или STUN (когда можно обойтись только STUN).

kostyarin_ ★★ ()
Последнее исправление: kostyarin_ (всего исправлений: 1)
Ответ на: комментарий от yoholo

Так сервер-то рабочий в «default_iceservers» указали?
STUN потребует возможности отправки удалённым узлом на отданный им адрес пакетов TCP/UDP. В вашем случае это означает проблемы, так как вы хотите светить похоже только внешний адрес прокси, который не принимает никаких входящих подключений. TURN же в свою очередь будет принимать поток у себя и слать его по уже установленному подключению TCP.

sanwashere ★★ ()
Ответ на: комментарий от kostyarin_

WebRTC скорее пачка спецификаций, среди которых имеется и ICE (и STUN/TURN, как основа), который для «пробивания дырок» как раз и создан.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)
Ответ на: комментарий от sanwashere

Я поставил turnserver на свой сервер, указал

media.peerconnection.default_iceservers=['ip_moego_servera:3478?transport=tcp']
netstat -ntulp | grep 3478
tcp        0      0 0.0.0.0:3478            0.0.0.0:*               LISTEN      -                   
udp        0      0 0.0.0.0:3478            0.0.0.0:*                           -    

https://test.webrtc.org/?turnURI=ip_moego_servera%3A3478
https://cdn1.savepice.ru/uploads/2020/3/8/a10b1aa2719e71f18679f0a02d307be0-full.png ХЗ что это значит.
Возможно есть 100% рабочий паблик turn?

yoholo ()
Ответ на: комментарий от yoholo

coturn конфигурировать надо, или только накатить?

Да там конфиг огромный. Не знаю я. Очень давно я настраивал его для частного использования – потому и конфигурировал. Но вообще, вероятно, если какой-нибудь быстрый how to на твой случай. И может быть даже и достаточно просто накатить и стартнуть.

kostyarin_ ★★ ()
Ответ на: комментарий от yoholo

В адресе сервера не забудьте указать «turn:» префиксом и добавить данные учётной записи (TURN требует). Получится что-то вроде «turn:myuser:mypassword@ip_servera:3478?transport=tcp».
Конфиг минимальный для coturn можно сделать типа такого:

fingerprint
lt-cred-mech
user=myuser:mypassword
realm=myserver.domain
no-stun
no-cli

Естественно не забываем поменять параметры «user», «realm», и соответственно поменять данные в URL сервера.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)
Ответ на: комментарий от yoholo

TURN в рамках WebRTC должен её использовать. И параметр с аутентификацией «media.peerconnection.default_iceservers» вроде должен быть такой:

media.peerconnection.default_iceservers=[{'url':'turn:my_turn.server.com:3478?transport=tcp', 'username': 'myuser', 'credential': 'mypassword'}]

sanwashere ★★ ()
Ответ на: комментарий от yoholo

В общем, поднял я ради интереса у себя coturn, и проверил конфигурацию.

coTURN (/etc/coturn/turnserver.conf):

fingerprint
lt-cred-mech
user=myuser:mypassword
no-stun
no-cli

Firefox (about:config):
media.peerconnection.default_iceservers=[{"url": "turn:turn.server.com:3478?transport=tcp", "username": "myuser", "credential": "mypassword"}]
media.peerconnection.ice.tcp=true
media.peerconnection.ice.no_host=true
media.peerconnection.ice.relay_only=false
media.peerconnection.use_document_iceservers=false

В таком варианте вроде лишние адреса не утекают, и браузер всегда использует мой TURN.

P.S. «realm» в turnserver.conf можно не указывать.
P.P.S. Главное не забыть запретить использование исходящего UDP в системе.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 5)
Ответ на: комментарий от sanwashere

А webrtc тест проходит(https://browserleaks.com/webrtc), или везде n/a?
Отключить webrtc никакой проблемы нет.
Проблема в том, чтобы тест показывал ip socks сервра или туннеля через который идет подключение.
Если просто дропать все udp подключения в обе стороны не отключая «media.peerconnection», webrtc палит внутренний ip сетевого интерфейса.
Каким образом сервер получает его? И что за параметр «url»? ip turn сервера разве недостаточно?

yoholo ()
Последнее исправление: yoholo (всего исправлений: 1)
Ответ на: комментарий от yoholo

Если включён «media.peerconnection.ice.no_host=true», то локальный интерфейс не палит. В принципе, с настройками, которые я приводил последними палит только адрес TURN сервера, даже с разрешённым UDP.
По поводу параметра «url»: там можно же и IP сервера указывать, никто не запрещает. «turn:» - это включение протокола TURN, иначе он будет использовать сервер только в роли STUN, что не нужно в вашей ситуации.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 3)
Ответ на: комментарий от sanwashere

Вот браузер обратился к stun серверу. Получил в ответе свой ip.
Кстати ищу в логе wereshark свой ip, и не нахожу. ХЗ как именно он передается.
Что происходит потом?

  1. Передача полученного ip серверу(по tcp) инициировавшему запрос к stun?
  2. Передача полученного ip серверу(по tcp) инициировавшему запрос к stun с последующим подключением к внешнему ip клиентской машины инициированным сервером?
  3. хз?
yoholo ()
Ответ на: комментарий от yoholo

IP в ответном пакете проходит через XOR (0x2112A442 для IPv4 и «свежей» версии STUN), так что в «чистом» виде там его и не будет.

После получения адреса от STUN (атрибут XOR-MAPPED-ADDRESS), ICE библиотека браузера откроет локальный порт на прослушивание и сформирует описание [адрес из STUN и номер порта] в виде кандидата с типом srflx («server reflexive»), и передаст его веб-приложению (обычно JavaScript), которое уже отправит эту строку-описание удалённой стороне посредством какого-либо сигнального протокола (обычно WebSocket). На той стороне веб-приложение, получив строку, передаст её в свою библиотеку ICE, которая попытается проверить связность, - послать запрос по указанному в описании (кандидате) адресу и номеру порта (опять STUN, но именно не серверу, а другой стороне; обычно посредством UDP, но TCP кандидаты тоже существуют). Если запрос долетит до первой стороны (его поймает библиотека ICE), то она в свою очередь тоже отправит ответный запрос. При получении ответного запроса обе стороны будут считать связь посредством данного кандидата «успешной», и могут/будут использовать этот адрес в качестве канала для данных (обычно RTP/RTCP через DTLS или двоичные сообщения посредством SCTP через DTLS).

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 2)
Ответ на: комментарий от sanwashere

Первым делом поставил на сервер TURN и поробовал использовать.
Толку от этого никакого, идея была в том чтобы сделать спуфинг на ip socks сервера.
socks сторонний, стоит не на сервере с TURN и проверку связанности не пройдет.
Так что пока хз как это реализовать.

yoholo ()
Ответ на: комментарий от yoholo

Я указывал работающую конфигурацию выше. Она прекрасно работает, и также прекрасно обманывает webrtc тесты.

Принцип работы webrtc? (комментарий)

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)
Ответ на: комментарий от yoholo

И ещё: при использовании TURN через TCP, будет поддерживаться постоянное подключение до сервера TURN, и проблема приёма подключений на SOCKS прокси не будет стоять, так что данные ходить будут, при этом будет доступен и виден только внешний IP сервера TURN.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)
Ответ на: комментарий от sanwashere

ОК. У меня не сработало и хотелось бы уточнить детали.
syslog в конфиге включен по умолчанию, но в /var/log ничего не падает.
Если включить log-file тоже ничего нет.
Клиентская машина linux?
Параметр «realm=» обязателен, или достаточно ip?

yoholo ()
Ответ на: комментарий от yoholo

- Клиентская машина была Linux, но это неважно. Тут важно наличиек самого Firefox.
- «realm» необязателен.
- Логи я и не включал, ибо смотрел в about:webrtc, но можно включить чем-то типа такого:

verbose
log-file=/path/to/my/log

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 1)
Ответ на: комментарий от sanwashere

ок. все еще сомневаюсь, что все просто. мои результаты с TURN:
https://cdn1.savepice.ru/uploads/2020/3/25/93070a0902ee4c39f42f4618a6d4ba07-full.png
https://cdn1.savepice.ru/uploads/2020/3/25/a08f0a586e36647a634d6cc1f244d48f-full.png
https://cdn1.savepice.ru/uploads/2020/3/25/a8253eff60498f190e59f3c7c6b76db7-full.png
Если у тебя идентично, предложенное решение не подходит.
Если нет, можем обменяться адресами TURN серверов, для уверенности что проблема на стороне сервера а не клиента?

yoholo ()
Ответ на: комментарий от yoholo

https://cdn1.savepice.ru/uploads/2020/3/25/18b599453dd9dc8c6760f41e73a7576b-f...

Я совсем не в Амстердаме, как вы понимаете. Там только адрес сервера TURN (логин «myuser», пароль «mypassword»). Можете проверить - пока не буду гасить его. Сам сервер для «успокоения души» имеет дополнительную включённую опцию «no-udp», чтобы точно проверять только TCP.

sanwashere ★★ ()
Последнее исправление: sanwashere (всего исправлений: 3)