LINUX.ORG.RU

Сообщения mik73

 

изменить метрику маршрута, полученного по RIP

Форум — Admin

Есть железка (обозначим как host1) на Linux, которая должна общаться с двумя удаленными железками (host2 и host3). Железка подключенная двумя интерфейсами к двум... назовем это «маршрутизаторам» (хотя функционально ограниченными), R1 и R2. Каждый маршрутизатор соединен двумя каналами через внешние сети с обоими удаленными железкам (внешняя сеть не IP, для маршрутизатора каждый канал выглядит как выделенный).

Вот так: https://i.ibb.co/myfdxcB/net.png

Если какой-то канал (ch1 или ch2) становится недоступен, то на маршрутизаторе пропадает и соответствующий маршрут на удаленную железку. На host1 каждый маршрутизатор умеет сообщать свои маршруты только по RIPv2 и больше никак. При этом все активные маршруты передает с одинаковой метрикой.

Т.е., если все каналы работают, то на локальной железке есть по два маршрута на каждую удаленную железку с одинаковой метрикой. А нужно по другому - чтобы маршрут на host2 через R1 имел метрику ниже (приоритет выше), чем маршрут на host3 через R1. И маршрут на host3 через R2 имел метрику ниже, чем маршрут на host3 через R1.

Тогда в нормальной ситуации (все каналы в работе) трафик на host2 пойдет через R1, трафик на host3 - через R2. Если какой-то канал отвалился, то соответствующий маршрут в таблице на host1 пропадет, и трафик на удаленный хост пойдет через другой маршрутизатор.

Маршруты нужно именно получать по RIP, а не прописывать статически, т.к. именно по RIP я получаю информацию о падении каналов (исчезает соответствующий маршрут - не сразу, конечно, но это устраивает), использовать же другие протоколы динамической маршрутизации возможности нет.

Т.е. задача: средствами host1 (Linux) уметь принудительно изменить метрику маршрута, полученного по RIPv2, в зависимости от сети назначения и адреса шлюза.

я покопался в возможностях ip2, iptables - но что-то ничего похожего не нашел.

 ,

mik73 ()

удаление файла произвольным пользователем

Форум — Admin

возникла странная задача:

какой-то пользователь создает файл в известном месте (на самом деле файл создает приложение, запущенное от имени пользователя, но это неважно). надо чтобы любой другой пользователь мог этот файл прочитать и после этого удалить, если сочтет нужным.

с помощью chmod можно задать права на чтение, запись, исполнение файла. в том числе для любого пользователя («всех остальных»)

с помощью chown можно поменять пользователя или группу пользователей, который смогут в том числе удалять этот файл.

а вот как дать права на удаление данного файла произвольному пользователю, входящему в произвольную группу (т.е. «всем остальным»)?

возможно, вопрос глупый, но сходу ответа не нашел.

 

mik73 ()

отправка команд в сессию Telnet из bash

Форум — Admin

Задача: открыть сессию Telnet с удаленным устройством и посылать в эту сессию команды из скрипта bash.

Простой способ с помощью expect известен - вызвать из скрипта bash скрипт expect и оттуда всё послать. Но из скрипта expect я могу открыть сессию Telnet, послать команду (или группу команд), закрыть сессию Telnet, вернуться в скрипт bash. Если надо послать что-то еще - опять открыть сессию Telnet, послать, закрыть сессию Telnet... И так далее.

Нужно иначе - не закрывать сессию после каждой команды, а открыть из скрипта bash сессию Telnet на удаленное устройство, отправить туда команду, не закрывая сессию, проделать манипуляции в скрипте bash (например посмотреть состояние другого устройства после действия на первом), в зависимости от результата - отправить команду в открытую сессию Telnet, опять проделать манипуляции в bash, по их результату - отправить команду в сессию Telnet и так далее (в конце концов командой, отправленной в сессию Telnet будет exit).

