Столкнулся с такой проблемой: DFL-260e с последней WW прошивкой, домашний провайдер с PPTP подключением, настройки WAN получает от DHCP прова.

Соответственно задействована схема с использованием PBR:

основные маршруты - показывают на интерфейс wan и соответственно в процессе подъема pptp отлично ресолвится dns-имя сервера подключения и т.п.
pbr правила - "заворачивают" обращения по альтернативным маршрутам в новый интерфейс "provider"

В общем базовый функционал (по тырнетам лазить) работает нормально.


Тут потребовалось связать домашнюю сеть с рабочей... столкнулся с проблемой подъема ipsec... дома слегка отвлекают, решил с работы поразбираться: добавляю в remote management интерфейс provider ... далее кучка танцев с бубном.... в общем застрял идеологически:

нужны ли какие-то дополнительные правила для PBR для сервисов remote management?

и вообще кто является "обработчиком" обращений rm - по логике core, но может быть за ним "прячется" еще какой-то серый кардинал?


У провайдера арендуется статический адрес, порты и сервисы по его утверждению не фильтруются, да и собственно когда экспериментировал - видел в логах дропы обращений себя снаружи - т.е. получается обращения прошли мимо remote management и далее под них не нашлось правила....

p/s/ сорри, что пока сумбурно и без конфигов, пост уже отписал, стирать жалко, а конфиги - дома (дополню пост ближе к ночи)

Речь, по-видимому, о DI-804?

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

Поправил пост и заголовок темы. Речь о DFL-260e с последней WW прошивкой v2.40.04.08 (от лета прошлого года)

Сколько у вас глобальных интрефейсов? (т.е. тех, что выходят в инет)

и что именно не получается?

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

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

Итак, попробую по-порядку:
WAN: DHCP Client, Automatically add a route for this interface using the given network - on, Automatically add a default route for this interface using the given default gateway - on, Route Metric = 100
PPTP Client:
name: provider, tunnel-protocol: PPTP, Remote endpoint: dns:remote_endpoint_FDQN Remote network: all-nets, Automatically add a route for this interface using the given remote network. - on
Route metric = 110

Создана вторая таблица маршрутизации (forward):

iFace: provider, network: all-nets, local IP addr: wan_ip metric: 80

и Routing rules вида:

rrule1: src: lan/lannet dst: wan/all-nets service: all_tcpudpicmp с маршрутизацией forward routing table: forward, return routing table: main
rrule2 - аналогично для pptp-suite (чтобы подцеплятся к своим рабочим шлюзам)

Собственно вот ядро настройки для работы с pptp подключением провайдера "по правильному" (dhcp получение адреса, шлюза, dns для wan, ресолвинга адресов pptp сервера провайдера и т.п.), но вот дальше - застрял:


включаю в remote management управление по http+https:8443 iface: provider, admin users из локальной базы
пытаюсь подключиться с роутеру снаружи (pptp подключение к рабочему шлюзу, rdp на рабочую станцию и оттуда броузером пытаюсь открыть http://мой_адрес и https://мой_адрес:8443 - отклика нет, в логах - чисто. ping мой_адрес - вижу в логах работу drop-правила
обращаюсь http/https с другими портами - отрабатывает drop-правило


.......... аж жалко стирать ....

Получилось ровно по правилу "правильно или тщательно сформулированный вопрос содержит в себе половину ответа" -)))

Все шаги описывал повторяя их в реале.
Дошел до шага попробовать создать "обратное правило маршрутизации для входа" и... добился доступа снаружи!!

Итак:
для работы remote management хватило правила:
src: provider/all-nets dst: core/pptp_ip* forward routing tbl: main return routing table: forward service: мое_название_https_8443

* pptp_ip - это адрес получаемый от pptp сервера провайдера


Итак вопрос1 снялся.

Второй вопрос пока не смог с налету разрешить:

поднять IPsec между этим роутером и аналогичным, но с "прямым" подключением...