В документе (http://xgu.ru/wiki/openvpn/gw) описывается как с помощью OpenVPN и двух независимых интернет-каналов низкой надёжности организовать надёжное подключение удалённой сети (или системы) к центральной сети.
Приведённое решение может быть полезно и без использования VPN - для решения задачи автоматического выбора основного шлюза.URL: http://xgu.ru/wiki/openvpn/gw
Новость: http://www.opennet.me/opennews/art.shtml?num=12103
Сложно-то как. Эх, старые добрые дистрибутивы с простыми скриптами, как мне вас не хватает.
И каждый стремится доработать напильником..
То есть ты считаешь этот скрипт сложным? Нда.... Двадцать строк на баше уже считаются сложными. Человеку спасибо надо сказать, за то, что он тратит свой время для обучения новичков. Для которых это действительно на начальном этапе сложно.ЗЫ: Ничего личного, но кто тебе мешаешь выложить красиво оформленную, грамотно написанную статью такого же плана.
Считаю лишним заводить дополнительные переменные, редактировать стандартные скрипты дистрибутива. Подобные вещи настраиваются, фигурально говоря, один раз. Достаточно внешнего скрипта.Человеку СПАСИБО за потраченное на красивую статью время.
p.s. будет подходящая, по моему мнению, тема, тогда выложу.
Хотел спросить, а почему бы для такой задачи не использовать OSPF?
Можно и это более эффективно и надежно. Не нужны никакие погремушки со скриптами.
Просто поднять OpenVPN через разных провайдеров и запустить внутри туннеля OSPF.Тот, кто хорошо знаком с маршрутизацией, тот так и сделает. Кто не знаком, тот будет скриптами разруливать.
Дело в постановке задачи. Правильной постановке.
В варианте один ставится задача обеспечить функционирование туннеля по каналу с резервированием через другого провайдера. Во втором случае, задача состоит в том, чтобы обеспечить соединение между двумя узлами через общедоступную сеть. Второй случай более общий, поэтому предполагает некоторое разнообразие вариантов для выбора. :)
При первом варианте постановки задачи, статья имеет кое-какой смысл.
1) Вы считаете, что держать два туннеля OpenVPN одновременно
и поднимать поверх них OSPF более эффективно и надёжно чем
элементарная проверка маршрута и переход с одного на другой?2) Как вы считаете, какое решение является более масштабируемым?
С OSPF over OpenVPN или передёргиванием шлюза?
Как вы думаете, сколько таких каналов можно будет поднять?3) Если предположить, что кроме поднятия туннеля в центр
необходимо ещё какое-то обращение к Интернет (имеется в виду обращения напрямую,
а не в обход — через OpenVPN-туннель), как вы себе видите
решение задачи предложенным вами способом?
не автор статьи, но рискну ответить :-)1. Мне кажется да, особенно если запуск ospf & openvpn производится без написания каких-либо скриптов - просто поставили через стандартный менеджер пакетов, поправили пару конфигурационных файлов и вперёд.
2. Описанное в первом пункте - масштабирование элементарно - правкой конфигурационных файлов, хотя не исключено, что для удобства это будет делаться через cfengine или нечто аналогичное. Количество каналов определяется исключительно возможностями железа - хоть сотни!
3. Элементарно - ставим default route на провайдера(ов), а внутренние маршруты получаем по ospf
Примечание: предполагается, что всё вышесказанное осуществляется на линуксе, который установлен на приличном железе.
>[оверквотинг удален]
>
>1. Мне кажется да, особенно если запуск ospf & openvpn производится без
>написания каких-либо скриптов - просто поставили через стандартный менеджер пакетов, поправили
>пару конфигурационных файлов и вперёд.
>
>2. Описанное в первом пункте - масштабирование элементарно - правкой конфигурационных файлов,
>хотя не исключено, что для удобства это будет делаться через cfengine
>или нечто аналогичное. Количество каналов определяется исключительно возможностями железа - хоть
>сотни!
>«Хоть сотни» это конечно звучит :)
Вопрос к знатокам OSPF:
зачем в OSPF существует понятие area?
И начиная со скольки записей в таблице описания топологий
при условии что демоны маршрутизации исполняются
на современном железе есть смысл создавать несколько area?
>3. Элементарно - ставим default route на провайдера(ов), а внутренние маршруты получаем
>по ospf
>Вот это подробнее.
У вас два провайдера.
На кого вы ставите default route?Или вы ставите сразу два default route?
>Примечание: предполагается, что всё вышесказанное осуществляется на линуксе, который установлен на приличном
>железе.Да.
Центр на приличном железе,
а отделения не так важно на каком железе.
Про это согласен.
OSPF и AREA.AREA - это просто область в которой несколько подсетей и обычно несколько роутеров.
Разделение на области сделано для того, чтобы более оптимально передавать информацию о маршрутах, если сеть большая и роутеров много.
Обмен информацией между AREA идет через специальную AREA c номером НОЛЬ.Вот вкрадце и все.
Для вашего случая поднимите OSPF на обоих концах с AREA 0, пропишите туда свои внутренние сети и получите щастье. Да, еще OSPF надо настроить для работы в режиме NBMA.
Сам протокол OSPF переключит маршрут на другой OpenVPN, если один из каналов поляжет. В протоколе OSPF заложены функции обнаружения пропадания канала и правки таблицы маршрутизации. Вы скриптами сделали тоже самое. Т.е. изобрели велосипед. Ну изобрели и изобрели, что ж делать-то...
Шлюз по умолчанию переключать надо для Интернет-трафика. Т.е. для ваших офисных пользователей, которые Асю юзают, к примеру :) Тут скрипты рулят, т.к. BGP и OSPF вам провайдер не даст. Но для решения задачи отказоустойчивых каналов между офисами можно было обойтись только двумя OpenVPN-ами и OSPF. Это вам любой приличный сетевик скажет.
Про масштабируемость OSPF: Масштабируется только в путь. Более того, если у вас стоит серьезное железо а-ля Циска, Джунипер, Алкатель, 3СОМ и иже с ними, то можете это решение легко с ними интегрировать, OSPF довольно сильно масштабируется.Если упретесь в ограничения OSPF, то делайте тоже самое на BGP. У него проблем с масштабируемостью нет. На BGP весь Интернет работает.
Если тема интересна, то найдите книгу "Создание масштабируемых сетей" издательства Cisco Press. Там подробно расписано про протоколы динамической маршрутизации.
>Про масштабируемость OSPF: Масштабируется только в путь. Более того, если у вас
>стоит серьезное железо а-ля Циска, Джунипер, Алкатель, 3СОМ и иже с
>ними, то можете это решение легко с ними интегрировать, OSPF довольно
>сильно масштабируется.
>
>Если упретесь в ограничения OSPF, то делайте тоже самое на BGP. У
>него проблем с масштабируемостью нет. На BGP весь Интернет работает.
>
>Если тема интересна, то найдите книгу "Создание масштабируемых сетей" издательства Cisco Press.
>Там подробно расписано про протоколы динамической маршрутизации.Правильно ли я вас понял, что вы рекомендуете вместо
описанно в заметке примитивного скрипта на 10 строчек
поднимать BGP?
Не передергивайте. :)Человек ясно сказал - не хватает OSPF - используйте BGP. А не предлагал использовать последнее для двух туннелей.
А вообще когда активное оборудование, даже хотя бы, циско+линукс (не каша из всего на свете) - то о универсальности само-собой задумываешься и скриптами на баше (со срабатыванием в 30 сек) в таком случае не обойдешься. :)
Хотя Вы правильно злитесь - задача стояла "ДВА_ПРОВАЙДЕРА_ДВА_ТУННЕЛЯ_ДВА_ЛИНУКСА", а тут понабежало и рассказывают о масштабируемости.
>Не передергивайте. :)
>
>Человек ясно сказал - не хватает OSPF - используйте BGP. А не
>предлагал использовать последнее для двух туннелей.
>Где два туннеля?
Вы хотели сказать два умножить на количество удалённых точек?
>А вообще когда активное оборудование, даже хотя бы, циско+линукс (не каша из
>всего на свете) - то о универсальности само-собой задумываешься и скриптами
>на баше (со срабатыванием в 30 сек) в таком случае не
>обойдешься. :)Чем вам не нравятся 30 секунд?
Сколько времени потребуется чтобы перестроить маршруты OSPF
как вы считаете (скажите мне в HELO-интервалах)?
>
>Хотя Вы правильно злитесь - задача стояла "ДВА_ПРОВАЙДЕРА_ДВА_ТУННЕЛЯ_ДВА_ЛИНУКСА", а тут понабежало и
>рассказывают о масштабируемости.Я сам первый начал рассказывать про масштабируемость.
Потому что линуксов, которые сконфигурированы
таким образом
и подключаются к центру может быть сколько угодно.А в случае с OSPF я задал вопрос: сколько таких удалённых точек безболезненно
можно поднять в пределах одной AREA?
Таких удаленных точек можно поднять много. Очень много.
Я уже рекомендовал литературу, кому интересна тема. Доказывать с пеной у рта что OSPF это круче я не буду, т.к. уже сказал, что если не хватит OSPF, то можно легко перейти на BGP.
Тайм-ауты для hello и dead-интервалы в OSPF настраиваются, так что как-то не понятно к чему вы клоните, когда просите что-то доказать.Раз вы такой умный и изобрели пингование, то почему же все остальные используют протоколы динамической маршрутизации? Если вы действительно умный, то объясните это популярно.
Например типа так: по сравнению с моим способом OSPF плох потому-то, а BGP потому-то. Только не занудствуйте, что настройка OSPF/BGP сложна. Это и так понятно. Изложите ограничения этих протоколов. Ваш пассаж про масштабируемость пока только пустой звук. Факты в студию.
>Таких удаленных точек можно поднять много. Очень много.
>Я уже рекомендовал литературу, кому интересна тема. Доказывать с пеной у рта
>что OSPF это круче я не буду, т.к. уже сказал, что
>если не хватит OSPF, то можно легко перейти на BGP.
>Тайм-ауты для hello и dead-интервалы в OSPF настраиваются, так что как-то не
>понятно к чему вы клоните, когда просите что-то доказать.
>Я не прошу ничего доказать.
Выше были упомянуты 30 секунд --- периодичность, с которой
проверяется доступность шлюза.
В ответ я написал, о том, что подумайте, за сколько у вас перестроится
маршрут при использовании VPN.
>Раз вы такой умный и изобрели пингование, то почему же все остальные
>используют протоколы динамической маршрутизации? Если вы действительно умный, то объясните это
>популярно.Это очень серьёзный аргумент «все остальные».
Прежде всего,
я не призываю отказаться везде от использования протоколов динамической маршрутизации.
Я считаю, что для решения описанной задачи лучше использовать «пингование»
по ряду причин.Думаю, что если внимательно прочитать обсуждение и статью,
то всё будет понятно и так, но тем не менее, повторюсь:1) Использование OSPF поверх OpenVPN не решает задачу полностью.
Задача решается только частично, а именно в той части, которая касается
доступа к удалённой сети.На вопрос «Как получить доступ к Интернету, если шлюз лёг?» этот способ не отвечает.
2) Масштабируемость.
Представьте что у вас таким способом к центру подключено несколько сотен отделений.
Они все должны оставаться на связи с центром.
Вы предлагаете использовать OSPF, причём разместить все связи в
одной AREA.Таким образом, каждый узел должен представлять всю топологию AREA полностью и
он должен получать апдейты, касающиеся любого изменения в топологии.Зачем все сотни узлов должны знать друг о друге?
Зачем лишний трафик обновления базы данных link-state database,
которая в этом случае должна пополняться информацией о любых новых отключениях
и подключениях?>Например типа так: по сравнению с моим способом OSPF плох потому-то, а
>BGP потому-то. Только не занудствуйте, что настройка OSPF/BGP сложна. Это и
>так понятно. Изложите ограничения этих протоколов. Ваш пассаж про масштабируемость пока
>только пустой звук. Факты в студию.Извините меня, пожалуйста,
я не помню ни одного своего высказывания,
из которого следует, что настройка OSPF сложна.Ещё раз, я ничего не имею против протоколов динамической маршрутизации.
Я ничего не говорю об их ограничениях.Но я не понимаю, зачем вы решили, что нужно использовать OSPF здесь,
когда проблема решается с помощью элементарного пингования?
Для двух хостов это хорошее решение. Для сотен - уже сомневаюсь.Кроме того, OSPF позволяет по другому живому каналу уведомить другую систему о смене маршрута и необходимости перерулить трафик. При правильно выставленных тайм-аутах работать это будет более эффективно, чем пинг.
Моя фраза запихнуть все в одну область касалась случая, когда есть сравнительно небольшое кол-во хостов. Если их много, то никто не мешает делать тупиковые области. Тогда вся таблица маршрутизации не будет передаваться в каждую точку. Всё о всех будет знать только центр. Люди, которые изобретали и развивали OSPF не лаптем щи хлебали. Думали о подобных проблемах. :)
Кроме того, OSPF позволит строить более извращенные и сложные подключения, раз уж у вас сотни хостов. Логичнее было бы подобную сеть задублировать через соседей. И тут только протоколы динамической маршрутизации смогут решить эту задачу. Я вас за язык не тянул, сами про масштабируемость заговорили. :)
Предлагаю флейм закончить. Ваше решение вполне жизнеспособно и вероятно кому-то пригодится.
Так уж получилось, что подобную задачу мне необходимо решить в ближайшее время.два канала Интернет, колокейшн который должен быть доступен с некой "внутренней адресацией" (специфика), припадении канала с туннелем, автоматический "переход" на второй канал.
Сделаю это с помощью OSPF, отвечу на все Ваши вопросы - подготовлю материал и "запощу" на опеннет.
Пойдет?
...
>AREA - это просто область в которой несколько подсетей и обычно несколько
>роутеров.
>
>Разделение на области сделано для того, чтобы более оптимально передавать информацию о
>маршрутах, если сеть большая и роутеров много.(спасибо, что вы это сказали; идём дальше)
>[оверквотинг удален]
>
>Для вашего случая поднимите OSPF на обоих концах с AREA 0, пропишите
>туда свои внутренние сети и получите щастье. Да, еще OSPF надо
>настроить для работы в режиме NBMA.
>
>Сам протокол OSPF переключит маршрут на другой OpenVPN, если один из каналов
>поляжет. В протоколе OSPF заложены функции обнаружения пропадания канала и правки
>таблицы маршрутизации. Вы скриптами сделали тоже самое. Т.е. изобрели велосипед. Ну
>изобрели и изобрели, что ж делать-то...
>Большое спасибо за такое подробное и трогательное объяснение.
Повторяю вопрос:
по вашему мнению, сколько узлов вы подразумеываете в сети,
когда пишите «большая сеть и роутеров много».Начиная с какого количества узлов рекомендуется делать
разбиение на AREA и не ограничиваться использованием одной лишь
AREA 0.Если это определяется количеством узлов.
Если же нет, то чем это определяется, и когда в таком случае
следует делать разбиение?
Таки прошу прощения, что включаюсь в столь активную дискуссию, но у меня есть ответы на ваши вопросы:
- разбиение на area как правильно действительно определяется количеством маршрутизаторов, но конкретное значение носит сугубо рекомендательный характер: не больше сотни маршрутизаторов в одной области
- время перестройки на резервный канал для ospf составит, скажем, 3 секунды (не вижу смысла приводить в его в неких абстрактных hello timeout)
- при всём моём уважении к Вашим усилиям, 30 секунд время решительно неприемлемое т. к. за это время вполне могут откиснуть tcp сессии, застопорится картинка в потоковом видео и возникнет неуместная пауза в разговоре по телефону
>Таки прошу прощения, что включаюсь в столь активную дискуссию, но у меня
>есть ответы на ваши вопросы:
>- разбиение на area как правильно действительно определяется количеством маршрутизаторов, но
>конкретное значение носит сугубо рекомендательный характер: не больше сотни маршрутизаторов в
>одной областиСпасибо.
>- время перестройки на резервный канал для ospf составит, скажем, 3 секунды
>(не вижу смысла приводить в его в неких абстрактных hello timeout)
>
>- при всём моём уважении к Вашим усилиям, 30 секунд время решительно
>неприемлемое т. к. за это время вполне могут откиснуть tcp сессии,
>застопорится картинка в потоковом видео и возникнет неуместная пауза в разговоре
>по телефонуЕсли 30 в скрипте заменить на 3 что-то принципиально изменится?
>Таки прошу прощения, что включаюсь в столь активную дискуссию, но у меня
>есть ответы на ваши вопросы:
>- разбиение на area как правильно действительно определяется количеством маршрутизаторов, но
>конкретное значение носит сугубо рекомендательный характер: не больше сотни маршрутизаторов в
>одной области
>- время перестройки на резервный канал для ospf составит, скажем, 3 секунды
>(не вижу смысла приводить в его в неких абстрактных hello timeout)
>Некие абстрактные hello timeout, которые на самом деле hello intervals -- это как раз те значения в которых измеряется такой интервал, как DeadInterval (Таймер, который начинает отсчитываться после того как маршрутизатор перестает слышать hello пакеты от соседа и по истечению которого сосед считается ушедшим в down). Только по истечению этого таймера ospf будет считать маршрут недоступным (а точнее маршруты через этого соседа).
Как правило hello interval = 10 sec, dead = 40 (для броадкаст сетей и point=to-point соединений).А вот Ваше утверждение о 3х секундах весьма любопытно.
Значения таймеров можно изменить. Однако слишком маленькие значения могут привести к тому, что у Вас, к примеру, из-за "плохого" канала пропадут hello пакеты. Тогда запустится таймер DeadInterval и если он у Вас 3-4 секунды, то Вы перестроитесь на резервный канал, хотя основной у Вас не падал. И такое будет происходить каждый раз при малейших проблемах с каналом.
Хотелось бы узнать, существует возможность в сети с двумя независимыми интернет-каналами, заставить один канал работать только как исходящий, а другой как приходящий? К примеру SYN шлются через первый канал, а ACK возвращаются через второй.
только если провайдер разрешит :)
>Хотелось бы узнать, существует возможность в сети с двумя независимыми интернет-каналами, заставить
>один канал работать только как исходящий, а другой как приходящий? К
>примеру SYN шлются через первый канал, а ACK возвращаются через второй.
>Исходящий трафик вы можете (теоретически) отправлять по тому каналу,
по которому вам захочется.
На то по какому каналу будут возвращаться ответы
вы можете влиять только устанавливая тот или иной обратный адрес.Пример, который приводится в статье,
с не большими доработками, может вам помочь.. /etc/network/gateways
ip rule add from $IP1 lookup 2
ip rule add from $IP2 lookup 3
ip route add default via $GW1 table 2
ip route add default via $GW2 table 3
ip route add default via $DEFAULTGWВообще, этот все необходимое изложено в отличном документе
LARTC.
Что касается поправки «теоретически» и замечания «если провайдер разрешит»,
то здесь, вероятно, имеется в виду то, что один из провайдеров (тот, который будет
транспортировать ответы) может выполнять динамеческую фильтрацию трафика,
и он решит, что ответы, которые приходят без запросов (а запросы-то ушли по другому каналу, но он этого не знает), это зло и будет их убивать.Вариант маловероятный, но возможный. В этом случае нужно просто попросить провайдера чтобы он так не делал.
Второй случай, более вероятный, что первый провайдер, то есть тот, через которого уходят
запросы, заблокирует их на том основании, что трафик приходит с обратным адресом
через интерфейс, по которому этот обратный адрес достичь невозможно (мы ведь помним, что в качестве обратного адреса у нас указан наш второй канал, доступный через другого провайдера). То есть, выполнит так называемый антиспуфинг (antispoof).Если ни антиспуфинг, ни динамическая фильтрация провайдерами не выполняется,
всё будет работать.
>[оверквотинг удален]
>. /etc/network/gateways
>ip rule add from $IP1 lookup 2
>ip rule add from $IP2 lookup 3
>ip route add default via $GW1 table 2
>ip route add default via $GW2 table 3
>ip route add default via $DEFAULTGW
>
>Вообще, этот все необходимое изложено в отличном документе
>LARTC.
>Представим себе маршрутизатор с тремя интерфейсами. Два линка к провайдерам, один - в офисную сетку, куда он раздает интернет.
В случае такой настройки (вышеприведенной), офис не получит доступ к "внешним" адресам сервера. Ведь правила (ip rule add) необходимо добавлять в верх списка правил ? Тогда соответственно в локальную сеть их надо отправлять отдельным правилом, чтобы они не уходили на шлюзы провайдера.
Имхо это так, чето на эту тему я колдовал с сервером... Поправьте, если не прав.
Поправляем.В таблицы 2 и 3 нужно добавить ещё правила для маршрутизации в локальную сеть.
Подробно расписал здесь:
http://xgu.ru/wiki/gw/source_policy_routing
Придумывают всякое говно типа OpenVPN и потом его к нему такие же костыли лепят. Юзать надо стандартные решения, multi-link PPP например, который умеет mpd.
Есть маленький нюанс - впн клиент в винде не применим для использования VoIP, т.к. вносит чудовищные задержки. Сервером выступает Mpd.Вылечилось использованием OpenVPN, который, к тому же, имеет удобный клиент, умеющий автоматически подключаться к серверу. Самое то для мобильных пользователей.
>Придумывают всякое говно типа OpenVPN и потом его к нему такие же
>костыли лепят. Юзать надо стандартные решения, multi-link PPP например, который умеет
>mpd.Зря вы на OpenVPN наехали.
Вопрос, можно ли поднять multilink PPP где на концах
кадого линка будут разные провайдеры?
Покажите как решить такую задачу с помощью OSPF
Кому вопрос и какую такую?
... и причем здесь OSPF?
>Придумывают всякое говно типа OpenVPN и потом его к нему такие же
>костыли лепят. Юзать надо стандартные решения, multi-link PPP например, который умеет
>mpd.Вы почитайте про историю создания OpenVPN. Автор его сделал именно потому, что наелся говна всякого типа multilink ppp, PPTP, IPSec, PPP over SSH и прочее. Это вечный гемор с фаерволами. Кто часто ездит в командировки, то знает эти грабли.
OpenVPN работает даже через HTTP-прокси. Так что, если с темой не знакомы, то не делайте скоропалительных выводов.
Кстати, multi-link PPP предназначен для модемных соединений. Удачи вам запустить его в режиме работы через разных провайдеров. Даже если это у вас получится, то скорость вам ОЧЕНЬ не понравится.
Я вам больше скажу.При соответствующей сноровке и знании дела
OpenVPN можно поднять не только поверх HTTP,
но даже и поверх пингов (то есть, ICMP)
и даже поверх DNS.Вот представьте,
если у вас изнутри сетки внешние доменные имена
резолвятся, то этого уже достаточно чтобы
поднять туннель наружу.(правда тут не только OpenVPN будет использоваться,
но сверху можно и OpenVPN)
Ну у _Вас_ - может быть, a у _нас_ и имена резольвятся и хрена ты такой тунель поднимишь :) Причем это не rocket science - почти во всех вменяемых сетях это заткнуто.
>Ну у _Вас_ - может быть, a у _нас_ и имена резольвятся
>и хрена ты такой тунель поднимишь :) Причем это не rocket
>science - почти во всех вменяемых сетях это заткнуто.А зачем собственно?
Наша сеть представляется мне вполне вменяемой, хотя ничего у нас не позатыкано: если пользователь хочет поднять туннель через днс-пакеты вместо нормального ip, то это его полное право.
Расскажите, пожалуйста, в двух словах
как закрыть туннель через DNS,
если это возможно
что то туплю.
есть 2 канала от одного и того же провайдера в разных офисах связанных между собой отдельной линией.
как переключить на второй офис в случае падения канала в первом понятно, но что то немогу представить, как переключить обратно, когда канал в первом офисе восстановится? не будешь же при каждой проверке переключать маршрут обратно и пинговать...