Заблочь на роутере rst

Собственно, вопрос: можно ли как-то заставить OpenWRT повторять на WAN пакеты пару/тройку раз после RST, без сообщения об этом клиенту за NAT?

Можно, только сервер вам не будет продолжать отсылать данные, если он прислал RST.

Странно, конечно. Если вы в России, может, DPI вашего провайдера сбоит, т.к. соединение разрывается с RST только в аварийных случаях.

Запишите дамп трафика и пришлите на iam@valdikss.org.ru, пожалуйста.

Дамп вечером пришлю. Пока могу добавить последние наблюдения, ездил только что физически в проблемную контору.

1) соединение через роутер - беру любой файл из журнала обновлений сбис. Вставляю ссылку в браузер - первая попытка всегда «ошибка сети», посоедующие попытки как правило нормальная загрузка.

2) соединение без роутера, машина напрямую с адресом провайдера - любые попытки загрузок нормальные.

3) iptables flush на роутере ничего не меняет. Точно не фаервол.

4) установил на другую машину с другим провайдером новый базовый СБИС. Через Wireshark так же вижу пакеты RST от сервера обновлений СБИС, только они не мешают всё таки принимать оьновления в итоге.

Пардон за почерк. С телефона пока.

А, забыл - сами обновления-то я ночью им пропихнул в итоге. Поэтому теперь все эксперименты тоьлко по файлам из журнаоа. До следующих настоящих обновлений.

Вот так и пропихивал - смотрю в журнале на каком файле заткнулось, убеждаюсь что браузер его скачивает, запускаю обновление ещё раз. Два часа упорства и всё установилось. Просто слелующий раз повторять не хочется.

Может на маршрутизаторе MTU на интерфейсе к провайдеру великоват? Попробуйте уменьшить.

Снял дампы со всех мест, написал длинное письмо...

Потом почитал ваше приветствие у вас в профиле и решил что я вас боюсь ))

Могу показать конец дампа, где сам обрыв происходит (пакеты с флагом RST). С измененным IP клиента. Это снято с внешнего интерфейса роутера.

00:53:48.306392 IP (tos 0x0, ttl 60, id 20807, offset 0, flags [DF], proto TCP (6), length 1500)
    185.60.132.183.443 > 999.999.999.999.2964: Flags [.], cksum 0x55ed (correct), seq 1007309:1008769, ack 1424, win 63, length 1460
00:53:48.350479 IP (tos 0x0, ttl 60, id 42976, offset 0, flags [DF], proto TCP (6), length 40)
    185.60.132.183.443 > 999.999.999.999.2964: Flags [R], cksum 0x889a (correct), seq 2063934667, win 0, length 0
00:53:48.350556 IP (tos 0x0, ttl 60, id 42977, offset 0, flags [DF], proto TCP (6), length 40)
    185.60.132.183.443 > 999.999.999.999.2964: Flags [R], cksum 0x889a (correct), seq 2063934667, win 0, length 0
00:53:48.350618 IP (tos 0x0, ttl 60, id 42978, offset 0, flags [DF], proto TCP (6), length 40)
    185.60.132.183.443 > 999.999.999.999.2964: Flags [R], cksum 0x889a (correct), seq 2063934667, win 0, length 0
00:53:48.352861 IP (tos 0x0, ttl 60, id 42980, offset 0, flags [DF], proto TCP (6), length 40)
    185.60.132.183.443 > 999.999.999.999.2964: Flags [R], cksum 0x82e6 (correct), seq 2063936127, win 0, length 0
00:53:48.352928 IP (tos 0x0, ttl 60, id 42981, offset 0, flags [DF], proto TCP (6), length 40)
    185.60.132.183.443 > 999.999.999.999.2964: Flags [R], cksum 0xe3c1 (correct), seq 2064501147, win 0, length 0

Не бойся его, ЕМНИП, его коду доверяют миллионы сограждан =D Если бы он встал на темную сторону и захотел полюбоваться на чужой трафик, он бы не просил вежливо дампы почтой.

По крайней мере, по этом куцому текстовому дампу предполагаю, что соединение разрывает всё же сервер. Обращайтесь к владельцу сервера.

Да, спасибо.

Выходные жеж. Завтра, наверное, буду звонить в ТП.

До сих пор с ТП бухгалтеры сами общались. И им, естественно, напихали, что проблема не с их стороны. Мол, проверяйте ваши интернеты. Пришлось ехать, проверять.

Вроде Тензор - приличная контора. Для начала хочу всё перепробовать на своей стороне. Хотя странно, что проблема только на их серверах проявляется.

Была похожая ситуация

Если первый ресет дропнуть, оно повторит само. Можно вообще все ресеты из этого направления дропать – в худшем случае оно будет считать, что сеть пакеты не доставляет. Правда, если там где-то состоятельный фиревол, может не помочь.

Вроде приличная контора

У меня такое было с NCR(кажется). Приличные конторы можут себе позволить купить слишком сложные системы раздачи файлов :)

В итоге так:

1) если на маршрутизаторе отбрасывать все пакеты с флагом RST (DROP) на 443 порту - никаких обрывов не происходит, все загрузки происходят нормально.

2) с ТП Тензор разговор не сложился, так и останется за кадром причина по которой их сервера пытаются оборвать соединения.

3) на всякий случай подготовлю к замене маршрутизатор.

Полагаю, вопрос исчерпан.

Пришлите хотя бы ссылку на файл на сервере, название провайдера, регион. Попробую воспроизвести проблему. Раз отбрасывание RST помогает, то дело либо в провайдерском DPI, либо в сбое каких-то систем балансировки или DDoS-защиты на стороне компании.