3

Иногда я использую PuTTY в качестве прокси-сервера SOCKS, и я заметил, что иногда, когда веб-страница, к которой я пытаюсь подключиться (из веб-браузера), не существует и требует длительного времени ожидания, сеанс оболочки останавливается (не может вводить интерактивно в терминале, пока не истечет время ожидания), а также все другие запросы веб-страниц также останавливаются.

Я недавно заметил, что это, похоже, связано с DNS: сейчас кажется, что серверы, указанные на стороне sshd в /etc/resolv.conf , имеют некоторые проблемы, и, в результате, почти невозможно просматривайте Интернет через прокси-сервер PuTTY SOCKS, а также терминал PuTTY останавливается почти все время, когда любой попытка просмотра веб-страниц была неудачной.

Следующая ошибка часто появляется в журналах PuTTY, после чего остановка на некоторое время прекращается:

2014-01-11 17:12:03 Forwarded connection refused by server: Administratively prohibited [open failed]

Обычно, это то, что я вижу в журналах, вместо этого создается впечатление, что мой браузер с поддержкой SOCKS даже не знает, к какому IP-адресу будет подключен прокси-сервер SOCKS:

2014-01-11 17:18:11 Opening forwarded connection to superuser.com:80

Изменение DNS-сервера вокруг демона ssh будет только временным решением, которое не решит основную проблему с остановкой OpenSSH / PuTTY в этих ситуациях. (Не использовать имена хостов через SOCKS тоже будет неправильно).

Есть ли способ смягчить срыв SSH навсегда?

(По крайней мере, казалось бы, что sshd должен быть более агрессивным в тайм-ауте DNS и повторных попытках с другим сервером. У меня есть несколько серверов, указанных в /etc/resolv.conf, и dig похоже, перезапускает запрос к следующему серверу ровно через 1 с, что кажется более подходящим, чем то, что, по-видимому, делает sshd.)

1 ответ1

1

По словам разработчика OpenSSH из официального списка рассылки, http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/031974.html, это связано с тем, что используется стандартный преобразователь libc OpenSSH, который является синхронным и блокирующим, поэтому никакой другой трафик не обрабатывается, пока выполняется разрешение.

Исправление этой проблемы потребовало бы исправления в ssh/channel.c # connect_to в OpenSSH (ошибка # 1357 подтверждает, что он находится в пути кода SOCKS5, используемого Mozilla), чтобы использовать функцию разрешения, отличную от getaddrinfo по умолчанию из libc.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .