Задержка подключения клиента SSH в локальной сети при включенном брандмауэре Windows

Проблема возникла после того, как я обновил свой компьютер разработчика до Win11, на котором до этого работала Win10.

  • На моем локальном сервере установлена ​​Ubuntu 22.04.
  • Ssh-клиенты Win11: putty, WSL2 ssh, оба испытывают 20-секундную задержку при подключении к серверу по локальной сети.
  • Однако те же клиенты подключаются к WAN-серверу без задержек.
  • Задержка одинакова для соединений с паролем или ключевым файлом.
  • Два разных клиента Android с двух разных устройств подключаются к одному и тому же серверу/порту без каких-либо проблем или задержек.

Что я пробовал до сих пор:

  • Номер порта SSH не имеет значения, та же проблема с 22 или любым другим.
  • Включение/отключение VPN на сервере/клиенте Win11 не имеет никакого эффекта, та же задержка, в то время как Android отлично подключается с VPN как на сервере/клиенте, так и без VPN.

Изначально я подозревал конфигурацию сервера, перепробовал все распространенные решения, для UseDNS установлено значение «нет», и подведем итог: ни одно из перечисленных здесь разрешений не помогает — https://jrs-s.net/2017/07/01/slow-ssh-логины/.

  • Добавление нового правила брандмауэра в брандмауэр Windows для шпатлевки не помогло, поскольку соединение не блокируется, а только эта задержка.

  • Кроме того, для тестирования, пытаясь найти нарушающее правило, я просто отключил все активные правила брандмауэра, никаких изменений, та же 20-секундная задержка. Отключение брандмауэра решает проблему.

  • Пробовал также редактировать групповые политики с помощью GPE(редактора групповой политики). Не уверен, что я понимаю, почему входящие правила в разделе «Политика локального компьютера/Конфигурация компьютера/Параметры Windows/Параметры безопасности/Брандмауэр Защитника Windows/Локальная группа WDF пусты, когда настройки брандмауэра в настройках Windows показывают большое количество правил, но в любом случае добавление входящих/исходящих правил» замазка там тоже не решила проблему.

  • Обошел сетевой коммутатор, в некоторых сообщениях это упоминалось как потенциальная проблема, прямое подключение обоих компьютеров к маршрутизатору, тот же результат.

  • Создал виртуальную машину Win10 и использовал ssh из терминала администратора, та же задержка.

На данный момент у меня закончились идеи для расследования.

Если я просто отключу брандмауэр защитника Windows, проблема исчезнет. Это не совсем вариант.

Никакие ошибки не регистрируются ни на стороннем сервере, ни на клиенте. Вывод журнала при возникновении задержки: На стороне клиента последняя строка перед задержкой:

debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.5

И соответствующая строка из журнала аутентификации сервера (в системном журнале ничего нет):

GatorNas sshd[1655346]: debug1: inetd sockets after dupping: 4, 4

Через 20 секунд все работает, появляется запрос пароля, соединение установлено, скорость в порядке и т. д.

Я вообще недоумеваю, почему соединение по локальной сети задерживается, а подключение к серверу в инете занимает доли секунды...

Обновления:

  • Захват пакетов на Win11, чтобы увидеть фильтрацию LLNMR и mDNS по udp 5355 и udp 5353. Ничего.
  • Захват пакетов в Ubuntu, тот же фильтр, что и выше для Wireshark, без трафика.

Использование фильтра (udp.port == 5355) || (udp.port == 5353). Любой совет о том, как отфильтровать сетевой трафик, чтобы сузить его до чего-то полезного, будет полезен.

Найдена причина задержки: дополнительный захват пакетов выявил проблему с идентификатором порта 113. Сервер отправляет запрос на 113, затем следуют 3 повторные передачи TCP, отсюда и задержка.

Все еще не могу понять:

  1. Почему проблема проявляется только в локальной сети
  2. Что еще более важно, открытие порта 113 в брандмауэре Windows для локальной сети не имеет никакого эффекта :(

Обходной путь: отклоните весь трафик на порту 113 на сервере ssh.

Источник

1 ответ

Ваш SSH-сервер настроен на отправку запроса Ident обратно подключающемуся клиенту, чтобы узнать имя пользователя ОС клиента (предположительно, для целей ведения журнала).

Почему проблема проявляется только в локальной сети

Сервер локальной сети — единственный, специально настроенный для выполнения идентификационных запросов. Это не значение по умолчанию (для достижения такой ситуации требуется довольно продуманная настройка), и ваш WAN-сервер этого не делает.

Я не видел ни одного SSH-сервера, который бы выполнял запросы Ident самостоятельно (OpenSSH, конечно, не делает), но из ваших журналов похоже, что ваш sshd запускается через inetd , а не является отдельной службой, как обычно. (Inetd и xinetd — это «суперсерверные» службы, которые ждут соединений и запускают фактическую службу sshd/ftpd/telnetd/etc. по требованию; это также известно как «активация сокета» в systemd или launchd.)

В частности, на сервере, вероятно, работает xinetd и имеетсяsshсервис настроен в/etc/xinetd.conf(или где-то в/etc/xinetd.d/ssh*). Если вы это обнаружите, найдите настройку, которая позволяетUSERIDlogging — если найден, удалите его и перезапустите xinetd. Это может быть что-то вроде этого:

      service ssh
{
    [...]
    log_on_success += HOST USERID
    log_on_failure += HOST USERID
}

Что еще более важно, открытие порта 113 в брандмауэре Windows для локальной сети не имеет никакого эффекта :(

В наши дни очень редко на каком-либо компьютере используется ответчик Ident (IRC — единственное место, где он нашел какое-либо существенное применение), но обычно входящее соединение с портом 113 будет немедленно отклонено с использованием пакета TCP RST и сервер будет продолжать работу. Аналогичным образом можно настроить брандмауэры для блокировки соединений, явно отклоняя их.

Однако брандмауэр Windows по умолчанию работает в «Скрытом режиме», где он игнорирует попытки подключения к портам, у которых нет прослушивающего сокета, поэтому сервер вынужден ждать тайм-аут TCP-соединения ~ 30 с. Это происходит, даже если вы явно разрешаете подключения к порту 113, поскольку функция «Скрытый режим» применяется ко всем запросам на неиспользуемые порты независимо от того, разрешают ли правила этот трафик или нет.

Поэтому, пока ничего не прослушивает порт 113 и брандмауэр активен, запрос будет спокойно игнорироваться (вместо отправки правильного пакета отклонения TCP RST).

Хотя лучшим вариантом было бы в первую очередь запретить серверу выполнять идентификационные запросы, вы также можете отключить «Скрытый» режим в Windows через реестр (вряд ли это на самом деле так важно, как утверждается — заблокированные запросы по-прежнему будут продолжаться). заблокировано):

  • Команда:

            for %p in (Public Private Domain Standard) do (
  reg add HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\%pProfile /v DisableStealthMode /t REG_DWORD /d 1
)
Источник
Другие вопросы по тегам