none
Проброс пакетов из одной сети в другую (forwarding/mapping) RRS feed

  • Вопрос

  • Есть сети :

         192.168.50.x      172.25.x.x

         255.255.255.0   255.255.0.0

    Подключенные к WinXP  

        192.168.50.91  172.25.32.185

    В сети 192.168.50.x есть рассылка UDP TTL:1

    Адрес источника   192.168.50.77:1028 

    Адрес назначения 229.1.2.4:6002 (пакеты на 192.168.50.91:6002 есть)

    Надо : 

    Пакеты рассылки доставить на 172.25.31.5:6002

    Хочется сделать средствами Windows и чтобы данные пакеты шли только на указанный интерфейс 172.25.31.5:6002

    Спасибо.







    21 декабря 2011 г. 14:01

Все ответы

  • <DISCLAIMER>
    Я никогда с рассылками не работал, не знаю, не понимаю.
    Экспертом по сетевым технологиям я тоже не являюсь.
    Шансы, что мой совет вам поможет, я бы оценил процента в 3. Но это всё же больше нуля.)
    Крайне рекомендую пробовать приведенную тут ахинею только в том случае, если вам другие участники недели две не ответят. Ибо как-то бредово всё. И мне кажется, что не взлетит.)
    </DISCLAIMER>

    По поводу маршрутизации...
    1.1. Включить на этом компьютере-шлюзе IP-маршрутизацию. Для этого запишите 1 в параметр реестра
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\IPEnableRouter
    (от тут про него имеется, но очень мало).
    После этого комп с WinXP будет перебрасывать все пакеты, пришедшие на его интерфейс и адресованные компьютеру из другой подсети, на интерфейс этой подсети. То есть станет маршрутизатором.
    1.2. Скорее всего (не помню точно), нужно будет основным шлюзом на компьютерах подсетей прописать этот новоявленный маршрутизатор (тот его интерфейс, который смотрит в соответствующую подсеть). То есть для компьютера из подсети 192.168.50.x шлюзом будет 192.168.50.91, а для компьютера из  172.25.x.x - 172.25.32.185.
    Если шлюзы менять - не вариант, то можно прописать маршруты. Нечто в духе
    route add 172.25.0.0 mask 255.255.0.0 192.168.50.91 metric 13  (для подсети 192.168.50.x),
    route add 192.168.50.0 mask 255.255.255.0 172.25.32.185 metric 13  (для подсети 172.25.x.x).
    Если вдруг заработает, то можно будет сделать маршруты статическими.

    Вероятные косяки моего великого плана:
    1) я НЕ уверен, что групповая рассылка пройдет через маршрутизатор - может, оне её отсечет.
    Broadcast отсечется наверняка (благодаря параметру ForwardBroadcasts, о котором написано тут, но что будет с Multicast - я не представляю);
    2) я НЕ уверен, что маршрутизатор не сожрет единичку из TTL'а и не угробит пакет. Если так, то TTL рассылки придется увеличить на 1;
    3) само по себе использование этого параметра, наверное, является косяком. Есть соответствующая служба вроде бы... и надо как-то настраивать её. Но этого я не умею.)

    З. Ы. Если кто-то из читающих нашел косяк, то прошу смело назвать меня дураком и объяснить, где я был неправ.)

    22 декабря 2011 г. 19:07
  • Спасибо что хоть кто-то откликнулся :)

    1.1 Включена.

    1.2 Я не буду вдаваться во все тяготы (прелести)  маршрутизации, но маршрутизация не подойдет т.к. ну не для того она :)  (чтобы не описывать весь ее принцип) я представляю как она работает. Эти две сети полностью состоявшиеся, не хочется, да и не будет ничего меняться ни с рассылкой, ни с TTL.

    Добавлять маршрут на интерфейсе получателя 172.25.31.5 незачем, получатель только слушает порт 6002

    Поднимать полноценный NAT не выход, ради одного потока ...

    Нужен фактически ретранслятор с изменение пары параметров: адреса назначения ну и может TTL. Как это сделать на iptables я знаю а вот с netsh туго, но городить вирт.маш. (машина не оч. шустрая) хостить интерфейсы и т.д. неохоца.

    Буду рад услышать еще идеи.


    23 декабря 2011 г. 13:18