Возможно ли установить P2P соединение между двумя машинами находящихся
в интернете, без промежуточного сервера. О машинах известно всё, т.е.
IP и пр.
Если да, где то можно посмотреть примеры программ? Желательно бы в
сырцах.

nen777w wrote:
>
> Возможно ли установить P2P соединение между двумя машинами находящихся
> в интернете, без промежуточного сервера. О машинах известно всё, т.е.
> IP и пр.
> Если да, где то можно посмотреть примеры программ? Желательно бы в
> сырцах.

TCP соединение есть p2p соединение.

--
Maxim Yegorushkin

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

Здравствуйте, dkDimon1976, Вы писали:

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

Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям

Здравствуйте, Антонш, Вы писали:

А>Здравствуйте, dkDimon1976, Вы писали:

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

А>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

Здравствуйте, dkDimon1976, Вы писали:

D>Здравствуйте, Антонш, Вы писали:

А>>Здравствуйте, dkDimon1976, Вы писали:

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

А>>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
D>Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, dkDimon1976, Вы писали:

D>>Здравствуйте, Антонш, Вы писали:

А>>>Здравствуйте, dkDimon1976, Вы писали:

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

А>>>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>>>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
D>>Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

А>ежели клиентов — разумное кол-во и они не часто "переезжают", то самый простой способ, решаемый штатными средствами это в каждом клиенте в качестве адресов пиров прописывается адрес сервера и некий порт, на сервере настраивается порт-форвард с ряда портов на соответствующие пиры,
А>таким образом клиент думает что идет на соседа, на самом деле он идет на сервер где тот отправляет соединение на нужного используя номер порта как индек получателя. недостаток — сложность конфигурирования при изменении топологии и конечное чило доступных портов (по-хорошему около 3 с половиной тысяч)
В принципе хорошее решение... Но опять же есть несколько нюансов. Во-первых, прописать в используемом клиенте адрес нельзя, т.е. придется перехватывать пакеты и пересылать их руками (читай написать программу для этого) — ну это в принципе решаемо. Второе — как осуществить форвардинг пакетов на сервере? Есть ли готовые решения для этого?

Здравствуйте, dkDimon1976, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, dkDimon1976, Вы писали:

D>>>Здравствуйте, Антонш, Вы писали:

А>>>>Здравствуйте, dkDimon1976, Вы писали:

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

А>>>>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>>>>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
D>>>Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

А>>ежели клиентов — разумное кол-во и они не часто "переезжают", то самый простой способ, решаемый штатными средствами это в каждом клиенте в качестве адресов пиров прописывается адрес сервера и некий порт, на сервере настраивается порт-форвард с ряда портов на соответствующие пиры,
А>>таким образом клиент думает что идет на соседа, на самом деле он идет на сервер где тот отправляет соединение на нужного используя номер порта как индек получателя. недостаток — сложность конфигурирования при изменении топологии и конечное чило доступных портов (по-хорошему около 3 с половиной тысяч)
D>В принципе хорошее решение... Но опять же есть несколько нюансов. Во-первых, прописать в используемом клиенте адрес нельзя, т.е. придется перехватывать пакеты и пересылать их руками (читай написать программу для этого) — ну это в принципе решаемо. Второе — как осуществить форвардинг пакетов на сервере? Есть ли готовые решения для этого?

что касается клиента — то пишется маленькая приблудка — порт маппер (в принципе таких уже понаписано много, почти любой персональный прокси такое умеет) и прописывается хост получателя в файлик hosts — адрес_клиента 127.0.0.1 — таким образом программа будет соединятся со своим компьютером и неким зашитим портом ххх, затем локальный порт-маппер отправляет соединение на твой сервер:порт (кстати говоря, можно написать умный маппер, который будет брать с сервера номер порта для этого клиента)

стандартный софт для порт-форвардинга в линукс/юникс это что-то вроде ipchain, ipfw итп, в общем в nix системах это легко,
в win системах нужно поставить нечто... я для подобных вещей сам писал маппер, думаю что такого софта как грязи

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, dkDimon1976, Вы писали:

