URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 90944
[ Назад ]
Исходное сообщение
"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено outloader , 14-Фев-11 21:41 
Знаю, звучит избито. Форум смотрел, статьи читал. Но, все равно, возникла проблема!

Имеем: шлюз с тремя сетевыми интерфейсами на openSUSE linux 11.3. Два внешних смотрят в интернет (два разных провайдера). Внутренний смотрит в локальную сеть. Также на шлюзе поднят squid (v3.0.STABLE25) и suseFirewall. Первый провайдер выдает адреса через DHCP, у второго - внешний IP.
Необходимо: http-запросы из локалки в зависимости от ip-шников юзеров посылать через squid либо к одному провайдеру, либо к другому.
Ознакомившись с темой принял решение делать маршрутизацию через iproute.
Для этого создал две дополнительные таблицы маршрутизации provider_1 и provider_2. Прописал таблицы в /etc/iproute2/rt_tables. Указал маршруты к соответствующим сетям (ip route add), указал правила для маршрутизации (ip rule add), написал скрипт в автозагрузку (/etc/init.d/after.local). В squid'е прописал acl и указал "tcp_outgoing_address" и "server_persistent_connections off" как и рекомендуют. В suseFirewall'е включил роутинг и маскарадинг.
Но… При попытке обращения к любому сайту через любого провайдера выдается сообщение что не удается определить ip-адрес источника:
===========================
"ERROR
The requested URL could not be retrieved

The following error was encountered while trying to retrieve the URL: http://www.google.ru/

Unable to determine IP address from host name "www.google.ru"

The DNS server returned:
Server Failure: The name server was unable to process this query.
==========================

Допустим, у нас такие сетевые параметры:
Провайдер 1 (DHCP), eth1:
IP: 10.8.5.14
Mask: 255.255.0.0
Gate: 10.8.0.1
DNS1: 10.8.0.101
DNS2: 192.168.10.101
DNS3: 192.168.10.102

Провайдер 2 (Manual), eth2:
IP: 80.242.156.56
Mask: 255.255.255.252
Gate: 80.247.156.55
DNS1: 192.8.128.130
DNS2: 192.8.128.137

Локальная сеть, eth0:
IP: 192.168.0.10
Mask: 255.255.255.0

Содержимое скрипта (адаптировано для перезапуска):
==========================
#!/bin/sh
#Manual policy routing for 2 internet providers
#
ip route flush table provider_1
ip route flush table provider_2
#
ip route add default via 10.8.0.1 table provider_1
ip route add default via 80.242.156.55 table provider_2
#
ip route add 10.8.0.0/16 dev eth1 src 10.8.5.14 table provider_1
ip route add 80.242.156.56/30 dev eth2 src 80.242.156.56 table provider_2
#
ip route add 195.8.128.130 dev eth2
ip route add 195.8.128.137 dev eth2
ip route add 10.8.0.101 dev eth1
ip route add 192.168.10.101 dev eth1
ip route add 192.168.10.102 dev eth1
#
ip route add 192.168.0.0/24 dev eth0 table provider_1
ip route add 192.168.0.0/24 dev eth0 table provider_2
#
ip rule del table provider_1
ip rule del table provider_2
#
ip rule add from 10.8.5.14 lookup provider_1
ip rule add from 80.242.156.56 lookup provider_2
#
ip route flush cache
==========================

В squid'е прописано:
==========================
http_port 192.168.0.10:3128

acl prov_1 src 192.168.0.15-192.168.0.32
acl prov_1 src 192.168.0.44-192.168.0.128

tcp_outgoing_address 10.8.5.14 prov_1
tcp_outgoing_address 80.242.156.56 prov_2

server_persistent_connections off
==========================

В suseFirewall'е прописано:
FW_ROUTE="yes"
FW_MASQUERADE="yes"
FW_MASQ_DEV="zone:ext"
FW_MASQ_NETS="192.168.0.0/24"

