Carp+Ассиметрия?

Yaroslav

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

Видимо в процессе формирования-выгрузки отчета поисходит таймаут соединения.

werter

Пробуйте Firewall Optimization Options" to Conservative under System -> Advanced на всех нодах.

Yaroslav

Не помогло :(

Yaroslav

Похоже проблема с маршрутами. Поменял внешний ip-адрес одному из шлюзов, занатил через него и отчет стал выполняться (раньше не выполнялся).
IP-адреса в одной локальной сети, но до 8.8.8.8 ходят по другому через один и тот же шлюз. Странности какие-то…
P.S. Проблема все-таки не в этом. Убрал нат на виртуальный интерфейс. Тестировал и статический порт НАТ для 1521, отчет то выполняется, то нет.
Потом настроил у себя на компе шлюз взял ip, который отобрал у резервного pf. Отчет выполняется замечательно...
P.P.S. Снес виртуальный локальный интерфейс на резервном шлюзе, отчеты выполняются плохо. Значит проблема не в ассиметрии. Думаю PF рвет таймаутное соединение, Можно как либо увеличить время жизни для таймаутного соединения?

werter

Попробуйте задействовать Stickly connections. И сделать после этого reset states для чистоты эксперимента.

Yaroslav

похоже помогло. спасибо!

Yaroslav

Нет не помогло, я тестил на не особо громозком отчете, а если отчет запускать, который формируется минут 20-40, то все равно связь теряется :(
Обнаружил, что рдп при простое тоже начинает терять связь и автоматически перекподключаться

werter

@Yaroslav:

Обнаружил, что рдп при простое тоже начинает терять связь и автоматически перекподключаться

Что при этом в логах?

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.
Хмммм**

Yaroslav

Может быть проблема с NAT?
Всех выгнал со шлюза, кто работает с базой, все работает замечательно, стоит ещё кому-то зацепиться и начать работать с базой начинаются перебои.
Похоже полностью придеться переводить основной шлюз на микротик, с микротика все что не касается базы слать во внешку через PF, а все что касается базы слать напрямую. Какие-нибудь проблемы могут появиться при такой схеме?
Думаю асимметрию bypass вылечит или если не поможет, то в отдельную сеть засуну pf.

werter

А попробуйте в англоветке спросить.