Смоленский Форум

Суть проблемы в том, что Ман-сеть глючит. конкретно сегодня раз 10 за вечер интернет пропадал разными способами: то к VPN-серверу не коннектится, то коннектится, но интернета нет. В общем напрягает.
Есть в наличии 2 канала связи: Ман-сеть через Ethernet - основной
Домолинк через ADSL - резервный.
Оба линка подняты одновременно.
На случай отваливания интернета написаны батнички с названиями sci.cmd (route change 0.0.0.0 MASK 0.0.0.0 192.168.1.253) и и mannet.cmd (route change 0.0.0.0 MASK 0.0.0.0 192.168.1.254), которые лежат в системном каталоге (а он как известно прописан в PATH) и вручную запускаются и оперативно меняют шлюз по умолчанию без обрыва коннекта (.253 - Домолинк, .254 - Ман-сеть).
Это позволяет восстановить работоспособность втечение нескольких секунд после обнаружения проблем с одним из каналов связи.
Проблема в том, что открытые SSH-сессии отваливаются, т.к. TCP-соединение было открыто во-первых с линуксовой машины, на которой шлюз я не меняю (хотя аналогичные батнички написать не проблема, но это не решит проблему), а во-вторых даже если бы я открывал их с виндовой машины, то после смены шлюза по умолчанию они отвалятся, т.к. при работающей Ман-сети соединения NAT-ятся роутером с IP-шником Ман-сети, а при смене шлюза они же теперь будут идти через ADSL-ный модем и будут NAT-иться адресом ЦентрТелекома. В общем самым простым решением видится здесь применение SCTP, который применяется как раз для multihomed-хостов так чтобы в случае отвала одного канала связи трафик мог идти через другой.

Вопрос в том стоит ли вообще пробовать, каковы перспективы, может у кого был опыт применения SCTP? Или может есть какое-то другое решение?
Подключиться к Билайну или там еще какому-то провайдеру - не выход, т.к. отвалиться может любой канал связи, даже если их будет 3 штуки - это ничего не меняет. Нужно решение именно по резервированию "на лету", которое позволяло бы работать без прерывания уже установленных коннектов
при отваливании одного из каналов связи.

Георгий писал(а): Вопрос в том стоит ли вообще пробовать, каковы перспективы, может у кого был опыт применения SCTP? Или может есть какое-то другое решение?

Стоит, конечно, если ты чувствуешь в себе силы переписать SSH под SCTP :)
Альтернатива - screen

_blackdog писал(а):

Георгий писал(а): Вопрос в том стоит ли вообще пробовать, каковы перспективы, может у кого был опыт применения SCTP? Или может есть какое-то другое решение?

Стоит, конечно, если ты чувствуешь в себе силы переписать SSH под SCTP :)
Альтернатива - screen

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

кстати интересный вариант нашел: http://2007.eurobsdcon.org/talk-tcp-sct ... -shim.html

Автоматически - это 2 GRE тунеля и динамический протокол маршрутизации с тюнингованным конвержденсом
А еще Циски поддерживают HA IPSEC, только за очень дорого

_blackdog писал(а):Автоматически - это 2 GRE тунеля и динамический протокол маршрутизации с тюнингованным конвержденсом
А еще Циски поддерживают HA IPSEC, только за очень дорого

подробнее можешь рассказать что нужно сделать?
я так понял надо поставить сервер в интернете (есть такой сервер), до него сделать 2 туннеля из дома - каждый через своего провайдера.
Настроить NAT на сервере в инете чтобы все входящее через оба туннеля отправлялось в интернет уже от одного фиксированного интерфейса (IP-адреса). Тогда задача сводится к тому чтобы научиться пускать трафик по второму туннелю в случае падения первого.
Как ее решить, куда копать?

Ну, мне нечего добавить к тому, что ты написал, все правильно
трафик по тунелям будет раскладывать протокол маршрутизации (OSPF, например) Т.к. это link-state протокол, то он на протокольном уровне отслеживает состояние интерфейсов (с твоем случае GRE) и будет автоматически стирать маршруты через не функционирующие линки. Единственное, надо будет уменьшить keepalive - если не ошибаюсь маршрут стирается если пропушено 3 keepalive подряд. Иначе есть шанс, что TCP таймаут придет первым и порвет сессию