D>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, dkDimon1976, Вы писали:

D>>>>Здравствуйте, Антонш, Вы писали:

А>>>>>Здравствуйте, dkDimon1976, Вы писали:

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

А>>>>>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>>>>>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
D>>>>Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

А>>>ежели клиентов — разумное кол-во и они не часто "переезжают", то самый простой способ, решаемый штатными средствами это в каждом клиенте в качестве адресов пиров прописывается адрес сервера и некий порт, на сервере настраивается порт-форвард с ряда портов на соответствующие пиры,
А>>>таким образом клиент думает что идет на соседа, на самом деле он идет на сервер где тот отправляет соединение на нужного используя номер порта как индек получателя. недостаток — сложность конфигурирования при изменении топологии и конечное чило доступных портов (по-хорошему около 3 с половиной тысяч)
D>>В принципе хорошее решение... Но опять же есть несколько нюансов. Во-первых, прописать в используемом клиенте адрес нельзя, т.е. придется перехватывать пакеты и пересылать их руками (читай написать программу для этого) — ну это в принципе решаемо. Второе — как осуществить форвардинг пакетов на сервере? Есть ли готовые решения для этого?

А>что касается клиента — то пишется маленькая приблудка — порт маппер (в принципе таких уже понаписано много, почти любой персональный прокси такое умеет) и прописывается хост получателя в файлик hosts — адрес_клиента 127.0.0.1 — таким образом программа будет соединятся со своим компьютером и неким зашитим портом ххх, затем локальный порт-маппер отправляет соединение на твой сервер:порт (кстати говоря, можно написать умный маппер, который будет брать с сервера номер порта для этого клиента)

А>стандартный софт для порт-форвардинга в линукс/юникс это что-то вроде ipchain, ipfw итп, в общем в nix системах это легко,
А>в win системах нужно поставить нечто... я для подобных вещей сам писал маппер, думаю что такого софта как грязи
А при форвардинге адрес получателя и отправителя в пакете какие будут?

Здравствуйте, dkDimon1976, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, dkDimon1976, Вы писали:

D>>>Здравствуйте, Аноним, Вы писали:

А>>>>Здравствуйте, dkDimon1976, Вы писали:

D>>>>>Здравствуйте, Антонш, Вы писали:

А>>>>>>Здравствуйте, dkDimon1976, Вы писали:

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

А>>>>>>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>>>>>>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
D>>>>>Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

А>>>>ежели клиентов — разумное кол-во и они не часто "переезжают", то самый простой способ, решаемый штатными средствами это в каждом клиенте в качестве адресов пиров прописывается адрес сервера и некий порт, на сервере настраивается порт-форвард с ряда портов на соответствующие пиры,
А>>>>таким образом клиент думает что идет на соседа, на самом деле он идет на сервер где тот отправляет соединение на нужного используя номер порта как индек получателя. недостаток — сложность конфигурирования при изменении топологии и конечное чило доступных портов (по-хорошему около 3 с половиной тысяч)
D>>>В принципе хорошее решение... Но опять же есть несколько нюансов. Во-первых, прописать в используемом клиенте адрес нельзя, т.е. придется перехватывать пакеты и пересылать их руками (читай написать программу для этого) — ну это в принципе решаемо. Второе — как осуществить форвардинг пакетов на сервере? Есть ли готовые решения для этого?

А>>что касается клиента — то пишется маленькая приблудка — порт маппер (в принципе таких уже понаписано много, почти любой персональный прокси такое умеет) и прописывается хост получателя в файлик hosts — адрес_клиента 127.0.0.1 — таким образом программа будет соединятся со своим компьютером и неким зашитим портом ххх, затем локальный порт-маппер отправляет соединение на твой сервер:порт (кстати говоря, можно написать умный маппер, который будет брать с сервера номер порта для этого клиента)

