#reset mark
#add through space to rule comment
:local resetMark reset-mark
/ip firewall filter reset-counters [/ip firewall filter find comment~"$resetMark"]
В вашем случае, при изменение порядка следования правил придется менять и правило сброса.
Попробуйте приведенный код. В комменты правил, счетчики которых нужно сбросить, добавьте текст reset-mark через пробел от основного коммента.
Тогда скрипт не будет зависеть от порядка правил. Для микротика это обычная практика.
Ну как, браузер отчаянно пытался получить контент по https, ждал когда закончится обмен ключами. А DPI всё дропал server hello done. В итоге браузер сдавался и работал по http.
Этого в дампе нет, просто догадка.
Почему именно эти пакеты? А почему нет?)
Сложности в этом нет, я даже на микротике такое настраивал. База сигнатур есть.
Об этом надо думать как об особенности реализации.
К тому же сервер пытался переслать пакеты повторно т.к. не получил ACK, но они по прежнему не доходили и сессия всё больше сегментирвалась. Один случайность, два закономерность.
Небольшая догадка, пакеты с цепочкой сертификатов весят много больше чем хилые пакеты c hello done состоящие из пары байт.
Соответственно, чем меньше весит пакет тем меньше времени и памяти уйдет на его анализ, если у вас тысячи клиентов, то время и память ключевые параметры.
Как я и сказал, нужно несколько дампов, чтобы сказать наверняка.
отсутствует Server Key Exchange и Server Hello Done в хендшейке
неверный номер пакета идущего от сервера после отправки сертификата
Так, сервер отправляет три ответа для установки сессионного ключа — это Certificate, Server Key Exchange, Server Hello Done. Двух последних в сессии нет.
Последний ответ сервера: сертификат. Воспользуемся тем что TCP маркирует пакеты чтобы получать подтверждения о доставке, маркер называется Sequence number.
Sequence number следующего пакета = Sequence number текущего + длинна TCP Segment текущего
Т.е. Sequence number следующего после сертификата пакета должен быть 5205, а у нас 5463. Значит сервер отправлял необходимые пакеты, но они не дошли.
Как удобно, отсутствует всего один ответ, но это не дает завершиться протоколу обмена ключами.
Дальше всё просто, сервер не получает подтверждения получения всех пакетов хендшейка, т.к. часть не дошла, и отправляет их заново, но они не доходят. Всё завершается сбросом соединения[TCP RST].
Для того чтобы сделать выводы, нужно несколько дампов.
Если во всех дампах будет отсутствовать Server Hello Done, то это сигнатурный анализ с последующий дропом пакета. В простонародье DPI. Никакие шейперы, натЫ и фаерволла не могут дропнуть один пакет из хендшейка и не давать переслать его заново, а сигнатурный анализ может.
В вашем случае, при изменение порядка следования правил придется менять и правило сброса.
Попробуйте приведенный код. В комменты правил, счетчики которых нужно сбросить, добавьте текст reset-mark через пробел от основного коммента.
Тогда скрипт не будет зависеть от порядка правил. Для микротика это обычная практика.
Ну как, браузер отчаянно пытался получить контент по https, ждал когда закончится обмен ключами. А DPI всё дропал server hello done. В итоге браузер сдавался и работал по http.
Этого в дампе нет, просто догадка.
Почему именно эти пакеты? А почему нет?)
Сложности в этом нет, я даже на микротике такое настраивал. База сигнатур есть.
Об этом надо думать как об особенности реализации.
К тому же сервер пытался переслать пакеты повторно т.к. не получил ACK, но они по прежнему не доходили и сессия всё больше сегментирвалась. Один случайность, два закономерность.
Небольшая догадка, пакеты с цепочкой сертификатов весят много больше чем хилые пакеты c hello done состоящие из пары байт.
Соответственно, чем меньше весит пакет тем меньше времени и памяти уйдет на его анализ, если у вас тысячи клиентов, то время и память ключевые параметры.
Как я и сказал, нужно несколько дампов, чтобы сказать наверняка.
Так, сервер отправляет три ответа для установки сессионного ключа — это Certificate, Server Key Exchange, Server Hello Done. Двух последних в сессии нет.
Последний ответ сервера: сертификат. Воспользуемся тем что TCP маркирует пакеты чтобы получать подтверждения о доставке, маркер называется Sequence number.
Sequence number следующего пакета = Sequence number текущего + длинна TCP Segment текущего
Т.е. Sequence number следующего после сертификата пакета должен быть 5205, а у нас 5463. Значит сервер отправлял необходимые пакеты, но они не дошли.
Как удобно, отсутствует всего один ответ, но это не дает завершиться протоколу обмена ключами.
Дальше всё просто, сервер не получает подтверждения получения всех пакетов хендшейка, т.к. часть не дошла, и отправляет их заново, но они не доходят. Всё завершается сбросом соединения[TCP RST].
Для того чтобы сделать выводы, нужно несколько дампов.
Если во всех дампах будет отсутствовать Server Hello Done, то это сигнатурный анализ с последующий дропом пакета. В простонародье DPI. Никакие шейперы, натЫ и фаерволла не могут дропнуть один пакет из хендшейка и не давать переслать его заново, а сигнатурный анализ может.