Рвется соединение tcp в сети с двумя шлюзами FreeBSD

[igonshi]

Добрый день.

Есть сеть (172.28.254.0/24). В ней есть два шлюза.

172.28.254.1 - через него уходит трафик в другие подсети конторы (например 172.28.252.0/24 и прочее). Он не мой и я им не управляю.

172.28.254.254 - это мой шлюз. FreeBSD 8.3. На нем работает интернет. На нем прописаны маршруты следующего вида

Код: Выделить всё

    route_LAN1="-net 172.28.252.0/24 172.28.254.1"
    route_LAN2="-net 172.28.251.0/24 172.28.254.1"
    route_LAN2="-net 172.21.2.0/23 172.28.254.1"

На этом же шлюзе стоит pf, но там есть правило ($int_if - 172.28.254.254, INTRANET="{172.28.252.0/24 172.28.251.0/24 172.21.2.0/23}")

Код: Выделить всё

 pass in quick on $int_if proto {tcp udp icmp} from $int_if/24 to $INTRANET

На рабочих машинах стоит шлюз по умолчанию - мой 172.28.254.254
По идее все должно нормально рулиться на нем, если машинки с моей сети пытаются подцепиться к хостам из сетей LAN1 или LAN2.

И вот беда. При попытке установить соединение с 172.28.254.20 на скажем 172.21.2.3 оно устанавливается и через какое-то время рвется.

Сам я самоучка, может чего не так понимаю в работе сетей. Кто подскажет что я делаю не правильно? В какую сторону вообще копать?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Гость]

поднимите pflog, натравите на него tcpdump
и мониторте проблему именно в момент разрыва
заодно и поднимите свой уровень

через какое то время - это ниочем, должно быть конретное число минут секунд,
иначе это может разрывать сам клиент или вообще с серверной стороны

чем проверяете коннект то?

[mak_v_]

Ничего не должно быть.
Пакет уходит от клиента с src 172.28.254.20 и dst 172.21.2.3 через 172.28.254.254
А ответ возвращается от 172.28.254.1
Вопрос на засыпку - почему возвращается не от 172.28.254.2 или к примеру не от 172.28.254.22 или 172.28.254.222....должен-то ведь придти от 172.28.254.254, через который и ушел.

[Гость]

если неправильный роутинг, то никакой связи устанавливатся недолжно
ТС значит лукавит

[igonshi]

Соединение я проверяю xmpp(jabber) клиентом до сервера который в другой подсети
На компьютере, с которого пробую работу, поставил WireShark. Вижу как бегают пакетики.
На своем шлюзе 172.28.254.254 сделал дамп на интерфейсе смотрящем в локалку (re0) и на pflog0

Получается следующий процесс работы.

1) Рабочая станция 172.28.254.29 пытается подключиться к 172.21.2.3. В этот момент я вижу как бегают пакеты на re0 на моем шлюзе 172.28.254.254
2) Когда мой шлюз говорит что надо ходить через 172.28.254.1, соединение устанавливается через него и пакеты бегать на re0 (через мой 172.28.254.254) перестают. WireShark на рабочей станции при этом показывает что соединение установлено и я вижу как поднимается TLS до нашего корпоративного XMPP-сервера.
3) По прошествии некоторого времени, я вижу на WireShark необычные пакеты, которые подписываются как "Повторная передача" или "Дублирующая передача".
. При этом на pflog0 на моем шлюзе видно как лочатся пакеты.
Но они не должны лочиться, потому что правило явно разрешает любые действия из нашей локалки в сторону нашего же 172.28.21.2

Такое ощущение что клиент периодически теряет маршрут или обновляет его через шлюз по умолчанию, отсылая пакеты ACK на 172.28.254.254 (вместо 172.28.254.1). А мой pf не отслеживая соединение, думает что это хитрая атака на него Не знаю. Я в замешательстве.

[igonshi]

Вот что пишет дамп на pflog0 в момент разрыва

Код: Выделить всё

tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes
10:19:22.115223 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 138 [bad hdr length 16 - too short, < 20]
10:19:22.516376 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 16 [bad hdr length 16 - too short, < 20]
10:19:22.617930 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 273 [bad hdr length 16 - too short, < 20]
10:19:23.071344 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 16 [bad hdr length 16 - too short, < 20]
10:19:23.218074 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 693 [bad hdr length 16 - too short, < 20]
10:19:24.018226 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 16 [bad hdr length 16 - too short, < 20]
10:19:24.418088 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 540 [bad hdr length 16 - too short, < 20]
10:19:25.622106 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 540 [bad hdr length 16 - too short, < 20]
10:19:25.707418 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 16 [bad hdr length 16 - too short, < 20]
10:19:26.822255 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222:  tcp 693 [bad hdr length 16 - too short, < 20]
10:19:28.854208 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222: [|tcp]
10:19:29.222305 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222: [|tcp]
10:19:31.839251 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222: [|tcp]
10:19:34.019590 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222: [|tcp]
10:19:37.603252 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222: [|tcp]
10:19:43.616768 rule 86/0(match): block in on re0: 172.28.254.29.55381 > 172.21.2.3.5222: [|tcp]

К слову результат pfctl -gsr | grep @86

Код: Выделить всё

@86 block drop in log all

Думаю если бы весь трафик в рамках одной сессии ходил бы через мой шлюз, все было бы нормально. Но для этого надо добавить на 172.28.254.1 маршрут, что-то типа
-net 172.28.254.0/24 172.28.254.254

Может есть какая-то директива pf.conf о которой я не знаю?