LINUX.ORG.RU

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

 , ,


2

2

Осталось решить последнюю задачку - есть сервис на манер turn’а, который связывает два ПК за nat’ами, соотв сервис знает внешние ip обоих ПК и раздаёт их [как портовая шалюха] бережно информирует компуктеры о том что у их [полового] сетевого партнера ip поменялся (если динамический).
Задачка - завернуть часть трафика через tcp (важно) напрямую между двумя ПК, притом сервером является только один из них и он может оказаться с серым IP за NAT’ом провайдера.
В случае с белым динамическим все просто и работает, в случае с udp иногда (не у всех провайдеров) помогает кинуть пакет ПК «сервером» в псевдоturn из нужного порта и ждать пакеты от ПК «клиента» (которые летят в Ip и порт из которого они прилетели в turn - я так понимаю по похожей логике работает stun) а вот как завернуть TCP чот не могу придумать - пров же сразу схлопнет порт на внешнем адресе когда когда клиент загасит подключение к псевдоturn’у?
Это вообще решаемая задача? Может можно как-то «передать» само «соединение» или как-то параллельно попользовать порт который nat держит открытым при наличии связи ПК «сервер»-псевдоturn?

★★★★

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

Peer-to-Peer Communication Across Network Address Translators

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

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

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

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

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

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

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

rukez ★★★★
() автор топика
Ответ на: комментарий от AITap

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

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

rukez ★★★★
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rukez ★★★★
() автор топика
Ответ на: комментарий от cobold

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

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

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

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

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

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

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

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

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

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

rukez ★★★★
() автор топика
Ответ на: комментарий от vodz

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

wolverin ★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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