Резервирование маршрутизации между двумя офисами. Нужен совет

[RTC]

Доброго времени суток

Нужен совет, т.к. собственного опыта в описанной ситуации пока нет, а поиски в интернет, к сожалению, не увенчались успехом

Итак, имеем два офиса.
Офис 1: локалка с выделенным сервером Win2003, интернет ADSL

Сеть 192.168.0.0/24
Шлюзом служит сервер 192.168.0.1
ADSL модем подключен ко второму интерфейсу сервера. Клиентские машинки ходят в интернет через работющий на сервере прокси Kerio WinRoute
Вобщем, классика жанра и ничего "эдакого"

Офис 2: локалка без выделенного сервера (мини-офис, меньше 10 рабочих мест) подключения к интернет нет
Сеть 192.168.1.0/24

Офисы соедиенны предоставленным городским провайдером каналом 4Mb.
В каждый из офисов заведен Ethernet-интерфейс, подключенный непосредственно к коммутаторам. Провайдером установлены IP адреса подключений 192.168.0.11 для офиса 1 и 192.168.1.11 для офиса 2 соответственно. Весь трафик с 192.168.0.11 бросается на 192.168.1.11 и наоборот.
На каждой клиентской машине (XP Pro) добавлен статический маршрут на сеть другого офиса
Для офиса 1: 192.168.1.0 mask 255.255.255.0 192.168.0.11 metric 10
Для офиса 2: 192.168.0.1 mask 255.255.255.0 192.168.1.11 metric 10
Локальные имена разрешаются через файлы lmhosts
Клиенты офиса 2 подключаются к сервисам, работющим на сервере офиса 1 и ходят через него же в интернет
Эта связка работает, никаких проблем с ней нет. А с учетом того, что менятся что-либо в этих сетях крайне редко, то и использование статических ip и lmhosts для разрешения имен не вызывают особых трудностей

Далее
Есть необходимость обеспечить резервирование имеющегося канала
В наличии выделенная медная пара, предоставляемая провайдером телефонии и два SHDSL модема Planet GRT-101, которые на имеющейся линии обеспечивают скорость подключения 512Kb. Модемы настроены в режиме роутеров, по аналогии с основным каналом связи ,включены непосредственно в коммутаторы каждого из офисов и имеют ip адреса 192.168.0.12 на стороне офиса 1 и 192.168.1.12 на стороне офиса 2, в таблицы маршрутизации клиентских машин добавлены маршруты
Для офиса 1: 192.168.1.0 mask 255.255.255.0 192.168.0.12 metric 20
Для офиса 2: 192.168.0.1 mask 255.255.255.0 192.168.1.12 metric 20

Теперь, собственно, вопрос
Насколько я понимаю, дальше для обеспечения переброски трафика на резервный канал необходимо определить момент обрыва основного канала и поменять метрики в таблицах маршрутизации клиентских машин.
Есть ли каке-либо системные средства для этого?
Или необходимо выдумывать собственную автоматизацию (например, периодический ping и в зависимости от результата - смена метрик?)

Возможно, кто-то сталкивался с такой задачей, просьба посоветовать наиболее простое и эффективное решение
Хотелось бы избежать применения аппаратных маршрутизаторов, хоть интуитивно догадываюсь, что именно это было бы более верным решением

Спасибо

[QRS]

Насколько я понимаю, дальше для обеспечения переброски трафика на резервный канал необходимо определить момент обрыва основного канала и поменять метрики в таблицах маршрутизации клиентских машин. »
На примере работы Windows XP с двумя шлюзами могу предположить, что в этом нет необходимости, т.к. клиентские машины сами будут пытаться переключиться на резервный канал в случае появления потерь на основном канале. Другой вопрос, что Вы не сможете сделать этого централизованно и у Вас почти всегда буду задействованы обе линии.

Хотелось бы избежать применения аппаратных маршрутизаторов, хоть интуитивно догадываюсь, что именно это было бы более верным решением »
Вы правы - это наиболее верное решение, хотя можно обойтись и программными маршрутизаторами (Windows server 2003+).

Офисы соедиенны предоставленным городским провайдером каналом 4Mb.
В каждый из офисов заведен Ethernet-интерфейс, подключенный непосредственно к коммутаторам. Провайдером установлены IP адреса подключений 192.168.0.11 для офиса 1 и 192.168.1.11 для офиса 2 соответственно. »

Попутно хочу обратить ваше внимание, что описываемая Вами схема - это т.н. VPN L3... в то же время весь трафик, передаваемый между офисами может прослушиваться и модифицироваться злоумышленниками (сотрудничающими с провайдером или воспользовавшиеся кривой настройкой сети провайдера, а снять сигнал с SHDSL для соответствующих органов вообще нечего делать), что однозначно не есть хорошо. В подобных случаях используется криптопреобразование, например, Kerio мог бы Вам помочь организовать site-to-site VPN.

С точки зрения отказоустойчивости можно рекомендовать два канала разнести по разным провайдерам иначе обрыв провода провайдера, который идет в один из офисов автоматически лишает Вас двух линий...

PS: о кривой настройке провайдера знаю из своего опыта... нам предоставлялся VPN L2 - провайдер сдает работы, высылает акты... я начинаю проверку всех линий (более 30 в облаке) с запущенным сниффером... откуда-то вылезает левый MAC. Провайдер сдавал сеть еще неделю - не мог найти косяк. Т.ч. использование VPN провайдера без шифрования подойдет разве что библиотеке или студенческой общаге - т.е. где подсмотреть нечего или нагадить негде; если у Вас есть конкуренты - шифруйтесь :)

PS2: когда идет речь об узком канале и количестве пользователей более 5, имеет смысл задуматься о QoS.

PS3: рекомендую cisco 18xx K9 с двумя L3 интерфейсами - отличная, хотя и недешевая вещь, для построения защищенной сети (поддерживает QoS & VoIP).

[RTC]

Спасибо, QRS

Самостоятельное переключение WinXP на другой канал уже опробовано и отвергнуто именно как неуправляемое

Буду пробовать использовать RIP. Предполагаю так:
1. На резервном канале 512 Planet GRT 101 это умеют
2. Канал VPN L3 провайдера (как Вы осовершенно правильно определили) на стороне офиса 1 подключу к отдельному интерфейсу на Win2k3, который в роли программного маршрутизатора вроде бы как тоже умеет RIP, а на стороне маленького офиса планирую задействовать простой маршрутизатор вроде Linksys BEFSR41, так же поддерживающий RIP
3. На клиентских машинах поднимаю службу "Слушателя RIP"

По идее при такой схеме таблицы маршрутизации на клиентских машинах должны перестраиваться автомтаом в зависимости от доступности маршрутизаторов, т.е. - как раз и будет обеспечено "управляемое" резервирование.

Рабочая ли такая схема, с какими нюансами можно столкнуться?
Особенно смущает использование Win2k3 в роли маршрутизатора, как то больше доверяю железякам в этом плане, но - таки проект очень бюджетный
Вобщем, просьба прокомментировать предполагаемое решение с RIP.

Спаисбо за совет по применению VPN. В данном случае прятать нечего :), так что воздержимся

[cameron]

на мой взгляд RIP как раз себе идея что надо, для данного случая
надеюсь вы помните о 30 секундном интервале в вещании рипа?

[QRS]

RTC, VPN L3 не гарантирует прохождение трафика RIP, т.к. это многоадресный (v2) или широковещательный (v1) трафик. Если RIP будет резаться провайдером, то либо настаивайте на VPN L2, либо оборачивайте весь трафик в GRE (но этого дешевые роутеры не умеют).
W2k3 в принципе нормально работает в роли маршрутизатора - у меня маршрутизация OSPF так крутилась несколько лет.

Кстати, Вы бы нарисовали схемку с адресами и сетевым оборудованием и выложили бы в топике... по тексту сложно понять что Вы куда хотите поставить...например, в малом офисе у Вас два отдельных роутера... через два канала выходят на W2k3 сервер с двумя сетевыми.
Скорее всего провайдер Вам адреса VPN L3 не поменяет и Вам придется давать новые диапазоныы адресов в оба офиса!

PS: про клиентские машины с RIP я не подумал - красиво! (хотя и не без изъянов - я все же придерживаюсь идеи, что принимать решение о пути прохождения трафика должен роутер, а не клиентская ОС).

[RTC]

cameron, спасибо за напоминание, переключение в пределах минуты вполне приемлемо в данном случае

QRS, Вы снова оказались правы. RIP трафик через VPN L3 не проходит.
Обратился к провайдеру с запросом, но пока тишина - контора большая, общаться приходится только с менеджерами, до инженеров не достучаться, так что жду. Кстати, может просветите чем в практике для провайдера отличается реализация схемы VPN L2 от VPN L3 и от чего чаще всего зависит возможность реализации первой или второй схемы?

Схемку выложу, добраться бы только до visio. Думаю, уже по результатам изображу и опишу, може кому сгодится

А придумка с RIP на клиентских машинах - это ж не от хорошей жизни. Голь, как говорится, на выдумки хитра - так и живем.