Как пустить емул через другое соединение?
для начала прочитать про маршрутизацию.
Меня интересуют конкретные предложения. Например тулза, которая для соединений через порт #### использует интерфейс ##. Гугл пока не очень помогает.
У каждого сетевого интерфейса своя таблица маршрутизации.
Если программа не поддерживает выбор сетевого интерфейса для исходящих соединений, значит нужно поставить себе прокси, который это поддерживает, и пустить программу через него.
Ссылка на 3proxy
(осторожно, NOD думает, что там вирус, хотя это не так)
Если программа не поддерживает выбор сетевого интерфейса для исходящих соединений, значит нужно поставить себе прокси, который это поддерживает, и пустить программу через него.
Ссылка на 3proxy
(осторожно, NOD думает, что там вирус, хотя это не так)
У каждого сетевого интерфейса своя таблица маршрутизации.И давно?
dev IfИз линуксовых man'ов по route.
force the route to be associated with the specified device, as the kernel will otherwise try to determine the device on its own (by checking already existing routes and device specifications, and where the route is added to). In most normal networks you won't need this.
If dev If is the last option on the command line, the word dev may be omitted, as it's the default. Otherwise the order of the route modifiers (metric - netmask - gw - dev) doesn't matter.
В винде соответствующий параметр тоже есть.
Посему полагаю с начала IP.
лол
Пояснил бы уж.
Я имею в виду, что выбор роутов зависит от того, какой локальный сетевой интерфейс использует программа.
Я имею в виду, что выбор роутов зависит от того, какой локальный сетевой интерфейс использует программа.
То, про что ты рассказываешь, определяет выбор исходящего интерфейса в зависимости от адреса назначения. Это как раз стандартная таблица маршрутизации, и она одна. В винде больше и не бывает.
Пояснил бы уж.
$ ip r
192.168.130.1 dev ppp0 proto kernel scope link src 192.168.169.177
172.16.254.0/24 via 172.16.35.1 dev eth0
172.16.32.0/22 dev eth0 proto kernel scope link src 172.16.35.196
172.16.0.0/12 via 172.16.32.1 dev eth0
10.0.0.0/8 via 172.16.32.1 dev eth0
127.0.0.0/8 dev lo scope link
default via 192.168.130.1 dev ppp0
смотрим после слова dev.
определяет выбор исходящего интерфейса в зависимости от адреса назначенияЛибо мы друг друга не понимаем, либо говорим об одном и том же разными словами.
Выбор интерфейса может осуществить пользователь, указав, например, что программа будет для своих исходящих соединений использовать с интерфейс xxx.
То, какие роуты будут задействованы в этом случае зависит исключительно от того, какие роуты определены через этот интерфейс (если такого термина ещё нет, назовём это множество роутов таблицей роутов интерфейса xxx роуты других интерфейсов не будут влиять на этот выбор.
Это пример того, как в зависимости от исходящего интерфейса и адреса назначения выбираются роуты.
P.S. Я просто поражён как оценки выставляются за информативность постов.
Выбор интерфейса может осуществить пользователь, указав, например, что программа будет для своих исходящих соединений использовать с интерфейс xxx.Уверен? Я детали не знаю, особенно про винду, но сильно сомневаюсь, там вроде посложнее ситуация.
То, какие роуты будут задействованы в этом случае зависит исключительно от того, какие роуты определены через этот интерфейс (если такого термина ещё нет, назовём это множество роутов таблицей роутов интерфейса xxx роуты других интерфейсов не будут влиять на этот выбор.
Сейчас погуглил - вроде в линуксе не работает то, что ты говоришь.
Прежде чем писать, специально проверил, повесив прокси на loopback при включенном интернете.
Выбор интерфейса может осуществить пользователь, указав, например, что программа будет для своих исходящих соединений использовать с интерфейс xxx.А где именно он может это указать ?
Как проверял? Интересно бы разобраться с этим.
Ты на сокетах писал программы?
Дальше говорю про linux.
Если ты делаешь listening, то надо указывать исходящий IP-адрес, он будет определять, на каких интерфейсах твой сокет прослушивается, или 0.0.0.0 для всех. Интерфейс при этом не указывается. Для этого просто нет полей у соответствующей структуры.
В случае connect тоже указать интерфейс напрямую никакой возможности нету, все следует из таблицы маршрутизации.
Дальше говорю про linux.
Если ты делаешь listening, то надо указывать исходящий IP-адрес, он будет определять, на каких интерфейсах твой сокет прослушивается, или 0.0.0.0 для всех. Интерфейс при этом не указывается. Для этого просто нет полей у соответствующей структуры.
В случае connect тоже указать интерфейс напрямую никакой возможности нету, все следует из таблицы маршрутизации.
SO_BINDTODEVICE
но я не уверен, что оно работает именно так, как сказано выше
но я не уверен, что оно работает именно так, как сказано выше
Напиши ipconfig /all, а тут тебе подскажут настройки маршрутов.
SO_BINDTODEVICEПервую константу, к сожалению, вижу впервые. На втором курсе писал http-сервер, ничего подобного не помню. Работал он прекрасно =) Даже исходники сейчас есть.
но я не уверен, что оно работает именно так, как сказано выше
upd: да, как оказалось, я лажанул, есть такое.
http://tuxology.net/tag/interface/
К примеру, перегрузка конструктора UdpClient из .NET BCL: http://msdn.microsoft.com/ru-ru/library/k227d11f.aspx
А вообще указание local endpoint проходили в курсе ОС на ВМиК.
А вообще указание local endpoint проходили в курсе ОС на ВМиК.
На втором курсе писал http-сервер, ничего подобного не помню. Работал он прекрасно =) Даже исходники сейчас есть.Авторитетный спор на форум локал.
К примеру, перегрузка конструктора UdpClient из .NET BCLтам не интерфейс, а локальный IP
который в винде не влияет на выбор маршрута (по крайней мере никто ещё в этом форуме показать, как может повлиять, хотя спрашивали неоднократно)
Авторитетный спор на форум локал.Ну против ссылок на ман устаревшей утилиты route, достаточно =) Например, ifconfig и компания не поддерживает два ip адреса у интерфейса.
> open System.Net;;
> open System.Net.Sockets;;
> let ep = IPEndPoint(IPAddress.Parse("127.0.0.1" 3526);;
val ep : IPEndPoint
> use ifclient = new TcpClient(ep);;
use ifclient = new TcpClient(ep);;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
stdin(4,1): warning FS0191: 'use' bindings are treated as 'let' bindings in modu
les.
val ifclient : TcpClient
> ifclient.Connect("google.com", 80);;
System.Net.Sockets.SocketException: A socket operation was attempted to an unrea
chable network 209.85.171.100:80
at System.Net.Sockets.TcpClient.Connect(String hostname, Int32 port)
at <StartupCode$FSI_0006>.$FSI_0006._main
stopped due to error
> ifclient.Close;;
val it : unit =
> let ep = IPEndPoint(IPAddress.Parse("172.17.209.211" 3529);;
val ep : IPEndPoint
> use ifclient = new TcpClient(ep);;
use ifclient = new TcpClient(ep);;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
stdin(10,1): warning FS0191: 'use' bindings are treated as 'let' bindings in mod
ules.
val ifclient : TcpClient
> ifclient.Connect("google.com", 80);;
val it : unit =
Локальный IP одного из интерфейсов.
Локальный IP одного из интерфейсов.В твоем случае можно обойтись (и ты обходишься) без указания интерфейсов. А как я и писал выше, просто указываешь соответствующим образом исходящий IP.
Например, ifconfig и компания не поддерживает два ip адреса у интерфейса.what?
what?Ладно, там это реализовано криво: создаются алиасные интерфейсы типа eth0:1 для каждого нового адреса.
iproute2 один фих правильнее юзать.
да, к слову, задача топикстартера решается в iproute2 через routing policies (ip rule) напрямую: можно замутить маршрутизацию почти по любому разумному критерию, а в сочетании с iptables, так и вообще по любому.
ifconfig справляется с этим?
Как в винде с этим делом, не знаю
Локальный IP одного из интерфейсов.Могу повторить, что это не влияет на выбор маршрута. В отличие от опции-аналога SO_BINDTODEVICE например (если таковая есть в винде).
Могу повторить, что это не влияет на выбор маршрута. В отличие от опции-аналога SO_BINDTODEVICE например (если таковая есть в винде).Так если верить логам, которые он отправил, то влияет. Правда это .NET, он может там и по IP интерфейс пропалить успевает и к нему прибиндиться.
Тут кто-нибудь на Win API и сокетах что-нибудь писал?
не поддерживает два ip адреса у интерфейса.ip addr add
не покатит?
ip addr addтак это iproute2, а не ifconfig
не покатит?
> Так если верить логам, которые он отправил, то влияет.
Не очевидно.
127.0.0.1 - специальный адрес.
плюс сообщение типа host/net unreachable может и файрвол выдавать.
Правильный эксперимент должен показывать, что пакеты с одинаковым назначением действительно уходят через разные интерфейсы (либо через один интерфейс в случае отрицательного исхода эксперимента - что как раз наблюдается на практике регулярно - винда любит слать пакеты с локальным src ip в ppp-интерфейс от ГЗшных юзеров инета).
Не очевидно.
127.0.0.1 - специальный адрес.
плюс сообщение типа host/net unreachable может и файрвол выдавать.
Правильный эксперимент должен показывать, что пакеты с одинаковым назначением действительно уходят через разные интерфейсы (либо через один интерфейс в случае отрицательного исхода эксперимента - что как раз наблюдается на практике регулярно - винда любит слать пакеты с локальным src ip в ppp-интерфейс от ГЗшных юзеров инета).
Да, тут вопрос к тебе.
У тебя ведь нет интерфейса ppp?
Иначе если есть, то все равно непонятно, как он у тебя до гугла достучался.
А если нету, то с твоего компа действительно будет сложно все проверить.
В линуксе в iproute2 хоть есть таблица local, а как в винде loopback реализован, эт я не знаю.
У тебя ведь нет интерфейса ppp?
Иначе если есть, то все равно непонятно, как он у тебя до гугла достучался.
А если нету, то с твоего компа действительно будет сложно все проверить.
В линуксе в iproute2 хоть есть таблица local, а как в винде loopback реализован, эт я не знаю.
можно замутить маршрутизацию почти по любому разумному критериюесли у двух провайдеров будет одни и те же адреса в локалках (серые то просасывает и ip rule
В линуксе в iproute2 хоть есть таблица local,в линуксе. кроме этого, есть куча явных проверок на 127/8
подозреваю, что и в винде они есть
если у двух провайдеров будет одни и те же адреса в локалках (серые то просасывает и ip ruleМожешь для тех кто в танке, какое значение имеют эти адреса? Просто после первого прочтения мана показалось, что iproute2 сам умеет основываясь на номере порта раскидывать по таблицам маршрутизации, а похоже придется все-таки через iptables метить пакеты (-j MARK а потом раскидывать (через fwmark в ip rule add). Только какое значение IP-адреса здесь имеют?
Можешь для тех кто в танке, какое значение имеют эти адреса?Нужно как-то отличать172.16.0.1 в локалке ГЗ от хоста с таким же адресом у Голдов.
че-то я не понимаю.
Вот так почему не проканает
далее
Сейчас у себя проверил, вся маршрутизация идет как надо.
Вот так почему не проканает
$ iptables -t mangle -A OUTPUT -p tcp --dport <needed port> -j MARK --set-mark 115
далее
$ ip rule add prio 250 fwmark 115 table 250
$ ip route add default <WiFi peer IP adress> dev <WiFi interface> table 250
Сейчас у себя проверил, вся маршрутизация идет как надо.
То, что ты написал, называется policy routing и не имеет никакого отношения к уровню приложения, о котором тут идет жОсткий спор.
Топикстартеру, очевидно, этот самый policy routing и нужен, только вот я в упор не знаю, чем его на винде можно забабахать.
Топикстартеру, очевидно, этот самый policy routing и нужен, только вот я в упор не знаю, чем его на винде можно забабахать.
чем его на винде можно забабахать.kerio умеет
это который Kerio Winroute?
kerio умеетВооот! Тебя-то мы и ждали.
он самый
То, что ты написал, называется policy routing и не имеет никакого отношения к уровню приложения, о котором тут идет жОсткий спор.У нас тут параллельно еще один вопрос, а как это называется я уже написал
Вот так почему не проканаетпотому что не всегда заранее известен <needed port>, либо они могут и совпадать
iptables -t mangle -A OUTPUT -p tcp --dport <needed port> -j MARK --set-mark 115
давай, рассказывай, как он это умеет
можно ссылкой
мы тебя тут ждали 3 года
можно ссылкой
мы тебя тут ждали 3 года
потому что не всегда заранее известен <needed port>, либо они могут и совпадатьДа, тут понял, порт, к которому коннектимся, зависит от настроек клиента на чужой стороне. Значит тут поумнее надо правило фильтрации, тут надо чуть детальнее знать p2p сети.
А чем тогда поможет различие IPшников инетовских интерфейсов?
Этот вопрос ведь все равно еще актуален.
нифига не вижу, где там указывается интерфейс и шлюз в зависимости от, например, src ip
Да, тут понял, порт, к которому коннектимся, зависит от настроек клиента на чужой стороне. Значит тут поумнее надо правило фильтрации, тут надо чуть детальнее знать p2p сети.причём тут p2p
там веб(или смтп)-сервер, и тут тоже
причём тут p2pтак по какому критерию фильтровать? Source port? Source (извините) pid? Ну реально туплю
там веб(или смтп)-сервер, и тут тоже
Может я обстановку неправильно понял?
У чувака стоит клиент eMule на компе и он хочет, чтобы все, что с ним связано шло через один интерфейс в инет, а все остальное — через другой? Или не так?
там рерутинг реализуется засчет Source NAT
http://www.kerio.com/manual/kwf/en/img/nat-src-iface.png
этот НАТ, понятно, можно навесить на любое фаервольное правило
http://www.kerio.com/manual/kwf/en/img/pr-rules-email.png
http://www.kerio.com/manual/kwf/en/img/nat-src-iface.png
этот НАТ, понятно, можно навесить на любое фаервольное правило
http://www.kerio.com/manual/kwf/en/img/pr-rules-email.png
где там указывается интерфейс и шлюз в зависимости от, например, src ipна последней картинке колонка Source и есть src ip, а на первой интерфейс - в поле Interface
> так по какому критерию фильтровать? Source port? Source (извините) pid? Ну реально туплю
мне пох, если я юзер
к компу подходит красный кабель и зелёный
этот сайт доступен через красный, а тот - через зелёный, и пофиг, что IP совпадают
мне пох, если я юзер
к компу подходит красный кабель и зелёный
этот сайт доступен через красный, а тот - через зелёный, и пофиг, что IP совпадают
мне пох, если я юзерТы мне можешь сказать, какое правило ты будешь добавлять в фаерволл?
к компу подходит красный кабель и зелёный
этот сайт доступен через красный, а тот - через зелёный, и пофиг, что IP совпадают
не знаю
причём тут файрвол?
я тебе говорю задачу, с которой линуксовая реализация не справляется
причём тут файрвол?
я тебе говорю задачу, с которой линуксовая реализация не справляется
не знаюЛадно, я сдаюсь, я тебя не понимаю.
причём тут файрвол?
я тебе говорю задачу, с которой линуксовая реализация не справляется
Если есть два сайта разных, то так как я написал легко можно к ним доступ раскидать через разные интерфейсы.
Скажи тогда, как виндовая справляется. Интересно все-таки.
Проверял от безделья на ОКах. Инет был через WiFi и адрес 172.*.*.* был вайфаевый.
Я в своём первом посте кидал ссылку на прокси. Так вот, если там поставить loopback в качестве external ip 127.0.0.1, она реагирует так же (перестаёт соединять из чего с некоторой долей вероятноси можно предположить, что дело не в возможностях .NET
Я в своём первом посте кидал ссылку на прокси. Так вот, если там поставить loopback в качестве external ip 127.0.0.1, она реагирует так же (перестаёт соединять из чего с некоторой долей вероятноси можно предположить, что дело не в возможностях .NET
Ставить kerio ради такой простой вещи, когда я уже кинул ссылку на бесплатный proxy меньше 100кб размера в одном exe, имхо, весьма бредовая затея (и платная, если я правильно помню).
Речь шла о routing policy. Прокси это прокси, а фаервол это фаервол.
Оставить комментарий
vook
Скажем есть СНТО с "черным" IP и Yota WiMax. Хочется чтобы eMule качал через wimax, т.к. в этом случае выдается High ID. Как это можно настроить? ОС - Windows XP SP2.