Зарегистрирован: Пт мар 02, 2018 14:57 Сообщений: 57
|
YuriAM писал(а): Но кто-то реализовал и выложил инструкцию на этом форуме. Поищите тщательнее и найдете. Если не получится, то уж поможем, наверное. Основная идея там была в правильном мониторинге и отключении как IPsec каналов, так и работающих WAN каналах. Когда найдете, то выложите ее, пожалуйста, сюда так, чтобы она была вложением к посту и хранилась на сервере D-Link, чтобы точно не пропала. Или, если так уже сделано автором ранее, то киньте ссылку. Что-то очень похожее: http://www.dlink.ru/ru/faq/331/1724.htmlВ моем случае, DMZ DFL-260 я заменю на WAN DFL-260. Вот только прошивка сильно "свежее" чем та, что у меня. И некоторые настройки не представляется возможным выполнить, просто нет упоминаемых в инструкции параметров. Вот еще подобная инструкция из темы: viewtopic.php?f=3&t=175592&p=973881&hilitdoctorA писал(а): в предлагаемой схеме 2 DFL - Master & Slave
настраиваем адресную книгу Master dfl Master_lannet - 192.168.1.0/24 Master_wan1 - 1.1.1.10 Master_wan2 - 2.2.2.20 Slave_wan1 - 3.3.3.30 Slave_wan2 - 4.4.4.40 Slave_lannet 192.168.2.0/24 remote_GRE1 - 192.168.22.1 remote_GRE2 - 192.168.22.2 remote_GRE3 - 192.168.22.3 remote_GRE4 - 192.168.22.4 local_GRE1 - 192.168.11.1 local_GRE2 - 192.168.11.2 local_GRE3 - 192.168.11.3 local_GRE4 - 192.168.11.4 remote_IPSec_1 - 192.168.2.221 remote_IPSec_2 - 192.168.2.222 remote_IPSec_3 - 192.168.2.223 remote_IPSec_4 - 192.168.2.224 local_IPSec_1 - 192.168.1.221 local_IPSec_2 - 192.168.1.222 local_IPSec_3 - 192.168.1.223 local_IPSec_4 - 192.168.1.224 делаем группу адресов LOCAL_NETS, добавляем туда Master_lannet и Slave_lannet
настраиваем адресную книгу Slave dfl Slave_wan1 - 3.3.3.30 Slave_wan2 - 4.4.4.40 Slave_lannet 192.168.2.0/24 Master_lannet - 192.168.1.0/24 Master_wan1 - 1.1.1.10 Master_wan2 - 2.2.2.20 remote_GRE1 - 192.168.11.1 remote_GRE2 - 192.168.11.2 remote_GRE3 - 192.168.11.3 remote_GRE4 - 192.168.11.4 local_GRE1 - 192.168.22.1 local_GRE2 - 192.168.22.2 local_GRE3 - 192.168.22.3 local_GRE4 - 192.168.22.4 remote_IPSec_1 - 192.168.1.221 remote_IPSec_2 - 192.168.1.222 remote_IPSec_3 - 192.168.1.223 remote_IPSec_4 - 192.168.1.224 local_IPSec_1 - 192.168.2.221 local_IPSec_2 - 192.168.2.222 local_IPSec_3 - 192.168.2.223 local_IPSec_4 - 192.168.2.224 делаем группу адресов LOCAL_NETS, добавляем туда Master_lannet и Slave_lannet
далее для каждого DFL создаем по две дополнительные таблицы маршрутизации, называем их WAN1 и WAN2 WAN1: interface WAN1, Network All-nets, gateway Wan1_gw, metric 80 WAN2: interface WAN2, Network All-nets, gateway Wan2_gw, metric 80 смысл в том, чтобы весь трафик при использовании этой таблицы шел в жестко заданный WAN. Мониторинг тут не нужен.
создаем 4 GRE тоннеля, галки добавления маршрута в таблицу и динамического маршрута везде отключаем. Master DFL: GRE1: IP address local_GRE1, Remote network не указываем, Remote endpoint - Slave_wan1, Outgoing Routing Table - WAN1 GRE2: IP address local_GRE2, Remote network не указываем, Remote endpoint - Slave_wan2, Outgoing Routing Table - WAN2 GRE3: IP address local_GRE3, Remote network не указываем, Remote endpoint - Slave_wan2, Outgoing Routing Table - WAN1 GRE4: IP address local_GRE4, Remote network не указываем, Remote endpoint - Slave_wan1, Outgoing Routing Table - WAN2 Slave DFL: GRE1: IP address local_GRE1, Remote network не указываем, Remote endpoint - Master_wan1, Outgoing Routing Table - WAN1 GRE2: IP address local_GRE2, Remote network не указываем, Remote endpoint - Master_wan2, Outgoing Routing Table - WAN2 GRE3: IP address local_GRE3, Remote network не указываем, Remote endpoint - Master_wan1, Outgoing Routing Table - WAN2 GRE4: IP address local_GRE4, Remote network не указываем, Remote endpoint - Master_wan2, Outgoing Routing Table - WAN1
добавляем созданные каналы в Interface Groups»LOCAL_Group вместе с LAN добавляем оба WAN в Interface Groups»WANS_Group
в Main IP Rules добавляем правила LOCAL_LANs_to_core: Action: allow, Source Interface: LOCAL_Group, Source Network: LOCAL_NETS, Destination Interface: core, Destination Network: LOCAL_NETS, Service: all_tcpudpicmp InternalRule: Action: allow, Source Interface: LOCAL_Group, Source Network: LOCAL_NETS, Destination Interface: LOCAL_Group, Destination Network: LOCAL_NETS, Service: all_tcpudpicmp allow_standard: Action: NAT, Source Interface: LOCAL_Group, Source Network: LOCAL_NETS, Destination Interface: WANS_Group, Destination Network: all-nets, Service: all_tcpudpicmp, NAT action: Use interface address
в таблицу Main добавляем маршруты для GRE: Interface: GRE1, Network: remote_GRE1, Gateway: (None), Local IP address: (None), Metric 10 Interface: GRE2, Network: remote_GRE2, Gateway: (None), Local IP address: (None), Metric 10 Interface: GRE3, Network: remote_GRE3, Gateway: (None), Local IP address: (None), Metric 10 Interface: GRE4, Network: remote_GRE4, Gateway: (None), Local IP address: (None), Metric 10 смысл в том, чтобы при обращении к IP-адресу GRE-канала завернуть трафик именно в него.
далее создаем 4 IPSec канала, убираем галки автоматического добавления маршрута IPSec1: Local Network: lannet, Remote Network: Slave_lannet, Remote Endpoint: remote_GRE1, Outgoing Routing Table: main, Local Endpoint: local_GRE1, Incoming Interface Filter: any, IP Address: local_IPSec_1 IPSec2: Local Network: lannet, Remote Network: Slave_lannet, Remote Endpoint: remote_GRE2, Outgoing Routing Table: main, Local Endpoint: local_GRE2, Incoming Interface Filter: any, IP Address: local_IPSec_2 IPSec3: Local Network: lannet, Remote Network: Slave_lannet, Remote Endpoint: remote_GRE3, Outgoing Routing Table: main, Local Endpoint: local_GRE3, Incoming Interface Filter: any, IP Address: local_IPSec_3 IPSec4: Local Network: lannet, Remote Network: Slave_lannet, Remote Endpoint: remote_GRE4, Outgoing Routing Table: main, Local Endpoint: local_GRE4, Incoming Interface Filter: any, IP Address: local_IPSec_4
в таблицу Main добавляем маршруты для IPSec: Interface: IPSec1, Network: remote_IPSec_1 , Gateway: (None), Local IP address: (None), Metric 10 Interface: IPSec2, Network: remote_IPSec_2 , Gateway: (None), Local IP address: (None), Metric 10 Interface: IPSec3, Network: remote_IPSec_3 , Gateway: (None), Local IP address: (None), Metric 10 Interface: IPSec4, Network: remote_IPSec_4 , Gateway: (None), Local IP address: (None), Metric 10 эти маршруты создаются для правильной работы мониторинга каналов, который мы сейчас сделаем:
в таблицу Main добавляем маршруты для Slave_lannet: Interface: IPSec1, Network: Slave_lannet, Gateway:(None), Local IP address: (None), Metric: 21, мониторинг пингом хоста remote_IPSec_1 Interface: IPSec2, Network: Slave_lannet, Gateway:(None), Local IP address: (None), Metric: 22, мониторинг пингом хоста remote_IPSec_2 Interface: IPSec3, Network: Slave_lannet, Gateway:(None), Local IP address: (None), Metric: 23, мониторинг пингом хоста remote_IPSec_3 Interface: IPSec4, Network: Slave_lannet, Gateway:(None), Local IP address: (None), Metric: 24, мониторинг пингом хоста remote_IPSec_4
то же самое на Slave DFL, только для Master_lannet
собственно, это всё. Каналы подняты постоянно, мониторинг работает, пропажа линка быстро отрабатывается. все настройки IPSec не стал приводить, там все стандартно, написал только ключевые параметры. Основная "неясность" в том, что все настройки реализованы на новых прошивках приборов. Еще тема по резервированию IPsec: viewtopic.php?f=3&t=171182&hilit=IPsecИнструкция: Shkiper писал(а): извиняюсь за задержку в схеме задействованы два дфл и коммутатор, адреса портов коммутатора изображают шлюзы внешних интерфейсов дфл коммутатор настроен таким образом, что с ванов дфл можно пинговать любой порт коммутатора (и соответственно wan интерфейсы dfl пингуют друг друга в любых направлениях) - типа интернет (но простой свич поставить нельзя, будет петля) ip адреса на портах коммутатора мы использовали для облегчения понимания схемы, ну и для мониторинга тоже (но думаю можно обойтись и без них , если в реале схема без шлюзов) настройки дфл симметричны, кроме одного момента (об этом в конце), например настраиваем верхний - dfl1 для него: wan1 - 1.1.1.10 wan1 - 2.2.2.20 нам понадобятся 4 ipsec туннеля, для каждого укажем local и remote endpoint № local remote name ---------------------------------- 1 wan1 3.3.3.30 ipsec1 2 wan2 4.4.4.40 ipsec2 3 wan1 4.4.4.40 ipsecCross1 4 wan2 3.3.3.30 ipsecCross2 галки добавления маршрута в таблицу и динамического маршрута везде отключены, ключ везде один т.е. схема делается на основе англоязычного howto, на который в начале я дал ссылку, первые два туннеля есть в англоязычном руководстве, они прямые, вторые два перекрестные - это мы их добавили в howto однозначность установления туннелей через нужные интерфейсы (wan1---wan1, wan2---wan2) обеспечивается двумя дополнительными маршрутами, у нас ipsec туннелей 4, соответственно и маршрутов 4, по два на каждом интерфейсе, и с мониторингом на одном из пары M NET IF GW Metr ----------------------------------- M 3.3.3.30 wan1 1.1.1.1 90 -- 3.3.3.30 wan2 2.2.2.2 100 M 4.4.4.40 wan2 2.2.2.2 90 -- 4.4.4.40 wan1 2.2.2.2 100 добавим маршруты для доступа к удаленной сети (для dfl1 это 192.168.2.0/24 ), их тоже 4 шт M NET IF Metr ------------------------------------ M 192.168.2.0/24 ipsec1 90 M 192.168.2.0/24 ipsec2 100 M 192.168.2.0/24 ipsecCross1 110 M 192.168.2.0/24 ipsecCross2 120 все маршруты с мониторингом, т.е. мы однозначно указываем dfl в какой последовательности использовать туннели для доступа к удаленной сети теперь очень важный момент это то зерно, которое мы взяли из второй ссылки, это к вопросу - как мониторить ipsec, этот вариант нам больше всего понравился, потому как самый однозначный в настройках ipsec, вкладка advansed, самый нижний пункт - IP Address т.е. когда туннель поднят, он будет пинговаться на этот адрес каждому ipsec присваиваем произвольный (из своей локальной сети) IP, т.к. мы разбираем настройку dfl1 то мониторить мы будем адреса удаленной для него сети, т.е. IP присвоенные туннелям на дфл2: dfl2_ipsec1 - 192.168.2.10 dfl2_ipsec2 - 192.168.2.11 dfl2_ipsecCross1 - 192.168.2.12 dfl2_ipsecCross2 - 192.168.2.13 и прописываем эти ip в мониторинге соответствующих им ipsec туннелей противоположного dfl для "приклеивания" этих IP соответствующим ipsec туннелям (на "противоположном" для них dfl), прописываем на dfl1 маршруты (и соответственно на dfl2 аналогично) 192.168.2.10 ipsec1 192.168.2.11 ipsec2 192.168.2.12 ipsecCross1 192.168.2.13 ipsecCross2 без мониторинга, с любыми метриками при добавлении двух крайних маршрутов (и соответственно при выборе ip для мониторинга на перекрестных туннелях) следует учитывать, что для перекрестных туннелей, на разных dfl могут понадобится ассиметричные настройки, т.е. для ip адреса туннеля на dfl1 - dfl1_wan1---dfl2_wan2, будет соответствовать ip адрес присвоенный туннелю на dfl2 - dfl2_wan2---dfl1_wan1 вот собственно и все чем понравилась эта схема - туннели переключаются мгновенно, нет ожидания ipsec, можно выставить параметры мониторинга на минимум, все переключается сразу если я выложил то что всем и так давно известно, прошу великодушно простить:)мониторинг wan интерфейсов "вынесен за скобки" doctorA писал(а): к вышеописанному пришлось добавить следующее: 2. две дополнительных таблицы маршрутизации для исключения ситуаций, когда пакет приходит на один WAN, а ответ уходит по другому. Из-за этих особенностей при некоторых сочетаниях отключенных/рабочих WAN-ов происходило периодическое убивание ключей IPSec и разрывы связи. Понял, что так происходит, когда увидел в логе запрос на создание IKE SA IPSec3 (remote WAN2 - local WAN1) с параметрами как у IPSec1 (remote WAN1-local WAN1).
Правда в этой инструкции много , для меня, темных пятен, не совсем все ясно.
|
|