Carp+Ассиметрия?
-
День добрый.
Настроен кластер шлюзов при помощи CARP.
Платформа 2.1.4-RELEASE.
В принципе работает все замечательно, но наблюдается следующая проблема:
В локальной сети есть хост на котором установлено клиент-серверное приложение, в интернетах есть ORA DB. При выполнении небольших запросов все работает хорошо, а при попытке выгрузить громозкий отчет периодически клиент-серверное приложение жалуется на разрыв соединения.
Перешерстил всю конфигу, проблемы не нашел, но осталось одно предположение, которое вызвало у меня ступор. Локальный интерфейс у основного шлюза 192.168.10.4/24, виртуальный 192.168.10.1/24 для кластера, хосты в локалке ходят через 192.168.10.1 до БД, а ответ на запрос видимо приходит с локального интерфейса шлюза, т.е. 192.168.10.4. Видимо проблема в этом. Т.к. это не совсем асимметричный маршрут, то опция Bypass firewall rules for traffic on the same interface мне не помогла.
Подскажите, пожалуйста, как это исправить?
Заранее спасибо за ответ! -
Включайте логирование fw и смотрите.
-
Status: System logs: Firewall ?
Нет ничего, что относилось бы к хосту 192.168.10.6
В Diagnostics: Show States я наблюдаю такую картину, когда пробую сделать отчет:tcp Х.Х.Х.Х:3389 <- 192.168.10.6:50355 ESTABLISHED:ESTABLISHED tcp 192.168.10.6:50355 -> Х.Х.Х.X:64158 -> X.X.X.X:3389 ESTABLISHED:ESTABLISHED tcp X.X.X.X:80 <- 192.168.10.6:50356 FIN_WAIT_2:FIN_WAIT_2 tcp 192.168.10.6:50356 -> X.X.X.X:56416 -> X.X.X.X:80 FIN_WAIT_2:FIN_WAIT_2 tcp X.X.X.X:1521 <- 192.168.10.6:50357 ESTABLISHED:ESTABLISHED tcp 192.168.10.6:50357 -> X.X.X.X:41033 -> X.X.X.X:1521 ESTABLISHED:ESTABLISHED tcp X.X.X.X:1521 <- 192.168.10.6:50363 ESTABLISHED:ESTABLISHED tcp 192.168.10.6:50363 -> X.X.X.X:45632 -> X.X.X.X:1521 ESTABLISHED:ESTABLISHED tcp X.X.X.X:1521 <- 192.168.10.6:50364 TIME_WAIT:TIME_WAIT tcp 192.168.10.6:50364 -> X.X.X.X:21749 -> X.X.X.X:1521 TIME_WAIT:TIME_WAITВидимо в процессе формирования-выгрузки отчета поисходит таймаут соединения.
-
Пробуйте Firewall Optimization Options" to Conservative under System -> Advanced на всех нодах.
-
Не помогло :(
-
Похоже проблема с маршрутами. Поменял внешний ip-адрес одному из шлюзов, занатил через него и отчет стал выполняться (раньше не выполнялся).
IP-адреса в одной локальной сети, но до 8.8.8.8 ходят по другому через один и тот же шлюз. Странности какие-то…
P.S. Проблема все-таки не в этом. Убрал нат на виртуальный интерфейс. Тестировал и статический порт НАТ для 1521, отчет то выполняется, то нет.
Потом настроил у себя на компе шлюз взял ip, который отобрал у резервного pf. Отчет выполняется замечательно...
P.P.S. Снес виртуальный локальный интерфейс на резервном шлюзе, отчеты выполняются плохо. Значит проблема не в ассиметрии. Думаю PF рвет таймаутное соединение, Можно как либо увеличить время жизни для таймаутного соединения? -
Попробуйте задействовать Stickly connections. И сделать после этого reset states для чистоты эксперимента.
-
похоже помогло. спасибо!
-
Нет не помогло, я тестил на не особо громозком отчете, а если отчет запускать, который формируется минут 20-40, то все равно связь теряется :(
Обнаружил, что рдп при простое тоже начинает терять связь и автоматически перекподключаться -
Обнаружил, что рдп при простое тоже начинает терять связь и автоматически перекподключаться
Что при этом в логах?
https://forum.pfsense.org/index.php?topic=69852.0
Yes, if you set to conservative, the UDP timeouts increase.
You can see the current timeouts on your system at **Diagnostics > pfInfoНо у RDP - tcp.
Хмммм** -
Может быть проблема с NAT?
Всех выгнал со шлюза, кто работает с базой, все работает замечательно, стоит ещё кому-то зацепиться и начать работать с базой начинаются перебои.
Похоже полностью придеться переводить основной шлюз на микротик, с микротика все что не касается базы слать во внешку через PF, а все что касается базы слать напрямую. Какие-нибудь проблемы могут появиться при такой схеме?
Думаю асимметрию bypass вылечит или если не поможет, то в отдельную сеть засуну pf. -
А попробуйте в англоветке спросить.