Вывод route -n:
Kernel IP routing table
Destination        Gateway    Genmask             Flags Metric Ref    Use     Iface
80.242.156.56        0.0.0.0             255.255.255.252     U         0          0            0     eth2
192.168.0.0        0.0.0.0             255.255.255.0       U         0          0            0     eth0
10.8.0.0                0.0.0.0             255.255.0.0         U         0          0            0     eth1
169.254.0.0         0.0.0.0             255.255.0.0         U         0          0            0     eth0
127.0.0.0               0.0.0.0             255.0.0.0               U         0          0            0     lo

Вывод ip ro:
80.242.156.56/30 dev eth2  proto kernel  scope link  src 80.242.156.56
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.10
10.8.0.0/16 dev eth1  proto kernel  scope link  src 10.8.5.14
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link

Вывод ip ru:
0:    from all lookup local
32764:    from 80.242.156.56 lookup provider_metrocom
32765:    from 10.8.5.14 lookup provider_lenreg
32766:    from all lookup main
32767:    from all lookup default

Не могу понять в чем дело. Люди пишут у них все работает! Конфиги, вроде, теже у всех. Переписывал скрипт с легкими вариациями на тему "ip route add 127.0.0.0/8 dev lo table provider_1" [provider_2] – добавление локального маршрута в таблицу первого/второго провайдера; "ip route add 195.8.128.130 dev eth2 table provider_2", " ip route add 10.8.0.101 dev eth1 table provider_1" – помещал DNS'ы из основной таблицы main в таблицы провайдеров. Но это ничего не дает.
В логах файрвола ничего криминального не обнаружил, дропов нет (даже при FW_LOG_DROP_ALL="yes"). На всякий случай пробовал отключать: rcSuSEfirewall2 stop – без результата.
Что самое интересное: по отдельности каналы работают. Т.е. если вставить один кабель в сетевуху и указать соответствующий дефолтный шлюз в таблице main (именно в main!!!) – все живет прекрасно! Такое впечатление, что не обрабатываются дополнительные таблицы маршрутизации provider_1 и provider_2 (или криво обрабатываются как-то...).
Судя по ругани браузера - сквид не может определить DNS-сервера. Кстати, в /etc/resolve.conf nameserver'ы прописаны корректно и сквид их оттуда считывает (по логам). В логах сквида видим только (при squid -k parse): "WARNING: failed to resolve 192.168.0.10 to a fully qualified hostname", но с этим, по идее, должно все работать (можно вылечить с помощью visible_hostname). Пробовал подключаться и без сквида.
Нашел также что-то про "rp_filter", но делу это не помогло.
Может в сусе как-то по другому iproute реализован или работа с таблицами иначе сделана?
Приветствуется любая помощь сообщества!

Содержание
Сообщения в этом обсуждении
"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено StreSS.t , 14-Фев-11 23:11 
Ну почти все правильно
Вы прописали куда должны уходить пакеты от провайдеров.
Таблицы есть, а вот как туда попадать пакеты?

Добавляем правило маркировки (здесь именно IP, с dev у меня не завелось)


iptables -t mangle -A OUTPUT -s 192.168.1.2 -j MARK --set-mark 2

Добавляем дефолтный маршрут для таблицы WIMAX (это у вас уже есть)
 
ip route add default via 192.168.1.1 dev eth2 table WIMAX

Добавляем правило работы с метками

ip rule add from all fwmark 2 lookup WIMAX

И конечно же SNAT/MASQUERADE

После этого ping -I eth0 8.8.8.8 должно выполняться нормально.
Если нет то смотрите tcpdump -i eth0 -n host 8.8.8.8 какой IP подставляется.

На объективность метода не претендую
Если нужна балансировка то это в LARTC (там пример есть).

"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено PavelR , 15-Фев-11 06:16 
> Ну почти все правильно
> Вы прописали куда должны уходить пакеты от провайдеров.
> Таблицы есть, а вот как туда попадать пакеты?

Вообще начнем с того, что до этой проблемы топикстартер еще не дошел. Эта проблема возникнет, когда он натить локалки начнет... Тогда и решит, маркировкой это делать или доп. правилами.

> Таблицы есть, а вот как туда попадать пакеты?

Как туда должны попадать пакеты - тоже известно:

Вывод ip ru:
0:    from all lookup local
32764:    from 80.242.156.56 lookup provider_metrocom
32765:    from 10.8.5.14 lookup provider_lenreg

Вы маленько не обратили внимание на проблему:

>Судя по ругани браузера - сквид не может определить DNS-сервера.

И это ведь так и есть :-)

>Т.е. если вставить один кабель в сетевуху и указать соответствующий дефолтный шлюз в
>таблице main (именно в main!!!)

Ну дык - ведь вы его нигде не указали :-) Поэтому и не работает. По какому каналу должен работать сам сервер, инициированные им соединения, в том числе и DNS-запросы ?

Добавьте указание дефолтного шлюза для сервера, и это будет решением.


"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено PavelR , 15-Фев-11 06:17 

>>Т.е. если вставить один кабель в сетевуху и указать соответствующий дефолтный шлюз в
>>таблице main (именно в main!!!)

Можно еще в таблице default указать :-)

>Вывод ip ru:
>0:    from all lookup local
>32764:    from 80.242.156.56 lookup provider_metrocom
>32765:    from 10.8.5.14 lookup provider_lenreg
>32766:    from all lookup main
>32767:    from all lookup default

Кагбэ поймите для себя, что это последовательность поиска маршрута, как нашел - так и закончил поиск )

"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено outloader , 15-Фев-11 15:15 
> Ну дык - ведь вы его нигде не указали :-) Поэтому и
> не работает. По какому каналу должен работать сам сервер, инициированные им
> соединения, в том числе и DNS-запросы ?
> Добавьте указание дефолтного шлюза для сервера, и это будет решением.

При добавлении дефолтного шлюза ситуация изменилась. Теперь работает так: если дефолтный шлюз и "tcp_outgoing_address" относятся к одному интерфейсу, то инет есть. Если outgoing-адрес меняется - dns не резолвится!
По идее какая разница откуда брать dns? Может же сервер dns'ы резолвить через одного провайдера (дефолтный шлюз), а tcp-запросы пересылать через другого (шлюз из доп. таблицы по "tcp_outgoing_address")... Или я чего-то не понимаю...?

"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено PavelR , 15-Фев-11 16:45 
> По идее какая разница откуда брать dns? Может же сервер dns'ы резолвить
> через одного провайдера (дефолтный шлюз), а tcp-запросы пересылать через другого (шлюз
> из доп. таблицы по "tcp_outgoing_address")...

Как-бы да, так и ожидалось.

Надо смотреть на полный вывод "ip ru sh" и "ip ro" по всем таблицам.
Без этих данных - разговаривать собственно не о чем...

;-)

"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено outloader , 16-Фев-11 09:45 
> Надо смотреть на полный вывод "ip ru sh" и "ip ro" по
> всем таблицам.
> Без этих данных - разговаривать собственно не о чем...
> ;-)

Вывод ip ru:
0:    from all lookup local
32764:    from 80.247.156.56 lookup provider_1
32765:    from 10.8.5.14 lookup provider_2
32766:    from all lookup main
32767:    from all lookup default

Вывод ip ro по таблицам:
local:
broadcast 192.168.0.255 dev eth0  proto kernel  scope link  src 192.168.0.10
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
local 192.168.0.10 dev eth0  proto kernel  scope host  src 192.168.0.10
broadcast 10.8.0.0 dev eth1  proto kernel  scope link  src 10.8.5.14
broadcast 80.247.156.56 dev eth2  proto kernel  scope link  src 80.247.156.56
local 10.8.5.14 dev eth1  proto kernel  scope host  src 10.8.5.14
local 80.247.156.56 dev eth2  proto kernel  scope host  src 80.247.156.56  
broadcast 192.168.0.0 dev eth0  proto kernel  scope link  src 192.168.0.10
broadcast 80.247.156.56 dev eth2  proto kernel  scope link  src 80.247.156.56
broadcast 10.8.255.255 dev eth1  proto kernel  scope link  src 10.8.5.14
local 127.0.0.2 dev lo  proto kernel  scope host  src 127.0.0.1
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1

