LINUX.ORG.RU
решено Форум — General  

Ubuntu 2 провайдера, проброс порта, статические маршруты.

 


0

1

Добрый день. Знаю, что по этой теме очень много инфы в инете, но кое-что не получается и не могу понять почему. Значит вводные данные: Ubuntu 14.04.3 LTS, 2 провайдера с белыми IP. Проблем две. 1) Статические маршруты. Если пишу в консоли: 

route add -net 8.8.8.8 netmask 255.255.255.255 gw 85.Х.Х.Х dev eth1
или 
ip ro add 8.8.8.8/32 via 85.Х.Х.Х
то все отлично. Маршрут добавляется и работает. Но, понятное дело, пропадает при перезагрузке. Потому добавляю его в /etc/network/interfaces. Вот тут проблема и появляется. Он не восстанавливается при перезагрузке. Думал особенность версии Убунты, но поставил эту же версию на виртуалку - там все отлично сохраняется. Не понимаю, почему на боевой системе это не работает. 2) Доступ из вне по 2-м провайдерам. Выполняем: 
ip route add default via 85.Х.Х.Х table 101
ip route add default via 109.Х.Х.Х table 102
ip rule add from 85.Х.Х.Х table 101
ip rule add from 109.Х.Х.Х table 102
После этого появляется доступ на шлюз по 2-м провайдерам. Все отлично, но нет доступа в локальную сеть со 2-го провайдера. Тут, я так понимаю, нужно маркировать пакеты. 
ip rule add fwmark 10 lookup 101
ip rule add fwmark 11 lookup 102
iptables -t mangle -A PREROUTING -i eth0 --dst 85.Х.Х.Х -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-mark 10
iptables -t mangle -A PREROUTING -i eth2 --dst 109.Х.Х.Х -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-mark 11
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
Вроде как все понятно и народ в интернетах пишет, что после этого должно работать все. Если не работает, отключите rp_filter на всех интерфейсах. Отключил, но даже пинга нет по 2-му провайдеру. Понятно, что где-то накосячил, но не понимаю где( Ткните носом в ошибки, пожалуйста.


← Проблема с установкой VLC
Почему линуксовые torrent-клиенты плохо ищут пиры? →

Первую проблему частично решил. /etc/network/interfaces: 

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 85.Х.Х.Х
netmask 255.255.255.0
gateway 85.Х.Х.Х
dns-nameservers 85.Х.Х.Х
up /sbin/ip ro add 8.8.8.8/32 via 85.Х.Х.Х
up /sbin/ip ro add default via 85.Х.Х.Х table 101
up /sbin/ip rule add from 85.Х.Х.Х table 101

auto eth1
iface eth1 inet static
address 192.168.0.1
netmask 255.255.255.0

auto eth2
iface eth2 inet static
address 109.Х.Х.Х
netmask 255.255.255.0
gateway 109.Х.Х.Х
dns-nameservers 109.Х.Х.Х
up /sbin/ip ro add default via 109.Х.Х.Х table 102
up /sbin/ip rule add from 109.Х.Х.Х table 102

pre-up iptables-restore < /etc/iptables.up.rules
В таком варианте маршруты прописанные после eth0 поднимаются, а после eth2 - нет. Пробовал вместо up использовать post-up, но все равно не добавляются. Зато после перезагрузки они нормально добавляются вручную и начинают работать.

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

Первую проблему решил полностью с помощью костыля. Все маршруты прописал в отдельный скрипт и добавил его в /etc/crontab. Работает. Если прописать этот скрипт в /etc/network/interfaces в виде «post-up /etc/route.sh», то тоже почему-то не срабатывает. По второй - по прежнему не понимаю почему не работает.

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

в /etc/route.sh второй строкой сказать «set -x» и stderr куда-нибудь в файл/log. Очень часто такие проблемы когда в путях отсутствует /sbin и /usr/sbin.

Если делать ping/traceroute/wget с явным указанием локального адреса - все работает?

А проброс портов куда ?

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

Если делать ping/traceroute/wget с явным указанием локального адреса - все работает?

Вы имеете ввиду: 

ping -I eth0 8.8.4.4
- работает, это основной провайдер. 
ping -I eth2 8.8.4.4
- а вот это уже не работает. Значит проблема похоже даже не в маркировке.

А проброс портов куда ?

Проброс в локальную сеть на винду с рдп. Его делаю так: 

-A PREROUTING -i eth0 -p tcp -m tcp -d 85.х.х.х --dport 1234 -j DNAT --to-destination 192.168.0.2:3389
-A POSTROUTING -o eth0 -p tcp -m tcp -s 192.168.0.2 --sport 3389 -j SNAT --to-source 85.х.х.х
-A PREROUTING -i eth2 -p tcp -m tcp -d 109.х.х.х --dport 1234 -j DNAT --to-destination 192.168.0.2:3389
-A POSTROUTING -o eth2 -p tcp -m tcp -s 192.168.0.2 --sport 3389 -j SNAT --to-source 109.х.х.х
Первое правило отрабатывает, второе нет. Но проблема, я так понимаю, не в них.

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

Да, просто с «traceroute -ns xxx.xxx.xxx.xxx 8.8.8.8» - это более наглядно.

А вот наличие локальной сети все немного усложняет. Хочется посмотреть «ip ru» и «ip ro»

правила 2 и 4 или нафиг не нужны, или написаны неверно.

Учти, что SNAT/DNAT/REDIRECT/MASQUERADE - завершает обработку цепочки. Может перед ними срабатывают правила ?

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

Трасерт проходит, в отличии от пинга. Странно. 

root@Gate:~# traceroute -ns 85.х.х.х -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  85.х.х.х  1.274 ms  1.514 ms  1.757 ms
 2  212.х.х.х  25.346 ms  26.860 ms  28.062 ms
 3  85.х.х.х  29.266 ms  30.498 ms  32.057 ms
 4  193.41.62.205 39.568 ms  39.827 ms  41.945 ms
 5  81.23.22.201  42.400 ms  42.509 ms  42.611 ms
 6  81.23.22.202  42.145 ms  42.421 ms  42.396 ms
 7  216.239.46.121 75.343 ms  56.733 ms  38.865 ms
 8  216.239.57.240 74.328 ms  75.204 ms  78.717 ms
 9  66.249.95.226 74.487 ms  69.720 ms  72.366 ms
10  108.170.234.149  69.362 ms  71.938 ms  71.880 ms
11  * * *
12  8.8.8.8  74.786 ms  65.262 ms  63.414 ms
root@Gate:~# traceroute -ns 109.х.х.х -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  109.х.х.х  0.750 ms  1.047 ms  1.302 ms
 2  10.х.х.х  0.530 ms  0.689 ms  0.820 ms
 3  195.х.х.х  8.610 ms  8.606 ms  8.609 ms
 4  216.239.46.121  21.935 ms  21.943 ms  21.893 ms
 5  216.239.57.240 48.315 ms  48.392 ms  48.430 ms
 6  66.249.95.226  42.130 ms  42.224 ms  42.140 ms
 7  108.170.234.149  41.613 ms  41.605 ms  41.571 ms
 8  * * *
 9  8.8.8.8  38.497 ms  38.517 ms  38.523 ms
ip ro 
default via 85.x.x.3 dev eth0
10.10.10.0/24 via 10.10.10.2 dev tun0
10.10.10.2 dev tun0  proto kernel  scope link  src 10.10.10.1
85.x.x.2/30 dev eth0  proto kernel  scope link  src 85.x.x.4
109.x.x.128/25 dev eth2  proto kernel  scope link  src 109.x.x.6
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1
192.168.2.0/24 via 10.10.10.2 dev tun0
ip ru 
0:      from all lookup local
32764:  from 109.x.x.6 lookup 102
32765:  from 85.x.x.4 lookup 101
32766:  from all lookup main
32767:  from all lookup default
Маскарад прописан самым последним правилом в POSTROUTING, а правило проброса самым первым в PREROUTING. Да, правил 2 и 4 раньше не было, добавил сегодня. Раньше проброс был таким правилом: 
-A PREROUTING -i eth0 -p tcp -m tcp --dport 1234 -j DNAT --to-destination 192.168.0.2:3389

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

Не знаю почему 

ping -I eth0 8.8.8.8
работает, а 
ping -I eth2 8.8.8.8
нет, но пинг с указанием адреса явно работает. Даже адреса сетевой, которая в локалку смотрит. 
ping -I 85.х.х.4 8.8.8.8
ping -I 109.х..6 8.8.8.8
ping -I 192.168.0.1 8.8.8.8

seven
() автор топика
Ответ на: комментарий от seven 
32764:  from 109.x.x.6 lookup 102
32765:  from 85.x.x.4 lookup 101
32766:  from all lookup main

На эти грабли рекомендованные larc наступают все.

Попробуй сделай «traceroute -ns 85.x.x.4 192.168.0.X»

Пока не будет прямых маршрутов в таблицах 101 и 102 - не видать тебе удачи.

А где 

ip rule add fwmark 10 lookup 101
ip rule add fwmark 11 lookup 102
без этой конструкции не будет работать одновременный проброс на одни порт.

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

Пока не будет прямых маршрутов в таблицах 101 и 102 - не видать тебе удачи.

Я так понимаю Вы про это: 

ip route add 192.168.0.0/24 dev eth1 table 101
ip route add 109.x.x.0/25 dev eth2 table 101
ip route add 127.0.0.0/8 dev lo table 101
ip route add 192.168.0.0/24 dev eth1 table 102
ip route add 85.x.x.0/30 dev eth0 table 102
ip route add 127.0.0.0/8 dev lo table 102

Попробуй сделай «traceroute -ns 85.x.x.4 192.168.0.X»

root@Gate:~# traceroute -ns 109.x.x.6 -I 192.168.0.2
traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 60 byte packets
 1  109.x.x.6  2996.305 ms !H  2996.265 ms !H  2996.263 ms !H
root@Gate:~# traceroute -ns 85.x.x.4 -I 192.168.0.2
traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 60 byte packets
 1  85.x.x.4  2996.433 ms !H  2996.374 ms !H  2996.371 ms !H

А где

Ой, извините. Удалил перед этим все свои эксперименты с маркировкой. 

0:      from all lookup local
32762:  from all fwmark 0xb lookup 102
32763:  from all fwmark 0xa lookup 101
32764:  from 109.x.x.6 lookup 102
32765:  from 85.x.x.4 lookup 101
32766:  from all lookup main
32767:  from all lookup default
Сейчас все вернул на место 
ip rule add fwmark 10 lookup 101
ip rule add fwmark 11 lookup 102
iptables -t mangle -A PREROUTING -i eth0 --dst 85.х.х.4 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-mark 10
iptables -t mangle -A PREROUTING -i eth2 --dst 109.х.х.6 -m conntrack --ctstate NEW,RELATED -j CONNMARK --set-mark 11
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

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

Забыл написать. Правило проброса теперь выглядит так: 

-A PREROUTING -p tcp -m tcp --dport 1234 -j DNAT --to-destination 192.168.0.2:3389
По первому (основному) провайдеру срабатывает, по второму нет.

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

Попробуй сделай «traceroute -ns 85.x.x.4 192.168.0.X»

root@Gate:~# traceroute -ns 109.x.x.6 -I 192.168.0.2 traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 60 byte packets

1 109.x.x.6 2996.305 ms !H 2996.265 ms !H 2996.263 ms !H

root@Gate:~# traceroute -ns 85.x.x.4 -I 192.168.0.2

traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 60 byte packets

1 85.x.x.4 2996.433 ms !H 2996.374 ms !H 2996.371 ms !H

А 192.168.0.2 живой ?

Про прямые маршруты - да. Только смущает «85.x.x.2/30 dev eth0 proto kernel scope link src 85.x.x.4»

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

А теперь представь пакет пришедший из tun0 в eth1 на порт tcp 1234.

IMHO требуется уточнение в виде "-i ethX", чтоб оно срабатывало только для пришедших через внешние интерфейсы.

Работает по тому провайдеру, на которого указывает DGW в таблице main. Значит правила маршрутизации почему-то не срабатывают.

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

А 192.168.0.2 живой ?

Да, уже нормально 

traceroute -ns 85.х.х.4 -I 192.168.0.2
traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 60 byte packets
 1  192.168.0.2  0.144 ms  0.128 ms  0.114 ms
root@Gate:~# traceroute -ns 109.х.х.6 -I 192.168.0.2
traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 60 byte packets
 1  192.168.0.2  0.128 ms  0.114 ms  0.104 ms

Только смущает «85.x.x.2/30 dev eth0 proto kernel scope link src 85.x.x.4»

А что именно не так? Этот маршрут был добавлен по умолчанию. Я во втором сообщении с маской ошибся. 

auto eth0
iface eth0 inet static
address 85.X.X.4
netmask 255.255.255.252
gateway 85.X.X.3
dns-nameservers 212.X.X.5

IMHO требуется уточнение в виде "-i ethX", чтоб оно срабатывало только для пришедших через внешние интерфейсы.

-A PREROUTING -i eth0 -p tcp -m tcp --dport 1234 -j DNAT --to-destination 192.168.0.2:3389
-A PREROUTING -i eth2 -p tcp -m tcp --dport 1234 -j DNAT --to-destination 192.168.0.2:3389

Работает по тому провайдеру, на которого указывает DGW в таблице main. Значит правила маршрутизации почему-то не срабатывают.

Да, это я понимаю, но не понимаю почему. Подобный конфиг с маркировкой и 2-мя таблицами и маршрутами отлично работает на Микротиках уже несколько лет. А на чистой Убунте первый раз настраиваю... P.S. Спасибо большое за помощь!

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

О, Боги. Решил проблему. Нужно быть в rp_filter не 0 записывать, а 2. Т.е.: 

echo 2 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/eth2/rp_filter
Пока тестирую. Вечером попробую перезагрузить и проверить после перезагрузки. vel, спасибо Вам большое за помощь. Сам бы я еще неделю сидел, если не больше.

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

Хм. а что за ядро? rp_filter=0 - это «No source validation.»

И есть приписка

The max value from conf/{all,interface}/rp_filter is used when doing source validation on the {interface}.

может у тебя было net.ipv4.conf.all.rp_filter=1 ?

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

Хм. а что за ядро?

root@Gate:~# uname -a
Linux Gate 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

может у тебя было net.ipv4.conf.all.rp_filter=1 ?

А как можно посмотреть? В файле /etc/sysctl.conf у меня эта строка закоментирована. 

root@Gate:~# cat /proc/sys/net/ipv4/conf/default/rp_filter
1
Еще интересный глюк заметил. После того как я записываю 2 в rp_filter для каждой сетевой, через несколько минут подымается пинг из вне до нескольких сотен мс на обоих сетевых, что смотрят в интернет. Возвращаю 0 или 1, также через несколько минут все снова в норме.

seven
() автор топика
Ответ на: комментарий от seven 
root@Gate:~# sysctl -a | grep rp_filter
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.eth2.arp_filter = 0
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 1
net.ipv4.conf.tun0.arp_filter = 0
net.ipv4.conf.tun0.rp_filter = 1
seven
() автор топика
Ответ на: комментарий от seven

Добавил в файл /etc/sysctl.conf 

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
Не работает. Изменил на 2 - работает.

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

Остается понять в какой момент времени при загрузке системы применяются значения из /etc/sysctl.conf

Про дикий пинг - пока нет догадок. Возможно что есть зацикливание трафика. Но это tcpdump-ом легко посмотреть.

У тебя есть 

10.10.10.0/24 via 10.10.10.2 dev tun0
192.168.2.0/24 via 10.10.10.2 dev tun0
Если с той стороны реально есть только 192.168.2.0/24, то заброс пакета на какой-нибудь адрес типа 10.10.10.5 может создавать лишнюю нагрузку.

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

Про дикий пинг - пока нет догадок. Возможно что есть зацикливание трафика. Но это tcpdump-ом легко посмотреть.

Последние часа 2 проблем нет, пинг не скачет. Наблюдаю. Также не очень понимаю почему при отключенном rp_filter не работает. И что вообще такое значение 2.

Если с той стороны реально есть только 192.168.2.0/24, то заброс пакета на какой-нибудь адрес типа 10.10.10.5 может создавать лишнюю нагрузку.

192.168.2.0/24 - это сеть с другой стороны туннеля. 10.10.10.0/24 - это сеть для OpenVPN. Маршруты созданы строками в конфиге openvpn: 

route 10.10.10.0 255.255.255.0
route 192.168.2.0 255.255.255.0
10-й маршрут убрал, он не нужен. Спасибо за подсказку.

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

Все работает вроде как нужно.Появились только 2 не понятных мне момента. Не хочу создавать новую тему, спрошу здесь, может ктото сможет пояснить. 1) Добавляю статический маршрут: 

