>>понятное дело, ведь сесии маскарад нужно править, ведь с какого адреса пакеты
>>будут
>>уходить, предсказать практически невозможно.
>>в таком разе предлагаю маскарад прописывать отдельно для каждого интерфейса.
>
> Маскарад был прописан для каждого - проблема с сообщениями
>ядра исчезла после правки ПОСТРУТИНГА с -j MASQUARADов на -j SNAT
>--to-address $STATIC_IP ($STATIC_IP1) (вроде так)
> Юзеры возрадовались, но openvpn тунелль с Волгограда до Нижнего
>не поднялся с equalize nexthopами, соответственно пришлось сделать ip route replace
>default nexthop .... c перекосом weight 3 к 1 (в сторону
>основного прова) - openvpn запахал - но радовался я недолго -
>он начал рвать соединение спустя некоторое время (судя по всему часть
>пакетов он пытался пихнуть на второй интерфейс - юзеры начали вопить
>что не могут залезть на терминальный сервак в волгограде). Пока включил
>1 дефолтовый маршрут.
>
>Может есть идеи как разрулить эту ситуацию ? идеи-то конечно есть,из того, что приходит в голову
1. для начала попробовать на удаленной стороне ovpn в конфигурации убрать адрес peer,
если конечно локальный ovpn выступает как клиент. работа не гарантирована, но попробовать
стоит.
2. соорудить 2 ovpn и опять-таки указать в маршрутизации multipath, хотя для этого дела
придется попотеть над рисованием скриптов, которые будут такие манипуляции производить
при ip/down ovpn интерфейса.
>Раз уж не выходит с балансировкой - может есть возможность настроить использование
>основного маршрута с авто переключением на второго прова в случае аварии
>(без костылей вроде пингования) ?
без костылей или bgp это врядли получится, хотя возможны варианты, какими интерфейсами ты
подключен к своим провайдерам ?