Примерно так.

 , ,

mik73 ()

Вложенные шейперы на tc - возможно?

Форум — Admin

Очередной вопрос про шейперы на tc. Использую дисциплину htb. Есть канал конечной пропускной способности, который делится между двумя классами пользователей, например так:

class htb 1:2 root rate 50Mbit ceil 50Mbit 
class htb 1:10 parent 1:2 leaf 10: prio 1 rate 30Mbit ceil 40Mbit 
class htb 1:20 parent 1:2 leaf 20: prio 2 rate 20Mbit ceil 40Mbit 

При этом qdisc, естественно:

qdisc htb 1: root refcnt 2 r2q 40 default 90 
qdisc sfq 10: parent 1:10 limit 127p quantum 1472b perturb 10sec
qdisc sfq 20: parent 1:20 limit 127p quantum 1472b perturb 10sec
Описание filter опускаю. Они есть и работают :-). Описание дефолтного класса 90 (куда попадает трафик, которого нет в filter) тоже.

Здесь все понятно: для пользователей (описанных в tc filters, естественно) из класса 10 и из класса 20 доступна макс. скорость по 40 Мбит (ceil), но поскольку канал всего 50, то, если суммарный трафик больше чем 50, класс 10 (prio 1) будет «выдавливать» класс 20 (prio 2). В пределе, когда все пытаются грузить канал по максимуму, установится соотношение между классами 30/20 (согласно rate). Это давно и много раз испытано и работает.

А теперь хочу сделать «вложенный шейпер». Т.е. под классом 20 сделать еще несколько классов так, чтобы скорости распределялись между ними, но ограничивались не «верхним» интерфейсом, а параметрами класса 20.

Например так:

class htb 1:201 parent 1:20 leaf 201: prio 2 rate 10Mbit ceil 25Mbit 
class htb 1:202 parent 1:20 leaf 202: prio 2 rate 10Mbit ceil 25Mbit 
хочется из этого получить:

Работает только класс 201. Тогда, если в канале есть место (трафика в классе 10 мало, классу 20 можно выделить до 40 Мбит/с), то класс 201 получает до 25 Мбит. Если нет (классу 20 выделяется 20), от и класс 201 ограничивается этими 20.

Если работают 201 и 202, то они «дерутся» между собой за место, доступное в классе 20, в пределе, когда класс 20 больше 20 Мбит предоставить не может, а 201 и 202 «хотят» по максимуму - каждый получит по 10 Мбит.

В общем, логичное, вроде, желание. Однако, тут налетаем на принципиальное ограничение, которое называется «шейпится только краевой класс». При попытке сделать вышеописанную конфигурацию и поместить каких-то пользователей в классы 201 и 202 через filter, получаем:

class htb 1:2 root rate 50Mbit ceil 50Mbit 
class htb 1:10 parent 1:2 leaf 10: prio 1 rate 30Mbit ceil 40Mbit 
class htb 1:20 parent 1:2 rate 20Mbit ceil 40Mbit 
class htb 1:201 parent 1:20 leaf 201: prio 2 rate 10Mbit ceil 25Mbit 
class htb 1:202 parent 1:20 leaf 202: prio 2 rate 10Mbit ceil 25Mbit 

qdisc htb 1: root refcnt 2 r2q 40 default 90 
qdisc sfq 10: parent 1:10 limit 127p quantum 1472b perturb 10sec
qdisc sfq 201: parent 1:201 limit 127p quantum 1472b perturb 10sec
qdisc sfq 202: parent 1:201 limit 127p quantum 1472b perturb 10sec

