Использование setfib и пропускание трафика

[Alteron]

Итак, сервер, два провайдера и внутренняя сеть. В сервере три сетевухи с адресами:
ПРОВАЙДЕР1 - 1.1.1.2/30 ШЛЮЗ 1.1.1.1
ПРОВАЙДЕР2 - 2.2.2.2/30 ШЛЮЗ 2.2.2.1
Внутренняя сеть - 192.168.0.1

В основной таблице маршрутизации шлюзом по умолчанию является железка провайдера 1, через неё все ходят в интернет. Провайдер 2, в основном, нужен для поднятия тоннелей из городов области, чтобы гонять трафик в пределах сети одного провайдера.

Собираем ядро с опциями

Код: Выделить всё

options         IPFIREWALL
options         IPFIREWALL_FORWARD
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=100
options         IPDIVERT

options         ROUTETABLES=4

В правилах IPFW для начала прописываю просто

Код: Выделить всё

ipfw add allow all from any to any

Вообще с другого компа пингую сервер по IP от первого провайдера, всё хорошо

Код: Выделить всё

# ping 1.1.1.2
PING 1.1.1.2 (1.1.1.2): 56 data bytes
64 bytes from 1.1.1.2: icmp_seq=0 ttl=48 time=2.326 ms
64 bytes from 1.1.1.2: icmp_seq=1 ttl=48 time=3.078 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=48 time=2.972 ms

Код: Выделить всё

# ping 2.2.2.2
PING 2.2.2.2 (2.2.2.2): 56 data bytes
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=1.788 ms
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=1.910 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=2.159 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=2.657 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=2.695 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=3.283 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=3.547 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=3.582 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=3.600 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=3.786 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=3.906 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=3.946 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=4.157 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=4.422 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=4.781 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=4.835 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=4.868 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=4.893 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=4.936 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=5.280 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=5.316 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=5.666 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=5.785 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=5.906 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=5.945 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=6.156 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=6.211 ms (DUP!)
36 bytes from r5-gi-0-0-444.v4.isp-internet.ru (178.1.6.8): Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 d960   0 0000  01  01 70b5 178.1.3.14  2.2.2.2

64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=6.905 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=7.036 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=7.301 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=58 time=7.325 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=2.534 ms
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=2.590 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=2.610 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=2.634 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=2.665 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=2.803 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=2.848 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=3.273 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=3.523 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=3.894 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=4.146 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=4.400 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=4.442 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=4.463 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=4.893 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=5.018 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=5.083 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=5.270 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=5.914 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=5.957 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=6.031 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=6.145 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=6.194 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=6.243 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=6.273 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=7.017 ms (DUP!)
36 bytes from r5-gi-0-0-444.v4.isp-internet.ru (178.1.6.8): Time to live exceeded
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 d990   0 0000  01  01 7085 178.1.3.14  2.2.2.2

64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=7.285 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=7.307 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=7.641 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=7.906 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=58 time=7.927 ms (DUP!)

Я хренею, дорогая редакция!!!
По идее, в этом случае, запрос должен приходить на сетевуху в сторону второго провайдера, а уходить согласно основной таблице маршрутизации - через первого провайдера!!! Но даже судя по tcpdump у меня на выходе было штук 20 ответов на один пинг!!!

Ладно, вторая часть марлезонского балета: вводим в действие вторую таблицу маршрутизации.

Прописываем маршрут по умолчанию во второй таблице маршрутизации. Она будет использоваться для пакетов, пришедших через интерфейс провайдера 2:

Код: Выделить всё

setfib 1 route add default 2.2.2.1

Файервол:

Код: Выделить всё

#!/bin/sh

ipfw="/sbin/ipfw -q"

${ipfw} -f flush

${ipfw} add 1 pass all from any to any via lo0

${ipfw} add 20 setfib 0 ip from any to any via em1
${ipfw} add 30 setfib 1 ip from any to any via em2

${ipfw} add 100 allow all from any to any>

Всё, что зашло через первого провайдера идёт в таблицу маршрутизации 0, всё, что зашло через провайдера 2 идёт в таблицу маршрутизации 1.

С другого компа пингуем IP нашего сервера на втором провайдере:

Код: Выделить всё

/root# ping 2.2.2.2
PING 2.2.2.2 (2.2.2.2): 56 data bytes
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=1.765 ms
64 bytes from 2.2.2.2: icmp_seq=1 ttl=62 time=1.409 ms
64 bytes from 2.2.2.2: icmp_seq=2 ttl=62 time=1.738 ms
64 bytes from 2.2.2.2: icmp_seq=3 ttl=62 time=1.318 ms
64 bytes from 2.2.2.2: icmp_seq=4 ttl=62 time=2.313 ms
64 bytes from 2.2.2.2: icmp_seq=5 ttl=62 time=1.697 ms
64 bytes from 2.2.2.2: icmp_seq=6 ttl=62 time=1.115 ms
64 bytes from 2.2.2.2: icmp_seq=7 ttl=62 time=1.216 ms

Теперь, вроде бы всё хорошо.

С нашего стороннего компьютера копируем файл на наш сервер:

Код: Выделить всё

/root# scp ./qq.exe  dima@2.2.2.2:/usr/local/tmp/qq.exe
Password:
qq.exe                                                            100%  270MB   3.4MB/s   01:19

Всё хорошо.
Ждём минут пять и пробуем снова

Код: Выделить всё

/root# scp -P 21211 ./qq.exe dima@178.161.131.122:/usr/local/tmp/qq.exe
Password:
qq.exe                                                              0% 2320KB 4.2KB/s - stalled -^qq.exe 

