| 1.1, Аноним (-), 17:46, 19/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Сложно-то как. Эх, старые добрые дистрибутивы с простыми скриптами, как мне вас не хватает.
И каждый стремится доработать напильником..
| | |
| 1.2, Михаил (??), 18:26, 19/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 То есть ты считаешь этот скрипт сложным? Нда.... Двадцать строк на баше уже считаются сложными. Человеку спасибо надо сказать, за то, что он тратит свой время для обучения новичков. Для которых это действительно на начальном этапе сложно.
ЗЫ: Ничего личного, но кто тебе мешаешь выложить красиво оформленную, грамотно написанную статью такого же плана.
| | |
| |
| 2.3, Аноним (-), 18:53, 19/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Считаю лишним заводить дополнительные переменные, редактировать стандартные скрипты дистрибутива. Подобные вещи настраиваются, фигурально говоря, один раз. Достаточно внешнего скрипта.
Человеку СПАСИБО за потраченное на красивую статью время.
p.s. будет подходящая, по моему мнению, тема, тогда выложу.
| | |
|
| 1.4, sash (??), 20:38, 19/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хотел спросить, а почему бы для такой задачи не использовать OSPF?
| | |
| |
| 2.6, Аноним (-), 21:47, 19/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
Можно и это более эффективно и надежно. Не нужны никакие погремушки со скриптами.
Просто поднять OpenVPN через разных провайдеров и запустить внутри туннеля OSPF.
Тот, кто хорошо знаком с маршрутизацией, тот так и сделает. Кто не знаком, тот будет скриптами разруливать.
| | |
| |
| 3.8, Аноним (-), 22:34, 19/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
Дело в постановке задачи. Правильной постановке.
В варианте один ставится задача обеспечить функционирование туннеля по каналу с резервированием через другого провайдера. Во втором случае, задача состоит в том, чтобы обеспечить соединение между двумя узлами через общедоступную сеть. Второй случай более общий, поэтому предполагает некоторое разнообразие вариантов для выбора. :)
При первом варианте постановки задачи, статья имеет кое-какой смысл.
| | |
| 3.9, xguru (?), 23:03, 19/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
1) Вы считаете, что держать два туннеля OpenVPN одновременно
и поднимать поверх них OSPF более эффективно и надёжно чем
элементарная проверка маршрута и переход с одного на другой?
2) Как вы считаете, какое решение является более масштабируемым?
С OSPF over OpenVPN или передёргиванием шлюза?
Как вы думаете, сколько таких каналов можно будет поднять?
3) Если предположить, что кроме поднятия туннеля в центр
необходимо ещё какое-то обращение к Интернет (имеется в виду обращения напрямую,
а не в обход — через OpenVPN-туннель), как вы себе видите
решение задачи предложенным вами способом?
| | |
| |
| 4.11, guest (??), 23:37, 19/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
не автор статьи, но рискну ответить :-)
1. Мне кажется да, особенно если запуск ospf & openvpn производится без написания каких-либо скриптов - просто поставили через стандартный менеджер пакетов, поправили пару конфигурационных файлов и вперёд.
2. Описанное в первом пункте - масштабирование элементарно - правкой конфигурационных файлов, хотя не исключено, что для удобства это будет делаться через cfengine или нечто аналогичное. Количество каналов определяется исключительно возможностями железа - хоть сотни!
3. Элементарно - ставим default route на провайдера(ов), а внутренние маршруты получаем по ospf
Примечание: предполагается, что всё вышесказанное осуществляется на линуксе, который установлен на приличном железе.
| | |
| |
| 5.12, xguru (?), 23:59, 19/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>
>1. Мне кажется да, особенно если запуск ospf & openvpn производится без
>написания каких-либо скриптов - просто поставили через стандартный менеджер пакетов, поправили
>пару конфигурационных файлов и вперёд.
>
>2. Описанное в первом пункте - масштабирование элементарно - правкой конфигурационных файлов,
>хотя не исключено, что для удобства это будет делаться через cfengine
>или нечто аналогичное. Количество каналов определяется исключительно возможностями железа - хоть
>сотни!
>
«Хоть сотни» это конечно звучит :)
Вопрос к знатокам OSPF:
зачем в OSPF существует понятие area?
И начиная со скольки записей в таблице описания топологий
при условии что демоны маршрутизации исполняются
на современном железе есть смысл создавать несколько area?
>3. Элементарно - ставим default route на провайдера(ов), а внутренние маршруты получаем
>по ospf
>
Вот это подробнее.
У вас два провайдера.
На кого вы ставите default route?
Или вы ставите сразу два default route?
>Примечание: предполагается, что всё вышесказанное осуществляется на линуксе, который установлен на приличном
>железе.
Да.
Центр на приличном железе,
а отделения не так важно на каком железе.
Про это согласен.
| | |
| 5.21, Аноним (-), 19:20, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
OSPF и AREA.
AREA - это просто область в которой несколько подсетей и обычно несколько роутеров.
Разделение на области сделано для того, чтобы более оптимально передавать информацию о маршрутах, если сеть большая и роутеров много.
Обмен информацией между AREA идет через специальную AREA c номером НОЛЬ.
Вот вкрадце и все.
Для вашего случая поднимите OSPF на обоих концах с AREA 0, пропишите туда свои внутренние сети и получите щастье. Да, еще OSPF надо настроить для работы в режиме NBMA.
Сам протокол OSPF переключит маршрут на другой OpenVPN, если один из каналов поляжет. В протоколе OSPF заложены функции обнаружения пропадания канала и правки таблицы маршрутизации. Вы скриптами сделали тоже самое. Т.е. изобрели велосипед. Ну изобрели и изобрели, что ж делать-то...
Шлюз по умолчанию переключать надо для Интернет-трафика. Т.е. для ваших офисных пользователей, которые Асю юзают, к примеру :) Тут скрипты рулят, т.к. BGP и OSPF вам провайдер не даст. Но для решения задачи отказоустойчивых каналов между офисами можно было обойтись только двумя OpenVPN-ами и OSPF. Это вам любой приличный сетевик скажет.
| | |
| |
| 6.22, Аноним (-), 19:28, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Про масштабируемость OSPF: Масштабируется только в путь. Более того, если у вас стоит серьезное железо а-ля Циска, Джунипер, Алкатель, 3СОМ и иже с ними, то можете это решение легко с ними интегрировать, OSPF довольно сильно масштабируется.
Если упретесь в ограничения OSPF, то делайте тоже самое на BGP. У него проблем с масштабируемостью нет. На BGP весь Интернет работает.
Если тема интересна, то найдите книгу "Создание масштабируемых сетей" издательства Cisco Press. Там подробно расписано про протоколы динамической маршрутизации.
| | |
| |
| 7.26, xguru (?), 20:12, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Про масштабируемость OSPF: Масштабируется только в путь. Более того, если у вас
>стоит серьезное железо а-ля Циска, Джунипер, Алкатель, 3СОМ и иже с
>ними, то можете это решение легко с ними интегрировать, OSPF довольно
>сильно масштабируется.
>
>Если упретесь в ограничения OSPF, то делайте тоже самое на BGP. У
>него проблем с масштабируемостью нет. На BGP весь Интернет работает.
>
>Если тема интересна, то найдите книгу "Создание масштабируемых сетей" издательства Cisco Press.
>Там подробно расписано про протоколы динамической маршрутизации.
Правильно ли я вас понял, что вы рекомендуете вместо
описанно в заметке примитивного скрипта на 10 строчек
поднимать BGP?
| | |
| |
| 8.27, sash (??), 20:24, 20/09/2007 [^] [^^] [^^^] [ответить] | +/– | Не передергивайте Человек ясно сказал - не хватает OSPF - используйте BGP А... текст свёрнут, показать | | |
| |
| 9.28, xguru (?), 20:39, 20/09/2007 [^] [^^] [^^^] [ответить] | +/– | Где два туннеля Вы хотели сказать два умножить на количество удалённых точек Ч... текст свёрнут, показать | | |
| |
| |
| 11.30, xguru (?), 23:12, 20/09/2007 [^] [^^] [^^^] [ответить] | +/– | Я не прошу ничего доказать Выше были упомянуты 30 секунд --- периодичность, с к... большой текст свёрнут, показать | | |
| |
| 12.32, sash (??), 02:50, 21/09/2007 [^] [^^] [^^^] [ответить] | +/– | Так уж получилось, что подобную задачу мне необходимо решить в ближайшее время ... текст свёрнут, показать | | |
|
|
|
|
|
|
| 6.25, xguru (?), 20:10, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
...
>AREA - это просто область в которой несколько подсетей и обычно несколько
>роутеров.
>
>Разделение на области сделано для того, чтобы более оптимально передавать информацию о
>маршрутах, если сеть большая и роутеров много.
(спасибо, что вы это сказали; идём дальше)
>[оверквотинг удален]
>
>Для вашего случая поднимите OSPF на обоих концах с AREA 0, пропишите
>туда свои внутренние сети и получите щастье. Да, еще OSPF надо
>настроить для работы в режиме NBMA.
>
>Сам протокол OSPF переключит маршрут на другой OpenVPN, если один из каналов
>поляжет. В протоколе OSPF заложены функции обнаружения пропадания канала и правки
>таблицы маршрутизации. Вы скриптами сделали тоже самое. Т.е. изобрели велосипед. Ну
>изобрели и изобрели, что ж делать-то...
>
Большое спасибо за такое подробное и трогательное объяснение.
Повторяю вопрос:
по вашему мнению, сколько узлов вы подразумеываете в сети,
когда пишите «большая сеть и роутеров много».
Начиная с какого количества узлов рекомендуется делать
разбиение на AREA и не ограничиваться использованием одной лишь
AREA 0.
Если это определяется количеством узлов.
Если же нет, то чем это определяется, и когда в таком случае
следует делать разбиение?
| | |
| |
| 7.34, Аноним (-), 00:39, 23/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
Таки прошу прощения, что включаюсь в столь активную дискуссию, но у меня есть ответы на ваши вопросы:
- разбиение на area как правильно действительно определяется количеством маршрутизаторов, но конкретное значение носит сугубо рекомендательный характер: не больше сотни маршрутизаторов в одной области
- время перестройки на резервный канал для ospf составит, скажем, 3 секунды (не вижу смысла приводить в его в неких абстрактных hello timeout)
- при всём моём уважении к Вашим усилиям, 30 секунд время решительно неприемлемое т. к. за это время вполне могут откиснуть tcp сессии, застопорится картинка в потоковом видео и возникнет неуместная пауза в разговоре по телефону
| | |
| |
| 8.38, guest (??), 16:19, 29/09/2007 [^] [^^] [^^^] [ответить] | +/– | Некие абстрактные hello timeout, которые на самом деле hello intervals -- это ка... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 1.5, Аноним (-), 21:39, 19/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хотелось бы узнать, существует возможность в сети с двумя независимыми интернет-каналами, заставить один канал работать только как исходящий, а другой как приходящий? К примеру SYN шлются через первый канал, а ACK возвращаются через второй.
| | |
| |
| 2.10, xguru (?), 23:12, 19/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Хотелось бы узнать, существует возможность в сети с двумя независимыми интернет-каналами, заставить
>один канал работать только как исходящий, а другой как приходящий? К
>примеру 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).
Если ни антиспуфинг, ни динамическая фильтрация провайдерами не выполняется,
всё будет работать.
| | |
| |
| 3.13, PavelR (??), 07:37, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>. /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) необходимо добавлять в верх списка правил ? Тогда соответственно в локальную сеть их надо отправлять отдельным правилом, чтобы они не уходили на шлюзы провайдера.
Имхо это так, чето на эту тему я колдовал с сервером... Поправьте, если не прав.
| | |
|
|
| 1.14, nuclight (?), 12:04, 20/09/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Придумывают всякое говно типа OpenVPN и потом его к нему такие же костыли лепят. Юзать надо стандартные решения, multi-link PPP например, который умеет mpd.
| | |
| |
| 2.15, PavelR (??), 12:19, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Есть маленький нюанс - впн клиент в винде не применим для использования VoIP, т.к. вносит чудовищные задержки. Сервером выступает Mpd.
Вылечилось использованием OpenVPN, который, к тому же, имеет удобный клиент, умеющий автоматически подключаться к серверу. Самое то для мобильных пользователей.
| | |
| 2.17, xguru (?), 13:09, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Придумывают всякое говно типа OpenVPN и потом его к нему такие же
>костыли лепят. Юзать надо стандартные решения, multi-link PPP например, который умеет
>mpd.
Зря вы на OpenVPN наехали.
Вопрос, можно ли поднять multilink PPP где на концах
кадого линка будут разные провайдеры?
| | |
| 2.23, Аноним (-), 19:37, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Придумывают всякое говно типа OpenVPN и потом его к нему такие же
>костыли лепят. Юзать надо стандартные решения, multi-link PPP например, который умеет
>mpd.
Вы почитайте про историю создания OpenVPN. Автор его сделал именно потому, что наелся говна всякого типа multilink ppp, PPTP, IPSec, PPP over SSH и прочее. Это вечный гемор с фаерволами. Кто часто ездит в командировки, то знает эти грабли.
OpenVPN работает даже через HTTP-прокси. Так что, если с темой не знакомы, то не делайте скоропалительных выводов.
Кстати, multi-link PPP предназначен для модемных соединений. Удачи вам запустить его в режиме работы через разных провайдеров. Даже если это у вас получится, то скорость вам ОЧЕНЬ не понравится.
| | |
| |
| 3.24, xguru (?), 20:03, 20/09/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Я вам больше скажу.
При соответствующей сноровке и знании дела
OpenVPN можно поднять не только поверх HTTP,
но даже и поверх пингов (то есть, ICMP)
и даже поверх DNS.
Вот представьте,
если у вас изнутри сетки внешние доменные имена
резолвятся, то этого уже достаточно чтобы
поднять туннель наружу.
(правда тут не только OpenVPN будет использоваться,
но сверху можно и OpenVPN)
| | |
| |
| 4.33, GR (??), 20:21, 21/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
Ну у _Вас_ - может быть, a у _нас_ и имена резольвятся и хрена ты такой тунель поднимишь :) Причем это не rocket science - почти во всех вменяемых сетях это заткнуто.
| | |
| |
| 5.35, Аноним (-), 00:43, 23/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Ну у _Вас_ - может быть, a у _нас_ и имена резольвятся
>и хрена ты такой тунель поднимишь :) Причем это не rocket
>science - почти во всех вменяемых сетях это заткнуто.
А зачем собственно?
Наша сеть представляется мне вполне вменяемой, хотя ничего у нас не позатыкано: если пользователь хочет поднять туннель через днс-пакеты вместо нормального ip, то это его полное право.
| | |
| 5.37, Аноним (-), 20:05, 26/09/2007 [^] [^^] [^^^] [ответить]
| +/– |
Расскажите, пожалуйста, в двух словах
как закрыть туннель через DNS,
если это возможно
| | |
|
|
|
|
| 1.39, Denis (??), 16:50, 20/05/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 что то туплю.
есть 2 канала от одного и того же провайдера в разных офисах связанных между собой отдельной линией.
как переключить на второй офис в случае падения канала в первом понятно, но что то немогу представить, как переключить обратно, когда канал в первом офисе восстановится? не будешь же при каждой проверке переключать маршрут обратно и пинговать...
| | |
|
