Добрый день,

Есть следующая конфигурация:
Две локальные сети А и Б соединенные двумя VPN (через разных провайдеров).

В сети А есть сервер X, который активно используется пользователями сети Б.

Требуется весь трафик между сервером X и сетью Б маршрутизировать через один VPN, а весь прочий трафик между сетями А и Б через другой VPN.
При отказе одного канала весь трафик автоматом переключается на оставшийся работоспособным VPN.

В тестовой схеме оба VPN поднимались на двух DFL-260E на WAN и DMZ. Схема, когда все маршрутизируеся через один канал, второй в резерве - работает.
Проблема возникает при отделении маршрута на сервер X.

Таблица маршрутизации сети Б
# Type Interface Network Gateway LocalIP Metric Monitor this route

1 Route fwB-ipsec1 Server 60 Yes
2 Route fwB-ipsec fwB-remotenet 80 Yes
3 Route fwB-ipsec1 fwB-remotenet 90 No
4 Route wan1 Off_net wan1_gw 100 No
5 Route wan wannet 100 No
6 Route wan1 wan1net 100 No
7 Route lan lannet 100 No

Таблица маршрутизации сети А

# Type Interface Network Gateway LocalIP Metric Monitor this route
1 Route fwB-ipsec1 fwB-remotenet Server 60 Yes
2 Route fwB-ipsec fwB-remotenet 80 Yes
3 Route fwB-ipsec1 fwB-remotenet 90 No
4 Route wan1 Off_net wan1_gw 100 No
5 Route wan wannet 100 No
6 Route wan1 wan1net 100 No
7 Route lan lannet 100 No

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

Через PBR маршрутизацию настраивать тоже пробовал - проблема та же (прямой пакет проходит, обратный - нет)

Пожалуйста подскажите, как правильно настроить такую схему.

С дополнительным маршрутом на сервер вы правильно сделали, но нужно сделать дополнительно

1) Обрабатывать входящие из IPsec в своих таблицах
Следующие действия делаются на каждом DFL для каждого IPsec

Routing > Routing tables
Сделайте таблицу alt_ipsec
Сделайте в ней маршрут ipsec all-nets 100

Routing > Routing rules
ipsec/all-nets any/all-nets, forward main, return alt_ipsec

Эти действия позволят мониторить туннели _только_ по ICMP, что благоприятно отразится на скорости блокирования нерабочих туннелей и восстановления после начала работы

2) Чтобы избежать обрывов соединений при падении одного из туннелей, вы можете использовать forward fast вместо Allow, только разрешайте трафик в обе стороны

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Большое спасибо, за помощь!
Обратные пакеты стали проходить.

Выяснилось только, что маршрут №1 в таблице сети А (где стоит сервер Х) работает не правильно.
Предполагалось, что параметр LocalIP = Server позволит маршрутизировать пакеты от сервера (если он открывает соединение), через выделенный для него канал.
На практике через канал для сервера идут все пакеты из сети А (если из нее открывается соединение), т.о. источник пакетов не проверяется

Если соединение открывает открывает клиент из сети B и стоит Allow - все маршрутизируется правильно, если стоит forward fast - обратный трафик идет через другой канал в соответствии с приоритетным маршрутом в таблице сети А.

Добрый день,

Решили изменить схему, поставить четыре FDL-260E на два VPN, т.к. две железки не тянут шифрование двух каналов одновременно.

Таблица маршутизации на всех железках такая:

Route fwB-ipsec fwB-remotenet 80 Yes
Route lan fwB-remotenet lan_gw 90 No

Где lan_gw локальный адрес другой железки с VPN.

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

Как здесь пропустить обратный пакет?

Используйте Forward fast чтобы пропускать просто пакеты

Чтобы не было путаницы, сделайте для дублирующего DFL отдельный VLAN через порт и тогда сможете сделать нормальную балансировку

А вообще лучше схему покажите...

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Добрый день,
Схема в файле. Железки 2 и 4 являются основными шлюзами сетей. Железки 1 и 3 шлюзы для сервера Х и его клиентов.
При удалении обратного пакета в логе ошибка ECHO_REPLY no_new_conn_for_this_packet drop.
Если поставить Forvard Fast вместо Allow - пакет обратный проходит.
По Forvard Fast читал, что он медленнее работает чем Allow. Не будет с ним тормозов на канале?

И по VLAN просьба пояснить подробнее, не понял вашу мысль.

В вашем случае альтернатив Forward fast нет т.к. Allow будет требовать наличия открытого соединения для обратного пакета

Про VLAN - соединения между DFL в каждом офисе лучше сделать не через LAN, а через DMZ или VLAN (port based) чтобы не было правил вида Allow lan > lan

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

скорость через основной VPN канал:

4 Мбайт/сек - на Allow
2.4 Мбайт/сек - Forward Fast

Снижение скорости значительное получается.




Lan to Lan у меня и без дополнительных правил проходит.

Пробовал соединять через dmz. В этом случае получается, что пакет с source lan приходит с интерфейса dmz. Прямой пакет drop defaul rule. Правило Allow all from dmz allnet to ipsec allnet не помогает.

А если правила наверх поднять?

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Тоже самое получается. На скорость не влияет.