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

https://tools.ietf.org/html/rfc7478

Все что касается сетевых протоколов гуглится банально: баззворд + rfc

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

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

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

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

Так на что вы его подменять-то собрались? Если на совершенно левый, то ICE не пропустит STUN (server reflexive) кандидата в виду неудачной проверки связности.

Я не знаю, что такое проверка связности и ICE.
Уверен, есть простое решение.

Объясняю «на пальцах».
Для клиента определяются 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. Проблему стоит всё-таки сформулировать более внятно.

Идея в том, чтобы обращаться к локальному 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 сервера в процессах(

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

coturn стартанул, но не вижу на каком порту он висит. В netstat отсутствует.

3478/UDP и 3478/TCP обычно. И да, кстати, - браузер будет использовать 3478/UDP по умолчанию.

Нет возможности использовать по умолчанию 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:~$ 

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

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

Вы хотите через 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

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

С этим:

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 сервером, кроме того что реализацию в паблике найти не удалось?

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

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

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

Проверьте на работоспособность указанный вами сервер TURN тут: https://test.webrtc.org/

Я поставил 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?

Возможно есть 100% рабочий паблик turn?

Да не надейся. Накати coturn на какой-нибудь дешманский OpenVZ-хостинг.

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

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

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

В адресе сервера не забудьте указать «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=myuser:mypassword»
При обращении к coturn потребуется аутентификация?

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

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

Точно нужен пароль? Почему нельзя оставить без аутентификации?

realm=myserver.domain точно нужно? Почему недостаточно ip?

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

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

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

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

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

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

Значит turn не подходит.

Ну, дело ваше. Данные настройки прячут IP, как локальный, так и провайдерский, так что тут мне добавить нечего.

Для этого достаточно «media.peerconnection=false».

Кто знает, - вдруг вам обязательно нужен WebRTC =).

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

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

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).

Тогда у меня нет предположений, как реализовать подмену внешнего ip на ip socks для webrtc тестов.

Как я уже говорил,- вам подходит только TURN. Но TURN серверы никто просто так не держит, ибо трафик таки денег стоит.

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

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

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

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

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

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

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

ок. все еще сомневаюсь, что все просто. мои результаты с 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 серверов, для уверенности что проблема на стороне сервера а не клиента?

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

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

Так это адрес TURN?)
Так должен палиться адрес прокси через который идет подключение к TURN.

А вот это уже невозможно. Но какая разница - адрес SOCKS или адрес TURN?

Может возможно, но на данный момент не реализовано?
С соксификацией dns на данный момент проблем не возникает, хотя там тоже udp.