LINUX.ORG.RU

Сообщения xeon_greg

 

назначение имен видеоустройствам правилами UDEV

Форум — Admin

Всем привет. система 16.04. есть такая проблемка, стало необходимо давать свои имена на видеоустройства, в частности на вебку и тюнер. накидал правило для UDEV

SUBSYSTEM=="video4linux", ATTRS{idVendor}=="5986", ATTRS{idProduct}=="0105", GROUP="video",SYMLINK+="webcam0"
SUBSYSTEM=="video4linux", ATTRS{vendor}=="0x1131", ATTRS{device}=="0x7134", GROUP="video", SYMLINK+="beholder0"
проверяю каждое устройство командой udevadm test, линки создаются все ок. перезагружаю сервер - линк на камеру создался на тюнер - нет, проверяю отдельно тюнер
sudo udevadm test /devices/pci0000:00/0000:00:04.0/0000:01:06.0/video4linux/video1
линк создался. теперь вопрос почему не создается при загрузке на тюнер?

 , ,

xeon_greg
()

Openvpn с двумя хвостами и MARK/CONNMARK

Форум — Admin

значит конфигурация такая. есть Openvpn сервер, с двумя провайдерами, соотв две статики, eth1 - 1.1.1.1 gw 1.1.1.2 eth2 - 2.2.2.1 gw 2.2.2.2

 
ip r:
1.1.1.0/24 dev eth1  proto kernel  scope link  src 1.1.1.1 
2.2.2.0/24 dev eth2  proto kernel  scope link  src 2.2.2.1 
default via 2.2.2.2 dev eth2 

ip r s t 1:
default via 1.1.1.2 dev eth1

ip r s t 2:
default via 2.2.2.2 dev eth2

ip ru:
0:	from all lookup local 
32760:	from all fwmark 0x2 lookup 1 
32764:	from 1.1.1.1 lookup 1
32765:	from 2.2.2.1 lookup 2
32766:	from all lookup main 
32767:	from all lookup default 

iptables:

iptables -t mangle -A INPUT -i eth1 -p udp --dport 1194 -j MARK --set-mark 2
iptables -t mangle -A INPUT -j CONNMARK --save-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
это базовые правила по которым дол;но все работать как надо, но... маршрутами стоят соот шлюзы провайдеров, соотв добавлены правила ip rule для хождения трафика через те интерфейсы с которых они пришли, таким образом работает автоматическое переключение дефолтного маршрута, в случае падения одного из провайдеров. у впн клиентов в конфигах прописаны обе статики сервера, чтобы в случае отказа какой либо, клиент подключался через другую. все работает хорошо, только есть один момент, не возможно подключится к впн серверу по той статике которая в данный момент не является маршрутом по умолчанию в мейне, смотрю в iptraf , клиент пытается подключиться , а ответ от сервера идет через дефолтный маршрут , а не через тот шлюз с которого пришел. сейчас начнете тыкать носом в эту тему iproute2+connmark, уже как только не извращался с коннмарком, видимо коннмарк не может тут корректно работать, тк соединение фактически не установлено те первый пакет имеет статус UNREPLIED, а просто марк сюда не подходит тк надо следить фактически за ответами сервера после долгих ковыряний прихожу к выводу, что пока это особенность работы опенвпн сервера, тк на этом же сервере вэбсервер работает как надо по обоим интерфейсам и без использования коннмарка, достаточно только правил маршрутизации. и напоследок лог того как маркируются пакеты в Iptables
sudo iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 13180 packets, 7377K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    9   682 CONNMARK   all  --  eth1   *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore 
    2    84 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x0 LOG flags 0 level 4 
    2    84 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match !0x0 LOG flags 0 level 4 

Chain INPUT (policy ACCEPT 1892 packets, 238K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    3   126 MARK       udp  --  eth1   *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 MARK xset 0x2/0xffffffff 
    6   508 CONNMARK   all  --  eth1   *       0.0.0.0/0            0.0.0.0/0           CONNMARK save 
    3   126 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match !0x0 LOG flags 0 level 4 
    3   126 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x0 LOG flags 0 level 4 

Chain FORWARD (policy ACCEPT 11288 packets, 7139K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match !0x0 LOG flags 0 level 4 
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x0 LOG flags 0 level 4 

Chain OUTPUT (policy ACCEPT 1606 packets, 289K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1606  289K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0           CONNMARK restore 
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x0 LOG flags 0 level 4 
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match !0x0 LOG flags 0 level 4 

Chain POSTROUTING (policy ACCEPT 12894 packets, 7428K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           mark match !0x0 LOG flags 0 level 4 
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           connmark match !0x0 LOG flags 0 level 4 
отсюда видно, что входящие соединения маркируются, марки сохраняются в соединениях, но не восстанавливаются, думаю как раз потому, что ответ опенвпн сервера начинает исходить с другим адресом источника( с другого интерфейса), из-за этого модуль коннтрак не считает его родственным соединению и не восстанавливает марку.

xeon_greg
()

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