ip ro add 8.8.4.4/32 via 109.x.x.х
Хочу чтобы доступ к 8.8.4.4 был только через основного провайдера. Таблица: 
default via 109.x.x.4 dev eth0
8.8.4.4 via 109.x.x.4 dev eth0
10.10.10.2 dev tun0  proto kernel  scope link  src 10.10.10.1
85.x.x.2/30 dev eth2  proto kernel  scope link  src 85.x.x.4
109.x.x.128/25 dev eth0  proto kernel  scope link  src 109.x.x.6
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1
192.168.2.0/24 via 10.10.10.2 dev tun0
Проверяем: 
root@Gate:~# traceroute -ns 109.х.х.6 -I 8.8.4.4
traceroute to 8.8.4.4 (8.8.4.4), 30 hops max, 60 byte packets
 1  109.х.х.4  0.708 ms  0.924 ms  1.052 ms
 2  10.х.х.х  0.560 ms  0.724 ms  0.884 ms
...................................................
 8  216.239.62.153  36.263 ms  36.277 ms  36.266 ms
 9  * * *
10  8.8.4.4  34.983 ms  34.969 ms  34.988 ms
root@Gate:~# traceroute -ns 85.х.х.4 -I 8.8.4.4
traceroute to 8.8.4.4 (8.8.4.4), 30 hops max, 60 byte packets
 1  85.х.х.3  1.198 ms  1.513 ms  1.770 ms
 2  212.х.х.х  25.002 ms  26.171 ms  27.325 ms
 3  85.х.х.х  32.086 ms  32.456 ms  33.451 ms
