TCP соединение между машинами под NAT-ом и файрволом

Всем привет. Вот мучаюсь одним вопросом.
Есть две машины в разных сетях. У обоих внутренние натовские адреса. Обе за файрволами. Входящие соединения запрещены. Или даже крайний случай, разрешено только 80 наружу. Как заставить их общаться? Обе машины полностью подконтрольны. настройки шлюзов недоступны. Возможно ли установить между ними прямое TCP соединение? Или может UDP спасет?

 

vpn

 

Причем тут это? Насколько мне известно VPN реализуется поверх существующего канала связи. У меня же такого канала нет. И задача собственно и состоит в его создании.

 

дык какие проблемы, возьми сервер, поставь на него впн-демон и обьедени свои машины в впн-сеть

 

Хм, возможно это выход. Не знаком хорошо с устройством VPN, потому еще вопросы. После установления соединения трафик будет идти напрямую между хостами без участия VPN сервера? Как насчет файрвола, он будет думать что хосты на вебсервер ходят за парнухой?

 

justcoder
VPN, для общего развития. В ответ на твой вопрос: трафик будет идти через vpn-server, который будет маршрутизировать его. Файрвол будет показывать соединение с этим сервером, но весь трафик зашифрован, так что ему не придётся думать.

 

Все-таки автор прав - при чем тут VPN?

В оригинале, указывается что ОБЕ машины за Натом, и соответсвенно чтобы вы там за фаерволом ни запускали (самый навороченный сервер с супер-пупер VPN) это не поможет. Тех кто посылал на VPN, я могу предложить почитать про фаерволл.

Наверное, должен быть кто-то третий, находящийся "снаружи". Вот через него можно организовать соединение двух машин. (Этим "снаружи" может быть VPN сервер - но это совсем не обязательно)

 

Я так понял, получается, что
1 сокет - {машина1 + промежуточный_сервер}
2 сокет - {машина2 + промежуточный_сервер}

Промежуточный сервер посредством внутри-процессных коммуникаций скидывает данные с одного соединения на другое?

 

Вот этим третьим и будет vpn-сервер. О чём спор?

 

Спасибо за ссылку, читали уже.

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

Законнектились скажем оба к этому третьему, разве нет возможности заставить его познакомить удаленные сокеты, дабы дальше они общались без него. Может технологии айпи спуфинга тут помогут?

 

Не помогут.

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

 

Не в сокрытости дело, а в экономии трафика на сервере. Два отдельных хоста это частный случай из множества в большой сетке.
Всем наверное знакома проблема LowId в ослинных сетях, или невозможность обмена файлами в ICQ, и многие другие примеры упирающиеся в невозможность создания прямого соединения. Вот и хочется выяснить, имеет ли она решение в принципе. Если сервер есть, не халявный даже а свой, и мутить там можно что угодно, и на клиентах тоже можно мутить. Неужели какой то там нат на пару с другом брандмауэром не дадут двум беднягам пообщаться наедине?

 

У этой проблемы есть решение, например, UPNP шлюз, или IGD, или NAT-PMP.
http://en.wikipedia.org/wiki/NAT-PMP
http://en.wikipedia.org/wiki/Internet_Gateway_Device
Но это все требует специальной настройки фаервола.

Давайте посмотрим, как работает NAT\фаервол (упрощенно):

Отправка:
1)На фаервол приходит пакет с локалной сети с адресом\портом "наружу"
2)Фаервол запоминает старые адрес\порт отправителя (возможно плюс адрес получателя), и выделяет первый свободный порт у себя.
3)Фаервол заменяет внутри пакета адрес отправителя на свой а номер порта на выделенный.
4)Фаерволл отправляет пакет "наружу"

Прием:
1)На фаервол приходит пакет на определенный порт с внешней сети.
2)Фаервол смотрит, запоминал ли он такой порт (возможно сравнивается еще и адрес отправителя(номер порта не сравнивается, так как при connect\accept выделяется новый порт)) - если нет - прибивание пакета.
3)Фаервол заменяет адрес получателя на оригинальные, и отправляет пакет во внутреннюю сеть.

Делайте выводы ...

 

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

 

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

 

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

Хотя я подумал можно ведь подсмотреть у получателя пакета какой порт, но как передать его назад.

 

Если фаерволом в пришедших на конкретный порт "снаружи" пакетах не проверяется адрес отправителя, тогда все просто:
1)Обе машины конектятся на внешний "координатор".
2)Координатор засекает внешние адрес\порт для каждого клиента.
3)Координатор передает засеченные данные клиентам.
4)Клиенты используют полученные адрес\порт для связи.

Ньюансы:
1) Правило "наружу" создается фаерволом только в случает посылки пакета "рукопожатия" для TCP-соединения, в остальных случаях пакет просто прибивается.
2) Правило "наружу" убивается по таймауту или по пришедшему пакету "закрытия сессии"
Поэтому для алгоритма выше нужно хакакть стек TCP\IP.

 

Ultrin Faern
Ну я это и имел в виду, моглибы так сделать p2p и torrnet? Тем более координаторы могут служить хабы/твикеры!

 

Кто знает, может и проканает, не так уж много этих портов.

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

В том то и дело что до получателя этот пакет не доходит

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

Не понял, зачем хакать, как, и где, у координатора?

 

ИМХО решение есть, но я не знаю как это реализовать + возможна логическая ошибка и техническая неточность в моем рассуждении.
Когда клиент из локальной сети устанавливает соединение с внешним сервером происходит "трехэтапное рукопожатие" и шлюз запоминает айпи сервера и выделяет порт для приема данных. При этом внешний сервер знает порт(его вроде можно получить из структуры типа sockaddr которая заполняется вызовом accept) который выделяет шлюз и ask и syn номера которые исполбзуются айпи протоколом.
Вот если эти данные передать дргому компьютеру и использывать их там то для клиента будет происходить все так как будто он общается с внешним сервером.А данные будут приходить от другого (нужного нам) компьютера.
Похожий метод использывался в какой то статье в которой описывалось как вклиниться чужое TCP/IP соединение.
А вот как это реализовать на практике я пока не совсем знаю.
Мне эта тема тоже интересна если кто реализовывал плиз поделитесь исходниками.