natd -p 8668 -a ip1
natd -p 8669 -a ip2ipfw add divert 8668 ip from any to ip1 recv if1
ipfw add divert 8669 ip from any to ip2 recv if2
ipfw add check-state
ipfw add prob 0.5 divert 8668 ip from 192.168.0.0/16 to any xmit if1 keep-state
ipfw add divert 8669 ip from 192.168.0.0/16 to any xmit if1 keep-state
ipfw add fwd gw1 ip from ip1 to any out xmit if1 (если default на if1)
ipfw add fwd gw2 ip from ip2 to any out xmit if1URL:
Обсуждается: https://www.opennet.ru/tips/info/1009.shtml
В строке
ipfw add fwd gw2 ip from ip2 to any out xmit if1
необходимо заменить имя интерфейса if1 на if2
вопрос Профи
как себя поведет этот метод в том сдкек когда хост назначения привязытся к ip искточника...
был печальный обыт с баланчировкой в PF но мне не понарвиось как вели себя мние сайты с авторизацией... которые повидимому запоминали ip источнка но приследующем обращении он сенялся на ip другго канала который не равен ip при логине ... как следстивие меня просто выбразывало со многих серверов ....
Хреново ведёт, только у меня вопрос - что это за поделки такие, которые с ип-а авторизацию делают? А если я, как юзер провайдера поменял? Или с другого источника инет юзаю? Вобщем если понаделали поделок - пусть сами с ними и ибу*а.
простите за кривые руки .... нечем не выровнить
А что будет, если 1 из каналов ляжет? 50% потерь?
>А что будет, если 1 из каналов ляжет? 50% потерь?в данном случае да, но никто не запрещает написать скрипт проверки канала и исправление правил в зависимости от ситуации.
В описанном виде работать не будет.
Объясню. Допустим, клиент соединяется с хостом foo по протоколу tcp. Высылает запрос, его запрос транслируется через ip1, получает ответ, tcp-сессия установлена, хост foo запоминает комбинацию ip1:src-port1 для этой сессии. Теперь, следующий пакет, от клиента, оттранслированный уже через ip2 придет на хост foo с ip2:src-port2 и, есс-но не будет связан с этой сессией и будет отброшен. Соответсвенно, получим 50% потерь для этой сессии.
Автору. Внимательно учим RFC793.
Не вникая в суть написанных правил и проблемы смею предположить что гейт, который делает балансировку, пакеты, идущие с одного ИП, будет слать в один и тот же канал. так что никаких потерь не будет. балансировки для одного tcp-соединения не будет.
Работать должно.
Дело тут не в канале, а в том, что пакеты одной и той же сессии приходят на узел назначения с разных адресов. Механизм мультиплексирования TCP протокола предполагает определение принадлежности пакетов к определенному TCP-соединению по комбинации пар IP:port источника и получателя. Разные адреса и/или порты источника - разные сессии с точки зрения получателя.
>пакеты, идущие с одного ИП, будет слать в
>один и тот же канал. так что никаких потерь не будет.>>>балансировки для одного tcp-соединения не будет. <<<
>Работать должно.
Абсолютно верно.
>В описанном виде работать не будет.
...
интересно, а для чего используется связка keep-state, check-state???
По моему имеено для сохранения сессий.
>>В описанном виде работать не будет.
>...
>интересно, а для чего используется связка keep-state, check-state???
>По моему имеено для сохранения сессий.
Внимательно читаем man ipfw.
Вкратце, данные команды предназначены для генерации динамических правил в ipfw. Никаих данных о TCP соединении они не сохраняют.
ну хорошо, пусть будет "динамические правила", которые запоминают связку адреса источника, назначения, протокол и интерфейс. Т.о. при повторении адресов повторяется и правило ipfw.
check-state:
"Checks the packet against the dynamic ruleset. If a match is
found, execute the action associated with the rule which gener-
ated this dynamic rule, otherwise move to the next rule."
keep-state:
"Upon a match, the firewall will create a dynamic rule, whose
default behaviour is to match bidirectional traffic between
source and destination IP/port using the same protocol."Возможно немного нужно будет подправить:
ipfw add check-state
ipfw add prob 0.5 divert 8668 ip from 192.168.0.0/16 to any xmit if1 keep-state
ipfw add divert 8669 ip from 192.168.0.0/16 to any xmit if1 keep-stateна:
ipfw add check-state
ipfw add prob 0.5 skip to xxx
ipfw add divert 8668 ip from 192.168.0.0/16 to any xmit if1 keep-state
ipfw add xxx divert 8669 ip from 192.168.0.0/16 to any xmit if1 keep-stateно в общем, пример очень даже рабочий.
и какой будет окончательный вердикт, все это ухищрения и заклинанья у кого нить работают однозначно хорошо или все хорошо то лько в теории
>и какой будет окончательный вердикт, все это ухищрения и заклинанья у кого
>нить работают однозначно хорошо или все хорошо то лько в теории
>
Балансировать трафик средствами ipfw во freebsd можно. Только немного иначе.Вкратце, идея: имеем ОДИН natd, адреса транслируем им на какой-либо свой. Собственно балансировка выполняется правилом fwd.
Идеально, если у вас есть собственная независимая от провайдера сеть и автономная система. Второй вариант, договориться с одним из провайдеров, чтобы он пускал к себе и выпускал из своей АС пакеты с обратным адресом другого.
Далее такая конфигурация файрволла.1. дефолтный маршрут через интерфейс ext0 (первый провайдер)
2. переменная ядра net.inet.ip.fw.one_pass=0
3. правила касающиеся балансировки:
# здесь x.x.x.x адрес маршрутизатора по умолчанию второго провайдера.
10 divert 8868 ip from any to any out via ext0
20 prob 0.5 fwd x.x.x.x ip from any to any out via ext04. natd должен иметь базовый адрес отвечающий описанным ранее условиям.
И будет вам счастье. Правда только для исходящего трафика. Балансировка входящего трафика от разных провайдеров задача очень трудно решаемая.
Внимательно смотрим, что я написал :-) И man ipfw на предмет keep-state. Случайным образом выбирается исходящий адрес только для первого пакета tcp/udp соединения. Все последующие пакеты этого соединения идут тем же интерфейсом, тем же шлюзом и от того же ip, как и первый.
>Внимательно смотрим, что я написал :-) И man ipfw на предмет keep-state.
>Случайным образом выбирается исходящий адрес только для первого пакета tcp/udp соединения.
>Все последующие пакеты этого соединения идут тем же интерфейсом, тем же
>шлюзом и от того же ip, как и первый.
Если динамические правила создаются для пакетов в обе стороны, а не только для ответных входящих, то работать будет. Надо еще проследить за значением переменных ядра касающихся динамических правил, чтобы время жизни правил соответсвовало времени жизни сессий и максимальное количество правил было достаточно.
Данное решение позволит равномерно распределить между каналами TCP/UDP сессии, но не трафик. Зато действовать будет как для исхода так и для входа.
Трудно предсказать, как это решение будет работать для протоколов кроме TCP/UDP. Лучше всего такие протоколы пустить через один из каналов статически.
Как-то криво работает keep-state в freebsd 5.4
как только проходит какой-то трафик через правило 8000
начинают сильно валить пакеты даже если на маршрутизатор их никто не шлет,
какбудь-то гоняет пакеты покругу. Через маршрутизатор трафик не проходит.
если убрать из правил keep-state инет начинает работать, трафик идет по обоим каналам
но естетсвенно tcp работает криво. Что не так с keep-state ?# ipfw show
06100 20 900 divert 8668 ip from any to 192.168.181.1 recv rl1
06200 84 5280 divert 8669 ip from any to 192.168.182.1 recv rl1
06500 0 0 check-state
08000 12239324 601865712 prob 0.500000 divert 8668 ip from 172.18.0.0/22 to any out keep-state
08600 462 105157 divert 8669 ip from 172.18.0.0/22 to any out keep-state
08700 20 4228 fwd 192.168.181.2 ip from 192.168.181.1 to any out
08800 53 6901 fwd 192.168.182.2 ip from 192.168.182.1 to any out
65010 0 0 allow ip from any to any via lo0
65020 984 167457 allow ip from any to any via rl0
65030 295 61321 allow ip from any to any via rl1
65535 308 29275 deny ip from any to any
>Как-то криво работает keep-state в freebsd 5.4
>как только проходит какой-то трафик через правило 8000
>начинают сильно валить пакеты даже если на маршрутизатор их никто не шлет,
>
>какбудь-то гоняет пакеты покругу.тоже самое freebsd 6,2
Господа, позвольте обратить Ваше внимание на девайс
Dlink DI-LB-604-
заявлена балансировка нагрузки между 2 WAN портами по IP,СЕССИЯМ и БАЙТАМ В СЕКУНДУ.Может и не мудрить тогда? Посавить железяку?
>Господа, позвольте обратить Ваше внимание на девайс
>Dlink DI-LB-604-
>заявлена балансировка нагрузки между 2 WAN портами по IP,СЕССИЯМ и БАЙТАМ В
>СЕКУНДУ.
>
>Может и не мудрить тогда? Посавить железяку?в таком случае может обращать внимания на продукты от мелкомягких и не париться с BSD и GNU?