...................................................
 9  66.249.95.39  56.933 ms  56.005 ms  61.382 ms
10  216.239.49.234  60.212 ms  59.473 ms  60.550 ms
11  209.85.248.101  61.422 ms  61.793 ms  61.798 ms
12  * * *
13  8.8.4.4  57.426 ms  56.455 ms  59.593 ms
И почему-то не работает, хотя должно и до этого точно работало. Второй вопрос касается iptables, заворота трафика в локальной сети. Выложу сразу правила может так понятнее будет, что я пытаюсь сказать. 
-A PREROUTING -s 192.168.0.0/24 -d 109.х.х.х/32 -p tcp -m tcp --dport 1234 -j DNAT --to-destination 192.168.0.2:3389
-A PREROUTING -s 192.168.0.0/24 -d 85.х.х.х/32 -p tcp -m tcp --dport 1234 -j DNAT --to-destination 192.168.0.2:3389
-A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.2/32 -p tcp -m tcp --dport 1234 -j SNAT --to-source 109.х.х.х
И здесь у нас все наоборот, работает, хоть не должно. Ну или я не понимаю, почему работает. Как я это понимаю: все запросы с локальной сети по порту 1234 на внешний IP 109.х.х.х мы заворачиваем на RDP сервер в локальной сети. Тоже самое делаем для второго внешнего IP. Вопросов нет, все понятно. Что происходит в 3-м правиле? Мы меняем адрес источника с адреса RDP сервера на наш внешний IP 109.х.х.х - на тот куда клиент посылал запрос и откуда ждет ответ. Все отлично и понятно. Но для второго внешнего IP я такую процедуру не делаю и если клиент посылает запрос на 85.х.х.х он оттуда и должен ждать ответ, а получает его от 109.х.х.х. Значит работать не должно, но все работает. Не то что бы я против, но просто хочу разобраться, уже совсем запутался. Скорей всего я до конца не понимаю правила POSTROUTING ну или дело в чем то другом. Буду благодарен, если натолкнете на мысль в чем тут дело и что почитать. Спасибо.

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