А>>стандартный софт для порт-форвардинга в линукс/юникс это что-то вроде ipchain, ipfw итп, в общем в nix системах это легко,
А>>в win системах нужно поставить нечто... я для подобных вещей сам писал маппер, думаю что такого софта как грязи
D>А при форвардинге адрес получателя и отправителя в пакете какие будут?

это как настроить, обычно адрес и порт форвардера,
тут все упирается в конкретную программу которую надо "обмануть"

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, dkDimon1976, Вы писали:

D>>Здравствуйте, Аноним, Вы писали:

А>>>Здравствуйте, dkDimon1976, Вы писали:

D>>>>Здравствуйте, Аноним, Вы писали:

А>>>>>Здравствуйте, dkDimon1976, Вы писали:

D>>>>>>Здравствуйте, Антонш, Вы писали:

А>>>>>>>Здравствуйте, dkDimon1976, Вы писали:

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

А>>>>>>>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>>>>>>>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
D>>>>>>Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

А>>>>>ежели клиентов — разумное кол-во и они не часто "переезжают", то самый простой способ, решаемый штатными средствами это в каждом клиенте в качестве адресов пиров прописывается адрес сервера и некий порт, на сервере настраивается порт-форвард с ряда портов на соответствующие пиры,
А>>>>>таким образом клиент думает что идет на соседа, на самом деле он идет на сервер где тот отправляет соединение на нужного используя номер порта как индек получателя. недостаток — сложность конфигурирования при изменении топологии и конечное чило доступных портов (по-хорошему около 3 с половиной тысяч)
D>>>>В принципе хорошее решение... Но опять же есть несколько нюансов. Во-первых, прописать в используемом клиенте адрес нельзя, т.е. придется перехватывать пакеты и пересылать их руками (читай написать программу для этого) — ну это в принципе решаемо. Второе — как осуществить форвардинг пакетов на сервере? Есть ли готовые решения для этого?

А>>>что касается клиента — то пишется маленькая приблудка — порт маппер (в принципе таких уже понаписано много, почти любой персональный прокси такое умеет) и прописывается хост получателя в файлик hosts — адрес_клиента 127.0.0.1 — таким образом программа будет соединятся со своим компьютером и неким зашитим портом ххх, затем локальный порт-маппер отправляет соединение на твой сервер:порт (кстати говоря, можно написать умный маппер, который будет брать с сервера номер порта для этого клиента)

А>>>стандартный софт для порт-форвардинга в линукс/юникс это что-то вроде ipchain, ipfw итп, в общем в nix системах это легко,
А>>>в win системах нужно поставить нечто... я для подобных вещей сам писал маппер, думаю что такого софта как грязи
D>>А при форвардинге адрес получателя и отправителя в пакете какие будут?

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

Здравствуйте, dkDimon1976, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, dkDimon1976, Вы писали:

D>>>Здравствуйте, Аноним, Вы писали:

А>>>>Здравствуйте, dkDimon1976, Вы писали:

D>>>>>Здравствуйте, Аноним, Вы писали:

А>>>>>>Здравствуйте, dkDimon1976, Вы писали:

D>>>>>>>Здравствуйте, Антонш, Вы писали:

А>>>>>>>>Здравствуйте, dkDimon1976, Вы писали:

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

А>>>>>>>>Всё завист от того, почему именно они не видят друг друга. И почему это им виден сервер? Там что прокси? Маршрутизатор? Подсетка что-ли? Всё будет зависеть от конткретики. Потенциально, если от сервера сможет придти ответный пакет назад к хосту, то в чем проблема?
А>>>>>>>>p2p соединение к серверу. А тот в свою очередь к хосту номер 2. Естественно, серверную часть придется писать ручками. И лучше делать свой протокол HTTP-based. Он более дружественный к прогулкам через прокси и по подсетям
D>>>>>>>Машины не видят друг друга, т.к. разные подсети... Вообще архитектура сети такая: подсеть -> шлюз -> оптоволоконная магистраль. Таких подсетей около 100-150. Собственно сам обмен то организовать через сервер, в принципе, легко... Есть одно но! Нужно заставить конкретную программу, которая требует p2p, работать через сервер. Вижу решение в лоб: перехватывать пакеты данной программы на машине А и пересылать их на сервер, добавляя в пакет информацию получателя. На сервер извлекать из пакета получателя и отправлять ему, изменив в пакете источника на адрес машины А. И, соответственно, в обратную сторону так же.

