Re: [freebsd] ECMP
20.09.2017 12:59, Vladislav V. Prodan пишет: 20 сентября 2017 г., 10:34 пользователь Andrew G Sorokin написал: 19.09.2017 20:16, Vladislav V. Prodan пишет: 19 сентября 2017 г., 17:23 пользователь Andrew G Sorokin < ange...@elm.dp.ua> написал: Доброго времени суток , коллеги. Завел у себя дома второго провайдера и решил сделать балансировку трафика -- У меня работает балансировка. поделитесь, пожалуйта. uname -r FreeBSD 11.0-STABLE #0 r311150: Tue Jan 3 04:47:48 EET 2017 спасибо у меня есть под боком еще роутер 11.0-RELEASE-p12 странно но проблема с маршрутизацией такая-же. попробую дома поставить STABLE этой ревизии >> ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] ECMP
20 сентября 2017 г., 10:34 пользователь Andrew G Sorokin написал: > > > 19.09.2017 20:16, Vladislav V. Prodan пишет: > >> 19 сентября 2017 г., 17:23 пользователь Andrew G Sorokin < >> ange...@elm.dp.ua> >> написал: >> >> Доброго времени суток , коллеги. >>> >>> Завел у себя дома второго провайдера и решил сделать балансировку трафика >>> >>> -- > >> >> У меня работает балансировка. >> > поделитесь, пожалуйта. > uname -r FreeBSD 11.0-STABLE #0 r311150: Tue Jan 3 04:47:48 EET 2017 > > Правда в случае отсутствия автономки и белых IP из разных диапазонов >> чревато обратными пакетами с разными src-IP. >> В итоге хомячок это видит как "не грузятся странички" на CDN сервисах. >> > CDN может кидать пакеты в 1 TCP сесию с разных IP ??? > что-то я не понял механизма А почему вы решили что современный браузер открывает только одну tcp сессию к заданному URL ? -- Vladislav V. Prodan System & Network Administrator support.od.ua ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] ECMP
On 19.09.2017 21:23, Andrew G Sorokin wrote: > Доброго времени суток , коллеги. > > Завел у себя дома второго провайдера и решил сделать балансировку трафика > defaulta.a.a.a US tun0 > defaultb.b.b.b US tun1 Раскидывать трафик одного TCP потока по разным провайдерам/разным src IP - безумная идея. Раскидывать трафик разных потоков трафика одного и того же хоста по разным провайдерам - просто плохая идея, так как очень многие сервисы, включая тот же ютуб, этого не любят и работать не будут стабильно, пока не отключишь. Раскидывать трафик разных хостов локалки по разным провайдерам можно без проблем, но в этом должен активное участие принимать NAT/пакетный фильтр и тогда ECMP просто не нужен. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] ECMP
19.09.2017 20:16, Vladislav V. Prodan пишет: 19 сентября 2017 г., 17:23 пользователь Andrew G Sorokin написал: Доброго времени суток , коллеги. Завел у себя дома второго провайдера и решил сделать балансировку трафика -- У меня работает балансировка. поделитесь, пожалуйта. uname -r Правда в случае отсутствия автономки и белых IP из разных диапазонов чревато обратными пакетами с разными src-IP. В итоге хомячок это видит как "не грузятся странички" на CDN сервисах. CDN может кидать пакеты в 1 TCP сесию с разных IP ??? что-то я не понял механизма Ну, еще нюансы с PF NAT... ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] ECMP
19.09.2017 18:36, Andrey V. Elsukov пишет: On 19.09.2017 17:23, Andrew G Sorokin wrote: Доброго времени суток , коллеги. Завел у себя дома второго провайдера и решил сделать балансировку трафика Добавил к GENERIC в конце options RADIX_MPATH перекомпилил и загрузился с новым ядром . -- Там Ermal предложил патч, который вроде бы должен помогать для IPv4, не пробовали? https://lists.freebsd.org/pipermail/freebsd-net/2017-February/047228.html пробовал - перестали через шлюз ходить ICMP, а балансировка так и не заработала. ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] ECMP
19 сентября 2017 г., 17:23 пользователь Andrew G Sorokin написал: > Доброго времени суток , коллеги. > > Завел у себя дома второго провайдера и решил сделать балансировку трафика > > Добавил к GENERIC в конце options RADIX_MPATH > перекомпилил и загрузился с новым ядром . > > но ожидаемого эффекта не получил. > в системе 2 дефолт маршрута но трафик уходит в тот , который появился в > системе первым. > если его руками положить\поднять - трафик начинает ходить по второму. > У меня работает балансировка. Правда в случае отсутствия автономки и белых IP из разных диапазонов чревато обратными пакетами с разными src-IP. В итоге хомячок это видит как "не грузятся странички" на CDN сервисах. Ну, еще нюансы с PF NAT... -- Vladislav V. Prodan System & Network Administrator support.od.ua ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] ECMP
On 19.09.2017 17:23, Andrew G Sorokin wrote: > Доброго времени суток , коллеги. > > Завел у себя дома второго провайдера и решил сделать балансировку трафика > > Добавил к GENERIC в конце options RADIX_MPATH > перекомпилил и загрузился с новым ядром . > > но ожидаемого эффекта не получил. > в системе 2 дефолт маршрута но трафик уходит в тот , который появился в > системе первым. > если его руками положить\поднять - трафик начинает ходить по второму. > > нарыл в такое > https://lists.freebsd.org/pipermail/freebsd-net/2017-February/047203.html > и решения там нет > > на 9.2 такая конструкция у меня раскидывала трафик по 3-м каналам... > это стало историей ? и нужно как-то по-другому решать ? > подскажите. Там Ermal предложил патч, который вроде бы должен помогать для IPv4, не пробовали? https://lists.freebsd.org/pipermail/freebsd-net/2017-February/047228.html -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature ___ freebsd mailing list freebsd@uafug.org.ua http://mailman.uafug.org.ua/mailman/listinfo/freebsd
Re: [freebsd] ECMP + ipfw nat
On 13.12.2011 13:47, Eugene Grosbein wrote: > 13.12.2011 18:34, Зеленяк Алексей пишет: > >> Правила "nat global" убрал т.к. из-за них локальная сеть не натилась. > Это вы где-то накосячили, всё натится с nat global. > >> Используется исключительно для доступа в интернет из локальной сети. >> Пробросы портов, и прочие прелести не нужны потому не знаю как они будут >> работать с этой конфигурацией. > Без nat global не будет работать проброс портов внутрь, > если входящий коннект пришел с одного канала, а ответы по роутингу стремятся > в другой. Возможно и накосячил, но я один в один скопировал Ваш конфиг и обнаружил, что правила 00080 nat 123 ip from $LAN to any out xmit $uplink1 00085 nat 100 ip from $LAN to any out xmit $uplink2 Не используются. Если же их поставить перед nat global то соответсвенно последние не используются. Т.к. основная задача была решена - сил и желания в три часа ночи на поиск "косяка" не осталось. -- С уважением, Зеленяк Алексей www: http://rent-it.net.ua
Re: [freebsd] ECMP + ipfw nat
Всем спасибо за ответы. В настоящий момент настроено так (8.2-STABLE): Для двух интерфейсов $uplink1 и $uplink2 с адресами $ip1 и $ip2 и провайдерскими шлюзами $gw1 и $gw2 соответственно: # транслируем входящий трафик (включая возможные пробросы портов внутрь LAN) 00050 nat 123 ip from any to any in recv $uplink1 00060 nat 100 ip from any to any in recv $uplink2 # транслируем остальные пакеты из LAN наружу в соответствии с таблицей маршрутизации 00080 nat 123 ip from $LAN to any out xmit $uplink1 00085 nat 100 ip from $LAN to any out xmit $uplink2 # заворачиваем результат трансляции в правильный интерфейс, # если он намеревается уйти в неправильный 04050 fwd $gw1 ip from $ip1 to any out xmit $uplink2 04055 fwd $gw2 ip from $ip2 to any out xmit $uplink1 netstat -anr DestinationGateway default $gw1 default $gw2 Правила "nat global" убрал т.к. из-за них локальная сеть не натилась. Используется исключительно для доступа в интернет из локальной сети. Пробросы портов, и прочие прелести не нужны потому не знаю как они будут работать с этой конфигурацией. Пока "полет нормальный" -- С уважением, Зеленяк Алексей e-mail: gr...@rent-it.net.ua www: http://rent-it.net.ua
Re: [freebsd] ECMP + ipfw nat
On 12.12.2011 23:17, Maxim Ignatenko wrote:
> On пн, 12 гру 2011 17:36:37 Зеленяк Алексей wrote:
>> On 12.12.2011 17:08, Maxim Ignatenko wrote:
>> Мне необходимо чтобы для каждой TCP сессии случайным образом выбирался нат.
>
> Немного перефразируя пример из упомянутого поста:
>
> ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
> ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
Вот у меня как-то так:
01000 nat 20 ip from any to 195.181.1.1 in recv ng1
01010 nat 10 ip from any to 89.162.1.5 in recv ng0
01410 count tag 1 ip from any to any in recv ng0 keep-state
01420 count tag 2 ip from any to any in recv ng1 keep-state
03000 nat 10 ip from 10.0.1.0/24 to any out xmit ng1 tagged 1
03010 nat 20 ip from 10.0.1.0/24 to any out xmit ng0 tagged 2
03100 nat 10 ip from 10.0.1.0/24 to any out xmit ng0
03110 nat 20 ip from 10.0.1.0/24 to any out xmit ng1
03410 fwd 91.201.1.5 ip from any to any out xmit ng0 tagged 2
03420 fwd 212.109.4.2 ip from any to any out xmit ng1 tagged 1
03510 fwd 91.201.1.5 ip from 195.18.1.1 to any out xmit ng0
03520 fwd 212.109.4.2 ip from 89.162.1.5 to any out xmit ng1
65000 allow ip from any to any
ipfw nat 10 config ip 89.162.1.5 same_ports reset redirect_port tcp
10.0.1.99:80 10080 redirect_port tcp 10.0.1.17:80 20080
ipfw nat 20 config ip 195.18.1.1 same_ports reset redirect_port tcp
10.0.1.99:80 10080 redirect_port tcp 10.0.1.17:80 20080
default91.201.1.5 UGS 0 1034622ng1
default212.109.4.2 UGS 0 1788715ng0
Это в 8.2-STABLE, в релизе не работало тегирование в check-state.
Вся эта свистопляска с тегами нужна только для пробросов портов, шлюз
можно правильно разрулить без тегирования. Это я пользовал еще с
какой-то беты 8.0 :).
> # поскольку возникает проблема с доступностью одного адреса через линк
> # другого провайдера, можно предположить что входящий интерфейс однозначно
> # определяет dst-ip
> ipfw add 300 nat 1 in tagged 1
> ipfw add 310 nat 2 in tagged 2
> ipfw add 320 allow { recv $ext_if1 or recv $ext_if2 }
> ipfw add 410 prob 0.5 skipto 450 in recv $int_if keep-state
> ipfw add 420 skipto 470 in recv $int_if keep-state
> ipfw add 450 nat 1
> ipfw add 460 skipto 500
> ipfw add 470 nat 2
> ipfw add 500 allow in recv $int_if
> ipfw add 600 fwd $gw1 tagged 1
> ipfw add 700 fwd $gw2 tagged 2
>
> Это несколько приблизительно, но суть, надеюсь, понятна.
>
>> Как поступать с UDP?
>>
>
> точно также. стейты просто запоминают 5 значений:
> номер протокола, (src|dst)-(ip|port)
> Что такое "TCP-сессия" они не знают и знать не хотят.
--
Cheers, Denis Zaika,ZDS-RIPE
"Soniko-svyaz" NOC engineer,ZDS-UANIC
Donetsk, UkraineZDS-EUNIC
+380933407844, +380623323232
Re: [freebsd] ECMP + ipfw nat
12 декабря 2011 г. 17:50 пользователь Зеленяк Алексей написал: > On 12.12.2011 17:42, greenh wrote: > > То есть, вполне может получиться ситуация, при которой пользователь, > > зайдя на страницу с одного адреса, а перейдя по ссылке - оказаться уже > > с другого? > > > > Да. > > Боюсь что некоторым сайтам/серверам это не понравится. вконтакт точно обидится
Re: [freebsd] ECMP + ipfw nat
On пн, 12 гру 2011 17:36:37 Зеленяк Алексей wrote:
> On 12.12.2011 17:08, Maxim Ignatenko wrote:
> > Тебе надо явно задать как отделять мух от котлет. А то в том письме на
> > которое ссылка полная каша. Например, до правила 101 пакет уже доходит
> > с изменённым src-ip и он не матчится. Если уж у тебя пакет и так out
> > xmit ng0, то ясен хрен что он и так профорвардится через шлюз который
> > на этом интерфейсе указан.
>
> Мне необходимо чтобы для каждой TCP сессии случайным образом выбирался нат.
Немного перефразируя пример из упомянутого поста:
ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
# поскольку возникает проблема с доступностью одного адреса через линк
# другого провайдера, можно предположить что входящий интерфейс однозначно
# определяет dst-ip
ipfw add 300 nat 1 in tagged 1
ipfw add 310 nat 2 in tagged 2
ipfw add 320 allow { recv $ext_if1 or recv $ext_if2 }
ipfw add 410 prob 0.5 skipto 450 in recv $int_if keep-state
ipfw add 420 skipto 470 in recv $int_if keep-state
ipfw add 450 nat 1
ipfw add 460 skipto 500
ipfw add 470 nat 2
ipfw add 500 allow in recv $int_if
ipfw add 600 fwd $gw1 tagged 1
ipfw add 700 fwd $gw2 tagged 2
Это несколько приблизительно, но суть, надеюсь, понятна.
> Как поступать с UDP?
>
точно также. стейты просто запоминают 5 значений:
номер протокола, (src|dst)-(ip|port)
Что такое "TCP-сессия" они не знают и знать не хотят.
Re: [freebsd] ECMP + ipfw nat
Это два равнозначных канала. Их основная задача - обеспечить отказоустойчивый канал между офисом и тех. площадкой. У меня получилось решить это путем option /RADIX_MPATH/ + vtund Теперь хотелось бы обеспечить "непрерывность" работы интернета в офисе. Использоваться должен любой "рабочий" т.е. любой внутренний адрес может выйти через любой nat. (контроль за работой каналов не обсуждается имеею ввиду что оба канала в данный момент времени работают правильно и нагрузка не контролируется). On 12.12.2011 17:13, greenh wrote: > А по какому принципу должны использоваться подключения? > 50/50 или по одному начальство, а по остальному смертные, или по > одному торренты по другому остальное? > 12 декабря 2011 г. 16:46 пользователь Зеленяк Алексей > mailto:gr...@rent-it.net.ua>> написал: > > Доброго времени суток. > > Помогите пожалуйста разобраться с ECMP + ipfw nat. > Ранее в рассылке обсуждался этот вопрос, но до меня пока не "доходит" > http://www.mail-archive.com/freebsd@uafug.org.ua/msg01428.html > > Ситуация следующая: есть два провайдера интернет и одна локальная > сеть. > Необходимо натить трафик через двух провайдеров одновременно. > > Не могу разобраться: > - как прописать наты чтобы использовались оба подключения? > - не удается "отвечать" через интерфейс, с которого было инициировано > подключение. > > Сейчас имеем: > netstat -anr > DestinationGateway > default > default > > Проблума: если "пинговать" этот сервер - то запросы могут приходить > через один интерфейс, а ответы будут уходить через другой. > > Можете ли привести пример настройки ipfw подобного подключения? > > -- > С уважением, > Зеленяк Алексей > www: http://rent-it.net.ua > > -- С уважением, Директор Рент ИТ, Зеленяк Алексей тел: +380 (44) 232-85-65 тел: +380 (63) 453-55-55 e-mail: gr...@rent-it.net.ua www: http://rent-it.net.ua
Re: [freebsd] ECMP + ipfw nat
On 12.12.2011 17:08, Maxim Ignatenko wrote: > Тебе надо явно задать как отделять мух от котлет. А то в том письме на > которое ссылка полная каша. Например, до правила 101 пакет уже доходит > с изменённым src-ip и он не матчится. Если уж у тебя пакет и так out > xmit ng0, то ясен хрен что он и так профорвардится через шлюз который > на этом интерфейсе указан. Мне необходимо чтобы для каждой TCP сессии случайным образом выбирался нат. Как поступать с UDP? > Олсо, как у тебя получилось два default задать? > option /RADIX_MPATH/ > Рекомендую почитать вот это: > http://nuclight.livejournal.com/124348.html Там как раз есть пример с > fwd и keep-state для ответа с того же интерфейса на который запрос > пришёл. А балансировку исходящих соединений между nat'ами можно > сделать хоть через проверку какого-то из битов адреса, хоть через prob > с keep-state. После этого и появили вопросы как завязать fwd и keep-state с двумя натами. -- С уважением, Директор Рент ИТ, Зеленяк Алексей тел: +380 (44) 232-85-65 тел: +380 (63) 453-55-55 e-mail: gr...@rent-it.net.ua www: http://rent-it.net.ua
Re: [freebsd] ECMP + ipfw nat port redirect
15.09.2011 19:41, Oleksandr V. Typlyns'kyi пишет:
> Today Sep 15, 2011 at 19:01 Denis Zaika wrote:
>
>> Так как дефолтные маршруты есть в оба интерфейса, путь к произвольному
>> адресу в сети до попытки связаться с ним неопределен. Если с такого
>> адреса пробовать подключаться к внутренней машине через нат, обратный
>> пакет может выйти через другой интерейс. То есть связи через один из
>> внешних адресов не будет. Причем когда запись в ECMP устареет, следующая
>> попытка может оказаться неуспешной уже на адресе, к которому раньше
>> коннектилось.
>>
>> Можно ли это вообще как-то правильно отконфигурировать? У меня идеи
>> кончились :(.
>
> Пролетала тут ссылочка на статью Вадима Гончарова:
> http://nuclight.livejournal.com/124348.html
> Она идей добавит :)
>
> В частности, с использованием появившегося во FreeBSD 6.2 параметра tag на
> каждый пакет
> можно навешивать внутриядерный тег, что в применении со skipto позволяет
> сделать,
> к примеру, запоминание, с какого шлюза пришел входящий пакет на машине с
> каналами
> к двум разным провайдерам, и ответные пакеты отправлять в тот канал, откуда
> они
> пришли (допустим, у вашей машины только один IP-адрес, и сделать fwd на базе
> внешнего адреса не получится), т.е. реализовать аналог reply-to из pf:
>
> ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
> ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
> ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 } # входящие снаружи
> ipfw add 400 allow in recv $int_if # разрешить ответы на внутреннем проходе
> ipfw add 500 fwd $gw1 tagged 1 # остались ответы на внешнем интерфейсе,
> ipfw add 600 fwd $gw2 tagged 2 # зарулим их куда надо
>
> UPDATE:
> 2. Динамические правила и ipfw fwd; теги.
>
> Приведенный в посте пример того, как на динамических правилах сделать
> аналог reply-to в pf, на самом деле, не работает. В исходниках был
> обнаружен запрет специально именно этого случая в мохнатом 2000 году из-за
> какой-то паники ядра на тех версиях. Что давно уже не актуально, но это,
> конечно же, поправить забыли. Патчится одной строчкой - открываете
> /sys/netinet/ip_fw2.c, находите слова case O_FORWARD_IP: (конкретный патч
> не приведу, зависит от версии системы). И вот там чуть ниже в строчке кусок
> if (!q || dyn_dir == MATCH_FORWARD)
> надо заменить на
> if (sa->sin_port && (!q || dyn_dir == MATCH_FORWARD))
> [UPD: 06.07.11 патч закоммичен в 7.x и 8.x, патч более неактуален, теперь всё
> работает так, как и описано в посте]
>
> Еще, кстати, не стоит забывать, что все имеющиеся на пакетах теги, будь то
> метаинформация самой системы (от того же IPSEC и много чего еще) или явно
> навешенные теги ipfw/pf - существуют только внутри ядра. То есть, если
> вывести пакет из ядра через divert, они потеряются.
>
Патч на 8.2 не накладывается - ядро не собирается, на стейбле - работает
как задумано :).
Re: [freebsd] ECMP + ipfw nat port redirect
Today Sep 15, 2011 at 19:01 Denis Zaika wrote:
> Так как дефолтные маршруты есть в оба интерфейса, путь к произвольному
> адресу в сети до попытки связаться с ним неопределен. Если с такого
> адреса пробовать подключаться к внутренней машине через нат, обратный
> пакет может выйти через другой интерейс. То есть связи через один из
> внешних адресов не будет. Причем когда запись в ECMP устареет, следующая
> попытка может оказаться неуспешной уже на адресе, к которому раньше
> коннектилось.
>
> Можно ли это вообще как-то правильно отконфигурировать? У меня идеи
> кончились :(.
Пролетала тут ссылочка на статью Вадима Гончарова:
http://nuclight.livejournal.com/124348.html
Она идей добавит :)
В частности, с использованием появившегося во FreeBSD 6.2 параметра tag на
каждый пакет
можно навешивать внутриядерный тег, что в применении со skipto позволяет
сделать,
к примеру, запоминание, с какого шлюза пришел входящий пакет на машине с
каналами
к двум разным провайдерам, и ответные пакеты отправлять в тот канал, откуда они
пришли (допустим, у вашей машины только один IP-адрес, и сделать fwd на базе
внешнего адреса не получится), т.е. реализовать аналог reply-to из pf:
ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 } # входящие снаружи
ipfw add 400 allow in recv $int_if # разрешить ответы на внутреннем проходе
ipfw add 500 fwd $gw1 tagged 1 # остались ответы на внешнем интерфейсе,
ipfw add 600 fwd $gw2 tagged 2 # зарулим их куда надо
UPDATE:
2. Динамические правила и ipfw fwd; теги.
Приведенный в посте пример того, как на динамических правилах сделать
аналог reply-to в pf, на самом деле, не работает. В исходниках был
обнаружен запрет специально именно этого случая в мохнатом 2000 году из-за
какой-то паники ядра на тех версиях. Что давно уже не актуально, но это,
конечно же, поправить забыли. Патчится одной строчкой - открываете
/sys/netinet/ip_fw2.c, находите слова case O_FORWARD_IP: (конкретный патч
не приведу, зависит от версии системы). И вот там чуть ниже в строчке кусок
if (!q || dyn_dir == MATCH_FORWARD)
надо заменить на
if (sa->sin_port && (!q || dyn_dir == MATCH_FORWARD))
[UPD: 06.07.11 патч закоммичен в 7.x и 8.x, патч более неактуален, теперь всё
работает так, как и описано в посте]
Еще, кстати, не стоит забывать, что все имеющиеся на пакетах теги, будь то
метаинформация самой системы (от того же IPSEC и много чего еще) или явно
навешенные теги ipfw/pf - существуют только внутри ядра. То есть, если
вывести пакет из ядра через divert, они потеряются.
--
WNGS-RIPE