п.1 - У тебя в правилах маршрутизации 

0:      from all lookup local
32762:  from all fwmark 0xb lookup 102
32763:  from all fwmark 0xa lookup 101
32764:  from 109.x.x.6 lookup 102
32765:  from 85.x.x.4 lookup 101
32766:  from all lookup main
32767:  from all lookup default
«ip ro add 8.8.4.4/32 via 109.x.x.х» - добавляет в main. Дальше сам догадаешься ?

В larc привели ОЧЕНЬ НЕХОРОШИЙ ПРИМЕР, который все копируют не задумываясь, а зря, т.к. там лежат грабли почти на всю ширину дороги.

Правильная реализация (легко масштабируемаяч для числа isp > 2):

  • перенос dgw из main в default
  • в доп. таблицах только dgw (без дублирования прямых маршрутов)
  • правила: 
    0:     from all lookup local
1000:  from all lookup main
2000:  from all fwmark 0xb lookup 102
2100:  from all fwmark 0xa lookup 101
2200:  from 109.x.x.6 lookup 102
2300:  from 85.x.x.4 lookup 101
2400:  from all lookup default
32766:  from all lookup main
32767:  from all lookup default

main нужно смотреть сразу после local - это решает все проблемы с прямыми маршрутами и статическими маршрутами (особенно если локалка больше одной сети) и специфическими статическими маршрутами (особенно если канал является туннелем).

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