Теперь скорость не моднимается выше 10 кб/с, а иногда передача файла вообще останавливается.

С нашего тестового компа снова пингуем наш сервер по IP адресу со стороны провайдера 2. Получаем:

Код: Выделить всё

PING 2.2.2.2 (2.2.2.2): 56 data bytes
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=2.463 ms
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=3.059 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=3.309 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=3.336 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=3.683 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=4.061 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=4.323 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=4.433 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=4.683 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=4.933 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=4.961 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=5.457 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=6.088 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=6.338 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=6.703 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=7.060 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=7.137 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=0 ttl=62 time=7.471 ms (DUP!)
64 bytes from 2.2.2.2: icmp_seq=1 ttl=62 time=1.254 ms
64 bytes from 2.2.2.2: icmp_seq=2 ttl=62 time=1.154 ms
64 bytes from 2.2.2.2: icmp_seq=3 ttl=62 time=1.237 ms
64 bytes from 2.2.2.2: icmp_seq=4 ttl=62 time=1.319 ms
64 bytes from 2.2.2.2: icmp_seq=5 ttl=62 time=1.262 ms
64 bytes from 2.2.2.2: icmp_seq=6 ttl=62 time=1.575 ms
64 bytes from 2.2.2.2: icmp_seq=7 ttl=62 time=1.455 ms
64 bytes from 2.2.2.2: icmp_seq=8 ttl=62 time=1.347 ms
64 bytes from 2.2.2.2: icmp_seq=9 ttl=62 time=1.368 ms
64 bytes from 2.2.2.2: icmp_seq=10 ttl=62 time=1.128 ms
64 bytes from 2.2.2.2: icmp_seq=11 ttl=62 time=1.142 ms
64 bytes from 2.2.2.2: icmp_seq=12 ttl=62 time=4.261 ms
64 bytes from 2.2.2.2: icmp_seq=13 ttl=62 time=1.336 ms

Т.е. первый пинг идёт с дупом, дальше сервер, какбы опомнился и начинает вести себя адекватно. Если снова начать копировать файл, то какое-то время (1-2 минуты) скорость держится в пределах 3 мб/с, но потом снова падает до 5-10 кб/с, и ситуация с пингами повторяется.

Ставил чистую операционку на виртуалку ESXi и серыми IP адресами - ситауция та же самая, т.е. железо точно ни при чём.

Если в основную таблицу маршрутизации прописать маршрут до нашего внешнего компа через провайдера 2, то ситуация сразу приходит в норму. НО!!!! ВНИМАНИЕ!!! Наш файервол весь трафик с интерфейса провайдера 2 НЕ ДОЛЖЕН пускать в основную таблицу маршрутизации.

В общем, чувствую, что либо я не вижу чего-то на поверхности, либо этот самый setfib ещё в противозачаточном состоянии в системе.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Alteron]

Забыл написать

Код: Выделить всё

l# uname -a
FreeBSD gate.company.local 8.2-RELEASE-p10 FreeBSD 8.2-RELEASE-p10 #0: Sat Aug 24 21:52:22 YEKT 2013     dima@gate.company.local:/usr/obj/usr/src/sys/my_kernel  amd64

[BaHJa]

вместо any укажы фаерволу какие сети куда должны ходить.
${ipfw} add 20 setfib 0 ip from any to any via em1
${ipfw} add 30 setfib 1 ip from any to any via em2

[Alteron]

Если что-то из интернета пришло на em1, то оно должно и выйти на em1. Если что-то из интернета пришло на em2, то оно должно выйти на em2.
У вас есть варианты описать "что-то" кроме как any?
Мне не внутренних юзеров надо раскидать по разным каналам в интернет, мне надо обеспечить работу тоннелей внезависимости от интерфейса, куда пришёл пакет.

[Alteron]

В общем, понял свою ошибку. setfib предназначен для того, чтобы запускать демоны в "окружении" другой таблицы маршрутизации, а не для того, чтобы запихивать файерволом пакеты в другой fib. Запустил второй MPD через "setfib 1" со вторым конфигом и привязкой к IP второго провайдера, теперь всё работает.
Только пинги всё равно дупятся. Пришлось запрещать весь трафик, кроме нужного на интерфейсе второго провайдера, чтобы его оборудование не отключило мой порт из-за флуда.

[7.62х39]

В общем, понял свою ошибку. setfib предназначен для того, чтобы запускать демоны в "окружении" другой таблицы маршрутизации, а не для того, чтобы запихивать файерволом пакеты в другой fib.

Правило setfib в ipfw работает только на проходе IN - тогда, когда трафик принимается на рутере через один из интерфейсов, но еще не произошло решение о его маршрутизации.

Трафик генерируемый самим сервером сразу же идет в проход OUT, поэтому ipfw setfib не сработает. Остается только запускать нужных демонов с явным указанием fib.

[Alteron]

Правило setfib в ipfw работает только на проходе IN - тогда, когда трафик принимается на рутере через один из интерфейсов, но еще не произошло решение о его маршрутизации.

Трафик генерируемый самим сервером сразу же идет в проход OUT, поэтому ipfw setfib не сработает. Остается только запускать нужных демонов с явным указанием fib.

Мне интересно, а зачем вы повторили, то, что я уже написал выше?

[C2H5OH]

а не для того, чтобы запихивать файерволом пакеты в другой fib.

как я уже написал - ето возможно

[Alteron]

а не для того, чтобы запихивать файерволом пакеты в другой fib.

как я уже написал - ето возможно

То, что я описал выше - бессмысленно, т.к. демон может "порождать" пакеты сам. Тогда система просто не будет знать на какой интерфейс правильно будет отправить пакет и по какой таблице маршрутизации.