Комментарии 46
Прекрасная статья. Интересно
Мне вот больше интересна статистика: 18 плюсов и 30 человек добавили статью в избранное. Это уже какой то верх цинизма %) Взять себе возьму, но спасибо не скажу! =)
У некоторых не хватает кармы, чтобы поставить плюс, но в избранное добавить можно.
Я, например, добавил в избранное, так как скоро предвидится подобная проблема и материал данной статьи может оказаться полезен. Но саму статью сейчас полностью не читал (за ненадобностью), и оценить ее качество не могу.
Благодарю!
НЛО прилетело и опубликовало эту надпись здесь
Ответ с того же интерфейса
Вместо
# iptables -t mangle -A INPUT -i ppp0 -j CONNMARK --set-mark 0x1
можно использовать всё тот же iproute2:
ip rule add dev ppp0 table isp1
либо
ip rule add from s.s.s.s table isp1
P.S. habrahabr.ru/blogs/sysadm/30076/ :)
К сожалению, вариант через ip rule from/dev вместо CONNMARK не работает совместно с управлением роутингом через fwmark. Т.е. если у Вас правила роутинга вот такие:
То всё будет работать без CONNMARK, но Вы не сможете управлять роутингом конкретных соединений — к примеру, нельзя будет настроить доступ к сайту со статистикой второго провайдера через второй канал. Дело в том, что если сделать правила для fwmark более приоритетными, чем правила ответа через тот же интерфейс:
То возникнет старая проблема — если с IP сервера статистики второго провайдера будет отправлен запрос на мой веб-сайт на s.s.s.s (канал первого провайдера), то из-за высокого приоритета правил fwmark ответ серверу статистики с моего веб-сайта уйдёт через канал второго провайдера, с IP d.d.d.d.
Если сделать эти правила менее приоритетными:
То, вспоминая про первый этап «Routing Decision» для локальных исходящих пакетов, получится, что когда с моего сервера отправляется любой запрос (например, на сервер статистики второго провайдера), для него вычисляется исходящий интерфейс (и исходный IP!), причём вычисляется он правилами по умолчанию, а там двойной default route — так что будет случайно выбран один из провайдеров. И это, с вероятностью 8 к 2, окажется первый провайдер (и, соответственно, исходящий IP для этого пакета будет выставлен ядром в s.s.s.s). Далее, несмотря на то, что я добавлю к этому пакету в файрволе fwmark 0x2, во время второго этапа «Routing Decision» сработают более приоритетные правила по from, а не по fwmark — а from у нашего пакета с вероятностью 8 к 2 это s.s.s.s, так что пакет на сервер статистики второго провайдера скорее всего уйдёт через канал первого провайдера.
Если погуглить, то в инете чаще всего встречается именно предложенное Вами решение через ip rule from, но нигде не описаны ограничения этого подхода.
# ip rule list
0: from all lookup local
200: from v.v.v.v lookup vpn
201: from s.s.s.s lookup isp1
202: from s.s.s.s lookup isp2
32766: from all lookup main
32767: from all lookup default
То всё будет работать без CONNMARK, но Вы не сможете управлять роутингом конкретных соединений — к примеру, нельзя будет настроить доступ к сайту со статистикой второго провайдера через второй канал. Дело в том, что если сделать правила для fwmark более приоритетными, чем правила ответа через тот же интерфейс:
# ip rule list
0: from all lookup local
100: from all fwmark 0x4/0x4 lookup vpn
101: from all fwmark 0x1/0x1 lookup velton
102: from all fwmark 0x2/0x2 lookup ukrtel
200: from v.v.v.v lookup vpn
201: from s.s.s.s lookup isp1
202: from s.s.s.s lookup isp2
32766: from all lookup main
32767: from all lookup default
То возникнет старая проблема — если с IP сервера статистики второго провайдера будет отправлен запрос на мой веб-сайт на s.s.s.s (канал первого провайдера), то из-за высокого приоритета правил fwmark ответ серверу статистики с моего веб-сайта уйдёт через канал второго провайдера, с IP d.d.d.d.
Если сделать эти правила менее приоритетными:
# ip rule list
0: from all lookup local
200: from v.v.v.v lookup vpn
201: from s.s.s.s lookup isp1
202: from s.s.s.s lookup isp2
300: from all fwmark 0x4/0x4 lookup vpn
301: from all fwmark 0x1/0x1 lookup velton
302: from all fwmark 0x2/0x2 lookup ukrtel
32766: from all lookup main
32767: from all lookup default
То, вспоминая про первый этап «Routing Decision» для локальных исходящих пакетов, получится, что когда с моего сервера отправляется любой запрос (например, на сервер статистики второго провайдера), для него вычисляется исходящий интерфейс (и исходный IP!), причём вычисляется он правилами по умолчанию, а там двойной default route — так что будет случайно выбран один из провайдеров. И это, с вероятностью 8 к 2, окажется первый провайдер (и, соответственно, исходящий IP для этого пакета будет выставлен ядром в s.s.s.s). Далее, несмотря на то, что я добавлю к этому пакету в файрволе fwmark 0x2, во время второго этапа «Routing Decision» сработают более приоритетные правила по from, а не по fwmark — а from у нашего пакета с вероятностью 8 к 2 это s.s.s.s, так что пакет на сервер статистики второго провайдера скорее всего уйдёт через канал первого провайдера.
Если погуглить, то в инете чаще всего встречается именно предложенное Вами решение через ip rule from, но нигде не описаны ограничения этого подхода.
Имея 2 адсл-модема, поднимать 2 pppoe соединения бриджем — нелогично.
Почему?
2 лишних интерфейса, у которых к тому же траблы с нумерацией, лишние if-up-down скрипты, лишние проверки доступности связи. Некритично, но и удобств не доставляет. Особенно при необходимости настройки гибкой маршрутизации с автоматическим переключением каналов и их мониторингом.
Траблы с нумерацией отсутствуют в принципе: параметр unit для pppd позволяет указать номер ppp-интерфейса поднимаемого этим pppd, так что мой канал второго провайдера всегда поднимается как ppp1, даже если интерфейса ppp0 в системе сейчас нет.
Проверки доступности связи отсутствуют — хватает переключения default route в ppp up/down скриптах. А, собственно, как Вы реализуете автоматическое переключение с одного канала на другой, если модемы в режиме router, а не bridge, и ведущие к ним eth0 и eth1 всегда доступны? Пинговать и, опять же, ручками менять default route? По-моему, up/down скрипты проще и эффективнее.
Далее, у меня всё-таки сервер, на котором поднято немало разных сервисов, и настраивать ручками форвардинг всех этих портов на модеме я не жажду.
Кроме того, я из соображений безопасности предпочитаю, чтобы черви и хакеры из инета долбились в мой, регулярно обновляемый, Hardened Gentoo, а не в древний линух на дешёвых ADSL модемах. В «Хакере» как раз недавно была статья на тему, «Троян в роутере», так что количество атак на модемы только увеличится.
Ну и последнее — у модемов в режиме router нередко возникают проблемы под большой нагрузкой, вроде торрентов — соединений много, трафик высокий, а проц слабый, памяти мало, и баги в прошивке. В режиме bridge баги в прошивке модема и его мощность уже не имеют никакого значения.
Проверки доступности связи отсутствуют — хватает переключения default route в ppp up/down скриптах. А, собственно, как Вы реализуете автоматическое переключение с одного канала на другой, если модемы в режиме router, а не bridge, и ведущие к ним eth0 и eth1 всегда доступны? Пинговать и, опять же, ручками менять default route? По-моему, up/down скрипты проще и эффективнее.
Далее, у меня всё-таки сервер, на котором поднято немало разных сервисов, и настраивать ручками форвардинг всех этих портов на модеме я не жажду.
Кроме того, я из соображений безопасности предпочитаю, чтобы черви и хакеры из инета долбились в мой, регулярно обновляемый, Hardened Gentoo, а не в древний линух на дешёвых ADSL модемах. В «Хакере» как раз недавно была статья на тему, «Троян в роутере», так что количество атак на модемы только увеличится.
Ну и последнее — у модемов в режиме router нередко возникают проблемы под большой нагрузкой, вроде торрентов — соединений много, трафик высокий, а проц слабый, памяти мало, и баги в прошивке. В режиме bridge баги в прошивке модема и его мощность уже не имеют никакого значения.
Параметр unit задает не номер интерфейса, а точку отсчета нумерации интерфейса. Так что канал второго провайдера запросто может подняться как ppp2.
В кроне скрипт проверяет доступность ближайшего шлюза провайдера и dns гугла по ip. В случае проблем срабатывают скрипты, меняющие роутинг. На pppoe случается такое, что и интерфейс есть (если бриджем настроено), и вроде все хорошо, а связи на самом деле нет.
На модемах я dmz выставляю — слишком слабая начинка, чтобы на нее полагаться.
С dmz черви будут долбиться в генту :)
С последним согласен, хуавей этим грешит.
В кроне скрипт проверяет доступность ближайшего шлюза провайдера и dns гугла по ip. В случае проблем срабатывают скрипты, меняющие роутинг. На pppoe случается такое, что и интерфейс есть (если бриджем настроено), и вроде все хорошо, а связи на самом деле нет.
На модемах я dmz выставляю — слишком слабая начинка, чтобы на нее полагаться.
С dmz черви будут долбиться в генту :)
С последним согласен, хуавей этим грешит.
У канала первого провайдера задан unit 0, у второго unit 1, и они всегда поднимаются под этими номерами. И, кстати, я не вижу в доке фразы про «точку отсчёта».
У меня проблем конкретно с pppoe не было. Бывало, что у самого провайдера лежит инет, это да. Но это случается настолько редко, и длится так недолго, что я даже не всегда это замечаю, и автоматизировать процесс желания пока не возникало. Если всё совсем плохо — я просто ручками кладу соединение к этому провайдеру, несколько часов работаю через оставшийся канал, потом поднимаю второй канал снова. Да, это ручками, но это приходится делать пару раз в год. А вот задержки/потери пингов — вещь гораздо более обычная, так что при автоматическом мониторинге могут быть ложные срабатывания и отрубания вполне рабочих каналов. Например, у меня настроен мониторинг доступности некоторых сайтов по схеме: раз в минуту делается ping -c1, если три минуты подряд сайт не ответил, отправить админу уведомление. Так вот, я эти уведомления получаю достаточно регулярно, хотя сайты в 98% случаев работают (просто пинги теряются).
У меня D-Link 500T и 2500U, на них DMZ вроде бы нет.
У меня проблем конкретно с pppoe не было. Бывало, что у самого провайдера лежит инет, это да. Но это случается настолько редко, и длится так недолго, что я даже не всегда это замечаю, и автоматизировать процесс желания пока не возникало. Если всё совсем плохо — я просто ручками кладу соединение к этому провайдеру, несколько часов работаю через оставшийся канал, потом поднимаю второй канал снова. Да, это ручками, но это приходится делать пару раз в год. А вот задержки/потери пингов — вещь гораздо более обычная, так что при автоматическом мониторинге могут быть ложные срабатывания и отрубания вполне рабочих каналов. Например, у меня настроен мониторинг доступности некоторых сайтов по схеме: раз в минуту делается ping -c1, если три минуты подряд сайт не ответил, отправить админу уведомление. Так вот, я эти уведомления получаю достаточно регулярно, хотя сайты в 98% случаев работают (просто пинги теряются).
У меня D-Link 500T и 2500U, на них DMZ вроде бы нет.
Насчет «точки отсчета» — из личного опыта.
И на 500T и на 2500U есть возможность сделать DMZ. Лично я предпочитаю пользоваться именно установлением соединения на модеме (если это не PPTP), и включать DMZ на сервер. Учитывая скорости DSL-соединений, проблем с падениями соединения практически нет. А вот дефолтный pppd на linux (конкретно на Gentoo) при активном использовании уж очень сильно грузит процессор (на фре такого не наблюдал, кстати). Поэтому, когда я у себя реализовывал подобное, то предпочел разнести функции подключения по модемам. Они напрягутся не сильно, а лишняя производительность на сервере (он же торрентокачалка, он же файлохранилка, он же UPnP/DLNA-сервер и т.д.) никогда не помешает.
Можно наоборот избавиться от eth0 и eth1, оставив ppp интерфейсы. Подключение настраивал через pppoeconfig.
исправьте название топика=)
А какой дистрибутив вы использовали для примера?
У меня Gentoo, но абсолютно всё описанное в статье применимо на любом дистрибутиве. Единственное, что в разных дистрибутивах отличается — это имена файлов, куда необходимо поместить описанные в статье команды: скрипт выполняющийся при загрузке системы (настройка ip rule), файл с правилами файрвола восстанавливающимися при загрузке системы, файлы up/down скриптов для pppd и openvpn.
Огромное спасибо автору. Я как раз вчера пытался выполнить такую-же задачу. Лично у меня не получалось запустить корректно оба vpn соединения. Теперь все работает. Еще раз большое спасибо.
Отличная статья! Тоже интересовался настройкой Linux на работу с двумя каналами, и писал потом по мотивам статью на хабр, правда у меня было не так детально расписано и без картинок. Зато с отказостойчивостью
Спасибо за просвещение!
Отличная статья. Единственное не пойму, что она делает на хабре? Всё-таки более логичней было бы разместить её на opennet. Хабр это же не howto сайт, а новостной…
В любом случае спасибо за старания.
В любом случае спасибо за старания.
:)) Вы не поверите, но хабр уже не торт. Когда-то я пришёл на хабр именно потому, что здесь было много больших и интересных авторских статей, ПЛЮС новости. Вы это время уже не застали. А вчера вечером я долго листал главную хабра в поисках хоть одной статьи из «Linux для всех» — но видел по большей части новости, причём из блогов компаний (особенно яндекса). Оказалось, что статей из «Linux для всех» на главной не было больше недели. Я решил, что это неправильно, и попытался исправить ситуацию в меру своих сил.
Отлично. У меня 2 вопроса.
Может подкините идею как реализовать то же самое, но с одним провайдером и IP шлюза одинаковые.
Мне не хватает пропускной способности одного канала при этом другого провайдера нет и в обозримом будущем не будет. Пока что реализовал двумя модемами в режиме роутера.
И второй вопрос, при использовании nexthop иногда слетает авторизация на сайтах, т.к. меняется маршрут на другой канал. Решали такую задачу?
Может подкините идею как реализовать то же самое, но с одним провайдером и IP шлюза одинаковые.
Мне не хватает пропускной способности одного канала при этом другого провайдера нет и в обозримом будущем не будет. Пока что реализовал двумя модемами в режиме роутера.
И второй вопрос, при использовании nexthop иногда слетает авторизация на сайтах, т.к. меняется маршрут на другой канал. Решали такую задачу?
С двумя каналами к одному провайдеру можно всё делать точно так же. Теоретически, в этом случае можно вообще объединить два канала в один (и делать более точную балансировку нагрузки по пакетам, а не по адресам назначения), но я подозреваю, что это потребует поддержки со стороны провайдера, а он врядли будет ради Вас заморачиваться (впрочем, лично я это никогда не настраивал, так что могу ошибаться).
Задача слетающей авторизации решается добавлением для таких сайтов в файрвол индивидуальных правил, выбирающего для них один из интерфейсов (через fwmark, как обычно) — как я сделал в статье для сайта со статистикой второго провайдера. Если таких сайтов 2-3 штуки, это сделать проще всего. Если их очень много, и правила в файрвол на каждый писать нереально — тогда не знаю, наверное надо копать в сторону настройки в ядре размера кеша маршрутов (который сбрасывается через ip route flush cache) или, что более надёжно, в сторону выставления файрволом fwmark для всех исходящих соединений на базе хеша от адреса назначения — у iptables вполне может найтись подходящий модуль (обычно такие вещи используются для балансировки нагрузки, и как побочный эффект можно получить закрепление за каждым сайтом своего канала).
Задача слетающей авторизации решается добавлением для таких сайтов в файрвол индивидуальных правил, выбирающего для них один из интерфейсов (через fwmark, как обычно) — как я сделал в статье для сайта со статистикой второго провайдера. Если таких сайтов 2-3 штуки, это сделать проще всего. Если их очень много, и правила в файрвол на каждый писать нереально — тогда не знаю, наверное надо копать в сторону настройки в ядре размера кеша маршрутов (который сбрасывается через ip route flush cache) или, что более надёжно, в сторону выставления файрволом fwmark для всех исходящих соединений на базе хеша от адреса назначения — у iptables вполне может найтись подходящий модуль (обычно такие вещи используются для балансировки нагрузки, и как побочный эффект можно получить закрепление за каждым сайтом своего канала).
Отлично! Сам подумываю, но реализовывать скорей всего буду на роутере прямо…
Одно но: по правилам хорошего тона — локалка обычно запускается на 192.168.0.x — второй байт начинают трогать если сетка оченнь сильно большая…
Одно но: по правилам хорошего тона — локалка обычно запускается на 192.168.0.x — второй байт начинают трогать если сетка оченнь сильно большая…
Я знаю, но… во-первых адреса в статье просто для примера, реальные у меня немного отличаются; во-вторых когда я в ~1994 году начинал изучать линух и роутинг, правила хорошего тона ещё отсутствовали, и я исторически привык к 192.168.2; в-третьих сильно раздражает, что адрес 192.168.0.x любит автоматически выставлять на интерфейсе винда при включении ICS (что особенно грустно в ситуации, когда инет расшаривается для интерфейса VMware), поэтому я стараюсь ни на одном реальном интерфейсе этот адрес не ставить, во избежание лишних конфликтов; в-четвёртых адрес 192.168.1.1 по умолчанию ставят на ADSL модемы — так что первый «безопасный» вариант для локалки получается как раз 192.168.2.
А как обстоят дела с производительностью при маркеровке пакетов? Через шлюз, на очень слабенькой машинке (целерон 1800), ходят в интернет порядка 80 пользователей. Сейчас вся маршрутизация только средствами iproute2. Как видно iproute2 + fwmark — дает много больше возможностей.
может перенести в блог Системное администрирование
В руководстве по iptables на opennet.ru, в схеме прохождения пакетов через файервол, отмечено всего 2 «routing decisions», в отличии от вашей схемы. Немогли бы вы дать источник вашей иллюстрации. Спасибо.
Протупил, схема вставленна прямо из источника, как я понимаю.
Мне теперь ваша статья покоя не дает, а поэксперементировать смогу только в субботу. Выложите, если возможно, ваши скрипты pppd: ip-up, ip-down, посмотреть как реализованны блокировки.
В Gentoo пользовательские ip-up/down скрипты предполагается класть в /etc/ppp/ip-{up,down}.d/90-local.sh:
# cat /etc/ppp/ip-up.d/90-local.sh
#!/bin/sh
chpst -l /etc/ppp/.lock /etc/ppp/ip-up.local.safe "$@"
# cat /etc/ppp/ip-down.d/90-local.sh
#!/bin/sh
chpst -l /etc/ppp/.lock /etc/ppp/ip-down.local.safe "$@"
# cat /etc/ppp/ip-up.local.safe
#!/bin/sh
[ "$1" == "ppp0" ] && table="isp1" || table="isp2"
ip route add default via $5 dev $1 table $table
...здесь должна быть установка одиночного/множественного default route...
ip route flush cache
# cat /etc/ppp/ip-down.local.safe
#!/bin/sh
# workaround race condition: pppd will delete default route in parallel
# with executing ip-down script
for i in $(seq 1 10); do
ip route list | grep -q ^default && break
sleep 0.3
[[ $i == 10 ]] && echo "Failed to wait until default route will be deleted"
done
...здесь должна быть установка одиночного default route если другой канал работает...
ip route flush cache
Отличная статья, спасибо.
Настроил вчера два дефолтных шлюза для разных интерфейсов, вот так работает:
ip rule add from 10.0.0.2 lookup t0
ip rule add from 192.168.5.2 lookup t0.51
ip route add default via 10.0.0.254 dev eth0 table t0
ip route add default via 192.168.5.254 dev eth0.51 table t0.51
а если первые два правила переписать с использованием интерфейсов
ip rule add dev eth0 lookup t0
ip rule add dev eth0.51 lookup t0.51
То не работает.
В чем причина, подскажите?
И можно ли такую функциональность реализовать ещё проще?
Настроил вчера два дефолтных шлюза для разных интерфейсов, вот так работает:
ip rule add from 10.0.0.2 lookup t0
ip rule add from 192.168.5.2 lookup t0.51
ip route add default via 10.0.0.254 dev eth0 table t0
ip route add default via 192.168.5.254 dev eth0.51 table t0.51
а если первые два правила переписать с использованием интерфейсов
ip rule add dev eth0 lookup t0
ip rule add dev eth0.51 lookup t0.51
То не работает.
В чем причина, подскажите?
И можно ли такую функциональность реализовать ещё проще?
Я предполагаю, что причина в том, что исходящий интерфейс всегда eth0, а алиасы вроде eth0:51 являются только способом повесить на этот интерфейс дополнительные IP, так что указание eth0:51 когда речь идёт о выборе интерфейса эквивалентно указанию eth0.
Далее, если Вы посмотрите вывод ip rule list для варианта через dev, то Вы увидите что вместо dev там указан iif. Судя по документации на iif в ip rule (а dev там вообще не упомянут), он используется для различения локальных и форвардящихся пакетов. Так что моё второе предположение заключается в том, что dev для этой задачи использовать вообще неуместно.
Кроме того, если у вас на 192.168.5.2 будет запущен, например, веб-сервер, и на него придёт запрос из сети 10.0.0.x, то ответ на этот запрос будет отправлен некорректно (ответ в сеть 10.0.0.x пойдёт через шлюз 192.168.5.254). Другие ограничения настройки через from описаны в одном из предыдущих комментов.
Так что я бы рекомендовал всё-таки настроить так, как описано в статье, через fwmark. Хотя для простых случаев Ваш вариант через from тоже сработает.
Далее, если Вы посмотрите вывод ip rule list для варианта через dev, то Вы увидите что вместо dev там указан iif. Судя по документации на iif в ip rule (а dev там вообще не упомянут), он используется для различения локальных и форвардящихся пакетов. Так что моё второе предположение заключается в том, что dev для этой задачи использовать вообще неуместно.
Кроме того, если у вас на 192.168.5.2 будет запущен, например, веб-сервер, и на него придёт запрос из сети 10.0.0.x, то ответ на этот запрос будет отправлен некорректно (ответ в сеть 10.0.0.x пойдёт через шлюз 192.168.5.254). Другие ограничения настройки через from описаны в одном из предыдущих комментов.
Так что я бы рекомендовал всё-таки настроить так, как описано в статье, через fwmark. Хотя для простых случаев Ваш вариант через from тоже сработает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка роутинга для домашнего multihomed сервера