LINUX.ORG.RU
Форум — Admin  

Policy Routing. Проблемы

 ,


0

1

Добры день Есть шлюз, который подключается к удаленной сети посредством Kerio VPN Client, при подключении формируется маршрут в удаленную сеть вида: 

ip r l
172.17.174.64/27 dev eth0  proto kernel  scope link  src 172.17.174.80 
10.0.0.0/8 via 10.253.245.1 dev kvnet  proto none  metric 1 onlink 
default via 172.17.174.94 dev eth0
Проблема в том, что в диапазоне 10.0.0.0/8 локальная сеть, соответственно, после того, как VPN канал поднят, связь до шлюза пропадает и удаленная сеть не видна. Думаю решить это средствами Policy Routing:

Создал доп. таблицу маршрутизации custom: 

ip route show table custom
10.39.1.70 dev kvnet  scope link 
default via 172.17.174.94 dev eth0
172.17.174.94 - адрес моего внутреннего маршрутизатора

10.39.1.70 - узел удаленной сети

Добавил правила: 

ip rule
0:	from all lookup local 
32762:	from 10.17.17.0/24 lookup custom 
32763:	from 10.39.1.70 lookup custom 
32766:	from all lookup main 
32767:	from all lookup default
Удаленный хост доступен, но проблема в том, что подсетей у нас несколько, к тому же необходимо помнить о необходимости внесения изменений при добавлении новых локальных подсетей.

Поэтому было принято решение маркировать трафик по интерфейсам: 

iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 19 packets, 1053 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   29  1518 CONNMARK   all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            CONNMARK set 0x1
    0     0 CONNMARK   all  --  kvnet  *       0.0.0.0/0            0.0.0.0/0            CONNMARK set 0x1

Chain INPUT (policy ACCEPT 11 packets, 573 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 9 packets, 409 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 9 packets, 409 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    9   409 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0            CONNMARK restore

И перенаправлять его: 

ip rule 
0:	from all lookup local 
32765:	from all fwmark 0x1/0x1 lookup custom 
32766:	from all lookup main 
32767:	from all lookup default

Но такая схема не работает, где-то ошибка. Как можно выяснить причины того, что пакеты не ходят?

И второй вопрос: Можно ли как-нибудь обеспечить доступ к VPN шлюзу из локальной сети? Судя по этой картинке решение о маршрутизации исходящего пакета принимается до mangle\OUTPUT и он ответные пакеты будут всегда уходить в удаленную сеть?


Непонятно что вы пытались сделать с помощью iptabels, выставляете маркер соединению в PREROUTING, а маркер пакета выставляете (восстанавливаете) в POSTROUTING, когда уже решение о маршруте принято.

Картинка неправильная, решение о маршруте локального пакета принимается дважды, один раз как показано, второй раз перед filter/OUTPUT. Первый раз, главный образом, решение принимается с целью определить src-ip адрес, если приложение его не указало (0.0.0.0), то он будет принят по главной (main) таблице маршрутизации, в соотвествии с выбранным маршрутом/интерфейсом.

mky ★★★★★
()
Ответ на: комментарий от mky

Судя по всему я запутался: 

iptables -t mangle -A PREROUTING -i eth0 -j CONNMARK --set-mark 1
Устанавливает метку на соединение, а не на пакеты?

Чтобы маркировать все пакеты соединения необходимо после выполнить: 

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
так?

или изначально маркировать пакеты: 

iptables -t mangle -A PREROUTING -i eth0 -j MARK --set-mark 1
верно?

alexg
() автор топика
Ответ на: комментарий от alexg

Да на все вопросы.

CONNMARK в основном применяют для маркировки ответных пакетов, когда нет возможности составить правило с ″-j MARK″.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin