faq обучение настройка
Текущее время: Вс ноя 18, 2018 13:53

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Failover PPTP DFL-860E
СообщениеДобавлено: Пн окт 15, 2018 11:11 
Не в сети

Зарегистрирован: Пт мар 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&hilit

Скрытый текст: показать
doctorA писал(а):
в предлагаемой схеме 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).

Правда в этой инструкции много , для меня, темных пятен, не совсем все ясно.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Failover PPTP DFL-860E
СообщениеДобавлено: Пн окт 15, 2018 14:22 
Не в сети

Зарегистрирован: Пт мар 02, 2018 14:57
Сообщений: 57
Разбираясь с IPsec, решил протестировать настройки которые провел ранее:
Скрытый текст: показать
Vadim_PV писал(а):
головной DFL, все еще на резервном канале Интернет. Настроил на нем второй PPTP-сервер где wan2(резервн. пров) указал как Outer server IP.
На удаленном DFL-е настроил второй PPTP-клиент где, как Remote Endpoint, указан IP-адрес wan2 головного DFL-а.
Далее, на удаленном DFL-е, снял галку автоматического создания маршрута для первого PPTP-клиента. В routes создал маршрут для первого PPTP-клиента с мониторингом, пингующим хост локальной сети головного DFL-а.
В status=>routes маршрут первого PPTP-клиента отобразился с флагами MX.
После этого подключение установилось: второй PPTP-клиент удаленного DFL-а, подключился ко второму PPTP-сервреру головного DFL-а.

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

И вроде бы все заработало.
С резерва перешел на основу - в Status=>User Authentication отобразились сразу 6 одновременно зарегистрированных пользователей (3 от основного PPTP-сервера, и 3 от резервного) Потом "пользователи" резервного пропали, остались только с основного.
Пропинговал, из удаленной сети, ресурс головной сети - пинг прошел. В общем все каналы подлнялись в полной мере.
Далее, снова отключил основной - так же каналы поднялись.
И снова включил основной канал интернет - все vpn-каналы заработали.
При переключениях проверял подключения, и тестировал сервисы использующие vpn для работы - все работает.
Время переключения резервных каналовы на основной около 3-4 минут,в целом приемлемо.

Момент на который не сразу обратил внимание, один из трех PPTP-клиентов в User Authentication=>Status отображается два раза, но с разными интерфейсами скриншот:
Скрытый текст: показать
Вложение:
юзер.jpg
юзер.jpg [ 47.78 KiB | Просмотров: 98 ]

Как такое возможно?
Настройки удаленных DFL-ов везде практически одинаковые. Пробовал разлогинить юзера с "неправильным" интерфейсом, через 5 сек он снова залогинивается.
Может ли так быть, что на этом удаленном DFL-е резервный тоннель PPTP образуется внутри основного тоннеля PPTP, таким образом "доходит" до головного DFL-а и там авторизуется пользователь?
Так же если переходим на резерв, то vpn от головного до удаленного включается, но сам удаленный DFL становится недоступен т.е. его адрес не пингуется, при этом ресурсы головной сети доступны, из сети за ним.

Но задачу по IPsec не оставляю.


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 17 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: Bing [Bot] и гости: 27


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB