a) Первая сеть с адресами: 192.168.1.XX
b) Вторая сеть с адресами: 192.168.2.XX
Также предположим (для упрощения) что есть три компьютера:
1) 192.168.1.1 — первый узел.
2) 192.168.2.1 — второй узел.
3) Имеется шлюз с подсоединением к двум вышеуказаннып сетям —
его адреса: 192.168.1.7 и 192.168.2.7.
Вопрос:
Как (на уровне UDP-сокетов) через этот самый шлюз транслировать UDP пакеты — от 192.168.1.1 к 192.168.2.1 и обратно?
Здравствуйте, AlexGin, Вы писали:
AG>Доброе время суток, уважаемые коллеги!
AG>Вот, предположим, что у нас имеется:
AG>a) Первая сеть с адресами: 192.168.1.XX AG>b) Вторая сеть с адресами: 192.168.2.XX
AG>Также предположим (для упрощения) что есть три компьютера: AG>1) 192.168.1.1 — первый узел. AG>2) 192.168.2.1 — второй узел. AG>3) Имеется шлюз с подсоединением к двум вышеуказаннып сетям - AG>его адреса: 192.168.1.7 и 192.168.2.7.
AG>Вопрос: AG>Как (на уровне UDP-сокетов) через этот самый шлюз транслировать UDP пакеты — от 192.168.1.1 к 192.168.2.1 и обратно?
Эээ
я не понял — этот "шлюз" он таки предназначен раутить пакеты сквозь себя или нет?
Если да — то вообще никакой особой заботы не нужно — IP стек всё сделает, просто 192.168.1.1 отправляет пакет на 192.168.2.1, и наоборот.
Если нет — то какая-то программа должна принимать на 192.168.1.7 датаграммки и передавать на 192.168.2.1, и в обратную сторону. Но зачем? (Ниже — с этим вариантом)
AG>Желательно — с привязкой к POSIX реализации.
Вам как — в одну нитку или в две? (два процесса?)
если можно две — тогда каждая из них делает socket(), bind(), и вечный цикл из recv() и sendto(). Отличаются только адреса.
Если одну — то, например, писать на движке событий поверх libuv, ASIO и десятков других аналогов.
The God is real, unless declared integer.
Re[2]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, netch80, Вы писали:
N>Если нет — то какая-то программа должна принимать на 192.168.1.7 датаграммки и передавать на 192.168.2.1, и в обратную сторону. Но зачем? (Ниже — с этим вариантом)
Мне кажется, на iptables можно такое сделать.
Re[3]: Пересылка UDP пакета из одной сети в другую
vsb:
N>>Если нет — то какая-то программа должна принимать на 192.168.1.7 датаграммки и передавать на 192.168.2.1, и в обратную сторону. Но зачем? (Ниже — с этим вариантом) vsb>Мне кажется, на iptables можно такое сделать.
Здравствуйте, netch80, Вы писали:
... AG>>Вопрос: AG>>Как (на уровне UDP-сокетов) через этот самый шлюз транслировать UDP пакеты — от 192.168.1.1 к 192.168.2.1 и обратно?
N>Эээ N>я не понял — этот "шлюз" он таки предназначен раутить пакеты сквозь себя или нет?
Да, именно так.
N>Если да — то вообще никакой особой заботы не нужно — IP стек всё сделает, просто 192.168.1.1 отправляет пакет на 192.168.2.1, и наоборот.
Сети не доступны таким образом (простой route здесь не пройдет).
N>Если нет — то какая-то программа должна принимать на 192.168.1.7 датаграммки и передавать на 192.168.2.1, и в обратную сторону. Но зачем? (Ниже — с этим вариантом)
Именно нет. Затем — что иниче (ИМХО) как решить данную проблему, если речь идет о разных сетях?
Кроме всего прочего, иногда потребуется переключить эту схему (при случае, если вторая сеть станет уже не 192.168.2.XX а, например, 192.168.22.XX).
AG>>Желательно — с привязкой к POSIX реализации.
N>Вам как — в одну нитку или в две? (два процесса?) N>если можно две — тогда каждая из них делает socket(), bind(), и вечный цикл из recv() и sendto(). Отличаются только адреса.
Да, это понятно, в смысле что это традиционная работа с UDP сокетом.
N>Если одну — то, например, писать на движке событий поверх libuv, ASIO и десятков других аналогов.
Спасибо, покопаю в этом направлении!
Re[3]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, netch80, Вы писали:
N>>Если нет — то какая-то программа должна принимать на 192.168.1.7 датаграммки и передавать на 192.168.2.1, и в обратную сторону. Но зачем? (Ниже — с этим вариантом)
vsb>Мне кажется, на iptables можно такое сделать.
Ну iptables — IMHO не то.
Вышеуказанные сети — никак не связяны, кроме как наличием этого самого "шлюза".
AG>a) Первая сеть с адресами: 192.168.1.XX AG>b) Вторая сеть с адресами: 192.168.2.XX
AG>Также предположим (для упрощения) что есть три компьютера: AG>1) 192.168.1.1 — первый узел. AG>2) 192.168.2.1 — второй узел. AG>3) Имеется шлюз с подсоединением к двум вышеуказаннып сетям - AG>его адреса: 192.168.1.7 и 192.168.2.7.
AG>Вопрос: AG>Как (на уровне UDP-сокетов) через этот самый шлюз транслировать UDP пакеты — от 192.168.1.1 к 192.168.2.1 и обратно?
Ты тут понаписал конкретную фигню (по не знанию), либо что-то важное не договариваешь (опять же, по не знанию).
Тебе тут, похоже, достаточно настроить маршрутизацию. Расскажу про роутинг (маршрутизацию), чтобы было понятно. Очень упрощенно.
Маршрутизация производится по адресу назначения (адрес источника не важен и тем более порты, потому что маршрутизация делается по IP).
При маршрутизации оба эти адреса в пакете не меняются.
Цель маршрутизации доставить пакет по назначению. Для этого в твоей сети ты настраиваешь на узле 192.168.1.1: адрес с маской подсети 192.168.1.1/24,
default (0.0.0.0/0) шлюз 192.168.1.7.
По адресу с маской подсети узел будет знать, какие IP адреса доступны напрямую. Остальные пакеты с адресами назначения не в сети 192.168.1.0/24, узел отправит шлюзу.
Аналогично для узла 192.168.2.1 адрес с маской подсети 192.168.2.1/24,
default (0.0.0.0/0) шлюз 192.168.2.7.
Настройка шлюза : 192.168.1.7/24 на одном интерфейсе,
192.168.2.7/24 на другом интерфейсе,
ip_forward, чтобы он маршрутизировал пакеты, предназначенные не ему.
Таким образом шлюз будет знать где находятся обе подсети. Еще возможно, шлюзу самому понадобиться шлюз по умолчанию, ведь, он знает только об этих двух подсетях, но это не относится к задаче.
Итак, узел 192.168.1.1 отправляет IP пакет (он может быть UDP, TCP, ICMP или любой другой IP пакет) узлу 192.168.2.1. Напрямую это адрес не доступен (у него сеть 192.168.1.1/24, а адрес 192.168.2.1), поэтому он отправляет пакет шлюзу 192.168.1.7. Тот получив пакет и обнаружив, что он предназначен не ему (dst 192.168.2.1) и, что у него включена маршрутизация поищет в таблице маршрутизации, куда его отдать дальше и отдаст в сеть 192.168.2.0/24 на адрес 192.168.2.1. Адреса источника и назначения в пакете не меняются. В результате узел 192.168.2.1 получит пакет от шлюза (маршрутизатора), но узнать он это сможет только по MAC (адреса в пакете src 192.168.1.1, dst 192.168.2.1).
Аналогично узел 192.168.2.1 отправит ответ, зная адрес отправителя из пакета (или как-то еще).
Еще бывает маршрутизация с трансляцией адресов NAT, когда адрес источника или назначения подменяется адресом шлюза (Source NAT) или другого узла (Destination NAT). Но, похоже, тебе это не надо.
Re[3]: Пересылка UDP пакета из одной сети в другую
N>>я не понял — этот "шлюз" он таки предназначен раутить пакеты сквозь себя или нет? AG>Да, именно так. N>>Если да — то вообще никакой особой заботы не нужно — IP стек всё сделает, просто 192.168.1.1 отправляет пакет на 192.168.2.1, и наоборот. AG>Сети не доступны таким образом (простой route здесь не пройдет).
Способность форвардить пакеты между сетями — фундаментальное свойство шлюза, если он этого не умеет — то никакой он не шлюз, а прости г-ди — multihomed host.
Если он этого не делает — видимо надо включить форвардинг на нем
А если делает, но просто не является дефолтовым шлюзом для хостов в 192.168.1.. и 192.168.2... — то нужен именно route (на обоих сторонах)
А если и делает и роуты через него хостам известны — то надо просто слать пакеты, как обычно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
O>А если делает, но просто не является дефолтовым шлюзом для хостов в 192.168.1.. и 192.168.2... — то нужен именно route (на обоих сторонах)
Тут сети directly connected и раут обычно назначается автоматически.
The God is real, unless declared integer.
Re[3]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, vsb, Вы писали:
N>>Если нет — то какая-то программа должна принимать на 192.168.1.7 датаграммки и передавать на 192.168.2.1, и в обратную сторону. Но зачем? (Ниже — с этим вариантом)
vsb>Мне кажется, на iptables можно такое сделать.
NATʼами? Ну да. Просто пока нет понимания, нужно ли именно в таком виде.
The God is real, unless declared integer.
Re[3]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, AlexGin, Вы писали:
N>>Если да — то вообще никакой особой заботы не нужно — IP стек всё сделает, просто 192.168.1.1 отправляет пакет на 192.168.2.1, и наоборот. AG>Сети не доступны таким образом (простой route здесь не пройдет).
Хм, вот это интересный сеттинг. Если это не просто выключенный форвардинг, сети назначены на интерфейсы, но недоступны... как и зачем?
Можно же было, например, включить форвардинг, но правилами iptables запретить его для всех случаев, кроме одного конкретного.
The God is real, unless declared integer.
Re[2]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, AlexGin, Вы писали:
AG>Но здесь имеется маленькое уточнение (по условию задачи): AG>Вторая сеть через пять минут может быть переключена на резервную — например: 192.168.22.XX
Да, это существенно.
AG>Именно поэтому я и предполагаю — работать не через таблицы маршрутизации, а именно через переприём UDP пакетов.
Можно таки ещё iptables с NAT правилами. Немного изврат, но позволяет освободиться от своего демона.
Всё равно о факте переключения надо кого-то пинать
The God is real, unless declared integer.
Re[4]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, netch80, Вы писали:
... N>Можно таки ещё iptables с NAT правилами. Немного изврат, но позволяет освободиться от своего демона. N>Всё равно о факте переключения надо кого-то пинать
Ну например так:
По таймеру наш шлюз пингует узел 192.168.2.1 (например с периодом 1 сек).
При каких-либо граничных условиях (время ping-а перевалило через установленный threshold,
или узел дальнего_конца ввобще "отвалился") — переходим на резервную сеть и резервный узел 192.168.22.1.
AG>Вторая сеть через пять минут может быть переключена на резервную — например: 192.168.22.XX
Тогда тебе нужен не шлюз (маршрутизатор), а прокси, который отслеживает IP подключенных клиентов и проксирует им запросы. Или само приложение при смене IP клиента должно повторно отправить запрос (или ответ) на новый IP клиента. Если происходит переключение на резервную сеть, то оповещение о смене IP может делать либо тот, кто инициирует переключение, либо при очередном запросе будет превышен таймаут (старая сеть недоступна).
Попытки смешать маршрутизацию и передачу трафика на уровне приложения приведут к ненужному усложнению задачи (такое крайне редко бывает нужно и, вряд ли, это твой случай). Маршрутизацией (в том числе динамической) должен заниматься шлюз (роутер, маршрутизатор), а приложение должно отправлять запросы на известный IP. Весь вопрос, откуда оно узнает этот IP (а как доставить туда данные — задача марштуризатора). Если IP клиента может меняться — делай так, чтобы об этом узнавало приложение. Если маршрут обмена трафиком может меняться — с этой задачей справится маршрутизатор.
Короче:
приложение должно работать с известным IP,
при смене IP клиента оно должно об этом узнать (либо от клиента, либо по таймауту, либо от еще кого-то),
маршрутизацией IP пакетов должен заниматься маршрутизатор (смешивать эти задачи — бесполезно усложнять свою работу).
Re[4]: Пересылка UDP пакета из одной сети в другую
AlexGin:
AG>Ну iptables — IMHO не то. AG>Вышеуказанные сети — никак не связяны, кроме как наличием этого самого "шлюза".
На шлюзе и настраивается маршрутизация через iptables.
Если маршрутизация нужна только для определенных портов то это тоже можно настроить.
Программировать в этом случае ничего не надо.
Re[4]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, уважаемый Reset, Вы писали:
...
R>Короче: R>
R>приложение должно работать с известным IP, R>при смене IP клиента оно должно об этом узнать (либо от клиента, либо по таймауту, либо от еще кого-то), R>маршрутизацией IP пакетов должен заниматься маршрутизатор (смешивать эти задачи — бесполезно усложнять свою работу). R>
+100500
Согласен — я посему и запостил сюда этк тему.
Здравствуйте, Bill Baklushi, Вы писали:
BB>AlexGin:
AG>>Ну iptables — IMHO не то. AG>>Вышеуказанные сети — никак не связяны, кроме как наличием этого самого "шлюза".
BB>На шлюзе и настраивается маршрутизация через iptables. BB>Если маршрутизация нужна только для определенных портов то это тоже можно настроить. BB>Программировать в этом случае ничего не надо.
То есть — просто настраивается всё (это в Linux) на уровне простых bash-скриптов?
Re[6]: Пересылка UDP пакета из одной сети в другую
AlexGin:
BB>>На шлюзе и настраивается маршрутизация через iptables. AG>То есть — просто настраивается всё (это в Linux) на уровне простых bash-скриптов?
В основном скрипты требуют однократного выполнения, кроме какого-то одного:
кажется что-то вроде "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERAD" должно вешаться на включение сетевухи в файле /etc/interfaces
Про то как вешается обработчик тоже есть по ссылкам. Мне лениво было, я руками запускаю, когда мне нужен шлюз
Здравствуйте, AlexGin, Вы писали:
AG>Доброе время суток, уважаемые коллеги!
AG>Вот, предположим, что у нас имеется:
AG>a) Первая сеть с адресами: 192.168.1.XX AG>b) Вторая сеть с адресами: 192.168.2.XX
AG>Также предположим (для упрощения) что есть три компьютера: AG>1) 192.168.1.1 — первый узел. AG>2) 192.168.2.1 — второй узел. AG>3) Имеется шлюз с подсоединением к двум вышеуказаннып сетям - AG>его адреса: 192.168.1.7 и 192.168.2.7.
AG>Вопрос: AG>Как (на уровне UDP-сокетов) через этот самый шлюз транслировать UDP пакеты — от 192.168.1.1 к 192.168.2.1 и обратно?
AG>Желательно — с привязкой к POSIX реализации.
AG>Заранее благодарен за подсказки.
Если бы адреса сетей были другими, то работало бы "из коробки", данные отправлялись бы из одной сети в другую через шлюз по-умолчанию (default gateway). А так — 192.168.0.0/16 немаршрутизируемый диапазон, поэтому пакеты никуда не уйдут. Возможно, можно это как-то обойти через port forwarding или другие настройки сети.
Re[2]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, cppguard, Вы писали:
... C>Если бы адреса сетей были другими, то работало бы "из коробки", данные отправлялись бы из одной сети в другую через шлюз по-умолчанию (default gateway). А так — 192.168.0.0/16 немаршрутизируемый диапазон, поэтому пакеты никуда не уйдут. Возможно, можно это как-то обойти через port forwarding или другие настройки сети.
Спасибо!
Буду в курсе!
P.S. Этот момент — насчет немаршрутизируемого_диапазона — я даже и не знал.
Re[2]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, cppguard, Вы писали:
C>Если бы адреса сетей были другими, то работало бы "из коробки", данные отправлялись бы из одной сети в другую через шлюз по-умолчанию (default gateway). А так — 192.168.0.0/16 немаршрутизируемый диапазон, поэтому пакеты никуда не уйдут.
Уйдут. "Немаршрутизируемый" 192.168 (как и другие частные сети) только в том смысле, что в мировом раутинге их нет и из другой автономной системы на них поток не направится. Или не направится там, где у раутера уже нет маршрута по умолчанию — а это, как правило, граничные раутеры автономных систем. На обычном домашнем или корпоративном всегда есть маршрут по умолчанию, и туда и 192.168/16, и 10/8, и все прочие уходят без проблем.
Но что делается внутри конкретной автономной системы это её дело, и тот же 192.168 она может использовать под свои нужды — и я такое видел.
Чтобы пакеты от/для 192.168 и прочих частных сетей точно не уходили к провайдеру или вообще аплинку, надо настроить явно egress filtering. Чтобы пакеты для этих адресов не приходили откуда не положено, надо явно настроить ingress filtering.
Они могут быть иногда автоматически включены на раутерах, которые имеют встроенный NAT — как обычный домашний WiFi раутер — и то не обязательно, есть масса моделей, на которых это не применено.
Для любой модели, которой предполагается сколь-нибудь квалифицированная настройка хотя бы спецом уровня CCNA, такого не делают — это уже дело админа-настройщика.
Пожалуйста, не вводите людей в заблуждение.
The God is real, unless declared integer.
Re[3]: Пересылка UDP пакета из одной сети в другую
Действительно, работает, как вы сказали. Видимо, до этого встречался исключительно с устройствами, в которых прописаны правила, ограничивающие такой тип транзита трафика.
Re[3]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, cppguard, Вы писали:
C>Ты тоже :-D 192.168.0.0/16 не маршрутизируется согласно RFC1918, поэтому ничего в шлюз по-умолчанию не отправится.
Глупость написал. Там сказано совсем другое:
Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
should not be forwarded across such links.
Внутри private networks маршрутизацию для этих подсетей можно настроить абсолютно как угодно и на шлюз по умолчанию будет уходиить все, что не из этой подсети.
Re[3]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, AlexGin, Вы писали:
AG>P.S. Этот момент — насчет немаршрутизируемого_диапазона — я даже и не знал.
Глупость он написал. Нет никакого "немаршрутизируемого_диапазона", есть диапазоны для частного использования, информация о которых не должна рапространяться глобально, но тебя это вообще не волнует (это BGP и все такое, провойдеры этим занимаются). Для твоей локальной машины нет никакой разницы между адресом 192.168.0.1 или 1.2.3.4, все зависит только от твоих настроек.
Re[4]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, cppguard, Вы писали:
C>Здравствуйте, netch80, Вы писали:
C>Действительно, работает, как вы сказали. Видимо, до этого встречался исключительно с устройствами, в которых прописаны правила, ограничивающие такой тип транзита трафика.
Это нормальное поведение для "честных" маршуртизаторов:
"Because private addresses have no global meaning, routing information
about private networks shall not be propagated on inter-enterprise
links, and packets with private source or destination addresses
should not be forwarded across such links."
Re[4]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, Skorodum, Вы писали:
S>Глупость он написал. Нет никакого "немаршрутизируемого_диапазона", есть диапазоны для частного использования, информация о которых не должна рапространяться глобально, но тебя это вообще не волнует (это BGP и все такое, провойдеры этим занимаются). Для твоей локальной машины нет никакой разницы между адресом 192.168.0.1 или 1.2.3.4, все зависит только от твоих настроек.
В любом случае, я для себя сделал вывод — как требуется решать данную задачу.
Конечно же, я не буду привязываться ни к какому диапазону.
Просто напишу свой (custom-ный) сервис маршрутизации UDP пакетов.
Он должен пересылать (в другую сеть) все UDP-пакеты, поступающие на определенный порт.
Так оно проще и надёжнее.
Re[5]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, AlexGin, Вы писали:
AG>Просто напишу свой (custom-ный) сервис маршрутизации UDP пакетов. AG>Он должен пересылать (в другую сеть) все UDP-пакеты, поступающие на определенный порт. AG>Так оно проще и надёжнее.
Проще и надежнее настроить маршрутизацию на любой линухе.
Re[6]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, AlexGin, Вы писали:
AG>>Просто напишу свой (custom-ный) сервис маршрутизации UDP пакетов. AG>>Он должен пересылать (в другую сеть) все UDP-пакеты, поступающие на определенный порт. AG>>Так оно проще и надёжнее.
S>Проще и надежнее настроить маршрутизацию на любой линухе.
Это — если бы была СТАТИЧЕСКАЯ ситуация.
Но я же сообщал — что сеть_дальнего_конца может неоднократно изменяться в процессе работы.
Re[7]: Пересылка UDP пакета из одной сети в другую
S>>Проще и надежнее настроить маршрутизацию на любой линухе. AG> AG>Это — если бы была СТАТИЧЕСКАЯ ситуация. AG>Но я же сообщал — что сеть_дальнего_конца может неоднократно изменяться в процессе работы.
А маршрутизация бывает и динамической.
Если у шлюза вдруг изменилась вторая сеть (мега странно), то он об этом должен как-то узнать и создать маршрут в нее.
А в это момент он тогда может и изменить port forwarding на нужный IP-адрес.
Может на самом деле сети все уже настроены, просто некоторые из них могут "отвалиться", потому-что сосед отключил ви-фи )))?
Re[8]: Пересылка UDP пакета из одной сети в другую
Здравствуйте, уважаемый Dimatec, Вы писали:
D>А маршрутизация бывает и динамической.
D>Если у шлюза вдруг изменилась вторая сеть (мега странно), то он об этом должен как-то узнать и создать маршрут в нее. D>А в это момент он тогда может и изменить port forwarding на нужный IP-адрес.
Дело в том, что речь идет о весма специализированной системе, которая и является моим творением.
Посему — самое правильное сделать отдельный сервис (который, кстати, я уже сделал и успешно протестировал).
D>Может на самом деле сети все уже настроены, просто некоторые из них могут "отвалиться", потому-что сосед отключил ви-фи )))?
Здесь не идет речь об Wi-Fi соседа. Оставим эти занятия для студентов.
P.S. Тем не менее, спасибо за подсказку! Буду знать какие готовые решения есть в данной сфере!
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, Skorodum, Вы писали:
S>>Глупость он написал. Нет никакого "немаршрутизируемого_диапазона", есть диапазоны для частного использования, информация о которых не должна рапространяться глобально, но тебя это вообще не волнует (это BGP и все такое, провойдеры этим занимаются). Для твоей локальной машины нет никакой разницы между адресом
AG>Просто напишу свой (custom-ный) сервис маршрутизации UDP пакетов.
Для динамического переключения копай haproxy или тот же socat с другим "send-to-host"
Это все для динамического failover на другую сеть.
Для статики — настрой маршрутизацию. Как тут уже писали, все адреса (* кроме multicast *) маршрутизируются на внутренних сетях. И именно они и маршрутизируются в 99.99...% случаях. В более грамотных организациях используют 172... или 10.. вместо "заезженного" 192...
При маршрутизации, если будет работать ping, то будет и UDP. Если firewall ничего не закрывает.