Класс 20 после этого перестает быть «краевым» (исчезает leaf) и по факту не работает (ничего не поменяется, если его из конфигурации исключить, a для 201 и 201 сделать parent 1:2, т.е. весь интерфейс), очередь (qdisc) для класса 20 исчезает, как и приоритет у класса. Даже если в filter описаны правила, направляющие трафик как в классы 201 и 201, так и прямо в класс 20 - трафик, направленный «прямо в класс 20» этим классом не обрабатывается и улетает в default. А 201 и 202 напрямую конкурируют с классом 10. Например, если трафика в классе 10 нет, то и 201 и 202 могут получить все 50 Мбит канала (по 25 каждый). А не определенные в их «родительском» классе максимальные 40. С другой стороны, если работают только 10 и 201, то 10 «выдавит» 201 до соотношения 40/10. А хотелось бы, чтобы 201 получал в таком случае определенные в его «родительском» классе классе 20.

Вопрос - можно какими-то стандартными средствами tc реализовать «вложенный шейпер»? Возможно, используя не htb, а другую дисциплину. С htb, насколько я сумел выяснить после долгой возни, это, похоже, невозможно. Хотя с другой стороны, возможность создавать вложенные классы есть - но раз всё равно не работают, то зачем?

 ,

mik73 ()

исключить несколько интерфейсов в iptables

Форум — Admin

Есть маршрутизатор на основе линус с несколькими интерфейсами (пусть 6, от eth0 до eth5) Нужно по критерию протокол-порт (пусть tcp, destination port 12345) маркировать трафик, входящий с нескольких из них. Пусть c eth1,eth2,eth4,eth5, с eth0 и eth3 - не надо.

Вроде все просто. Пишем соотвествующее количество правил в таблицу mangle:

-A PREROUTING -i eth1 -p tcp -m tcp --dport 12345 -j MARK --set-xmark 0x10/0xffffffff
-A PREROUTING -i eth2 -p tcp -m tcp --dport 12345 -j MARK --set-xmark 0x10/0xffffffff
-A PREROUTING -i eth4 -p tcp -m tcp --dport 12345 -j MARK --set-xmark 0x10/0xffffffff
-A PREROUTING -i eth5 -p tcp -m tcp --dport 12345 -j MARK --set-xmark 0x10/0xffffffff

Вопрос - как заменить эти 4 записи на одну? Т.е. не 4 раза «маркировать с порта ethХ» а один раз «маркировать со всех портов кроме eth0, eth3»

Если бы было нужно со всех портов, кроме eth0, то опять все просто

-A PREROUTING ! -i eth0 -p tcp -m tcp --dport 12345 -j MARK --set-xmark 0x10/0xffffffff

а вот как сформулировать для iptables «не с порта eth0 и не с порта eth3» ? Вроде как-то можно использовать and в правилах, но синтаксис не очевиден. Примеры пытался погуглить - не нашел.

 

mik73 ()

непонятки с SNAT

Форум — Admin

Дано: сервер на Linux (Centos 6.3 - да, уже старый, но «работает-не трогай»), работающий Интернет-шлюзом для нескольких частных сетей. Адреса в частных сетях «серые», На интерфейсе eth0, которым сервер подключен к Интернет-сегменту, делается SNAT по принципу «много в один» (подсеть «серых» адресов в один «белый» IP). Например (реальные адреса, естественно, заменены):

 -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j SNAT --to-source 1.1.1.1

По идее пакетов с источником из сети 10.10.10.0 на выходе с eth0 после этого быть не должно, вместо этого у всех исходящих с eth0 пакетов источником должен быть 1.1.1.1. В большинстве случаев это так, однако регулярно появляются и пакеты с сурсом из 10.10.10.0. И tcpdump'ом на eth0 их видно и на внешние адреса приходят.

Например, фрагмент дампа, где появляются такие пакеты:

22:16:20.458067 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 2865:4297, ack 312, win 288, length 1432
22:16:22.915330 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 4297:5729, ack 312, win 288, length 1432
22:16:26.611440 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 1433:2865, ack 312, win 288, length 1432
22:16:28.601530 IP 1.1.1.1.58349 > 93.184.221.240.http: Flags [.], ack 2865, win 160, length 0
22:16:28.604610 IP 1.1.1.1.58349 > 93.184.221.240.http: Flags [F.], seq 312, ack 2865, win 160, length 0
22:16:28.625207 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], seq 5729:7161, ack 312, win 288, length 1432
22:16:28.625236 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [P.], seq 7161:8593, ack 312, win 288, length 1432
22:16:28.628016 IP 93.184.221.240.http > 1.1.1.1.58349: Flags [.], ack 313, win 288, length 0
22:16:28.656497 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:29.011868 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.505264 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.756197 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.883696 IP 10.10.10.124.58349 > 93.184.221.240.http: Flags [R], seq 3280738781, win 0, length 0
22:16:35.968263 IP 1.1.1.1.58349 > 93.184.221.240.http: Flags [R], seq 3280738782, win 0, length 0

В интернетах копался долго, но ничего похожего не нашел.Насколько я понимаю, в цепочку POSTROUTING таблицы nat должны попадать все выходящие через интерфейс (в данном случае eth0) пакеты, и source IP у них должен подменяться. После этого теоретически с ними мог бы что-до делать mangle POSTROUTING, но его у меня нету. Но по факту - иногда source IP не подменяется.

Вопрос: а почему? И как от этого избавиться.

Примечание: если сделать трансляцию «один в один», типа

 -A POSTROUTING -s 10.10.10.124/32 -o eth0 -j SNAT --to-source 1.1.1.1
то такой ерунды, вроде, не происходит. Но это же не выход. Сильно жирно - на каждый «серый IP» выделять по белому. И даже по отдельному правилу писать - тоже не выход, особенно если этих «серых» IP во внутренней сети (да еще не одной) сильно много.

 ,

mik73 ()

Распределение трафика в одном классе htb

Форум — Admin

Исходные данные: есть ограниченная полоса, для управления трафиком пользователей используется шейпер, созданный с помощью tc, дисциплина htb. Полоса делится на несколько классов с разными приоритетами. Для помещения трафика в каждый класс используется фильтрация по IP пользователя. В каждый класс помещается несколько пользователей. Распределение между классами замечательно работает.

Проблема: ожидается что в пределах одного класса полоса будет делиться между пользователями примерно равномерно. Т.е. классу в данный момент доступно, допустим, 12 мб/с, в нем три пользователя. Один пользователь может занять все 12, если работают двое - каждому достанется по 6, если трое - каждому по 4. По факту так не получается. Выделяемая полоса зависит от количества сессий. Один пользователь может запустить какой-нибудь торрент и съест практически всю полосу, выделенную классу, а двум другим, которые хотят, например, почитать почту, не остается почти ничего.

Пример создания класса:

#/sbin/tc class add dev eth0 parent 1:2 classid 1:20 htb rate 8000Kbit ceil 12000Kbit prio 1

# /sbin/tc qdisc add dev eth0 parent 1:20 handle 20 sfq perturb 10

# /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 172.16.0.1/32 classid 1:20

# /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 172.16.0.2/32 classid 1:20

# /sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst 172.16.0.3/32 classid 1:20

Нужно, чтобы когда работают все трое (172.16.0.1, .2, .3) каждому доставалось примерно по 4 Мбит. А не так, чтобы 1 запустил 100 сессий и съел всё, а 2 и 3 запустили по одной сессии и ничего не получают. Предположительно здесь можно применить flow hash в filter, но пока не понимаю как. Мануалы читал, но в голове сумбур.

Отягчающие обстоятельства: По условиям эксплуатации сети приоритизация допустима только по IP пользователей, устраивать приоритизацию по типам сервисов (почта, серфинг, торрент и т.п.) - не предлагать. Создавать отдельный класс для каждого пользователя - выход, но плохой (наоборот, хочется от этого уйти по ряду причин).

 , , ,

mik73 ()

RSS подписка на новые темы