Система: FreeBSD 8.0-RELEASEНа сервере два интерфейса. Один смотрит в "мир", другой смотрит в выделенный канал.
Идея в том, что "в мире" живёт второй сервер, который видит мой сервер так же через публичный интернет и выделенный канал. Когда он устанавливает сессию с моим сервером он это делает то так то так. То есть может быть 10 сессий из которых 3-4 идут через публичный интернет, а 6-7 через выделенный канал.
Можно ли как-то сделать чтобы мой сервер понимал откуда пришла сессия (интернет или выделенный канал) и отвечал в нужную сторону?
Дело осложняется тем, что вне зависимостиот того, через что пошла сессия IP адреса будут одинаковые. Плюс, до кучи, большинство трафика будет UDP.
> Система: FreeBSD 8.0-RELEASE
> На сервере два интерфейса. Один смотрит в "мир", другой смотрит в выделенный
> канал.Захватывающе. А "два провайдера" aka http://lmgtfy.com/?q=policy+routing+freebsd+site%3Aopen... не про это же? Нет? Ну, ладно...
> устанавливает сессию с моим сервером он это делает то так то
> Захватывающе. А "два провайдера"
> не про это же? Нет? Ну, ладно...Увы, нет.
Потому что в случае с "два провайдера" и пр. у нас разные IP адреса источника и получателя. А здесь адреса всегда одни и те же.
>> Захватывающе. А "два провайдера"
>> не про это же? Нет? Ну, ладно...
> Увы, нет.
> Потому что в случае с "два провайдера" и пр. у нас разные
> IP адреса источника и получателя. А здесь адреса всегда одни и
> те же.у вас на 2-х интерфейсах одинаковые ip?
и что udp у exim делает?
> у вас на 2-х интерфейсах одинаковые ip?Нет, разный, конечно. И на моём сервере и на удалённом.
Но сам сервис, с которым поднимаются сессии поднять от одного интерфейса.
Ну, грубо говоря от loopback> и что udp у exim делает?
Эм. Откуда в заголовке exim не знаю. :) Опечатка какая-то.
>> у вас на 2-х интерфейсах одинаковые ip?
> Нет, разный, конечно. И на моём сервере и на удалённом.
> Но сам сервис, с которым поднимаются сессии поднять от одного интерфейса.
> Ну, грубо говоря от loopbackто есть вы делаете проброс?
сервис может быть поднят на нескольких портах?>> и что udp у exim делает?
> Эм. Откуда в заголовке exim не знаю. :) Опечатка какая-то.
> то есть вы делаете проброс?
> сервис может быть поднят на нескольких портах?Нет.
Схема такая:
Сервер1:
интерфейс vlan1 IP1
На нём висит сервис.
Он же смотрит в публичный интернет.Интерфейс vlan2 IP2
Это просто p2p канал.Соответсвенно удалённый сервер шлёт все запросы на IP1 всегда.
Порт один и тот же всегда.Но иногда некий маршрутизатор на пути поворачивает трафик из выделенного канала vlan2 в публичный интернет и мы его ловим на vlan1.
Так как с нашей стороны статический маршрут к удалённому серверу строго через vlan2 то нифига не работает.
Вот хотелось бы этого избежать.
Формальный критерий для удалённого сервера слать всё в публичный интернет - это забитость выделенного канала. Но реально это глючит и он при пустом канале может слать в публичный интернет.
Мы можем развесить сервис на всех адресах, но удалённый сервер шлёт только на один.
Вообще это - телефония.
>[оверквотинг удален]
> в публичный интернет и мы его ловим на vlan1.
> Так как с нашей стороны статический маршрут к удалённому серверу строго через
> vlan2 то нифига не работает.
> Вот хотелось бы этого избежать.
> Формальный критерий для удалённого сервера слать всё в публичный интернет - это
> забитость выделенного канала. Но реально это глючит и он при пустом
> канале может слать в публичный интернет.
> Мы можем развесить сервис на всех адресах, но удалённый сервер шлёт только
> на один.
> Вообще это - телефония.если ваш сервис можно запустить на разных портах, то при приходе пакета через vlan1 можно было бы пробросить его на другой порт и потом по исходящим портам определять через что слать ответ.
если удаленный сервер шлет пакеты с разных портов, то можно было бы попробовать 2 таблицы маршрутизации и keep-state/check-state, правда если он отправит пакеты с одного порта , а придут они на разные интерфейсы, то так не получится
в худшем случае можно попробовать нагородить nat на входе с изменением адреса источника, redirect или обратное преобразование в nat для восстановления ip удаленного сервера, fwd/route-to для указания нужного шлюза(канала)
>[оверквотинг удален]
> На нём висит сервис.
> Он же смотрит в публичный интернет.
> Интерфейс vlan2 IP2
> Это просто p2p канал.
> Соответсвенно удалённый сервер шлёт все запросы на IP1 всегда.
> Порт один и тот же всегда.
> Но иногда некий маршрутизатор на пути поворачивает трафик из выделенного канала vlan2
> в публичный интернет и мы его ловим на vlan1.
> Так как с нашей стороны статический маршрут к удалённому серверу строго через
> vlan2 то нифига не работает.кстати, а почему?
вить канал по моему не должен был повлиять если адреса и порты остались правильные. если по пути стоит нат или редирект или пакетные фильтры так настроены, тогда еще можно понять> Вот хотелось бы этого избежать.
> Формальный критерий для удалённого сервера слать всё в публичный интернет - это
> забитость выделенного канала. Но реально это глючит и он при пустом
> канале может слать в публичный интернет.
> Мы можем развесить сервис на всех адресах, но удалённый сервер шлёт только
> на один.
> Вообще это - телефония.