в схеме где то не отрабатывает принцип "труб" (одна "труба" для ванов 1 другая для ванов 2), при отключении одной трубы все ее соединения должны отрубаться
почему не ложится ipsec1 мне пока непонятно (из-за этого схема то и не работает), разбираться пока не хочу, мне эта схема из "труб" несимпатична
у меня есть одна дикая идея, но ее надо попробовать
сначала хочу уточнить два момента:
1) цель всего мероприятия - просто failover ipsec между сетями, т.е. чтоб при пропадании какого-либо интерфейса сохранялась связь между сетями?
2) дср поддерживает объединение в группы адресов и интерфейсов? (с дср не сталкивался)

1 - в основном да
2 - в том то и дело, что нет..

на дфле в качестве второго вана настроен дмз

_________________
понял настроил забыл

это не важно


а это засада, это точно?

есть возможность взять у Д-линк на тестирование дфл?

это точно, ибо чересчур круто будет для дСР.)))
есть возможность взять ДФЛ у себя.
Ибо есть два дфл 860 и 260, но для полноценного теста дома не хватает ещё одного интернета. только три конца есть.

надо будет проверить схему 2+1, кстати..

_________________
понял настроил забыл

Попробовал вот по этой схеме сделать ещё раз. С динамическими туннелями.
download/file.php?id=5165

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

Ох, вообщем ладно.. сдается мне, что проблема в дср. Как только нахлобучиваешь ДФЛ сложными правилами, мониторингом, пбэром и т.д - ДСР ничего не понимает.
Остается последний вариант - поставить у клиента ДФЛ и у себя ДФЛ и проверить обе схемы со статическими айписеками и с динамическими и с пбэрами. И убедится, что всё работает.
С ДСР только простецкие варианты прокатывают. Обычные туннели он с ДФЛ цепляет на раз два..
Но, если всё заведется на ДФЛэлах, то из ДСР можно сделать только свич )))

_________________
понял настроил забыл

в общем позвонил в свой Д-Линк, там сказали по этому поводу:
1) ДСР не может мониторить ip_sec что-бы реализовать fail_over (wan интерфейсы может) - аппаратные ограничения (ip_sec fail_over, группы адресов и интерфейсов это все за счет аппаратной поддержки в dfl, так сказали), т.е. на ДСР надо запрещать поднятие ip_sec при отсутствии какого-либо wana правилами маршрутизации
2) со стороны ДСР можно обращаться не к IP адресу, а к dyn-dns имени (типа как к группе адресов на dfl)

то есть то, что мне приходится на дфл выключать роут вида - айписек1 ремоутнэт и отключать мониторинг на роуте второго айписека (тоже на дфл) для того чтобы пошли данные по резевному айписеку - виноват во всём ДСР?
может сегодня просто по тимвьюверу глянете, что у меня на дфл всё правильно и я успокоюсь.

а так да - на дср всё просто как две копейки. делаешь два айписека - один на первые два вана, второй на вторые и один вставляешь в другой.
Указываешь, что второй резервный.
Мониторится всё по ванам и переключение айписеков соответственно через ваны идёт.
То есть мне кажется, что должно работать в паре с дфл и что упрямится именно ДФЛ.

_________________
понял настроил забыл

я это сделал. чуть позже отпишусь...

_________________
понял настроил забыл

За основу были взяты инструкции от Данилова 2+2 и 2+1 и неделя творческого подхода.

Сначала по ДСР.
На нём настроено автопереключение ванов (по пингу хоста) то есть постоянно доступен только один ван. Настроено резервирование айписеков (по сути это тоже переключение ванов). Всё.

ДФЛ
Сделал только одну альтернативную таблицу на ван2 (ван2-оллнетс-ван2гейт).
Правило маршрутизации - ван2-оллнетс-эни-оллнетс (форвард-мэйн, ретёрн-альтван2).
Сделал один айписек на группу ванов ДСР в ремот ендпойнте.
Мониторится только ван1-оллнетс-ван1гейт.

Итого- айписеки переключаются и самое главное назад потом возвращаются (проверял путём отключения вана1 на дфл, соответственно ван1 на ДСР тоже ложится), пинги идут, никаких задвоений SA - четко нужное.
И со стороны ДФЛ одновременная доступность двух ванов как бонус.

И впрямь надо от простого к сложному идти, а не наоборот. И главное - ДСР чётко отрабатывает переключение.

_________________
понял настроил забыл

от души поздравляю!
главное не отчаиваться:)
а со стороны дср, какая привязка удаленных точек туннелей к интерфейсам дср (один туннель: wan1_dsr - ip_wan1_dfl, воторой: wan2_dsr - ip_wan2_dfl)?

да. именно так.

_________________
понял настроил забыл

надо попробовать вариант с dyn_dns именем в качестве конечной точки в туннелях на дср
по текущей схеме получается если отвалятся интерфейсы "крест-накрест" (ван1_дср и ван2_дфл), то туннель не подымется

да. попробую.
сегодня сделал вторую схему - ДФЛ - два вана, ДСР - один ван.
на ДСР сделал два туннеля, каждый на свой ван ДФЛ (как обычно один туннель вложен в другой, т.е первый основной - второй резервный (я думаю именно так ДСР и маркирует потом туннели метриками - мы просто этого в настройках вебинтерфейса не видим, но наверняка можно увидеть в таблице через ССШ).
на ДФЛ - один туннель. В правилах маршрутизации ДФЛ прописал недоступность второго вана при рабочем первом.
работает. туннели на дср переключаются при падении первого вана на ДФЛ и возвращаются обратно на первый ван ДФЛ потом, что говорит о том, что ДСР всё-таки переключать айписеки может не только путем переключения своих ванов..

_________________
понял настроил забыл

интересно, если на дср сделать таким образом 4 туннеля, (2 комплекта, от каждого вана дср на два вана дфл ), т.е. получится два туннеля с резервированием, он сможет их разрулить?

по идее должен. надо попробовать..

_________________
понял настроил забыл