roysbike Posted April 17, 2014 (edited) · Report post Добрый вечер, уважаемые коллеги. Нужна ваша помощь. Использую 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 Share this post Link to post Share on other sites
pppoetest Posted April 17, 2014 (edited) · Report post Если я правильно понял задачу, то 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 Share this post Link to post Share on other sites
roysbike Posted April 17, 2014 (edited) · Report post Если я правильно понял задачу, то 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 Share this post Link to post Share on other sites
vlad11 Posted April 17, 2014 · Report post у Линукса для этого есть ipset Share this post Link to post Share on other sites
roysbike Posted April 18, 2014 (edited) · Report post у Линукса для этого есть ipset да, я его использую в iptables. Возможно ли его использовать в конструкции ip rule from 172.30.0.0/16 to таблица(ipset) table 200 Edited April 18, 2014 by roysbike Share this post Link to post Share on other sites
kayot Posted April 18, 2014 · Report post Вы для начала опишите что хотите получить, словами. Что б подсеть идущая на определенные IPшки выходила через другой шлюз? А зачем? Share this post Link to post Share on other sites
s.lobanov Posted April 18, 2014 · Report post у Линукса для этого есть 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
pppoetest Posted April 18, 2014 · Report post PBR-чики - зло Можете пояснить чем pbr хуже маркировки? Share this post Link to post Share on other sites
s.lobanov Posted April 18, 2014 · Report post я не понял вопроса Share this post Link to post Share on other sites
roysbike Posted April 18, 2014 (edited) · Report post Вобщем схема такая. Есть 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 Share this post Link to post Share on other sites
s.lobanov Posted April 18, 2014 · Report post roysbike я же написал как сделать именно это на линуксе. что именно не понятно? Share this post Link to post Share on other sites
roysbike Posted April 18, 2014 · Report post roysbike я же написал как сделать именно это на линуксе. что именно не понятно? Спасибо, попробую . Share this post Link to post Share on other sites
nuclearcat Posted April 18, 2014 · Report post 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
taf_321 Posted April 19, 2014 · Report post А зачем столько route городить, или вариант с ipset'ом в правиле iptables дороже по накладным расходам получается? Share this post Link to post Share on other sites
pppoetest Posted April 19, 2014 · Report post я не понял вопроса И правильно что не понял, ***ню-с написал. Share this post Link to post Share on other sites
nuclearcat Posted April 19, 2014 · Report post А зачем столько 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
s.lobanov Posted April 19, 2014 · Report post А зачем столько 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
alex_001 Posted April 19, 2014 · Report post А зачем столько 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
s.lobanov Posted April 19, 2014 · Report post RAM для PC/серверов стоит копейки, поэтому наверное имеет смысл использовать ipset(ввиду того, что он в режиме hash будет быстрее таблицы маршрутизации), а судя по текущей политической ситуации, список IP адресов Роскомандзора будет только расти кстати, по поводу счётчиков iptables - ни разу не видел, чтоб что-то упёрлась именно в них. ну а вообще, наверное, было бы неплохо заиметь опцию для отмены подсчёта трафика по конкретному правилу Share this post Link to post Share on other sites
nuclearcat Posted April 19, 2014 · Report post Были в свое время замеры, что просто подгрузка модулей netfilter(даже не conntrack) мгновенно роняла производительность в pps. Если же netfilter уже используется - особой разницы думаю не будет. Share this post Link to post Share on other sites
alex_001 Posted April 21, 2014 (edited) · Report post 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 Share this post Link to post Share on other sites
vitalyb Posted April 22, 2014 · Report post по ipset hash:net - не знаю на сколько текущая реализация стала лучше, но раньше была очень медленная, с чем не сравни Share this post Link to post Share on other sites
