Jump to content

FreeBSD. Использование setfib и трафик через интерфейсы

Alteron
 Share

Recommended Posts

Alteron

Alteron

Posted
Posted

Итак, сервер, два провайдера и внутренняя сеть. В сервере три сетевухи с адресами:

ПРОВАЙДЕР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 ещё в противозачаточном состоянии в системе.

 

# 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

Alteron

Alteron

Posted
  • Author
Posted

NAT на чём сделан ? Ибо откуда провайдеры будут знать о вашей 192.168.0.0 ?

Речь о нате пока не идёт. Пока нужно разрулить трафик извне на сам сервер. Нат я вообще не стал пока приплетать, что бы не усложнять объяснения.

st_re

st_re

Posted
Posted

Итак, сервер, два провайдера и внутренняя сеть. В сервере три сетевухи с адресами:

ПРОВАЙДЕР1 - 1.1.1.2/30 ШЛЮЗ 1.1.1.1

ПРОВАЙДЕР2 - 2.2.2.2/30 ШЛЮЗ 2.2.2.1

Внутренняя сеть - 192.168.0.1

 

С домашнего компа пингую сервер по 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=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.2.2.2 это IP Вашей машины ? По таблице маршрутизации маршрут на нее есть сразу по поднятии интерфейса. (тут, судя по Вашему описанию мы не городим еще второй таблицы. В основной есть 3 маршрута на 1.1.1./20 2.2.2./30 и 192.168.х.х/24, 3 маршрута на Вашу же машины на 3 Ваших IP на интерфейсах. ну и, как Вы говорите, дефолт)

 

setfib 0 netstat -rn

setfib 1 netstat -rn

 

в этом месте теста покажите ? А то может чтото недоговариваете ? Ибо не ясно, че оно пошло кругами. Само (с настройками по Вашему описанию) не пошло бы. Или полные конфиги. А то там еще разные параметры у ifconfig есть, например интерфейс можно к fdb прибить.. А можно не прибить.

 

Домашний комп, он где ? 192.168 ? B натится он где и чем?

Alteron

Alteron

Posted
  • Author
Posted

Вот

# setfib 0 netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            1.1.1.1            UGS         0  1177009    em1
1.1.1.0/30         link#2             U           0        3    em1
1.1.1.2            link#2             UHS         0        0    lo0
127.0.0.1          link#6             UH          0       48    lo0
2.2.2.0/30         link#3             U           0        0    em2
2.2.2.2            link#3             UHS         0        0    lo0
192.168.0.0/24     link#1             U           0      134    em0
192.168.0.1        link#1             UHS         0        0    lo0


# setfib 1 netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            2.2.2.1            UGS         0     4852    em2
1.1.1.0/30         link#2             U           0        0    em1
127.0.0.1          link#6             UH          0        0    lo0
2.2.2.0/30         link#3             U           0        0    em2
192.168.0.0/24     link#1             U           0        0    em0

post-3505-084994700 1377850484_thumb.png

YuryD

YuryD

Posted
Posted (edited)

Чего хотите достичь с помощью setfib ? pbr построить ? Или что-то другое ?

Edited by YuryD
Alteron

Alteron

Posted
  • Author
Posted

Контора, куча офисов по области. Сейчас по области два провайдера, будет третий. Хотелось бы соединить офисы с центром через сеть того же провайдера.

Также хочется иметь возможность переключить города области на другого провайдера в центральном офисе в случае чего.

YuryD

YuryD

Posted
Posted

Контора, куча офисов по области. Сейчас по области два провайдера, будет третий. Хотелось бы соединить офисы с центром через сеть того же провайдера.

Также хочется иметь возможность переключить города области на другого провайдера в центральном офисе в случае чего.

Постройте себе vpn, и получится всё. С маршрутизацией - не получится... И fib Вам мне не помогут...

srg555

srg555

Posted
Posted

+1 за vpn. в данном случае, это судя по всему будут тунели поверх паблика

 

собственно, поднимаются тунели и настраивается динамическая маршртизация. если в центральной точки 3 оператора, то с переферии поднимается три тунеля(на каждый IP адрес сервера), поверх тунелей запускается ospf или bgp и наступает счастье. Я бы предпочёл bgp, tcp не так страшно поверх публичных тунелей гонять. Можно подкрутить таймеры, если нужно чтоб побыстрее сходилось

 

Если на переферии больше одного провайдера, то стартуете несколько тунелей, в общем случае NxM (где N-кол-во операторов в центре, M-количество операторов на переферии)

 

И в центре и в удалённых офисах делаете правила типа "если паблик_src_ip=A, то выпускать трафик через оператора A", чтобы балансировать исходящий трафик и не заниматься наглым спуфингом(которые нормальные операторы порежут)

st_re

st_re

Posted
Posted

ну к интерейсу 2.2.2.2 добавьте в описание fib 1 наверное.... И что кажет tcpdump на 1-м и 2-м интерфейсах при пинге с наружи 2.2.2.2 и дупах? Реально прилетает 1 запрос и улетает 10 ответов ?

YuryD

YuryD

Posted
Posted (edited)

+1 за vpn. в данном случае, это судя по всему будут тунели поверх паблика

 

собственно, поднимаются тунели и настраивается динамическая маршртизация.

Собственно динамическая маршрутизация там не не нужна, госконторы не любят горизонталей. ipsec в помощь... Киску конесчно не поставить, а блинки вполне.... Только хрен укупишь..

А про fib 0 - :) я бы другие номера fib использовал. Реально использую setfib-ы 1,2 для pbr, работает.

Edited by YuryD

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.