Перейти к содержимому
Калькуляторы

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)'

Изменено пользователем 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

Изменено пользователем 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

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

 

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

 

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

Изменено пользователем roysbike

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем roysbike

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

PBR-чики - зло

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем roysbike

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

roysbike

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

roysbike

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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          

Изменено пользователем alex_001

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.