lan-viper Опубликовано 23 октября, 2011 (изменено) · Жалоба Привет! Столкнулся с проблемой - не могу заставить маршрутизатор направлять свои собственные пакеты через второго резервного провайдера. Конфигурация следующая (реальные имена и адреса изменены): 1.1.1.0/31 - сеть основного провайдера на интерфейсе eth2, который по умолчанию маршрутизируется через таблицу main P2 - имя второго (резервного канала) 2.2.2.0/30 - сеть у P2 на интерфейсе eth1 vlan1 - локальная сеть 10.0.0.0/24, tun0 - openvpn 10.8.0.0/24 root@nas:~# cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 101 P2 root@nas:~# ip route show table P2 2.2.2.0/30 dev eth1 scope link src 2.2.2.2 10.0.0.0/24 dev vlan1 scope link 10.8.0.0/24 dev tun0 scope link 127.0.0.0/8 dev lo scope link default via 2.2.2.1 dev eth1 root@nas:~# ip rule list 0: from all lookup local 32761: from 10.0.0.4 lookup P2 32762: from 10.0.0.5 lookup P2 32765: from 2.2.2.2 lookup P2 32766: from all lookup main 32767: from all lookup default , где 10.0.0.4 и 10.0.0.5 - сервера, NAT-ящиеся через P2 root@nas:~# ip route show table main 10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1 1.1.1.0/31 dev eth2 proto kernel scope link src 1.1.1.1 10.8.0.4/30 via 10.8.0.2 dev tun0 10.0.0.0/24 dev vlan1 proto kernel scope link src 10.0.0.2 10.8.0.0/24 via 10.8.0.2 dev tun0 10.105.0.0/16 via 10.0.0.254 dev vlan1 default via 1.1.1.0 dev eth2 Особенность данной конфигурации в том, что я не делал отдельную таблицу для основного аплинка, т.к. всё и так прекрасно работает через настройки по умолчанию в системной таблице main. Возможно в этом моменте я не прав и надо всё-таки настраивать их отдельно, но почти всё работает так, как мне нужно, за исключением собственных сетевых пакетов маршрутизатора. Вот примеры неработоспособности: root@nas:~# ping -n -I eth1 ya.ru PING ya.ru (77.88.21.3) from 2.2.2.2 eth1: 56(84) bytes of data. From 2.2.2.2 icmp_seq=2 Destination Host Unreachable From 2.2.2.2 icmp_seq=3 Destination Host Unreachable From 2.2.2.2 icmp_seq=4 Destination Host Unreachable ^C --- ya.ru ping statistics --- 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2999ms pipe 3 при этом в tcpdump root@nas:~# tcpdump -i lo icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes 11:35:34.891415 IP 2.2.2.2 > 2.2.2.2: ICMP host www.yandex.ru unreachable, length 92 11:35:34.891423 IP 2.2.2.2 > 2.2.2.2: ICMP host www.yandex.ru unreachable, length 92 11:35:34.891428 IP 2.2.2.2 > 2.2.2.2: ICMP host www.yandex.ru unreachable, length 92 ^C 3 packets captured 9 packets received by filter 0 packets dropped by kernel Ткните пальцем, в каком месте я лоханулся ))). Почему пакеты не бегают через второго провайдера, при пинге с явным указанием интерфейса. PS К серверу извне через второго провайдера я спокойно подключаюсь по ssh на ip 2.2.2.2 PPS Если настроить провайдеров ровно наоборот, т.е. P2 сделать основным, а P1 через доп. таблицу, то эта элементарная проверка пингом работает... Изменено 23 октября, 2011 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 24 октября, 2011 (изменено) · Жалоба маркируем iptables + mark маршрутизируем ip rule по критерию fwmark Изменено 24 октября, 2011 пользователем Lynx10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 24 октября, 2011 · Жалоба Lynx10, мне кажется это лишним. Я бы хотел сначала разобраться, почему не работает в данной конфе, а способ маршрутизации маркированных пакетов считаю альтернативным. Ещё одну странность заметил, traceroute работает нормально root@nas:~# traceroute -i eth1 ya.ru traceroute to ya.ru (213.180.204.3), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * ae-8.m7-ar4.msk.ip.rostelecom.ru (87.226.133.178) 80.974 ms 80.976 ms 6 79.133.94.58 (79.133.94.58) 78.202 ms 54.937 ms 52.701 ms 7 hummer-vlan601.yandex.net (77.88.16.60) 45.183 ms 35.669 ms 47.924 ms 8 * * * 9 www.yandex.ru (213.180.204.3) 65.510 ms 63.986 ms 64.925 ms Да и web сервер нормально отдаёт странички через P2, странно всё это. Только один ping не работает... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 24 октября, 2011 · Жалоба В принципе сам себе проблему придумал. Если P1 отвалится, то есть несколько способов заставить пакеты маршрутизатора ходить через P2: начиная от элементарной смены default gateway до балансировки, описанной в lartc. Сейчас маршрутизатор доступен по двум провайдерам, но я хотел, что-бы сам маршрутизатор ходил через P2, на который не стоит default gateway. Тут видать и вправду только маркировка поможет. PS Такие поверхностные рассуждения у меня от того, что пока слабо понимаю внутренние механизмы маршрутизации пакетов в ядре линукса Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 24 октября, 2011 · Жалоба Такие поверхностные рассуждения у меня от того, что пока слабо понимаю внутренние механизмы маршрутизации пакетов в ядре линукса http://upload.wikimedia.org/wikipedia/ru/a/ad/Netfilter-diagram-rus.png http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 24 октября, 2011 · Жалоба Я себе вторую схемку даже распечатал на цветном A3, заламинировал - получилось просто заглядение :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 25 октября, 2011 (изменено) · Жалоба s.lobanov, спасибо за схемки, особенно за вторую, такую я ещё не видел. Но, с iptables (Netfilter) у меня проблем с пониманием нет. Я имел ввиду понимание роутинга (на этих схемках квадратик с надписью routing decision), т.е. какой алгоритм выбора таблицы маршрутизации, в какой последовательности просматриваются маршруты в таблице, да прочие тонкости :) Вот к примеру во всех статьях инета, что находятся яндексом и гуглом, создают ДВЕ таблицы маршрутизации (для ядра фактически их получается ТРИ) и таблица main остаётся в стороне. Почему все на неё так резко забили? Боятся отойти в сторону от незыблимого мануала lartc и делают всё в точности как там? Изменено 25 октября, 2011 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 25 октября, 2011 · Жалоба lan-viper А что там в понимании роутинга? Есть ip rule и ip route, там вроде бы всё прозрачно. Ну есть всякие мелкие тонкости, что, например, с ядра 2.6.33 сняли ограничения на редактирования таблицы правил(ip rule). И если уж на то пошло, то получается 4 таблицы, кроме main ещё есть local, которая используется Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 25 октября, 2011 (изменено) · Жалоба И если уж на то пошло, то получается 4 таблицы, кроме main ещё есть local, которая используетсяНе, моя мысль неправильно истолкована. Я имел ввиду создание двух НОВЫХ таблиц, помимо local, main, default - P1 и P2. Такое практикуется почему-то во всех руководствах, хотя достаточно создать одну новую для второго аплинка, а первого аплинка не трогать, оставляя в таблице main. Получаются те же яйца, только в профиль. Изменено 25 октября, 2011 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...