А>>>>>>ежели клиентов — разумное кол-во и они не часто "переезжают", то самый простой способ, решаемый штатными средствами это в каждом клиенте в качестве адресов пиров прописывается адрес сервера и некий порт, на сервере настраивается порт-форвард с ряда портов на соответствующие пиры,
А>>>>>>таким образом клиент думает что идет на соседа, на самом деле он идет на сервер где тот отправляет соединение на нужного используя номер порта как индек получателя. недостаток — сложность конфигурирования при изменении топологии и конечное чило доступных портов (по-хорошему около 3 с половиной тысяч)
D>>>>>В принципе хорошее решение... Но опять же есть несколько нюансов. Во-первых, прописать в используемом клиенте адрес нельзя, т.е. придется перехватывать пакеты и пересылать их руками (читай написать программу для этого) — ну это в принципе решаемо. Второе — как осуществить форвардинг пакетов на сервере? Есть ли готовые решения для этого?

А>>>>что касается клиента — то пишется маленькая приблудка — порт маппер (в принципе таких уже понаписано много, почти любой персональный прокси такое умеет) и прописывается хост получателя в файлик hosts — адрес_клиента 127.0.0.1 — таким образом программа будет соединятся со своим компьютером и неким зашитим портом ххх, затем локальный порт-маппер отправляет соединение на твой сервер:порт (кстати говоря, можно написать умный маппер, который будет брать с сервера номер порта для этого клиента)

А>>>>стандартный софт для порт-форвардинга в линукс/юникс это что-то вроде ipchain, ipfw итп, в общем в nix системах это легко,
А>>>>в win системах нужно поставить нечто... я для подобных вещей сам писал маппер, думаю что такого софта как грязи
D>>>А при форвардинге адрес получателя и отправителя в пакете какие будут?

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

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

Здравствуйте, Аноним, Вы писали:

А>уж больно "нехорошая" программа вам досталась,
А>ipchain и ipwf можно настроить чтоб "прикидывались" другим хостом, читать маны по ним
А>только нехорошо это все... некрасиво.
А>наверно проще смаршрутизировать раздельные сетки или повесить VPN
Конечно vpn повесить — это самое простое решение, но, увы, нет такой возможности (политика компании)...

Здравствуйте, dkDimon1976, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

А>>уж больно "нехорошая" программа вам досталась,
А>>ipchain и ipwf можно настроить чтоб "прикидывались" другим хостом, читать маны по ним
А>>только нехорошо это все... некрасиво.
А>>наверно проще смаршрутизировать раздельные сетки или повесить VPN
D>Конечно vpn повесить — это самое простое решение, но, увы, нет такой возможности (политика компании)...

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, dkDimon1976, Вы писали:

D>>Здравствуйте, Аноним, Вы писали:

А>>>уж больно "нехорошая" программа вам досталась,
А>>>ipchain и ipwf можно настроить чтоб "прикидывались" другим хостом, читать маны по ним
А>>>только нехорошо это все... некрасиво.
А>>>наверно проще смаршрутизировать раздельные сетки или повесить VPN
D>>Конечно vpn повесить — это самое простое решение, но, увы, нет такой возможности (политика компании)...

А>ну еще идейка это внедриться в winsock (а-ля соксифиеры) и организовать свою сокетную прослойку
А>между программой и сетью с сервером, программа будет думать что работает с пирами, а на самом деле...
А>только вот это уж совсем грустно.
А где можно нарыть информацию по такому способу?
ЗЫ. Больше никаких идей нет?