Тем временем принимаются пожелания по балансировке трафика.
Чтобы высказать свои пожелания, сначала надо знать возможные варианты в этой системе Смутно догадываюсь, что они могут быть фиксированными, т.е. тупо переключаться с отказавшего в какой-то момент провайдера на работающего, либо складывать их скорость в суммарную, и т.п. Впрочем, не уверен. Какие они могут быть?
Возможные варианты, если грубо:
1. Статическая маршрутизация: на указанные хосты ходить через одного провайдера, на остальные - через второго (например, деление по зонам UAIX-мир).
2. Динамическая балансировка: запуск маршрутов на новые хосты пропорционально заданным вероятностям (например, 100:8). При этом не учитывается объем скачиваемого контента (т.к. в момент определения маршрута еще не скачано ничего), поэтому может оказаться, что самый трафико-емкий хост пойдет по медленному каналу.
Т.к. второй способ работает недостаточно умно, а 100 мегабит мне лично достаточно - я дома все запускаю через 100 мегабитный канал, а второй ждет своей очереди исключительно как резервный.
Теоретически, есть еще способы, как сложить пропускную способность двух каналов... но по известной мне методике для этого нужен сервер в интернете, который будет эти два канала терминировать и пересылать весь трафик через себя. Предлагаю этот метод пока пропустить.
Целиком согласен на 1-й вариант.
Кстати, он умеет сам переключаться на второй канал, когда первый отказал?
Есть всего пара доступных способов организовать failover дома. 1. Указать два дефолтовых шлюза. Поставить необходимый gc_timeout. На резервный переключит, но обратно, с резервного канала на основной - нет. 2. Использовать простенький скрипт с пингом. Будет переключать в обе стороны, но все будет зависеть от правильно выбранного IP для пинга. Остальные способы работают на протоколах динамической маршрутизации и дома не помогут.
Для двух линков так-же надо будет настроить две таблицы маршрутизации и два правила под каждый линк, с помощью ip route и ip rule.
Я например дома failover не использую, но делю трафик в зависимости от экзешника, который его генерит.
Целиком согласен на 1-й вариант.
Кстати, он умеет сам переключаться на второй канал, когда первый отказал?
Howto по частному случаю первого варианта - весь трафик через 100 мбитный канал со статикой, второй канал с DHCP - резервный. Failover - автоматический в обе стороны. Используем dd-wrt v24 SP2 (проверено на прошивках _openvpn и _voip). Предполагаем, что провайдера с DHCP будем втыкать в порт WAN, а статического провайдера - в порт LAN4.
1. Настраиваем роутер на работу с одним провайдером, воткнутым в WAN, через DHCP. Принудительно задаем DNS, который отвечает на запросы от любого провайдера (например, гугловский DNS - 8.8.8.8):
2. Setup -> VLANs. Порт 4 переводим в VLAN 2. Жмем Apply.
3. Setup -> Networking. vlan2 = Unbridged. Устанавливаем IP адрес и маску сети согласно статических настроек провайдера (вместо того, что на картинке обозначено как 192.168.208.99 и 255.255.255.128). Жмем Apply.
4. Administration -> Commands. Вводим следующее в окно Command Shell:
if [ "$PROVIDER" == "1" ] ; then if ! ping -c 1 $KEEPALIVEHOST > /dev/null ; then sleep 10 if ! ping -c 1 $KEEPALIVEHOST > /dev/null ; then sleep 10 if ! ping -c 1 $KEEPALIVEHOST > /dev/null ; then ip route del 0.0.0.0/1 via $GW ip route del 128.0.0.0/1 via $GW PROVIDER=2 fi fi fi else if ping -c 1 $KEEPALIVEHOST > /dev/null ; then sleep 10 if ping -c 1 $KEEPALIVEHOST > /dev/null ; then ip route add 0.0.0.0/1 via $GW ip route add 128.0.0.0/1 via $GW PROVIDER=1 fi fi fi done
Выделенное красным - это Default Gateway согласно настроек провайдера со статическим адресом. Выделенное синим - это какой-нибудь надежный узел в интернете, который обладает высокой доступностью, но нам в практическом применении совершенно не нужен
Нажимаем Save Custom Script
6. Administration -> Commands Вводим следующее в окно Command Shell:
ip route add 0.0.0.0/1 via 192.168.208.1 ip route add 128.0.0.0/1 via 192.168.208.1
Выделенное красным - это Default Gateway согласно настроек провайдера со статическим адресом.
Нажимаем Save Startup
7. Administration -> Management. Нажимаем Reboot Router. После перезагрузки проверяем, все ли работает.
Если достаточно обеспечить доступ изнутри сети наружу - на этом можно и остановиться. Если же требуется еще и доступ из интернета к роутеру (например, удаленный доступ через VPN) - нужно еще поиграться с таблицами маршрутизации, о чем говорил codex (чтобы на запрос, пришедший через провайдера 1, обеспечить ответ через этого же провайдера 1 независимо от текущего дефолтного маршрута и источника запроса в инете). Если это нужно делать - дайте знать: покажу, что где добавить.
Да, внешний доступ, а особенно проброс портов на внутренние сетевые устройства очень интересует.
Да, внешний доступ, а особенно проброс портов на внутренние сетевые устройства очень интересует.
С пробросом портов на внутренние сетевые устройства в режиме обеспечения доступности через любого из двух провайдеров (а не только через активного в данный момент) - это не очень простой вопрос. Т.е. если задачу можно упростить до такой постановки: "Если инет через провайдера 1 доступен, то проброс портов работает через него, а проброс портов через провайдера 2 не работает; если провайдер 1 отвалился, то проброс портов работает через провайдера 2" - тогда все элементарно (нужно добавить пару строк в Howto в раздел Firewall). Если же нужно одновременно обеспечить доступ и через провайдера 1, и через провайдера 2 - тогда нужно круто прогнуться, и значительно проще обеспечить удаленный доступ к локалке через OpenVPN (который будет доступен через любого из двух провайдеров в любой момент времени, когда соответствующий провайдер не отвалился), после чего работать с хостами в локальной сети, обращаясь к этим хостам по внутренним локальным айпишникам. Тебе что больше по душе?
Если же нужно одновременно обеспечить доступ и через провайдера 1, и через провайдера 2 - тогда нужно круто прогнуться
Это два правила в iptables .
"Если инет через провайдера 1 доступен, то проброс портов работает через него, а проброс портов через провайдера 2 не работает; если провайдер 1 отвалился, то проброс портов работает через провайдера 2" - тогда все элементарно (нужно добавить пару строк в Howto в раздел Firewall).
Этот вариант вполне устраивает, потому что провайдер 2 низкоскоростной, динамический, и пробрасывать для его случая порты неактуально.
------------------------------ И кстати, хотелось бы, чтобы 1-й провайдер (статический, скоростной) был присоединен к штатному WAN, так оно вроде субъективно логичнее выглядит. Это не слишком усложнит хавту?
Если же нужно одновременно обеспечить доступ и через провайдера 1, и через провайдера 2 - тогда нужно круто прогнуться
Это два правила в iptables .
А ну-ка покажи Давай я сразу поясню:
Естественно, добавляем два правила PREROUTING, которые пробрасывают нужный порт или диапазон портов на устройство во внутренней сети. И пакеты снаружи в сеть попадают. А вот обратно... идет такой себе реплайный пакет, у которого source ip из локальной сетки, а destination ip - в инете. Хинт: сначала ядро принимает решение, куда его маршрутизировать, а уже потом (на этапе POSTROUTING) меняет ему source ip в соответствии "наоборот" с теми правилами PREROUTING, которые мы добавляли раньше. И куда уйдет этот пакет? Ты уверен, что на того же провайдера, с которого пришел запрос? Каким именно ip rule это обеспечится?
------------------------------ И кстати, хотелось бы, чтобы 1-й провайдер (статический, скоростной) был присоединен к штатному WAN, так оно вроде субъективно логичнее выглядит. Это не слишком усложнит хавту?
Можно, только скрипты поднятия второго провайдера будут чуть сложнее (нужно будет запустить dhcp клиента для этого vlan, после чего позаботиться о том, чтобы эти параметры были где-нибудь сохранены для дальнейшего применения в скриптах управления маршрутизацией). Я таким путем тоже "ходил", поэтому если тебе это действительно интересно - могу и этот путь показать. Да, уточню, что это достаточно сильно усложнит скрипты И красивее будет выглядеть оформление скриптов не в полях web интерфейса, а в области JFFS файловой системы (с соответствующей необходимостью их редактирования в консоли командной строки).
В пользу этого подхода можно сказать то, что в результате управление пробросом портов для основного провайдера будет выполняться через WEB интерфейс (в предложенном мной варианте WEB интерфейс будет чудно делать это для резервного dhcp провайдера ).
Если же нужно одновременно обеспечить доступ и через провайдера 1, и через провайдера 2 - тогда нужно круто прогнуться
Это два правила в iptables .
А ну-ка покажи Давай я сразу поясню:
Естественно, добавляем два правила PREROUTING, которые пробрасывают нужный порт или диапазон портов на устройство во внутренней сети. И пакеты снаружи в сеть попадают. А вот обратно... идет такой себе реплайный пакет, у которого source ip из локальной сетки, а destination ip - в инете. Хинт: сначала ядро принимает решение, куда его маршрутизировать, а уже потом (на этапе POSTROUTING) меняет ему source ip в соответствии "наоборот" с теми правилами PREROUTING, которые мы добавляли раньше. И куда уйдет этот пакет? Ты уверен, что на того же провайдера, с которого пришел запрос? Каким именно ip rule это обеспечится?
Есть пути. Например пробрасывать внешние соединения на разные IP внутри сети, в зависимости от того, по какому каналу пришел запрос. Ну и соответственно иметь на "целевой" машине 2 ip адреса, которые слушает сервис.... Соответственно и ответные пакеты будут валить с разных адресов, что делает их обработку файрволом - тривиальной. Вариант совсем тупой, но простой и рабочий. Для иных путей - таки надо statefull файевол
Можно, только скрипты поднятия второго провайдера будут чуть сложнее
Нет, тогда не нужно, конечно. Проще запомнить куда какой кабель включаешь, даже если выбор не нравится
Каким именно ip rule это обеспечится?
ip rule add from src_ip lookup table table_name сорс роутинг src_ip - провайдерский айпи table_name - имя таблицы, по одной на каждого провайдера, где перечислены все локальные сети и соответствующий дефолтовый шлюз провайдера
Каким именно ip rule это обеспечится?
ip rule add from src_ip lookup table table_name сорс роутинг src_ip - провайдерский айпи table_name - имя таблицы, по одной на каждого провайдера, где перечислены все локальные сети и соответствующий дефолтовый шлюз провайдера
Повторюсь, что это работать не будет, потому что реплайный пакет на момент разборки правил маршрутизации будет всегда от ip девайса из локальной сети (скажем, если порт проброшен на 192.168.1.100 - в реплайном пакете source ip всегда будет 192.168.1.100 на момент принятия решения о маршрутизации этого пакета), и только после принятия решения о маршруте отправки - он будет заменен на провайдерский. Попробуй... я уже пробовал
Есть пути. Например пробрасывать внешние соединения на разные IP внутри сети, в зависимости от того, по какому каналу пришел запрос. Ну и соответственно иметь на "целевой" машине 2 ip адреса, которые слушает сервис.... Соответственно и ответные пакеты будут валить с разных адресов, что делает их обработку файрволом - тривиальной. Вариант совсем тупой, но простой и рабочий.
Хороший вариант... но это и есть то, что я называю "надо прогнуться" Ибо заводить по два айпишника на юзерских машинах - это таки прогибон и неудобство
Есть пути. Например пробрасывать внешние соединения на разные IP внутри сети, в зависимости от того, по какому каналу пришел запрос. Ну и соответственно иметь на "целевой" машине 2 ip адреса, которые слушает сервис.... Соответственно и ответные пакеты будут валить с разных адресов, что делает их обработку файрволом - тривиальной. Вариант совсем тупой, но простой и рабочий.
Хороший вариант... но это и есть то, что я называю "надо прогнуться" Ибо заводить по два айпишника на юзерских машинах - это таки прогибон и неудобство
На юзерских - ото нать не нать... На ДМЗ - почему нет? Сколько там машин, которым надо? Нет, если конечно radmin пробрасывать везде, и по прямому IP, то да, но это ведь еще больший идиотизм. Тут ВПН лепить надо... А для 1-2 ДМЗ хостов - вполне приемлимый вариант Тем более что там и так статику придется ставить скорее всего
Каким именно ip rule это обеспечится?
ip rule add from src_ip lookup table table_name сорс роутинг src_ip - провайдерский айпи table_name - имя таблицы, по одной на каждого провайдера, где перечислены все локальные сети и соответствующий дефолтовый шлюз провайдера
Повторюсь, что это работать не будет, потому что реплайный пакет на момент разборки правил маршрутизации будет всегда от ip девайса из локальной сети (скажем, если порт проброшен на 192.168.1.100 - в реплайном пакете source ip всегда будет 192.168.1.100 на момент принятия решения о маршрутизации этого пакета), и только после принятия решения о маршруте отправки - он будет заменен на провайдерский. Попробуй... я уже пробовал
я iptables решительно не знаю, но в pf нечто похожее - вполне работает. Когда фаервол держит таблицу соединений, и ею плодотворно пользуется. Ибо помнит, с какого IP и порта какое соединение растет через какой интерфейс. А дестинейшн адрес и порт у реплайного пакету известны. Это statefull firewall и есть, на самом деле
Каким именно ip rule это обеспечится?
ip rule add from src_ip lookup table table_name сорс роутинг src_ip - провайдерский айпи table_name - имя таблицы, по одной на каждого провайдера, где перечислены все локальные сети и соответствующий дефолтовый шлюз провайдера
Повторюсь, что это работать не будет, потому что реплайный пакет на момент разборки правил маршрутизации будет всегда от ip девайса из локальной сети (скажем, если порт проброшен на 192.168.1.100 - в реплайном пакете source ip всегда будет 192.168.1.100 на момент принятия решения о маршрутизации этого пакета), и только после принятия решения о маршруте отправки - он будет заменен на провайдерский. Попробуй... я уже пробовал
я iptables решительно не знаю, но в pf нечто похожее - вполне работает. Когда фаервол держит таблицу соединений, и ею плодотворно пользуется. Ибо помнит, с какого IP и порта какое соединение растет через какой интерфейс. А дестинейшн адрес и порт у реплайного пакету известны. Это statefull firewall и есть, на самом деле
iptables по сути и есть тот же pf и выполняет те же задачи. Но я уже говорил, почему это не будет работать: по причине того, что source ip (вообще для любого пакета, но в рассматриваемой ситуации важно, что это происходит для реплайного пакета в том числе) подменяется на этапе POSTROUTING. Т.е. когда все правила ip rule уже закончили обработку, и решение о маршруте этого пакета уже принято. Т.е. важна именно последовательность событий. Именно поэтому твой альтернативный вариант (с двумя ip на хосте DMZ) работать будет (ip rule add from dmz_ip1 lookup table_prov_1 && ip rule add from dmz_ip2 lookup table_prov_2), а с единственного ip хоста DMZ - нифига работать не будет: уйдет пакет через другого провайдера запросто, и отмаскарадится айпишником другого провайдера так же запросто.
iptables по сути и есть тот же pf и выполняет те же задачи. Но я уже говорил, почему это не будет работать: по причине того, что source ip (вообще для любого пакета, но в рассматриваемой ситуации важно, что это происходит для реплайного пакета в том числе) подменяется на этапе POSTROUTING. Т.е. когда все правила ip rule уже закончили обработку, и решение о маршруте этого пакета уже принято. Т.е. важна именно последовательность событий. Именно поэтому твой альтернативный вариант (с двумя ip на хосте DMZ) работать будет (ip rule add from dmz_ip1 lookup table_prov_1 && ip rule add from dmz_ip2 lookup table_prov_2), а с единственного ip хоста DMZ - нифига работать не будет: уйдет пакет через другого провайдера запросто, и отмаскарадится айпишником другого провайдера так же запросто.
Насколько я понимаю как работает pf, там маскарад (нат) происходит на "выходном" интерфейсе, на внешнем. Вернее - как напишешь правила, но обычно - так. А решение о его роутинге, происходит несколько раньше Ну кагбе по последовательности работы правил, а не по порядку написания правил в конфе И это реально - таки работает. Могу посмотреть живой конфиг, и привести цитаты, если интересно
Відповісти
Поперед.
Зміст
Наступ.
Гілками
.
