Приветствую всех, Уважаемые Гуру!

Нужна консультация в решении задачи.

Есть офис и фиал, у которых локальные сети связанны через L2TP туннель, с маршрутизацией в обе стороны. Для наглядности все отражено на схеме.



Также в офисе и филиале, есть дополнительная гостевая сеть - для планшетов, ноутбуков и т.д., которая имеет доступ только в интернет, через WAN2/Провайдер В (пока только в офисе). С маршрутизацией в офисе проблем не возникло NAT+дополнительные типовые правила маршрутизации для WAN2.

Сама задача состоит в том, что нужно аналогично сделать проброс с гостевой-филиальной сети в офис, а далее NATом в WAN2.

Сам прекрасно понимаю, что шифровать интернет-трафик от гостевой сети до офиса не имеет смысла, тем самым создавать дополнительную нагрузку.

Пока опробовал так:

Для упрощения задачи, пока исключил заморочку с WAN2, а для начала сделать NATом на WAN1.
Создал отдельный IPSec – туннель и связал обе гостевых сети.

На стороне филиала:
IPSec-Tunnel:
Имя: ipsec_to_office
Локальная сеть: dmznet
Удаленная сеть: all-nets

Правило только в одну сторону:
Имя: all_dmz_to_office_dmz
Действие: Allow
Сервис: all_services
Источник: dmz / dmznet
Назначение: ipsec_to_office / all-nets

На стороне офиса:
IPSec-Tunnel:
Имя: ipsec_to_filial
Локальная сеть: all-nets
Удаленная сеть: filial_remote_net

Правило:
Имя: all_filial_dmz_to_office
Действие: NAT
Сервис: all_services
Источник: ipsec_to_filial / filial_remote_net
Назначение: wan1 / all-nets

Так работает, но нужно дописывать маршрут до статического ip-адреса на WAN1 офиса, т.к. all-nets на филиале завернул в ipsec, иначе туннель не поднимается.
Такой сценарий не приемлем, из-за того, что в филиале публикуются в наружу свои серверы через WAN1.

1. Подскажите, как правильно завернуть трафик с DMZ филиала, в офис + NAT, не трогая main маршрут all-nets по умолчанию в филиале?
2. Как уменьшить нагрузку из-за шифрования трафика, использовать GRE? Или есть другие решения?

Автору большой респект за образцовую схему!!

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

Вместо IPsec можете просто поднять GRE туннель между гостевыми сетями и уже через него выходить в инет гостевой сетью филиала через головной офис (c PBR, конечно)

Кроме того, если нет противопоказаний, я бы сделал PBR, чтобы публиковать нужные вам сервисы через оба WAN порта в центральном офисе.

Не вижу тут противоречия. Цепляетесь c помощью доп маршрута на WAN1 и сервисы опубликованы на нём же.

Или не понимаю до конца в чём все-таки проблема.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Думаю, что с PBR проблем не должно быть, это уже следующий этап.

Здесь я так понимаю, что аналогично как IPSec, но суть маршрутизации не меняется?

Я так понял, что идея заключается в том, чтобы отказаться от публикации серверов напрямую в наружу на филиале, а опубликовать их через главный офис? Если так, то не совсем то, что нужно для филиалов.
На самом деле, я привел упращенную схему сети. В действительности на WAN1 и WAN2 в главном офисе – навешано очень много правил и публикаций, которые не относятся к данной лабораторной задаче.

У меня основная проблема в том, что я не знаю как смаршрутизировать только all-nets для DMZ, в новоиспеченный туннель (только с DMZ сети филиала)?
Чтобы оставить остальные правила как были, к примеру для локальной сети:
Правило NAT: Lan/ip-pbx_ip to wan1/all-nets
То есть, не изменять all-nets по умолчанию для всей DFL.

А происходит то, что когда я меняю
На стороне филиала:

IPSec-Tunnel:
Имя: ipsec_to_office
Локальная сеть: dmznet
Удаленная сеть: office_net на all-nets

и

Правило только в одну сторону:
Имя: all_dmz_to_office_dmz
Действие: Allow
Сервис: all_services
Источник: dmz / dmznet
Назначение: ipsec_to_office / office_net на all-nets

То тогда отказывают маршруты, которые должны ходить через WAN1 филиала, т.к. all-nets теперь завернуто в главный офис.

Подозреваю, что нужно писать отдельную таблицу маршрутизации для DMZ и туннеля?

http://forum.dlink.ru/viewtopic.php?t=65359&start=14
http://forum.dlink.ru/viewtopic.php?f=3&t=93443

Я предлагаю вам сразу заменить IPsec на GRE, т.к. он нешифрованный и свободно-маршрутизируемый. А PBR вам все равно придется настраивать

В ссылках примеры настройки PBR как для исходящего, так и для входящего (проброс портов) трафика.

Нет. Речь, только о том, чтобы публиковать в центральном офисе ваши сервисы через оба WAN'а. Для надежности. Но к вашей задаче это прямого отношения не имеет.

можете пока вообще оставить только имеющийся L2TP туннель мужду офисами и завернуть через PBR гостевую сеть из филиала в центр. В центре при этом понадобятся правила NAT для вывода в инет и PBR аналогичный тому, что есть для гостевой сети центра.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

На GRE можно и заменить, но настройка PBR имеется введу, когда с туннеля в главном офисе траффик завернуть NATом в WAN2?

Уже так и используется два WANa, для публикации (mx1, mx2, nginx и т.д.) Правила для WAN2 c PBR, как описано в примерах.


Вы имеете введу пропихнуть траффик с гостевой сети филиала в центр через уже существующий L2TP-туннель? Или вообще отказаться от туннеля, в пользу прямой маршрутизации трафика ClientFilial > DMZ > Core > WAN1 >>>> WAN1 > Core > WAN2 > Internet ?

Да, как временный, более простой вариант.

Хотя я сам бы не тратил время на промежуточные варианты и делал сразу окончательный )

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

YuriAM, спасибо за помощь! Вопрос решен.
Пришлось отказаться от GRE, т.к. возникли проблемы с прохождением трафика через провайдера. А в тестовой среде – все работает.
Итог:
На стороне филиала (основная проблема которая была), оказалось для корректного заворачивания трафика в существующий туннель с использованием PBR – нужно было сгруппировать интерфейсы WAN1+туннель который смотрит в офис (аналогично как схема с двумя провайдерами). А дальше уже маршрутизировать в правилах указывать на all-wans/all-nets + PBR с альтернативной таблицей маршрутизации, в которой all-nets смотрит в туннель.

На стороне офиса - трафик из туннеля через NAT в WAN2 + PBR.

Причин все-таки оставить только L2TP туннель, было несколько:
1. Более упращенная конфигурация, без дополнительного туннеля.
2. Серверная часть L2TP – дублируется в офисе, сразу на WAN1 и WAN2 (на филиале, в случае отказа первого провайдера в офисе, просто меняется ip-адрес на второго).
3. Частично, некоторые сервисы с изолированной сети филиала, ограничено, ходят через определенные порты в офисную LAN и DMZ-2 по принципу разделенного DNS.
4. На некоторых филиалах нет былых IP-адресов.

Осталось теперь внедрить аналогично в остальных филиалах.