Про snat/dnat не читал.

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

Ага, теперь то все стало понятно. Я пока разбирался сделал так 

ip ro add 8.8.4.4/32 via 109.x.x.4 table 99
ip rule add from 85.x.x.4 table 99 priority 99
Но Ваш вариант мне нравится намного больше. Итоговый скрипт получился следующим: 
/sbin/ip ro del default via 109.x.x.4 table main
/sbin/ip ro add default via 109.x.x.4 table default
/sbin/ip ro add 8.8.4.4/32 via 109.x.x.4
/sbin/ip ro add default via 109.x.x.4 table 101
/sbin/ip ro add default via 85.x.x.3 table 102
/sbin/ip rule add from all table main priority 1000
/sbin/ip rule add fwmark 10 lookup 101 priority 2000
/sbin/ip rule add fwmark 11 lookup 102 priority 2100
/sbin/ip rule add from 109.x.x.6 table 101 priority 2200
/sbin/ip rule add from 85.x.x.4 table 102 priority 2300
/sbin/ip rule add from all table default priority 2400
Проверил, все отлично работает. vel, еще раз большое спасибо за помощь!

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

Неделю тестирую. Наблюдаю непонятную ситуацию. Сразу после загрузки все работает отлично. Через несколько часов пропадает доступ из вне на 2-го провайдера. С самого сервера тоже весь трафик идет только через первого. Если добавить 

/sbin/ip rule add from 85.x.x.4 table 102
в правила перед main 
0:      from all lookup local
999:    from 85.x.x.4 lookup 102
1000:   from all lookup main
..........
Все начинает работать, кроме статических маршрутов. Если перегрузить сервер, то опять несколько часов все отлично. Не сталкивались с таким?

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

Нашел причину странного поведения. В таблице main была запись 

default via 109.x.x.4 dev eth0
Но откуда она там берется, если сразу после загрузки удаляется оттуда скриптом, что приведен 2-мя сообщениями выше?

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

Разобрался в чем дело. Это скрипт автопереключения на резервный канал в случаи, если основной лежит, добавлял этот маршрут в main. Переписал его немного, теперь вроде все отлично.

seven
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Проблема с установкой VLC
General
Почему линуксовые torrent-клиенты плохо ищут пиры? →