Серые IP и входящий TCP - возможно или нет?

Только подымать что-то вроде VPN. Я ssh -L для такого использовал.

Задачка - завернуть часть трафика через tcp (важно) напрямую между двумя ПК, притом сервером является только один из них и он может оказаться с серым IP за NAT’ом провайдера.

Peer-to-Peer Communication Across Network Address Translators

А также работы Samy Kamkar 1 2 3 4

На практике не проверял, 100%-й работы точно гарантировать не удастся. Всегда имейте в запасе прокси.

Только подымать что-то вроде VPN

да, видимо придётся городить UDP транспорт для TCP потоков

Я ssh -L для такого использовал.

ему же один фиг надо иметь доступ к порту на сервере
в теории можно цепануть оба через ssh -R к псевдоturn’у но тогда трафик пойдёт через turn

100%-й работы точно гарантировать не удастся. Всегда имейте в запасе прокси.

чем дальше я погружаюсь в дебри обычного пользовательского интернета тем больше я в афиге от того что за последние 30 лет простая задача «передать видосик с компа на комп» обросла просто адиозным количеством несовместимостей и палок в колёсах :-D

но тогда трафик пойдёт через turn

Это неустранимо. Или нужен какой-то доступ к шлюзу хотя бы с одной стороны для включения DNAT снаружи.

Был старый прикол (на баше?), как какой-то немец звонит себе домой, выжидает столько-то гудков и кладёт трубку. Модем у него дома, получив нужное количество гудков, коннектится в интернет и выкладывает на домашней страничке этого немца свой IP, по которому потом немец логинится на домашнюю машину. Если не заходит, инет отваливается по таймауту.

Если не заходит

Модем значить дешевый. Большинство модемов средней и выше категории вам мог бы сказать из wav-чика голосом IP :)

Байка из 90-х, вряд ли тогда такое было.

Байка из 90-х, вряд ли тогда такое было.

Голосовые модемы появились в начале 90, так от Zyxel - в 92 году. Но даже не важно, в 90-е как раз IP скорее всего можно было получить именно по аналоговому модему, вряд ли у него была вторая линия.

гугли dynamic dns nat

Интересно, можно ли было написать стартовое сообщение без кривляний?

гугли dynamic dns nat

Это для белых динамических, для серых дднс бесполезен как и мой [портовый шлюшарий] сторонний информатор

Интересно, можно ли было написать стартовое сообщение без кривляний?

Нет

У меня pwnat не заработал. Я действовал строго по примеру. Возможно за 12 лет с тех пор, как эта тулза была написана, что-то в реализации NATов изменилось, и они теперь блокируют UDP пакеты, которые шлёт pwnat.

ну, тогда поднимай свой vps где-нибудь и пробрасывай туннели. как-то так.

У меня сейчас так и сделано, но есть хотелка отделить мелкий быстрый трафик (который остаётся на туннелях) от медленного но сильно объемного ибо каналы дюже дорогими выходят - для бесплатного решения это несколько разорительно

сквид.

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

и да, таки с разделением доменов по каналам тоже могут быть заморочки, ибо некоторые сайты могут и не понять, если их трафик начинают делить по разным интерфейсам.

Для домашнего пользователя с простой сетью может помочь такой вариант https://habr.com/ru/post/279969/

В корп сетях скорее всего не будет работать

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

нюанс лишь в том что толщина канала вынуждена измеряться в гигабитах

Для домашнего пользователя с простой сетью может помочь такой вариант https://habr.com/ru/post/279969/ В корп сетях скорее всего не будет работать

это всё для прокидывания порта из локалки через роутер на внешний белый адрес, это у меня сделано (правда не работает с микротиками :-D ) а мне надо проброс порта между внешним серым адресом роутера и внешним белым адресом провайдера - т.е. достучаться в локалку извне когда известны:

• внешний белый адрес провайдера, на который он коммутирует роутер (это не белый адрес роутера!)
• серый адрес роутера в сети провайдера
• внутренний адрес в локалке

с юдп это иногда работает если кинуть пакет на сервер в инетике и по обратному адресу закидывать пакеты с другого пк (что мне и надо) - если бы это можно было бы реализовать в тсп - было бы волшебно, но видимо проще сдаться и перейти на юдп

