История изменений

вот что-то похожее нагуглил

Тема практически пятничная, но разбирательство слишком затянулось, поэтому всем доброе утро.

Имеются несколько подсетей, связанных c головной подсетью через IP-туннели. В них несколько сотен устройств нескольких моделей, которые управляются через TCP-сессии.

Замечено, что в нескольких сетях (и только в них) при ответе на определённый запрос (и только на него) подвисают сессии со всеми устройствами двух моделей. Остальные модели в этих подсетях работают нормально. В большинстве подсетей нормально работают все устройства всех моделей.

Методом проб и ошибок выяснено, что если на управляющем компьютере выключены TCP Timestamps (sysctl net.ipv4.tcp_timestamps=0 в Линуксе), то ответ от устройства на «плохой запрос» уйдёт через шлюз в удалённой сети в ip-туннель, но не придёт из ip-туннеля на шлюз в сети компьютера. После чего начнутся keep-alives, retransmits и т.д.

Т.е. проходит пакет, который содержит TCP Options (NOP, NOP, TSval+TSecr), и блокируется пакет, в котором Options отсутствуют. Кстати, у «плохого» пакета может быть верная контрольная сумма, а у «хорошего» - неправильная. Всё остальное одинаково.

Вопрос: почему IP-туннель может блокировать только TCP-пакеты с определённым ответом, и только если у них отсутствует необязательный TCP-флаг?

Тыц
У нас как раз у провайдера FreeBSD на серверах стоит, как и у автора этого поста.

вот что-то похожее нагуглил

Тема практически пятничная, но разбирательство слишком затянулось, поэтому всем доброе утро.

Имеются несколько подсетей, связанных c головной подсетью через IP-туннели. В них несколько сотен устройств нескольких моделей, которые управляются через TCP-сессии.

Замечено, что в нескольких сетях (и только в них) при ответе на определённый запрос (и только на него) подвисают сессии со всеми устройствами двух моделей. Остальные модели в этих подсетях работают нормально. В большинстве подсетей нормально работают все устройства всех моделей.

Методом проб и ошибок выяснено, что если на управляющем компьютере выключены TCP Timestamps (sysctl net.ipv4.tcp_timestamps=0 в Линуксе), то ответ от устройства на «плохой запрос» уйдёт через шлюз в удалённой сети в ip-туннель, но не придёт из ip-туннеля на шлюз в сети компьютера. После чего начнутся keep-alives, retransmits и т.д.

Т.е. проходит пакет, который содержит TCP Options (NOP, NOP, TSval+TSecr), и блокируется пакет, в котором Options отсутствуют. Кстати, у «плохого» пакета может быть верная контрольная сумма, а у «хорошего» - неправильная. Всё остальное одинаково.

Вопрос: почему IP-туннель может блокировать только TCP-пакеты с определённым ответом, и только если у них отсутствует необязательный TCP-флаг?

Тыц У нас как раз у провайдера FreeBSD на серверах стоит, как и у автора этого поста.

вот что-то похожее нагуглил

Тема практически пятничная, но разбирательство слишком затянулось, поэтому всем доброе утро.

Имеются несколько подсетей, связанных c головной подсетью через IP-туннели. В них несколько сотен устройств нескольких моделей, которые управляются через TCP-сессии.

Замечено, что в нескольких сетях (и только в них) при ответе на определённый запрос (и только на него) подвисают сессии со всеми устройствами двух моделей. Остальные модели в этих подсетях работают нормально. В большинстве подсетей нормально работают все устройства всех моделей.

Методом проб и ошибок выяснено, что если на управляющем компьютере выключены TCP Timestamps (sysctl net.ipv4.tcp_timestamps=0 в Линуксе), то ответ от устройства на «плохой запрос» уйдёт через шлюз в удалённой сети в ip-туннель, но не придёт из ip-туннеля на шлюз в сети компьютера. После чего начнутся keep-alives, retransmits и т.д.

Т.е. проходит пакет, который содержит TCP Options (NOP, NOP, TSval+TSecr), и блокируется пакет, в котором Options отсутствуют. Кстати, у «плохого» пакета может быть верная контрольная сумма, а у «хорошего» - неправильная. Всё остальное одинаково.

Вопрос: почему IP-туннель может блокировать только TCP-пакеты с определённым ответом, и только если у них отсутствует необязательный TCP-флаг?

Тыц