Нет, сейчас вновь началась такая тема, значит не исчезла

Выше правил SAT, что я написал выше, указать это правило:

SAT lan/lannet -> core/all-nets http-in SATDEST server_ip
NAT lan/lannet -> core/all-nets http-in

Вместо http-in можно указать http-in-all по необходимости.

_________________
DFL-860E (10.22.01.04), DFL-210 (2.27.08.03-22678), DGS-1210-20/ME/B1A (7-03-B043), DGS-3200-10 (2.21.B018), DES-3200-10 (4.38.B012), DWL-2100AP (250eu-rc358), DNS-323 (1.10), DI-824VUP (1.06b21), DSL-300T (2.00B01T01.EU.20071227)

Но не всегда это поможет. Наглядный пример с ВКонтакте. Два сервера могут проводить перекрестную сверку IP.

_________________
DFL-860E (10.22.01.04), DFL-210 (2.27.08.03-22678), DGS-1210-20/ME/B1A (7-03-B043), DGS-3200-10 (2.21.B018), DES-3200-10 (4.38.B012), DWL-2100AP (250eu-rc358), DNS-323 (1.10), DI-824VUP (1.06b21), DSL-300T (2.00B01T01.EU.20071227)

Оно обязательно должно быть выше?
Сейчас у меня вот какая штука в логе растет постоянно.
А с локального компа на сервер захожу нормально.

Если используется Any, то да, а если отдельные правила, то необязательно.

Таблицу роутинга покажите полностью. На скриншот main, а Status - Routes

_________________
DFL-860E (10.22.01.04), DFL-210 (2.27.08.03-22678), DGS-1210-20/ME/B1A (7-03-B043), DGS-3200-10 (2.21.B018), DES-3200-10 (4.38.B012), DWL-2100AP (250eu-rc358), DNS-323 (1.10), DI-824VUP (1.06b21), DSL-300T (2.00B01T01.EU.20071227)

Я примерно понимаю в чем дело, но не знаю как с этим бороться. Дело в том, что на интерфейсе PPTP назначается адрес 80.70.231.68, который по сути лежит в диапазоне адресов, на которые надо ходить через 10.5.0.2. Ситуация получается такая, что все адреса, которые прописаны через шлюз 10.5.0.2 доступны и через него и через PPTP интерфейс, но в этом случае в 10 раз медленнее. Исходя из маршрутов DFL ждет обращения от 80.70.228.245 на интерфейсе wan1_phys_mns_local, а вместо этого получает запрос на wan1_mns_unlim. Я попробовал исключить 80.70.228.245 из адресов, работающих через 10.5.0.2 - и все подключилось, но медленно. Попробовал поиграть с PBR, создал альтернативную таблицу с маршрутом 0.0.0.0/0 wan1_mns_unlim 90, а в правилах маршрутизации создал для http-in по аналогии:
Name: rule_route_wan1_mns_unlim_http
Forward routing table: alt_table_wan1_pptp
Return routing table: alt_table_wan1_pptp
Service: http-in
Source Interface: wan1_mns_unlim
Source Network: all-nets
Destination Interface: core
Destination Network: all-nets

Ничего из этого не вышло, а занимать PPTP канал локальным трафиком непозволительная роскошь. В итоге сейчас с локала провайдера нет доступа.

Я чего-то не понял, откуда здесь взялся PPTP?? Почему у wan2 подсеть 192.168.120.0/24, а не 192.168.102.0/24. У Вас Интернет по VPN от провайдера что ли? Да и не вижу маршрутов до all-nets через wan2 и dmz, о которых я писал. В любом случае ошибка, которую Вы привели из лога, означает отсутствие прописанной маршрутизации туда, откуда пришел пакет. Также в случае SAT и PBR в Вашем случае в поле Forward routing table всегда будет фигурировать main, а вот в поле Return routing table - тот интерфейс, через который пойдет ответный пакет от Server_ip.

_________________
DFL-860E (10.22.01.04), DFL-210 (2.27.08.03-22678), DGS-1210-20/ME/B1A (7-03-B043), DGS-3200-10 (2.21.B018), DES-3200-10 (4.38.B012), DWL-2100AP (250eu-rc358), DNS-323 (1.10), DI-824VUP (1.06b21), DSL-300T (2.00B01T01.EU.20071227)

Топология выглядит наверное очень сурово, но это вынужденное решение, распределенность сети не позволяла сразу воткнуть 1 DFL-800 и кроме того так локальный пользователь может самостоятельно сменить шлюз. Я понимаю, что постепенно можно настроить авторизацию пользователей для привязки к конкретному wan на dfl-800, но это все время, а учиться на живой схеме несколько проблематично.

Хостинг фотографий


Add: на схеме есть опечатка, конечно же нижний DFL-800, не 210

А и еще на 192.168.0.10 и 192.168.0.5 есть правило
allow_standard NAT lan/lannet lan/all-nets all_tcpudp

И маршрут на 80.70.0.0/16 через 192.168.0.7

Заметил, что сервер, расположенный за каскадом из 2 DFL откликается с задержкой 3-4 секунды, в то время как если подключить его за 1 DFL открытие сайта происходит мгновенно.
Что можно оптимизировать для ускорения процесса?
Можно ли как-то связать DMZ порты фаерволов из первого каскада с WAN портами DFL-800, стоящего вторым, чтобы избежать использования SAT дважды. Или не в этом дело?

Вы случайно не визардом настраивали?

_________________
Сообщения в PM игнорируются, задавайте вопросы на форуме.

Случайно да, но это только генерация первых 4 правил, синхронизации времени и пароля админа.
После визарда не работал только DFL, подключенный к инету через PPTP, а что теперь надо на всех еще что-то тюнинговать?

Наружу все замечательно идет, никаких задержек...

Воспользовался утилитой http-ping, а также попросил нескольких человек для сравнения - результат один и тот же, как я и говорил 3 сек задержка:



Для сравнения пинг в обратную сторону через каскад DFL

SYN flood protection может оказывать такое влияние на работу сервера за DFL?
Просто прямой пинг сервера дает вот такой результат:


И с маршрутами из 80.70.0.0/16 пока не получилось разобраться.

Вот содержимое таблицы main


Вот содержимое alt_table_unlim


Создано Routing Rule

в котором forward - main, return - alt_table_unlim

И ничего не работает - в ответ на запросы с адресов 80.70.X.X - получаем ошибку 504.

А вот что видим в логе



Если убрать маршруты

То все работает, но в 10 раз теряется скорость, т.к. весь трафик начинает идти через VPN. А нужно, чтобы он через него шел только в случае обращения на внешний IP VPNа.