Мм, я помню в былые времена скайп использовал для таких целей концепцию суперноды. Т.е. юзал какого-то условно рандомного челика из своих пользователей в качестве прокси для других пользователей

куда тебе гигабиты-то? ты хочешь на халяву стриминговый сервер зафигачить? не выйдет.

все эти наколенные решения - это не про гигабиты. это про васянский сервер для дохлого локалхоста. а если нужны честные гигабиты - тогда хостинг и нормальное железо, широкие каналы, 24/7... вот это всё. но это будет не так уж дёшево. как только вопрос ставится о деньгах, аппетиты обычно уменьшаются и вместо гигабитов выясняется, что хватит и пары мегабит :)

и вообще, гигабиты на васянском сервере - это про локалки.

а так, если смотреть пропускную способность сетей в абстрактном удалённом доступе, то там пара сотен мегабит - это ну просто шоколадно, это если повезло. а в реальности всё обычно гораздо хуже, но оно и не нужно быстрее, потому что для обычного юзверя и браузера не нужны такие каналы.

куда тебе гигабиты-то?

Пытаемся выложить в бесплатный доступ то, что охраняет Шереметьево :-) Изучу спрос на охранную софтинку: бесплатную, но с закрытыми исходниками

Так что нет, речь не про васян сервер.
Для Платников все работает на честных каналах в чужом цоде, где аренда каналов покрывается платой за сервис, бонусом большинство Платников сами имеют свои мощности для прокидывания каналов и решают эту задачу сами.
Я лишь хочу слепить костылик для возможности минимально дёшево связать бесплатного клиента с его системой сбора видео. Видео не наш профиль и мы вполне довольны интеграцией с трассиром и интеллектом, но вангую что бесплатные клиенты не имеют оных и соотв не откажутся от бесплатной системы видео верификации заместо платного видеонаблюдения

кстати, костылик, гугли webrtc player p2p

Мм, я помню в былые времена скайп использовал для таких целей концепцию суперноды. Т.е. юзал какого-то условно рандомного челика из своих пользователей в качестве прокси для других пользователей

Ну суперноды - это типа DHT в торрентах, но изначальную задачу не решает - как получить первый IP, где уже загрузить список.

тогда тем более непонятно. если это чистая коммерция, то почему бы не купить человеческий сервер на хостинге и не маяться дурью. как известно, кроилово ведёт к попадалову. и я не спец в бюрократии, но эксплуатация чужого софта может вызвать всякие там неожиданные проблемы юридического характера. это надо изучать лицензию и всякие тонкости публикации и прав на использование такого софта.

тогда тем более непонятно.

Я не готов объяснять по четвёртому кругу

Если я правильно понял, оп решает задачу передачи большого объема данных п2п, но не особо хочет гонять их через свой сервер. Толи денег жалко, толи товарища майора боится. Но опять же, если я правильно понял, смущает больше объём трафика, а не неполная децентрализация. Список ip по объёму не велик, его можно и с своего сервера отдавать. Тем более никто не заставляет отдавать вообще весь список, если он прям большой

Йеп! Список ip и всякая служебка занимает муку и она остаётся бегать через сервер. Задача лишь организовать между двумя пк, которые могут общаться с сервером, параллельный канал без участия сервера, для передачи сильно габаритных данных.

Если совсем на пальцах то:
А и Б - компьютеры, В - сервер.
Компьютер А переодически кидает серверу В сообщения (и сервер В соотв знает белый IP А) и попутно открывает нужные порты через upnp в своей локалке.
Компьютер Б переодически запрашивает сервер В о событиях, которые прислал А и сервер В отправляет их компьютеру Б, попутно оповещая его о белом адресе компьютера А.
По некоторым событиям, компьютер Б изволит заиметь с компьютера А большой кусок данных, который компьютер А с радостью отдаст по запросу в известный обоим порт.

И все это отлично работает с провайдерами, которые выдают динамические белые ip адреса (или с пробросом большого куска данных через сервер, аналогично сообщениям).
Беда только в том что некоторые провайдеры выдают серые ip адреса и компьютер Б не сможет достучаться до А по белому ip, с которого приходят сообщения на сервер.
Вот именно о такой ситуации и был вопрос. Но как показали вялые потуги - с tcp тут ловить нечего, задача помечена нерешаемой, увы и ах

Но даже не важно, в 90-е как раз IP скорее всего можно было получить именно по аналоговому модему, вряд ли у него была вторая линия.

Именно по этому

модемов средней и выше категории вам мог бы сказать из wav-чика голосом IP

не мог. IP ещё не было на момент звонка. Софтина после звонка звонила, получала ip и публиковала его.

Алсо, я не припомню спич-ту-текста в 90-ых на домашних PC.

Именно по этому

Охренеть логика. Если модем соединился по диалапу, то второй входящий даже при услуге информирования о втором звонке (что тоже появилось весьма недавно) всё равно не мог рассказать, так как командный и data режим в модеме неразделены.

не мог. IP ещё не было на момент звонка. Софтина после звонка звонила, получала ip и публиковала его.

Куда звонила? По IP? Вот опубликовать можно было, скорее всего я думаю так выглядело: звонок именно запускал процедуру диалапа и опубликования IP на внешнем сервере — вот о таком я много читал.

Если модем соединился по диалапу, то второй входящий
Куда звонила? По IP?

У тебя дисклескися?

0. Софт на ПеКа + модем слушают аналоговую линию на предмет входящих звонков.
1. Входит звонок, софт на ПеКа считает гудки. Трубка вешается звонящим.
2. Софт с ПеКа инициирует дозвон через модем до прова.
3. Устанавливается PPP-соединение, клиент получает IP.
4. Софт на ПеКа генерит страничку с IP и загружает её на какой-нибудь GeoCities.

Какие «вторые линии», какой «второй входящий», какой «звонил по IP», норкоман? Всё происходит по единственной обычной телефонной линии.

Дяденька, прежде чем возмущаться не по делу, стоило бы дочитать сообщение до конца, где и была изложена эта схема.

до конца, где и была изложена эта схема.

Зачем ты изложил в самом конце схему, которую изложили в самом начальном посте? Точнее, зачем ты изложил всё остальное, не имеющее никакого отношения к схеме из начального поста?

Зачем ты изложил в самом конце схему, которую изложили в самом начальном посте?

Может потому что вы тупой и не умеет читать и понимать шуток? На то сообщение был шутливый ответ, в том числе потому что и тот пост pr849, хоть и отвечен ТС-у, не отвечал на вопрос, как получить IP, если оба конца серые.

Точнее, зачем ты изложил всё остальное,

Ну то есть, вы не пропарсив накатали «схему» по пунктам повторив идею уже в третий раз в этом топике и так и не сообразив, что я ни разу не отвечал ТС-у.

Большинство модемов средней и выше категории вам мог бы сказать из wav-чика голосом IP :)
Может потому что вы тупой и не умеет читать и понимать шуток?

Да, я тупой, и не понял в каком месте слово «лопата».

В соседней теме тоже самое обсуждаю, уже частично сделал обмен файлами между двумя узлами за нат, используя внешний стун и свой mqtt сервер для обмена командами/адресами. Проблема в тсп в том, что маршрут в нате создаётся сложнее чем для удп в силу специфики протокола (статусы пакетов, правило трёх рукопожатий и прочее бла бла бла) Те напрямую туннель по тсп между 2 узлами за нат невозможен, а вот удп без проблем, на Хабре человек опенвпн поднимал башем между 2 узлами за нат

Решение я бы видел такое - поднятие опенвпн по удп и заварачивание в него всего трафика между узлами за нат, но может потребоваться как я понимаю анализ адресов - можно внутри сети провайдера оказаться, и выполнять автоматическое поддержание и пересоздание тунеля

Мои ниокры ) С++ vs RTSP proxy/server

А ссш сервер умеет по удп? Если да, то не балуясь башем, можно накодить и анализ адресов и поднятие на нужном порту ссш сервера и тунеля до него.

Это вообще решаемая задача?

