Клиенты Linux не могут соединиться, сервер и Windows Size TCP / проблема Меток времени
У нас есть проблема, которую много клиентов (вся Ubuntu Linux) иногда не в состоянии подключить к удаленному серверу по SSH. Если проблема происходит, клиенты Windows не имеют той проблемы и могут соединиться очень хорошо.
Я нашел этот другой вопрос с подобной проблемой: Почему сервер не отправил бы пакет SYN/ACK в ответ на пакет SYN
Отключение TCP, Устанавливающего метку времени на сервере, действительно решает проблему, но я хотел бы знать, какова настоящая проблема. Я действительно не вижу, почему это должно вызвать любые проблемы, определенно не при установлении соединения.
При использовании Wireshark я вижу, что клиенты Windows используют Размер окна 8 192, тогда как клиенты Linux используют Размер окна 29 200. Клиенты Windows получают SYN_ACK, клиенты Linux не делают. Действительно ли возможно, что этот более высокий начальный размер окна ответственен за то, что не был отправлен SYN_ACK сервером? Я не могу придумать разумное объяснение относительно того, почему оно могло вызвать данную проблему, но так как это - единственное (видимый мне) различие, это, действительно кажется, похоже на это. Я пропускаю что-то?
*** РЕДАКТИРОВАНИЕ После большего количества поиска, размышления и некоторого волшебства вуду, я думаю, что, возможно, придумал вероятное объяснение. Действительно требуются некоторые предположения и особые условия существовать, но я действительно полагаю, что они могли бы просто быть возможными в этой конкретной ситуации.
Оба пользователя находятся позади того же устройства NAT (в нашем случае, брандмауэре Fortigate). Этот брандмауэр присвоит локальные порты на, он - внешний интерфейс/IP к каждому соединению NAT'ed. Если порт уже используется другому пользователю, он пропускается. Если соединение закрывается, порт выпущен и возвращен к пулу NAT. Если тот порт будет затем присвоен другому пользователю, но сервер все еще имеет некоторую запись соединения (TIME_WAIT, заключительный FIN/ACK, не полученный), и метка времени пакета ниже из метки времени предыдущего соединения, то пакет будет тихо disgarded.
Хорошо, существуют, многие из если там, но... - эти два пользователя разрабатывают на том же веб-сайте, таким образом, они будут устанавливать много связей с тем же удаленным сервером - брандмауэр (Fortigate) appearantly сохраняет последовательный счетчик порта NAT на источник IP/destinationIP/destinationPort. Если счетчики обоих пользователей друг близко к другу, возможности такой "коллизии", происходящей с двумя соединениями с тем сервером, не состоят в том, что вряд ли, учитывая, что оба целевых IP как порт то же. Это объяснило бы, почему проблема только происходит эпизодически.
Единственная проблема с этой теорией состоит в том, что я не могу найти доказательство этого случая на стороне сервера. Нет всунутого TIME_WAIT никакого соединения или чего-то как этот, и я действительно предполагаю, что, после того как они исчезают из вывода netstat, сервер забыл о них.
Я действительно полагаю, что начальный Размер окна не играет роль в этом, таким образом, я поразителен что один из списка подозреваемых.
Итак, если У клиентов Windows нет проблемы, я предполагаю, что они не запрашивают метки времени TCP, в то время как клиенты Linux. Вы можете убедиться в этом, снова посмотрев на записи Wireshark из обоих примеров.
Чтобы начать устранение основной причины проблемы с меткой времени, первым делом необходимо убедиться, что клиент и сервер синхронизированы с серверами NTP. Если у них просто часы, работающие бесплатно, это вполне может быть причиной проблемы. Например:
# ntpq -p
remote refid st t when poll reach delay offset jitter
========================================================================
*utcnist2.colora .ACTS. 1 u 92 1024 377 50.242 2.041 1.847
+time-c.timefreq .ACTS. 1 u 623 1024 377 55.413 -1.781 0.418
Убедитесь, что хотя бы у одной звездочка впереди. Это означает, что все синхронизировано. Как-то странно видеть остановку сеанса TCP в самом начале. Можно было бы ожидать, что он остановится после обмена несколькими пакетами со значениями меток времени. Точнее, когда значение метки времени из одного пакета кажется обратным по времени от предыдущего пакета.