Re: хитрый policy routing
19 мая 2008 г. 18:50 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 11:20 +0400, Sapytsky Ilya пишет: 19 мая 2008 г. 10:37 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 09:38 +0400, Sapytsky Ilya пишет: вья Добрый день! пару дней тут изучал доку по policy routing. после прочтения так и не понял можно ли сделать вот такую штуку: чтобы маршрут ставился в зависимости от интерфейса, по которому пакет пришел? типа если пришло через eth0 - обратно все пакеты этого соединения через этот интерфейс и отправлять. Если через eth1 - отправлять все пакеты этого соединения через eth1. И есть default gw, через который отправлять все исходящие соединения. Шаршрутизируй по FWMARK, FWMARK выставляй в iptables. Как известно в iptables критериев мнго. По входящему интерфейсу совсем не проблема. хм... не понял как это сделать? пока не понятна технология. Почему не понятна - если пришел пакет через eth0, а default gw стоит eth1 то будет следующее - пакет будет пытаться пролезть через eth0, но при этом ip отправителя будет стоять от интерфейса eth1. Или я не прав? можно ли примерчик? Примерчика нет. Скажу сразу, я такое пытался делать давно, но у меня не получилось. В рассылке netfilter'а проскакивают такие темы, я был на правильном пути, но видать где-то не доглядел... Если в кратце, то принцип такой: 1. На интересующее входящее с внешней стороны соединение, на пакет начинающий соединение (SYN) ставишь CONNMARK в какое-нибудь значение. 2. На обратном пути (пакеты-ответы) будут иметь такое же значение CONNMARK. Поскольку iproute2 не умеет работать с CONNMARK, а работает с MARK, тут тебе нужно сделать --restore-mark чтобы скопировать значение CONNMARK в MARK. 3. С помощью альтернативных таблиц маршрутизации делаешь так, чтобы пакеты с соответствующей маркой шли куда тебе надо. Повторить для каждого интерфейса где нада такая фишка. получилось сделать тупо, но при этом работает: ip rule add from my_ip_isp2 table outtest ip route add default src my_ip_isp2 dev eth1 via gw_ip_isp2 table outtest conntrack у меня при этом работает хорошо, но меченные пакеты в альтернативную таблицу маршрутизации не попадают :( примерно такая же проблема встретилась мне тут http://marc.info/?l=netfilterm=110893893101924w=2 сайта по ссылке нет, но зеркало тут: http://archives.mandrivalinux.com/cooker/2005-07/msg02543.php Может и у нас такие же проблемы есть до сих пор? кто-нибудь может это проверить? У меня с С программингом очень плохо... Если кто возьмется - СПАСИБО!
Re: хитрый policy routing
В Срд, 21/05/2008 в 15:58 +0400, Sapytsky Ilya пишет: 19 мая 2008 г. 18:50 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 11:20 +0400, Sapytsky Ilya пишет: 19 мая 2008 г. 10:37 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 09:38 +0400, Sapytsky Ilya пишет: вья Добрый день! пару дней тут изучал доку по policy routing. после прочтения так и не понял можно ли сделать вот такую штуку: чтобы маршрут ставился в зависимости от интерфейса, по которому пакет пришел? типа если пришло через eth0 - обратно все пакеты этого соединения через этот интерфейс и отправлять. Если через eth1 - отправлять все пакеты этого соединения через eth1. И есть default gw, через который отправлять все исходящие соединения. Шаршрутизируй по FWMARK, FWMARK выставляй в iptables. Как известно в iptables критериев мнго. По входящему интерфейсу совсем не проблема. хм... не понял как это сделать? пока не понятна технология. Почему не понятна - если пришел пакет через eth0, а default gw стоит eth1 то будет следующее - пакет будет пытаться пролезть через eth0, но при этом ip отправителя будет стоять от интерфейса eth1. Или я не прав? можно ли примерчик? Примерчика нет. Скажу сразу, я такое пытался делать давно, но у меня не получилось. В рассылке netfilter'а проскакивают такие темы, я был на правильном пути, но видать где-то не доглядел... Если в кратце, то принцип такой: 1. На интересующее входящее с внешней стороны соединение, на пакет начинающий соединение (SYN) ставишь CONNMARK в какое-нибудь значение. 2. На обратном пути (пакеты-ответы) будут иметь такое же значение CONNMARK. Поскольку iproute2 не умеет работать с CONNMARK, а работает с MARK, тут тебе нужно сделать --restore-mark чтобы скопировать значение CONNMARK в MARK. 3. С помощью альтернативных таблиц маршрутизации делаешь так, чтобы пакеты с соответствующей маркой шли куда тебе надо. Повторить для каждого интерфейса где нада такая фишка. у меня получилось примерно так же: на машине firewall (шлюз 2х dmz сетей) всё достаточно просто - mark1 для входа и mark2 для выхода. никаких conntrack не надо, просто если пришло на eth2 отдать через eth3 и наоборот - всё просто. а вот на конечной машине не всё так просто оказалось... настройки роутинга: ip route add $GATE dev eth1 table ytk ip route add default via $GATE dev eth1 table ytk /sbin/ip rule add fwmark 1 table ytk GATE - гейт для второго подключения, не default на машине настройки огненной стенки: EXT - удаленная машина, TEST1 - конечная, на которой всё и делается... iptables -t mangle --append PREROUTING --protocol tcp --syn --source $EXT --dst $TEST1 --in-interface eth1 --jump CONNMARK --set-mark 1 iptables -t mangle --append PREROUTING -m connmark --mark 1 --source $EXT --dst $TEST1 --in-interface eth1 --jump CONNMARK --restore-mark iptables --append INPUT -m connmark --mark 1 --source $EXT --dst $TEST1 --in-interface eth1 --jump ACCEPT до сюда отрабатывает хорошо, всё mark как надо... iptables -t mangle --append OUTPUT -m connmark --mark 1 --source $TEST1 --dst $EXT --jump CONNMARK --restore-mark iptables --append OUTPUT --source $TEST1 --dst $EXT --jump LOG --log-prefix output eth1 finded тут mark тоже ставиться как надо, но при этом на ip rule оно не уходит и пакет хочет выйти через eth0, хотя в ip rule указано, что надо через eth1 выходить.. Думал, что роутинг срабатывает раньше, чем mangle output работает, но по докам с картинками routing decision вроде как стоит позже. Вот на этом и застрял. Гугл ничего про эту ситуацию рассказать мне не смог. Может чего подскажете? Где я в 5 строчках мог накосячить? Спасибо! Смотри, в INPUT попадают пакеты адресованные самому роутеру, в OUTPUT попадают пакеты посылаемые самим роутером. На сколько я понял TEST1 и роутер это разные машины, если это так то тут и косяк. Честно говоря, я не въехал в схему подключения, можешь нарисовать? -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: хитрый policy routing
22 мая 2008 г. 12:11 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Срд, 21/05/2008 в 15:58 +0400, Sapytsky Ilya пишет: у меня получилось примерно так же: на машине firewall (шлюз 2х dmz сетей) всё достаточно просто - mark1 для входа и mark2 для выхода. никаких conntrack не надо, просто если пришло на eth2 отдать через eth3 и наоборот - всё просто. а вот на конечной машине не всё так просто оказалось... настройки роутинга: ip route add $GATE dev eth1 table ytk ip route add default via $GATE dev eth1 table ytk /sbin/ip rule add fwmark 1 table ytk GATE - гейт для второго подключения, не default на машине настройки огненной стенки: EXT - удаленная машина, TEST1 - конечная, на которой всё и делается... iptables -t mangle --append PREROUTING --protocol tcp --syn --source $EXT --dst $TEST1 --in-interface eth1 --jump CONNMARK --set-mark 1 iptables -t mangle --append PREROUTING -m connmark --mark 1 --source $EXT --dst $TEST1 --in-interface eth1 --jump CONNMARK --restore-mark iptables --append INPUT -m connmark --mark 1 --source $EXT --dst $TEST1 --in-interface eth1 --jump ACCEPT до сюда отрабатывает хорошо, всё mark как надо... iptables -t mangle --append OUTPUT -m connmark --mark 1 --source $TEST1 --dst $EXT --jump CONNMARK --restore-mark iptables --append OUTPUT --source $TEST1 --dst $EXT --jump LOG --log-prefix output eth1 finded тут mark тоже ставиться как надо, но при этом на ip rule оно не уходит и пакет хочет выйти через eth0, хотя в ip rule указано, что надо через eth1 выходить.. Думал, что роутинг срабатывает раньше, чем mangle output работает, но по докам с картинками routing decision вроде как стоит позже. Вот на этом и застрял. Гугл ничего про эту ситуацию рассказать мне не смог. Может чего подскажете? Где я в 5 строчках мог накосячить? Спасибо! Смотри, в INPUT попадают пакеты адресованные самому роутеру, в OUTPUT попадают пакеты посылаемые самим роутером. На сколько я понял TEST1 и роутер это разные машины, если это так то тут и косяк. Честно говоря, я не въехал в схему подключения, можешь нарисовать? уже постил сюда, еще раз повторю: структура моих внешних сетей / mail 1.0.1.2 пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3 firewall пров2 30.0.0.2 / \ 2.0.2.2 \ vpn 2.0.2.3 и мне надо прикрутить к машине mail еще одну сетевуху и сделать на ней второй mx чтобы было так / mail 1.0.1.2 --\ пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3\ firewall| пров2 30.0.0.2 / \ 2.0.2.2 ---2.0.2.4-/ \ vpn 2.0.2.3 нарисовал вроде как более-менее понятно... на машинке firewall всё правильно сделал, policy routing работает как надо, шлет пакеты через нужную сетевуху. Там всё просто, ибо там используется только prerouting. Только вот при traceroute неправльный ip отправляется, но через нужную сетевуху :D Это я думаю побороть можно А на конечной машинке mail, у которой 2 сетевухи - не получается именно так как я написал в предыдущем письме. Еще у меня возникла идея собрать ядро с поддержкой -j route, но ядро пока только собирается... я уже проверил - все соединения маркируются как надо, пакеты в mangle output тоже промаркированы как надо, а пакеты на роутинг не идут... Проверял на стандартном linux-2.6.18-6-486
Re: хитрый policy routing
19 мая 2008 г. 18:50 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 11:20 +0400, Sapytsky Ilya пишет: 19 мая 2008 г. 10:37 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 09:38 +0400, Sapytsky Ilya пишет: вья Добрый день! пару дней тут изучал доку по policy routing. после прочтения так и не понял можно ли сделать вот такую штуку: чтобы маршрут ставился в зависимости от интерфейса, по которому пакет пришел? типа если пришло через eth0 - обратно все пакеты этого соединения через этот интерфейс и отправлять. Если через eth1 - отправлять все пакеты этого соединения через eth1. И есть default gw, через который отправлять все исходящие соединения. Шаршрутизируй по FWMARK, FWMARK выставляй в iptables. Как известно в iptables критериев мнго. По входящему интерфейсу совсем не проблема. хм... не понял как это сделать? пока не понятна технология. Почему не понятна - если пришел пакет через eth0, а default gw стоит eth1 то будет следующее - пакет будет пытаться пролезть через eth0, но при этом ip отправителя будет стоять от интерфейса eth1. Или я не прав? можно ли примерчик? Примерчика нет. Скажу сразу, я такое пытался делать давно, но у меня не получилось. В рассылке netfilter'а проскакивают такие темы, я был на правильном пути, но видать где-то не доглядел... Если в кратце, то принцип такой: 1. На интересующее входящее с внешней стороны соединение, на пакет начинающий соединение (SYN) ставишь CONNMARK в какое-нибудь значение. 2. На обратном пути (пакеты-ответы) будут иметь такое же значение CONNMARK. Поскольку iproute2 не умеет работать с CONNMARK, а работает с MARK, тут тебе нужно сделать --restore-mark чтобы скопировать значение CONNMARK в MARK. 3. С помощью альтернативных таблиц маршрутизации делаешь так, чтобы пакеты с соответствующей маркой шли куда тебе надо. Повторить для каждого интерфейса где нада такая фишка. у меня получилось примерно так же: на машине firewall (шлюз 2х dmz сетей) всё достаточно просто - mark1 для входа и mark2 для выхода. никаких conntrack не надо, просто если пришло на eth2 отдать через eth3 и наоборот - всё просто. а вот на конечной машине не всё так просто оказалось... настройки роутинга: ip route add $GATE dev eth1 table ytk ip route add default via $GATE dev eth1 table ytk /sbin/ip rule add fwmark 1 table ytk GATE - гейт для второго подключения, не default на машине настройки огненной стенки: EXT - удаленная машина, TEST1 - конечная, на которой всё и делается... iptables -t mangle --append PREROUTING --protocol tcp --syn --source $EXT --dst $TEST1 --in-interface eth1 --jump CONNMARK --set-mark 1 iptables -t mangle --append PREROUTING -m connmark --mark 1 --source $EXT --dst $TEST1 --in-interface eth1 --jump CONNMARK --restore-mark iptables --append INPUT -m connmark --mark 1 --source $EXT --dst $TEST1 --in-interface eth1 --jump ACCEPT до сюда отрабатывает хорошо, всё mark как надо... iptables -t mangle --append OUTPUT -m connmark --mark 1 --source $TEST1 --dst $EXT --jump CONNMARK --restore-mark iptables --append OUTPUT --source $TEST1 --dst $EXT --jump LOG --log-prefix output eth1 finded тут mark тоже ставиться как надо, но при этом на ip rule оно не уходит и пакет хочет выйти через eth0, хотя в ip rule указано, что надо через eth1 выходить.. Думал, что роутинг срабатывает раньше, чем mangle output работает, но по докам с картинками routing decision вроде как стоит позже. Вот на этом и застрял. Гугл ничего про эту ситуацию рассказать мне не смог. Может чего подскажете? Где я в 5 строчках мог накосячить? Спасибо!
Re: хитрый policy routing
В Пнд, 19/05/2008 в 09:38 +0400, Sapytsky Ilya пишет: вья Добрый день! пару дней тут изучал доку по policy routing. после прочтения так и не понял можно ли сделать вот такую штуку: чтобы маршрут ставился в зависимости от интерфейса, по которому пакет пришел? типа если пришло через eth0 - обратно все пакеты этого соединения через этот интерфейс и отправлять. Если через eth1 - отправлять все пакеты этого соединения через eth1. И есть default gw, через который отправлять все исходящие соединения. Шаршрутизируй по FWMARK, FWMARK выставляй в iptables. Как известно в iptables критериев мнго. По входящему интерфейсу совсем не проблема. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: хитрый policy routing
Sapytsky Ilya - debian-russian @ Mon, 19 May 2008 09:38:32 +0400:
SI вья Добрый день!
SI пару дней тут изучал доку по policy routing.
SI после прочтения так и не понял можно ли сделать вот такую штуку:
SI чтобы маршрут ставился в зависимости от интерфейса, по которому пакет
SI пришел?
SI типа если пришло через eth0 - обратно все пакеты этого соединения через
этот
SI интерфейс и отправлять.
SI Если через eth1 - отправлять все пакеты этого соединения через eth1.
SI И есть default gw, через который отправлять все исходящие соединения.
SI Для чего это надо:
SI есть 2 провайдера и хочется сделать на *одной *машинке почтовик, который в
SI dns прописать как 2 mx двух внешних ip двух провайдеров.
SI Но 2 ip не для load balansing, а для отказоустойчивости через 2 провайдера.
SI точно так же хотелось бы сделать ftp сервер с 2мя ip и так далее.
SI Может я многого хочу и так сделать нельзя?
SI Или лучше сделать вторую машину с одним внешним интерфейсом второго
SI провайдера, хотя очень не хочется делать по дубовому, хотя машинок могу
SI наделать сколько хочу (виртуализация).
SI Сейчас у 2х провайдеров, которые есть в моем шкафу есть 2 сети на 16
адресов
SI (типа dmz у каждого из провайдеров) и пока никакой отказоустойчивости нет,
а
SI охота.
SI Подскажите что в моей ситуации можно сделать?
Если TCP, то можно. В TCP обратный пакет идет с того же адреса, на
который пришел исходный. Дальше строго по соответствующей главе lartc.
Если почтовка стоит за DNAT, то, соответственно, натить разные адреса
надо в разные.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
HTTP тоже не каждый дятел может сделать. Только дятлы об этом обычно не знают.
Victor Wagner в [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: хитрый policy routing
19 мая 2008 г. 10:37 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 09:38 +0400, Sapytsky Ilya пишет: вья Добрый день! пару дней тут изучал доку по policy routing. после прочтения так и не понял можно ли сделать вот такую штуку: чтобы маршрут ставился в зависимости от интерфейса, по которому пакет пришел? типа если пришло через eth0 - обратно все пакеты этого соединения через этот интерфейс и отправлять. Если через eth1 - отправлять все пакеты этого соединения через eth1. И есть default gw, через который отправлять все исходящие соединения. Шаршрутизируй по FWMARK, FWMARK выставляй в iptables. Как известно в iptables критериев мнго. По входящему интерфейсу совсем не проблема. хм... не понял как это сделать? пока не понятна технология. Почему не понятна - если пришел пакет через eth0, а default gw стоит eth1 то будет следующее - пакет будет пытаться пролезть через eth0, но при этом ip отправителя будет стоять от интерфейса eth1. Или я не прав? можно ли примерчик?
Re: хитрый policy routing
19 мая 2008 г. 11:03 пользователь Artem Chuprina [EMAIL PROTECTED] написал: Sapytsky Ilya - debian-russian @ Mon, 19 May 2008 09:38:32 +0400: SI вья Добрый день! SI пару дней тут изучал доку по policy routing. SI после прочтения так и не понял можно ли сделать вот такую штуку: SI чтобы маршрут ставился в зависимости от интерфейса, по которому пакет SI пришел? SI типа если пришло через eth0 - обратно все пакеты этого соединения через этот SI интерфейс и отправлять. SI Если через eth1 - отправлять все пакеты этого соединения через eth1. SI И есть default gw, через который отправлять все исходящие соединения. SI Для чего это надо: SI есть 2 провайдера и хочется сделать на *одной *машинке почтовик, который в SI dns прописать как 2 mx двух внешних ip двух провайдеров. SI Но 2 ip не для load balansing, а для отказоустойчивости через 2 провайдера. SI точно так же хотелось бы сделать ftp сервер с 2мя ip и так далее. SI Может я многого хочу и так сделать нельзя? SI Или лучше сделать вторую машину с одним внешним интерфейсом второго SI провайдера, хотя очень не хочется делать по дубовому, хотя машинок могу SI наделать сколько хочу (виртуализация). SI Сейчас у 2х провайдеров, которые есть в моем шкафу есть 2 сети на 16 адресов SI (типа dmz у каждого из провайдеров) и пока никакой отказоустойчивости нет, а SI охота. SI Подскажите что в моей ситуации можно сделать? Если TCP, то можно. В TCP обратный пакет идет с того же адреса, на который пришел исходный. Дальше строго по соответствующей главе lartc. Если почтовка стоит за DNAT, то, соответственно, натить разные адреса надо в разные. нет, почтовка стоит за firewall, на котором 4 интерфейса для 2х провайдеров по 2 сетевухи. Как на это firewall это сделать - думаю
Re: хитрый policy routing
Sapytsky Ilya - debian-russian @ Mon, 19 May 2008 11:20:39 +0400:
SI Почему не понятна - если пришел пакет через eth0, а default gw
SI стоит eth1 то будет следующее - пакет будет пытаться пролезть через
SI eth0, но при этом ip отправителя будет стоять от интерфейса
SI eth1. Или я не прав?
По умолчанию - ровно наоборот.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
А еще следует потребовать, чтобы программисты, перед тем, как писать код,
внимательно прочли спецификацию: с сыром - это чизбургер.
Игус в [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: хитрый policy routing
Sapytsky Ilya - debian-russian@lists.debian.org @ Mon, 19 May 2008 11:23:20
+0400:
Если TCP, то можно. В TCP обратный пакет идет с того же адреса, на
который пришел исходный. Дальше строго по соответствующей главе lartc.
Если почтовка стоит за DNAT, то, соответственно, натить разные адреса
надо в разные.
SI нет, почтовка стоит за firewall, на котором 4 интерфейса для 2х
SI провайдеров по 2 сетевухи. Как на это firewall это сделать - думаю
Кто на ком стоял? Конфигурацию опиши подробно. Интерфейсы и адреса
на почтовке и на файрволе, и соотношение их с провайдерами. Можно
ненастоящие, но соответствие должно быть :-)
У тебя только что было 2 интерфейса, а уже стало 4...
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
У кошки четыре ноги: ввод, вывод, земля и питание.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: хитрый policy routing
19 мая 2008 г. 11:59 пользователь Artem Chuprina [EMAIL PROTECTED] написал: Sapytsky Ilya - debian-russian@lists.debian.org @ Mon, 19 May 2008 11:23:20 +0400: Если TCP, то можно. В TCP обратный пакет идет с того же адреса, на который пришел исходный. Дальше строго по соответствующей главе lartc. Если почтовка стоит за DNAT, то, соответственно, натить разные адреса надо в разные. SI нет, почтовка стоит за firewall, на котором 4 интерфейса для 2х SI провайдеров по 2 сетевухи. Как на это firewall это сделать - думаю Кто на ком стоял? Конфигурацию опиши подробно. Интерфейсы и адреса на почтовке и на файрволе, и соотношение их с провайдерами. Можно ненастоящие, но соответствие должно быть :-) У тебя только что было 2 интерфейса, а уже стало 4... ситуация такая: структура моих внешних сетей / mail 1.0.1.2 пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3 firewall пров2 30.0.0.2 / \ 2.0.2.2 \ vpn 2.0.2.3 и мне надо прикрутить к машине mail еще одну сетевуху и сделать на ней второй mx чтобы было так / mail 1.0.1.2 --\ пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3\ firewall | пров2 30.0.0.2 / \ 2.0.2.2 ---2.0.2.4-/ \ vpn 2.0.2.3 нарисовал вроде как более-менее понятно... при этом надо будет настраивать пока непонятно как routing на машинках mail и firewall соответственно, чтобы этот трафик можно было выпустить... Наверное всё это хозяйство можно как-нибудь переделать, чтобы было более оптимально, но пока не знаю как...
Re: хитрый policy routing
Sapytsky Ilya - debian-russian@lists.debian.org @ Mon, 19 May 2008 13:53:47
+0400:
Если TCP, то можно. В TCP обратный пакет идет с того же адреса, на
который пришел исходный. Дальше строго по соответствующей главе
SI lartc.
Если почтовка стоит за DNAT, то, соответственно, натить разные адреса
надо в разные.
SI нет, почтовка стоит за firewall, на котором 4 интерфейса для 2х
SI провайдеров по 2 сетевухи. Как на это firewall это сделать - думаю
Кто на ком стоял? Конфигурацию опиши подробно. Интерфейсы и адреса
на почтовке и на файрволе, и соотношение их с провайдерами. Можно
ненастоящие, но соответствие должно быть :-)
У тебя только что было 2 интерфейса, а уже стало 4...
SI ситуация такая:
SI структура моих внешних сетей
SI/ mail 1.0.1.2
SI пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3
SI firewall
SI пров2 30.0.0.2 / \ 2.0.2.2
SI\ vpn 2.0.2.3
SI и мне надо прикрутить к машине mail еще одну сетевуху и сделать на ней
SI второй mx
SI чтобы было так
SI/ mail 1.0.1.2 --\
SI пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3\
SI firewall |
SI пров2 30.0.0.2 / \ 2.0.2.2 ---2.0.2.4-/
SI\ vpn 2.0.2.3
SI нарисовал вроде как более-менее понятно...
SI при этом надо будет настраивать пока непонятно как routing на машинках mail
SI и firewall соответственно, чтобы этот трафик можно было выпустить...
SI Наверное всё это хозяйство можно как-нибудь переделать, чтобы было более
SI оптимально, но пока не знаю как...
Не, еще одну сетевуху совершенно ни к чему. Достаточно еще один адрес
на ту же сетевуху. Можно в той же подсети. На почтовке по идее больше
ничего делать не надо. Она будет отвечать с того адреса, на который
пришли, а маршрут тот же самый.
Судя по тому, что я вижу, у тебя, похоже, все-таки DNAT на файрволе, а
не просто маршрутизация. Разница, впрочем, невелика. Просто надо его
настроить так, чтобы он пакеты для одного из внешних адресов mx
пробрасывал на один его внутренний адрес, а для другого - на другой.
А дальше - http://lartc.org/howto/lartc.rpdb.multiple-links.html. Тебя
интересует не load balancing, а split access. Это делается на файрволе.
В случае с NAT может быть разница во фрагменте
ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
Тут может потребоваться указывать внутренние адреса почтовки, а не
внешние, поскольку, если я правильно ошибаюсь, на момент принятия
решения о роутинге обратный NAT еще не произведен.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
Including Common Lisp.
-- Robert Morris
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: хитрый policy routing
19 мая 2008 г. 16:41 пользователь Artem Chuprina [EMAIL PROTECTED] написал: Sapytsky Ilya - debian-russian@lists.debian.org @ Mon, 19 May 2008 13:53:47 +0400: Если TCP, то можно. В TCP обратный пакет идет с того же адреса, на который пришел исходный. Дальше строго по соответствующей главе SI lartc. Если почтовка стоит за DNAT, то, соответственно, натить разные адреса надо в разные. SI нет, почтовка стоит за firewall, на котором 4 интерфейса для 2х SI провайдеров по 2 сетевухи. Как на это firewall это сделать - думаю Кто на ком стоял? Конфигурацию опиши подробно. Интерфейсы и адреса на почтовке и на файрволе, и соотношение их с провайдерами. Можно ненастоящие, но соответствие должно быть :-) У тебя только что было 2 интерфейса, а уже стало 4... SI ситуация такая: SI структура моих внешних сетей SI/ mail 1.0.1.2 SI пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3 SI firewall SI пров2 30.0.0.2 / \ 2.0.2.2 SI\ vpn 2.0.2.3 SI и мне надо прикрутить к машине mail еще одну сетевуху и сделать на ней SI второй mx SI чтобы было так SI/ mail 1.0.1.2 --\ SI пров1 20.0.0.1 \ / 1.0.1.1 - ftp 1.0.1.3\ SI firewall | SI пров2 30.0.0.2 / \ 2.0.2.2 ---2.0.2.4-/ SI\ vpn 2.0.2.3 SI нарисовал вроде как более-менее понятно... SI при этом надо будет настраивать пока непонятно как routing на машинках mail SI и firewall соответственно, чтобы этот трафик можно было выпустить... SI Наверное всё это хозяйство можно как-нибудь переделать, чтобы было более SI оптимально, но пока не знаю как... Не, еще одну сетевуху совершенно ни к чему. Достаточно еще один адрес на ту же сетевуху. Можно в той же подсети. На почтовке по идее больше ничего делать не надо. Она будет отвечать с того адреса, на который пришли, а маршрут тот же самый. мне в vmware несложно еще одну сетевуху нарисовать :) ибо все интернет сервисы у меня виртуализированы. из той же подсети не надо, ибо у меня есть 2 белые сети провайдеров. Именно ради 2х разных ip из разных сетей это всё и затевалось. Судя по тому, что я вижу, у тебя, похоже, все-таки DNAT на файрволе, а не просто маршрутизация. Разница, впрочем, невелика. Просто надо его настроить так, чтобы он пакеты для одного из внешних адресов mx пробрасывал на один его внутренний адрес, а для другого - на другой. нет, у меня именно марштутизация, у меня от 2х провайдеров есть 2 белых сети на 16 адресов каждая, которые на рисунке обозначены 1.0.1.1 и далее и 2.0.2.2 и далее А дальше - http://lartc.org/howto/lartc.rpdb.multiple-links.html. Тебя интересует не load balancing, а split access. Это делается на файрволе. В случае с NAT может быть разница во фрагменте ip rule add from $IP1 table T1 ip rule add from $IP2 table T2 Тут может потребоваться указывать внутренние адреса почтовки, а не внешние, поскольку, если я правильно ошибаюсь, на момент принятия решения о роутинге обратный NAT еще не произведен. сейчас пытаюсь это дело смоделировать на виртуалках - до самого процесса тестирования пока еще не дошел. все адреса, которые я указывал на рисунке - белые.
Re: хитрый policy routing
Sapytsky Ilya - debian-russian@lists.debian.org @ Mon, 19 May 2008 16:58:49
+0400:
SI мне в vmware несложно еще одну сетевуху нарисовать :)
Верю, что несложно. Только это нафиг не нужно. Городить двустволку
вполне достаточно только на файрволе.
--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]
If a `religion' is defined to be a system of ideas that contains
unprovable statements, then Godel taught us that mathematics is not
only a religion, it is the only religion that can prove itself to be
one.
-- John Barrow
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: хитрый policy routing
В Пнд, 19/05/2008 в 11:20 +0400, Sapytsky Ilya пишет: 19 мая 2008 г. 10:37 пользователь Покотиленко Костик [EMAIL PROTECTED] написал: В Пнд, 19/05/2008 в 09:38 +0400, Sapytsky Ilya пишет: вья Добрый день! пару дней тут изучал доку по policy routing. после прочтения так и не понял можно ли сделать вот такую штуку: чтобы маршрут ставился в зависимости от интерфейса, по которому пакет пришел? типа если пришло через eth0 - обратно все пакеты этого соединения через этот интерфейс и отправлять. Если через eth1 - отправлять все пакеты этого соединения через eth1. И есть default gw, через который отправлять все исходящие соединения. Шаршрутизируй по FWMARK, FWMARK выставляй в iptables. Как известно в iptables критериев мнго. По входящему интерфейсу совсем не проблема. хм... не понял как это сделать? пока не понятна технология. Почему не понятна - если пришел пакет через eth0, а default gw стоит eth1 то будет следующее - пакет будет пытаться пролезть через eth0, но при этом ip отправителя будет стоять от интерфейса eth1. Или я не прав? можно ли примерчик? Примерчика нет. Скажу сразу, я такое пытался делать давно, но у меня не получилось. В рассылке netfilter'а проскакивают такие темы, я был на правильном пути, но видать где-то не доглядел... Если в кратце, то принцип такой: 1. На интересующее входящее с внешней стороны соединение, на пакет начинающий соединение (SYN) ставишь CONNMARK в какое-нибудь значение. 2. На обратном пути (пакеты-ответы) будут иметь такое же значение CONNMARK. Поскольку iproute2 не умеет работать с CONNMARK, а работает с MARK, тут тебе нужно сделать --restore-mark чтобы скопировать значение CONNMARK в MARK. 3. С помощью альтернативных таблиц маршрутизации делаешь так, чтобы пакеты с соответствующей маркой шли куда тебе надо. Повторить для каждого интерфейса где нада такая фишка. -- Покотиленко Костик [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
хитрый policy routing
вья Добрый день! пару дней тут изучал доку по policy routing. после прочтения так и не понял можно ли сделать вот такую штуку: чтобы маршрут ставился в зависимости от интерфейса, по которому пакет пришел? типа если пришло через eth0 - обратно все пакеты этого соединения через этот интерфейс и отправлять. Если через eth1 - отправлять все пакеты этого соединения через eth1. И есть default gw, через который отправлять все исходящие соединения. Для чего это надо: есть 2 провайдера и хочется сделать на *одной *машинке почтовик, который в dns прописать как 2 mx двух внешних ip двух провайдеров. Но 2 ip не для load balansing, а для отказоустойчивости через 2 провайдера. точно так же хотелось бы сделать ftp сервер с 2мя ip и так далее. Может я многого хочу и так сделать нельзя? Или лучше сделать вторую машину с одним внешним интерфейсом второго провайдера, хотя очень не хочется делать по дубовому, хотя машинок могу наделать сколько хочу (виртуализация). Сейчас у 2х провайдеров, которые есть в моем шкафу есть 2 сети на 16 адресов (типа dmz у каждого из провайдеров) и пока никакой отказоустойчивости нет, а охота. Подскажите что в моей ситуации можно сделать?