Я бы посмотрел как подобная задача решена в Интернет-телефонии, например, в «СИПе».

Для связи двух вычислительных устройств потребуется внешний третий вычислительный узел с постоянным сетевым адресом, выступающий переговорщиком-справочником-посредником для установления соединения между двумя «собеседниками».

Сначала каждый из «собеседников» шлёт запрос к посреднику о желании установки соединения с нужным «собеседником». Посредник отвечает первому «собеседнику» сетевым адресом и портом второго «собеседника» и приглашает к соединению второго «собеседника».

Далее данные передаются напрямую между двумя ЭВМ по сетевым адресам и портам, полученным на шаге переговоров от посредника. Завершение соединения двух ЭВМ осуществляется таким же образом через посредника, который поочередно отключит каждого из «собеседников» и уведомит каждого об этом.

Я бы посмотрел как подобная задача решена в Интернет-телефонии, например, в «СИПе».

Она везде решается через udp, но в моем случае уже был реализован hls через tcp с stun’ом и я наивно надеялся что несколько десятилетий развития интернетов прошли не зря и столь примитивная задача может быть решена «в лоб».
Я ошибался :-D

в моем случае уже был реализован hls через tcp с stun’ом

трафик то так же как с вашим турном через сервер ходит? в чем решение тогда задачи, если вы просто проксируете видеопоток через сервер?

столь примитивная задача может быть решена «в лоб»

задача не примитивная отродясь, иначе не было бы предложено столько новых протоколов обхода ее, но решение в лоб у нее есть - использование ipv6

трафик то так же как с вашим турном через сервер ходит? в чем решение тогда задачи, если вы просто проксируете видеопоток через сервер?

Решения нет, задача как раз была убрать турн из этой цепочки, завязанной на тсп

задача не примитивная отродясь, иначе не было бы предложено столько новых протоколов обхода ее

Задача то как раз примитивная если бы за последние годиков 30 хоть кто-то озадачился upnp способным пройти от клиента до внешнего ойпи

задача как раз была убрать турн из этой цепочки, завязанной на тсп

так если у вас проксируется трафик через сервер, то и стун зачем нужен!?

кто-то озадачился upnp

всмысле кто то? он есть даже в бытовых роутерах, но провайдер вам не обязан это обеспечивать, он продает белый адрес

так если у вас проксируется трафик через сервер, то и стун зачем нужен!?

что-бы убрать турн
по крайней мере в случаях когда у пк1 адрес белый

всмысле кто то? он есть даже в бытовых роутерах, но провайдер вам не обязан это обеспечивать, он продает белый адрес

всмысле что upnp как и 20 лет назад работает только до бытового роутера но не может пробить канал в инет если за бытовым роутером есть еще один роутер
и вот если бы был некий «global upnp» в виде широко применяемого стандарта то провайдеру ничто не мешало бы обеспечивать его работу либо за деньги либо в качестве маркетинговой плюшки, притом если бы все практиковали последнее то считай что это было бы бесплатным дефолтом как всякие айпитиви

по крайней мере в случаях когда у пк1 адрес белый

аа понял, надежда на белый ип с одной стороны, чтобы запустить трафик минуя сервак

было бы бесплатным

ахахахахаа ))) наивные мечты

я пока сделал пуляние трафика в одну сторону через оба пк за нат, щас вылижу код, достестирую, потом шаблонно в обе стороны допилю чтоб по запросам трафик ходил и начну копать webrtc, чтоб не тупо файло через udp слать, а сразу видеопоток в тот же браузер, как и с hls у вас, НО БЕЗ серверов.

а так уапще прикольно получается, можно гонять файлы через наты с помощью udp без всяких тунелей и прокси-серверов и как известно udp быстрее tcp

Попробуй разобраться в stun

Решения нет, задача как раз была убрать турн из этой цепочки, завязанной на тсп

мне тут насоветовали легкий WebRTC сервер https://janus.conf.meetecho.com/

оказался очень даже вещь! прокидывается через наты вообще БЕЗ БЕЛЫХ АДРЕСОВ на любых концах, используя сторонние STUN сервера + сигнальный сервер (в моем случае MQTT)