У нас есть проблема, что некоторые клиенты (все это Linux Ubuntu) иногда не могут подключиться к удаленному серверу через SSH. Если проблема возникает, клиенты Windows не имеют этой проблемы и могут нормально подключиться.
Я нашел этот другой вопрос с аналогичной проблемой: Почему сервер не отправляет пакет SYN / ACK в ответ на пакет SYN
Отключение меток времени TCP на сервере действительно решает проблему, но я хотел бы знать, в чем настоящая проблема. Я действительно не понимаю, почему это должно вызывать какие-либо проблемы, определенно не при установлении соединения.
При использовании Wireshark я вижу, что клиенты Windows используют размер окна 8192, тогда как клиенты Linux используют размер окна 29200. Клиенты Windows получают SYN_ACK, клиенты Linux - нет. Возможно ли, что этот более высокий начальный размер окна отвечает за то, что сервер не отправляет SYN_ACK? Я не могу придумать разумного объяснения того, почему это может вызвать данную проблему, но, поскольку это единственное (видимое мне) различие, оно действительно выглядит так. Я что-то упускаю?
*** РЕДАКТИРОВАТЬ После дополнительных поисков, размышлений и некоторой магии вуду, я думаю, что мог бы придумать правдоподобное объяснение. Для этого требуются некоторые допущения и особые условия, но я верю, что это возможно в данной конкретной ситуации.
Оба пользователя находятся за одним и тем же устройством NAT (в нашем случае - межсетевым экраном Fortigate). Этот брандмауэр будет назначать локальные порты на своем внешнем интерфейсе / IP для каждого соединения с NAT. Если порт уже используется другим пользователем, он пропускается. Если соединение закрывается, порт освобождается и возвращается в пул NAT. Если этот порт затем назначен другому пользователю, но сервер все еще имеет некоторую запись соединения (TIME_WAIT, окончательный FIN / ACK не получен), а временная метка пакета меньше, чем у предыдущего соединения, пакет будет молча проигнорировал.
Хорошо, там много if, но ... - два пользователя разрабатывают один и тот же веб-сайт, поэтому они будут делать много подключений к одному и тому же удаленному серверу - брандмауэр (Fortigate), по-видимому, поддерживает последовательный счетчик порта NAT для каждого IP-адреса источника / IP-адреса назначения / порта назначения. Если счетчики обоих пользователей близки друг к другу, шансы на такое «столкновение» с двумя подключениями к этому серверу не так уж маловероятны, учитывая, что оба 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 в самом начале. Можно было бы ожидать, что он остановится после обмена несколькими пакетами со значениями меток времени. Точнее, когда значение метки времени из одного пакета кажется обратным по времени от предыдущего пакета.