vladd Posted February 27, 2013 (edited) По многочисленным просьбам выкладываю небольшую доделку к модулю RAWNAT из пакета xtables-addons. Суть доделки в том, что в отличие от оригинала, меняющего IP пакетов в соответствии с правилом iptables, этот модуль смотрит в находящуюся внутри него таблицу соответствия "старый ip -> новый ip" и меняет в соответствии с ней. Также имеются таблицы не для смены IP, а для установки skb->priority, поэтому получается табличный аналог -j CLASSIFY. Все таблицы в данной версии содержат 65535 записей, что достаточно для обработки подсети /16. Больше нам не требовалось. Имеется таблица для SNAT, DNAT, и 4 таблицы для CLASSIFY. По результатам работы (более полугода), загрузка ядер обычного core i7 при шейпинге (tc htb...) трафика порядка 1.5 гбит/c в обе стороны составляет 2-3% - это на linux 3.7 с отключенным route cache. Такая же ситуация и с натом, но нат у нас делается на одной машине с bgp, который дает основную нагрузку на ядра. Сетевые карты - ixgbe. Собирать следующим образом: ./configure ./make ./make install cd extensions gcc gcc -o iptrnat iptrnat.c cp ./iptrnat /usr/local/bin Использование. Для примера имеем две подсети серых адресов 192.168.0.0/19 и 192.168.64.0/19, одну подсеть реальников 195.33.64.0/20. modprobe xt_RAWNAT (в dmesg должно появиться сообщение, что загружен правильный модуль) iptables -A POSTROUTING -t rawpost -s 192.168.0.0/19 -j TABSNAT iptables -A POSTROUTING -t rawpost -s 192.168.64.0/19 -j TABSNAT iptables -A PREROUTING -t raw -d 195.33.64.0/20 -j TABDNAT Добавляем сопоставление: iptrnat -a -t 1 -i 195.33.64.5 -r 192.168.10.33 iptrnat -a -t 2 -i 192.168.10.33 -r 195.33.64.5 Теперь проходящий с адреса 192.168.10.33 будет превращаться в 195.33.64.5 и наоборот. Такое сопоставление нужно добавлять скриптом при авторизации каждого клиента, например, при помощи lISG. Удаление сопоставления при выходе клиента из сети: iptrnat -d -t 1 -i 195.33.64.5 iptrnat -d -t 2 -i 192.168.10.33 Шейпинг можно сделать например так. eth0 - внутренний интерфейс, eth1 - наружный: tc qdisc add dev eth0 root handle 1: htb default 1 tc class replace dev eth0 classid 1:1 htb rate 2000Mbit ceil 2000Mbit quantum 1500 burst 2000k cburst 2000k tc qdisc add dev eth0 parent 1:1 handle 10: pfifo limit 10000 tc qdisc add dev eth1 root handle 1: htb default 1 tc class replace dev eth1 classid 1:1 htb rate 2000Mbit ceil 2000Mbit quantum 1500 burst 2000k cburst 2000k tc qdisc add dev eth1 parent 1:1 handle 10: pfifo limit 10000 iptables -t mangle -A POSTROUTING -s 192.168.0.0/16 -o eth1 -j TABCLAS --cmatch src --ctable 3 iptables -t mangle -A POSTROUTING -s 195.33.64.0/20 -o eth1 -j TABCLAS --cmatch src --ctable 4 iptables -t mangle -A POSTROUTING -d 192.168.0.0/16 -o eth0 -j TABCLAS --cmatch dst --ctable 5 iptables -t mangle -A POSTROUTING -d 195.33.64.0/20 -o eth0 -j TABCLAS --cmatch dst --ctable 6 И для каждого клиента создаем правила. Допустим, у клиента с номером $ID имеется 3 адреса - 192.168.10.33, 192.168.55.70 и реальник 195.33.65.95: iptrnat -a -t 3 -i 192.168.10.33 -c 1:$ID iptrnat -a -t 3 -i 192.168.55.70 -c 1:$ID iptrnat -a -t 4 -i 195.33.65.95 -c 1:$ID iptrnat -a -t 5 -i 192.168.10.33 -c 1:$ID iptrnat -a -t 5 -i 192.168.55.70 -c 1:$ID iptrnat -a -t 6 -i 195.33.65.95 -c 1:$ID tc class replace dev eth0 parent 1:1 classid 1:$ID htb rate $SPEEDkibit ceil $SPEEDkibit quantum 1500 burst 10k cburst 10k tc qdisc replace dev eth0 parent 1:$ID handle $ID:0 pfifo limit $QUEUE tc class replace dev eth1 parent 1:1 classid 1:$ID htb rate $SPEEDkibit ceil $SPEEDkibit quantum 1500 burst 10k cburst 10k tc qdisc replace dev eth1 parent 1:$ID handle $ID:0 pfifo limit $QUEUE Как видно, все работает без заумных фильтров и гигантских деревьев. И почему это раньше никто не реализовал? Скачать можно тут: http://195.22.104.3/xtables-addons-1.41-tabnat.tgz Edited February 27, 2013 by vladd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vitalyb Posted February 28, 2013 Интересно, спасибо. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alexxx71 Posted February 28, 2013 (edited) интересная штука получается. Можно будет отказаться от хэш-фильтров. Надо потестить. Планируете разработчикам писать - что бы они закоммитили ? Edited February 28, 2013 by alexxx71 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
martini Posted February 28, 2013 я так понимая что это 1:1 NAT, тоесть просто занатить \24 на один-два ИП не получится ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alexxx71 Posted February 28, 2013 (edited) Я так понял что это 1:1 NAT, но если нет match'а по таблице TABCLAS то пакет идет дальше и рано или поздно попадет под действие ipt_SAME, который его и занатит. Можно вообще не использовать сопоставления, а просто делать CLASSIFY. (итересно - это быстрее чем хеш-фильтры или утопия?) Я правильно понял ? Edited February 28, 2013 by alexxx71 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vladd Posted February 28, 2013 (edited) интересная штука получается. Можно будет отказаться от хэш-фильтров. Надо потестить. Именно так. Работает все красивее и естественней. Плюс можно один класс делить между несколькими IP, из разных подсетей в произвольном количестве - нам это и надо было, т.к. на многих учетках у пользователей несколько адресов, и чтобы скорость между ними делилась. А в отличие от того же ipfw, работает на нескольких ядрах и нагрузку дает на порядок меньшую. Такое впечатление, что с текущим железом и 10 гиг прожует. Нат да, 1-к-1. Раньше приходилось для такого ната выстраивать огромное дерево и несколько десятков тысяч правил в iptables. Планируете разработчикам писать - что бы они закоммитили ? Да, надеюсь примут. Edited February 28, 2013 by vladd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vladd Posted February 28, 2013 Я так понял что это 1:1 NAT, но если нет match'а по таблице TABCLAS то пакет идет дальше и рано или поздно попадет под действие ipt_SAME, который его и занатит. Можно вообще не использовать сопоставления, а просто делать CLASSIFY. TABCLAS - для классификации, TABDNAT/TABSNAT - для ната. Можно использовать только то, что нужно. (итересно - это быстрее чем хеш-фильтры или утопия?) Не медленнее точно, но гораздо проще и гибче в применении. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
micol Posted November 7, 2013 (edited) Приветствую, интересно покрутить данную наработку Вопрос в лоб. Имеем серые подсети скажем 10.ХХХ.0.0/16, 10.YYY.0.0/16 и допустим 10.ZZZ.0.0/16 Естественно, у нас нет блоков реальников такого объема. Как в таком случае строить правила iptables 1-в-1? Уменьшать размеры до /24? или можно сделать что-то в духе: 10.XXX.0.0/16 в aaa.bbb.ccc.0/19 10.YYY.0.0/16 в aaa.bbb.ccc.0/19 10.ZZZ.0.0/16 в aaa.bbb.ccc.0/19 Вопрос номер два: У нас есть два блока реальников из разных диапазонов и разных размеров: aaa.bbb.ccc.0/19 и ddd.eee.fff.0/20 Сейчас они попилены на более мелкие, но есть возможность воссоединить один из них в большой. Вопрос в том, как строить правила ната имея разные блоки реальников? iptrnat -a -t 1 -i 195.33.64.5 -r 192.168.10.33 iptrnat -a -t 2 -i 192.168.10.33 -r 195.33.64.5 На что в данном случае влияют эти -t 1 и -t 2? Как я понял 1 и 2 это номера таблиц. Одна таблица на одно сопоставление идет? Или какой тут принцип? Edited November 7, 2013 by micol Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
OperationCwal Posted November 12, 2013 (edited) Доброго времени суток! Очень заинтересовала приведённая разработка. Захотелось посмотреть. Но не удалось собрать. Тестировал на одной и той же машине с разными версиями ядер (2.6.39 - 3.10.17) Обнаружил две проблемы. Первая возникает при сборке с ядрами версией выше 3.5.7 Её победить удалось. Вторая при сборке с ядром любой версии. /root/shaping/ipt_TABCLAS/xtables-addons-1.41/extensions/xt_RAWNAT.c: В функции «ipt_rnat_set_ctl»: /root/shaping/ipt_TABCLAS/xtables-addons-1.41/extensions/xt_RAWNAT.c:437:3: предупреждение: format «%ld» expects argument of type «long int», but argument 2 has type «__be32» [-Wformat] /root/shaping/ipt_TABCLAS/xtables-addons-1.41/extensions/xt_RAWNAT.c:437:3: предупреждение: format «%ld» expects argument of type «long int», but argument 3 has type «__be32» [-Wformat] WARNING: "nf_nat_setup_info" [/root/shaping/ipt_TABCLAS/xtables-addons-1.41/extensions/xt_DNETMAP.ko] undefined! WARNING: "ipt_unregister_table" [/root/shaping/ipt_TABCLAS/xtables-addons-1.41/extensions/iptable_rawpost.ko] undefined! WARNING: "ipt_register_table" [/root/shaping/ipt_TABCLAS/xtables-addons-1.41/extensions/iptable_rawpost.ko] undefined! WARNING: "ipt_do_table" [/root/shaping/ipt_TABCLAS/xtables-addons-1.41/extensions/iptable_rawpost.ko] undefined! In file included from ../include/net/netfilter/nf_nat.h:4:0, from libxt_DNETMAP.c:14: ../include/net/netfilter/nf_conntrack_tuple.h:29:7: ошибка: повторное определение «union nf_conntrack_man_proto» /usr/include/linux/netfilter/nf_conntrack_tuple_common.h:13:7: замечание: originally defined here make[3]: *** [libxt_DNETMAP.oo] Error 1 make[2]: *** [user-all-local] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Дистрибутив: gentoo gcc версия 4.6.3 (Gentoo 4.6.3 p1.13, pie-0.5.2) Конфиг ядра 3.5.7 в аттаче. Подскажите, пожалуйста, что пропатчить в исходниках. В первую очередь интересует сборка для ядра 3.10.7 Ежели потребуется дополнительная информация, постараюсь предоставить. config.gz Edited November 12, 2013 by OperationCwal Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Andy52280 Posted November 27, 2013 Жаль, что тема заглохла. Очень любопытное решение. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted March 25, 2014 (edited) Начал доделывать: https://github.com/alexey001/xtables-addons. Для таргета TABCLAS сделан lookup из таблицы роутинга , в качестве классификатора юзается realm , тоесть както так: iptables ...... -j TABCLAS --rtable 100 --cmatch dst ip route add 1.2.3.4 dev lo realm 1/100 table 100. Соответственно будет брать из таблицы 100 (при совпадении) realm и засовывать его в priority (class). Ну и переведен на xtables поновее. Если нужны realm > 255 патч к iproute2. diff --git a/lib/rt_names.c b/lib/rt_names.c index 911e4d2..aac5859 100644 --- a/lib/rt_names.c +++ b/lib/rt_names.c @@ -307,7 +307,7 @@ int rtnl_rtrealm_a2n(__u32 *id, const char *arg) } res = strtoul(arg, &end, 0); - if (!end || end == arg || *end || res > 255) + if (!end || end == arg || *end || res > 65535) return -1; *id = res; return 0; Решение АБСОЛЮТНО не тестированное (времени не было), но вроде должно работать :) P.S. Все работает , но надо учитывать что в tc класс - hex , в iproute realm - dec , t.e например для tc класс 1:20 для iproute realm 1/32 Edited April 21, 2014 by alex_001 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Dyr Posted March 31, 2014 Тот самый случай, когда и хочется, и колется. ;) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ThreeDHead Posted March 31, 2014 с отключенным route cache Кто-нибудь имеет больше информации о том как это делать и какой профит с включенным "route cache" и без? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted March 31, 2014 ThreeDHead Как сделать - поставить ядро начиная с 3.6 и выше. Сведения про профит противоречивы, но вероятно после отключения стало лучше, раз его глобально выпилили. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ThreeDHead Posted March 31, 2014 kayot, есть где подробнее посмотреть, а то ченйнджлоги молчат? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vitalyb Posted March 31, 2014 (edited) но вероятно после отключения стало лучше Лучше стало только в части cache thrashing неконтролируемым внешним воздействием - его больше нет. В остальном, очевидно, что существует некий размер таблицы маршрутизации, при котором новая схема начнет проигрывать. https://home.regit.org/2013/03/david-miller-routing-cache-is-dead-now-what/ http://www.spinics.net/lists/netdev/msg205545.html Edited March 31, 2014 by vitalyb Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kayot Posted April 1, 2014 vitalyb Спасибо, стало яснее. Профит от кеша был невелик, а вот возможность загнать удаленный хост в DOS была. Потому и прибили. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ThreeDHead Posted April 1, 2014 Что есть "отключенный route cache"? Как это делается и какие накладные и какой профит? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted April 1, 2014 Что есть "отключенный route cache"? Как это делается и какие накладные и какой профит? Про профит написали. Что это есть - этакая динамическая route table , lookup делался по ней и только если нет в кэше лезло в осн. таблицу (заполняя попутно кэш). Я так понимаю смогли выпилить когда осн. таблицу стали хранить в trie (раньше это была опция) , размер уменьшился , и видимо время выборки стало практически равным времени выборки из кэша. Проблемы с кэшем как уже указывали - возможность DOS'a и необходимость сборки мусора (старых записей). Сам кэш можно посмотреть - 'ip route sh cache' Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ThreeDHead Posted April 2, 2014 Т.е. "отключенный route cache", это ничто иное как тупо версия ядра >= 3.6 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vitalyb Posted April 2, 2014 Т.е. "отключенный route cache", это ничто иное как тупо версия ядра >= 3.6 Не совсем. В более ранних версиях, точно не скажу с каких, он отключался автоматически если начинал идти "плохой" трафик. см. крутилку /proc/sys/net/ipv4/rt_cache_rebuild_count Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted April 23, 2014 Если кто хочет на gentoo попробовать - https://github.com/alexey001/iln-overlay тут патченный ebuild iproute2. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alex_001 Posted April 23, 2014 (edited) Небольшой скрипт для управления всей конструкцией. https://github.com/alexey001/farsh/tree/master/shell инициализация: shp.sh shaper_init; shp.sh shaper_load. Ссылка на ebuild для klish - в пред. посте. Действия по добавлению/изменению лучше делать через clish - проверки на правильность параметров в самом скрипте не делал. Edited April 23, 2014 by alex_001 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
pppoetest Posted March 16, 2016 Планируете разработчикам писать - что бы они закоммитили ? Да, надеюсь примут. v2.4 (2014-01-09) ================= Enhancements: - Support for Linux up to 3.13 Changes: - remove unmaintained RAWSNAT/RAWDNAT code ЗЫ. Коллеги, ни у кого сырцов не осталось? До автора не достучался, ссылка мертвая. ((( Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bomberman Posted March 17, 2016 присоеденяюсь к вопросу pppoetest Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...