У меня проблема с нашими ящиками RHEL7, которые обмениваются данными с центральным сервером, находящимся за межсетевым экраном Cisco ASA.
Эти машины загружаются и запускают агент, который устанавливает и поддерживает соединение с центральным сервером. Затем центральный сервер периодически отправляет трафик по этому туннелю клиенту. Через 5 минут мы увидели, что агенты отключились и не могли отправлять трафик через соединение, если мы не перезапустили соединение, после чего все работало нормально.
Дальнейшие исследования показали, что дело не только в этом приложении / агенте, и что мы можем воспроизвести его с помощью «nc» в обязательном порядке. Мы перехватили пакеты и обнаружили, что через 5 минут ASA отбрасывает пакеты ACK, отправляемые с клиентского сервера. Центральный сервер не будет видеть никаких пакетов и продолжит попытки повторной передачи. Клиент получит повторные передачи, отправит ACK, ASA сбросит его - промыть / повторить.
Изучая перехваты, мы обнаружили, что на отметке 5 минут клиентский сервер сбрасывает TSVal в пакете ACK до некоторого низкого значения.
Вы можете видеть в приведенном ниже захвате пакета, что пакет 101, клиент отправляет ACK с TSVal, равным 4294962488. Затем сервер отправляет больше данных (пакет 102), но на пакет 103 теперь клиент отвечает ACK с TSVal, установленным на 196.
No. Time Timestamp Source Destination Protocol Length Info
96 2017-07-11 15:16:04.717785 22:16:04.717785 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107029 Ack=2031069343 Win=29056 Len=35 TSval=1400815609 TSecr=4294947477
97 2017-07-11 15:16:04.717802 22:16:04.717802 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107064 Win=29312 Len=0 TSval=4294952481 TSecr=1400815609
98 2017-07-11 15:16:09.721130 22:16:09.721130 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107064 Ack=2031069343 Win=29056 Len=35 TSval=1400820612 TSecr=4294952481
99 2017-07-11 15:16:09.721152 22:16:09.721152 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107099 Win=29312 Len=0 TSval=4294957485 TSecr=1400820612
100 2017-07-11 15:16:14.724742 22:16:14.724742 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107099 Ack=2031069343 Win=29056 Len=35 TSval=1400825616 TSecr=4294957485
101 2017-07-11 15:16:14.724757 22:16:14.724757 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107134 Win=29312 Len=0 TSval=4294962488 TSecr=1400825616
102 2017-07-11 15:16:19.728187 22:16:19.728187 10.158.35.162 10.153.195.227 TCP 101 4506 → 38208 [PSH, ACK] Seq=3089107134 Ack=2031069343 Win=29056 Len=35 TSval=1400830619 TSecr=4294962488
103 2017-07-11 15:16:19.728207 22:16:19.728207 10.153.195.227 10.158.35.162 TCP 66 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107169 Win=29312 Len=0 TSval=196 TSecr=1400830619
104 2017-07-11 15:16:19.728556 22:16:19.728556 10.158.35.162 10.153.195.227 TCP 66 [TCP Dup ACK 2#1] 4506 → 38208 [PSH, ACK] Seq=3089107169 Ack=2031069343 Win=29056 Len=0 TSval=1400830619 TSecr=4294962488
105 2017-07-11 15:16:19.928307 22:16:19.928307 10.158.35.162 10.153.195.227 TCP 101 [TCP Spurious Retransmission] 4506 → 38208 [PSH, ACK] Seq=3089107134 Ack=2031069343 Win=29056 Len=35 TSval=1400830820 TSecr=4294962488
106 2017-07-11 15:16:19.928319 22:16:19.928319 10.153.195.227 10.158.35.162 TCP 78 [TCP Dup ACK 103#1] 38208 → 4506 [ACK] Seq=2031069343 Ack=3089107169 Win=29312 Len=0 TSval=396 TSecr=1400830820 SLE=3089107134 SRE=3089107169
107 2017-07-11 15:16:19.928702 22:16:19.928702 10.158.35.162 10.153.195.227 TCP 66 [TCP Dup ACK 2#2] 4506 → 38208 [PSH, ACK] Seq=3089107169 Ack=2031069343 Win=29056 Len=0 TSval=1400830820 TSecr=4294962488
Затем ASA считает это искаженным и отбрасывает его, поскольку TSVal не должен уменьшаться.
Мы экспериментировали с отключением tcp_timestamps через / proc / sys / net / ipv4 / tcp_timestamps. Это работает, и проблема исчезает, однако отключение временных меток может иметь другие последствия для трафика других приложений.
Кроме того, все еще возникает вопрос, почему TSVal сбрасывается до такого низкого значения через 5 минут пребывания хоста в сети? Это происходит только в наших системах RHEL7u2 - наши блоки RHEL6 не испытывают этой проблемы.
Любые мысли / помощь будут оценены.
Я не думаю, что брандмауэр должен их отбрасывать, он должен смотреть на оба порядковых номера и отметки времени вместе ... я предполагаю, что RHEL 7 теперь рандомизирует отметки времени из соображений безопасности, но, возможно, брандмауэр довольно старый? "