Jump to content
Калькуляторы

Linux setfib bsd надо завернуть трафик по dst

Добрый вечер, уважаемые коллеги. Нужна ваша помощь. Использую freebsd и setfib для заварачивания трафика на другой шлюз.

Посидел почитал погугли , в debian есть ip rule и таблицы(шлюз). Но как я понял аналог table как bsd в нем нет(. Каким образом можно повторить данную кострукцию?

172.30.0.0/16 клиентская сеть,

172.30.0.3- шлюз куда завернуть

table(3) 1к IP-шников

#${fwcmd}
setfib 1 route delete default 
setfib 1 route add default 172.30.0.3
${fwcmd} add setfib 1 ip from 172.30.0.0/16 to 'table(3)'

Edited by roysbike

Share this post


Link to post
Share on other sites

Если я правильно понял задачу, то

ip ru add from 172.30.0.0/16 t 1000

ip ro add default via 172.30.0.3 dev eth0 t 1000

Edited by pppoetest

Share this post


Link to post
Share on other sites

Если я правильно понял задачу, то

ip ru add from 172.30.0.0/16 t 1000

ip ro add default via 172.30.0.3 dev eth0 t 1000

table 1000? это просто название таблицы. А мне нужно ip rule from 172.30.0.0/16 to 8.8.8.8

 

если попадает под это правило, то пакеты напрвять через 172.30.0.3

 

В freebsd у меня в table(3) хранится список ip-шников. около 1000 штук

Edited by roysbike

Share this post


Link to post
Share on other sites

у Линукса для этого есть ipset

да, я его использую в iptables. Возможно ли его использовать в конструкции ip rule from 172.30.0.0/16 to таблица(ipset) table 200

Edited by roysbike

Share this post


Link to post
Share on other sites

Вы для начала опишите что хотите получить, словами. Что б подсеть идущая на определенные IPшки выходила через другой шлюз? А зачем?

Share this post


Link to post
Share on other sites

у Линукса для этого есть ipset

да, я его использую в iptables. Возможно ли его использовать в конструкции ip rule from 172.30.0.0/16 to таблица(ipset) table 200

 

да. маркируете нужный вам трафик с помощью iptables ... -j MARK <mark>

 

заворачиваете его в другую RT:

ip rule fwmark <mark> table <RT>

в <RT> делаете свой дефолт:

ip route add table <RT> default via <NH>

 

P.S. PBR-чики - зло

Share this post


Link to post
Share on other sites

Вобщем схема такая. Есть bras на FReebsd в качестве PPPoE. Uplink 172.30.0.2 , default gateway 172.30.0.1. Клиенты в сети 172.30.0.0/16. На шлюзе 172.30.0.3 выполняется фильтрация http урлов. На freebsd в таблице 3 находятся список IP принадлежащие доменам из роскомнадзора.

 

#${fwcmd}
setfib 1 route delete default 
setfib 1 route add default 172.30.0.3
${fwcmd} add setfib 1 ip from 172.30.0.0/16 to 'table(3)'

 

При совпадение правила

ip from 172.30.0.0/16 to 'table(3)'[/code]

 

пакеты отправляеются на шлюз 172.30.0.3

 

Как сделать такую тему на linux?

post-88211-032753900 1397852161_thumb.png

Edited by roysbike

Share this post


Link to post
Share on other sites

roysbike

я же написал как сделать именно это на линуксе. что именно не понятно?

Спасибо, попробую .

Share this post


Link to post
Share on other sites

iptables -t mangle -A PREROUTING -s 172.30.0.0/16 -p tcp --dport 80 -j MARK --set-mark 0x1

 

ip rule add fwmark 0x1 table 100

ip route add table 100 x.x.x.x/32 via filter.gw

ip route add table 100 z.z.z.z/32 via filter.gw

 

x.x.x.x

z.z.z.z

адреса из ркн

дефолт писать в таблицу 100 не надо - оно если не найдет ip - будет искать роут в нормальной таблице

 

про порт 80 это я уже отсебятину добавил, но по идее 443 и 80 должно быть достаточно

Share this post


Link to post
Share on other sites

А зачем столько route городить, или вариант с ipset'ом в правиле iptables дороже по накладным расходам получается?

В принципе почти одинаково. Есть такая мелочь как счетчики в iptables, которые будут отьедать ресурсы (особенно если они не atomic), и в моей схеме при желании можно обойтись без iptables(которые сами по себе здорово роняют производительность сети) - вообще. Например с помощью tc filter + skbedit. Учитывая что изначально задача про порты не стояла вообще, тогда можно сократить до:

 

ip rule add from 172.30.0.0/16 table 100

ip route add table 100 x.x.x.x/32 via filter.gw

ip route add table 100 z.z.z.z/32 via filter.gw

Share this post


Link to post
Share on other sites

А зачем столько route городить, или вариант с ipset'ом в правиле iptables дороже по накладным расходам получается?

В принципе почти одинаково. Есть такая мелочь как счетчики в iptables, которые будут отьедать ресурсы (особенно если они не atomic), и в моей схеме при желании можно обойтись без iptables(которые сами по себе здорово роняют производительность сети) - вообще. Например с помощью tc filter + skbedit. Учитывая что изначально задача про порты не стояла вообще, тогда можно сократить до:

 

ip rule add from 172.30.0.0/16 table 100

ip route add table 100 x.x.x.x/32 via filter.gw

ip route add table 100 z.z.z.z/32 via filter.gw

 

Но при такой схеме будет два lookup-а по RT для "нормального" трафика (сначала по filter.gw, затем по main)

 

Кстати, что сейчас(после 3.6) из себя представляет fib в linux? btree? Вопрос к тому, что дороже(с точки зрения алгоритмической сложности) - искать в ipset-е или в RT?

Share this post


Link to post
Share on other sites

А зачем столько route городить, или вариант с ipset'ом в правиле iptables дороже по накладным расходам получается?

В принципе почти одинаково. Есть такая мелочь как счетчики в iptables, которые будут отьедать ресурсы (особенно если они не atomic), и в моей схеме при желании можно обойтись без iptables(которые сами по себе здорово роняют производительность сети) - вообще. Например с помощью tc filter + skbedit. Учитывая что изначально задача про порты не стояла вообще, тогда можно сократить до:

 

ip rule add from 172.30.0.0/16 table 100

ip route add table 100 x.x.x.x/32 via filter.gw

ip route add table 100 z.z.z.z/32 via filter.gw

 

Но при такой схеме будет два lookup-а по RT для "нормального" трафика (сначала по filter.gw, затем по main)

 

Кстати, что сейчас(после 3.6) из себя представляет fib в linux? btree? Вопрос к тому, что дороже(с точки зрения алгоритмической сложности) - искать в ipset-е или в RT?

 

LC-Trie представляет из себя. Насчет сравнения с ipset - там ведь разные типы есть таблиц - hash,bitmap. Скорее всего скорость работы сопоставима(с iphash,net) - trie меньше размером (больше попадает в кэш) , хэши тратят меньше операций на lookup, но жрут больше памяти.

Share this post


Link to post
Share on other sites

RAM для PC/серверов стоит копейки, поэтому наверное имеет смысл использовать ipset(ввиду того, что он в режиме hash будет быстрее таблицы маршрутизации), а судя по текущей политической ситуации, список IP адресов Роскомандзора будет только расти

 

кстати, по поводу счётчиков iptables - ни разу не видел, чтоб что-то упёрлась именно в них.

ну а вообще, наверное, было бы неплохо заиметь опцию для отмены подсчёта трафика по конкретному правилу

Share this post


Link to post
Share on other sites

Были в свое время замеры, что просто подгрузка модулей netfilter(даже не conntrack) мгновенно роняла производительность в pps.

Если же netfilter уже используется - особой разницы думаю не будет.

Share this post


Link to post
Share on other sites

RAM для PC/серверов стоит копейки, поэтому наверное имеет смысл использовать ipset(ввиду того, что он в режиме hash будет быстрее таблицы маршрутизации), а судя по текущей политической ситуации, список IP адресов Роскомандзора будет только расти

Вот только доступ к кэшу сильно быстрее чем к RAM .. На небольших таблицах (ipset/route) оно жрет сравнимо. С FW и большим ipset/om у меня нет машины , но думаю там уже будет выигрывать trie (при сравнимом количестве записей с ipset hash)

    1.38%  [ip_set]            [k] ip_set_test                      
    1.33%  [kernel]            [k] __slab_free                      
    1.29%  [kernel]            [k] hash_conntrack_raw               
    1.14%  [kernel]            [k] update_ts_time_stats             
    1.05%  [kernel]            [k] _raw_spin_lock_irqsave           
    1.04%  [kernel]            [k] ip_route_input_common            
    0.92%  [kernel]            [k] rb_erase                         
    0.91%  [kernel]            [k] kmem_cache_free                  
    0.90%  [igb]               [k] igb_msix_ring                    
    0.87%  [ipt_NETFLOW]       [k] netflow_target                   
    0.86%  [sch_htb]           [k] htb_enqueue                      
    0.86%  [kernel]            [k] add_interrupt_randomness         
    0.85%  [ip_set_hash_ip]    [k] hash_ip4_test          

Edited by alex_001

Share this post


Link to post
Share on other sites

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.