provider_1:
192.168.0.0/24 dev eth0  scope link
10.8.0.0/16 dev eth1  scope link  src 10.8.5.14
127.0.0.0/8 dev lo  scope link
default via 10.8.0.1 dev eth1

provider_2:
80.247.156.56/30 dev eth2  scope link  src 80.247.156.56
192.168.0.0/24 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 80.247.156.55 dev eth2

main:
80.247.156.56/30 dev eth2  proto kernel  scope link  src 80.247.156.56
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.10
10.8.0.0/16 dev eth1  proto kernel  scope link  src 10.8.5.14
169.254.0.0/16 dev eth0  scope link
127.0.0.0/8 dev lo  scope link
default via 10.8.0.1 dev eth1

В default ничего не заносил.

"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено outloader , 17-Фев-11 13:06 
Кажется дело тронулось! В сквиде ставлю "udp_outgoing_address 80.242.156.56" и все работает! Т.о. сквид берет dns'ы из сети второго провайдера. Выходит первый провайдер как-то хитро блокирует dns-запросы (до этого шло через дефолтный шлюз первого провайдера). Продолжаю разбираться.
"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено PavelR , 18-Фев-11 07:47 
> Кажется дело тронулось! В сквиде ставлю "udp_outgoing_address 80.242.156.56" и все работает!
> Т.о. сквид берет dns'ы из сети второго провайдера. Выходит первый провайдер
> как-то хитро блокирует dns-запросы (до этого шло через дефолтный шлюз первого
> провайдера). Продолжаю разбираться.

Добавьте маршруты к DNS-серверам через правильного провайдера (в таблицу main, можно обычными командами route). для повышения надежности мы хотим использовать DNS-ы обеих провайдеров, верно ?  Маршруты к ним всегда должны идти через своего провайдера, поскольку "не своим клиентам" обычно рекурсивный DNS не предоставляют.

"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено StreSS.t , 15-Фев-11 16:12 
Согласился бы с Вами. Если бы не пара экспериментов на Debian "Squeeze".
Года полтора назад делал все по руководству LARTC и  все работало.
Недавно делал роутер для одной компании и точно такие же настройки уже не прокатили (настройки переносил один в один).
Создаю таблицы и добавляю default для них. (в первой 10.10.1.1, во второй 192.168.1.1, моя сеть 192.168.0.0/24)
В таблице main, в качестве дефолтного стоит 10.10.1.1
делаю ping -i eth0 8.8.8.8 (это первый провайдер со шлюзом 10.10.1.1) - все прекрасно работает.
Делаю ping -i eth1 8.8.8.8 (второй интерфейс со шлюзом 192.168.1.1) - нет ответов, и глядя tcpdump -i eth0 -n host 8.8.8.8 (да, да нахожу их именно на первом интерфейсе).
Сам долго не мог понять как это происходит но факт на лицо причем даже не применяются политики SNAT.
"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено PavelR , 15-Фев-11 16:43 
>[оверквотинг удален]
> Создаю таблицы и добавляю default для них. (в первой 10.10.1.1, во второй
> 192.168.1.1, моя сеть 192.168.0.0/24)
> В таблице main, в качестве дефолтного стоит 10.10.1.1
> делаю ping -i eth0 8.8.8.8 (это первый провайдер со шлюзом 10.10.1.1) -
> все прекрасно работает.
> Делаю ping -i eth1 8.8.8.8 (второй интерфейс со шлюзом 192.168.1.1) - нет
> ответов, и глядя tcpdump -i eth0 -n host 8.8.8.8 (да, да
> нахожу их именно на первом интерфейсе).
> Сам долго не мог понять как это происходит но факт на лицо
> причем даже не применяются политики SNAT.

всему есть объяснение. В Вашем случае надо смотреть на полный вывод "ip ru sh" и "ip ro" по всем таблицам. Без этих данных - разговаривать собственно не о чем...

"Проблемы маршрутизации (3 сети, 2 пров.)"
Отправлено out_t , 18-Фев-11 16:28 
для тех у кого работало - задача усложняется: оба линка от одного провайдера, но на одном статика, а на втором dhcp. провайдер ессно юзает нат и имеет в свою очередь тоже 2 аплинка...)