[roysbike]

Добрый вечер, уважаемые коллеги. Нужна ваша помощь. Использую 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 April 17, 2014 by roysbike

[pppoetest]

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

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 April 17, 2014 by pppoetest

[roysbike]

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

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 April 17, 2014 by roysbike

[vlad11]

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

[roysbike]

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

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

Edited April 18, 2014 by roysbike

[kayot]

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

[s.lobanov]

у Линукса для этого есть 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-чики - зло

[pppoetest]

PBR-чики - зло

Можете пояснить чем pbr хуже маркировки?

[s.lobanov]

я не понял вопроса

[roysbike]

Вобщем схема такая. Есть 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?

Edited April 18, 2014 by roysbike

[s.lobanov]

roysbike

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

[roysbike]

roysbike

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

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

[nuclearcat]

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 должно быть достаточно

[taf_321]

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

[pppoetest]

я не понял вопроса

И правильно что не понял, ***ню-с написал.

[nuclearcat]

А зачем столько 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

[s.lobanov]

А зачем столько 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?

[alex_001]

А зачем столько 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, но жрут больше памяти.

[s.lobanov]

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

 

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

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

[nuclearcat]

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

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

[alex_001]

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 April 21, 2014 by alex_001

[vitalyb]

по ipset hash:net - не знаю на сколько текущая реализация стала лучше, но раньше была очень медленная, с чем не сравни