удаленный сервер закрыл соединение код ошибки 1
«Ошибка HTTP при обращении к серверу: https:// Удаленный узел не прошел проверку»
Ошибка возникает при запуске ИБ. Например, когда выполняете соединение по HTTPS через тонкого клиента, но 1С не может проверить SSL-сертификат сервера. В большинстве случаев — это самоподписанный сертификат.
Возможные решения
1. Проверка даты/времени на ПК
Проверьте корректность через «Панель управления — Часы и регион — Дата и время». Отправьте команду на автоматическую синхронизацию, если вы соединены с сетью Интернет.
2. Проверка доступности
Скопируйте путь и попробуйте подключиться к базе 1С с помощью браузера (веб-клиента). Скорее всего, вы увидите дополнительные сообщения, которые покажут причину ошибки.
Посмотрите сведения о сертификате. В открывшемся окне перейдите на последнюю закладку и убедитесь, что цепочка сертификатов корректная. Непрерывная и без каких-либо предупреждающих иконок.
Если адрес не открывается — другие распространенные причины:
• доступ заблокирован через файл hosts;
• нет доступа из-за прокси-сервера;
• ресурс блокирован firewall/антивирусом.
3. Отключение проверок
Список ИБ — Выбор базы — Изменить… — Дополнительно… — Далее >
Выберите клиентский сертификат: Не предоставлять
Выберите способ проверки сертификата сервера: Не проверять
Не проверять сертификат сервера
4. Игнорирование ошибки проверки отзыва
В конфигурацию платформы — в файл conf с расширением cfg — добавьте следующую опцию:
Расположение файла:
• C:\Program Files\1cv8\8.х.хх.хххх\bin\conf
• C:\Program Files (x86)\1cv8\8.х.хх.хххх\bin\conf
Данный механизм игнорирует именно ошибки проверки отзыва, а не отменяет проверку отзыва сертификата. Поэтому, если сертификат сервера отозван и это подтверждено, то соединение с таким сервером установлено не будет.
5. Импорт самоподписанного сертификата
Добавьте сертификат сервера на ПК, с которого вы подключаетесь, в список «Локальный компьютер — Доверенные корневые центры сертификации — Сертификаты».
В этом случае поставьте режим «Выберите способ проверки сертификата сервера = Хранилище сертификатов Windows». Или укажите файл сертификатов CA — как удобнее.
6. Диагностика ошибок
Используйте методические рекомендации по диагностике ошибок ОС Windows из официальной статьи 1С.
Если окружение настроено корректно и есть доверие к сертификату удаленного ресурса, то ошибки не будет. Пусть все получится. 🤗
Если требуется дополнительная поддержка — наши специалисты готовы вам помочь → +7-911-500-10-11
Немного обо всем и все о немногом, или практический опыт системного администратора.
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| « Апр | Июнь » | |||||
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | ||||||
Соединение закрыто удаленным сервером
Подмена IP адресов и их DNS имен была реализована через файл hosts, который находится в каталоге C:\Windows\system32\drivers\etc\hosts. Чтобы исправить проблему достаточно открыть этот файл в том же Блокноте и удалить оттуда все строки с таким IP адресом. После этого все будет работать и можно будет снова заходить на все сайты. Кстати у вас IP адрес может быть и другим.
Остался ли где на компьютере сам вирус не знаю. Антивирус, по словам Виктории, ничего не обнаружил, в реестре тоже ничего подозрительного не было. В любом случае после перезагрузки, все сайты открывались как положено. Вероятно расчет был только на то, чтобы подменить файл hosts не оставляя никаких следов. Пользователь, попав на ложный сайт вконтакте, набрал бы свой логин и пароль и таким образом передал бы их третьим лицам.
Так что будьте бдительны и не попадайтесь на такие уловки.
Исправлено: Существующее соединение было принудительно закрыто удаленным хостом.
Обновление: Перестаньте получать сообщения об ошибках и замедляйте работу своей системы с помощью нашего инструмента оптимизации. Получите это сейчас на эту ссылку
Это происходит с сокетным соединением между клиент и сервер, Связь жива и здорова, передаются огромные объемы данных, но затем они отключаются из ниоткуда.
Обычно это означает, что удаленная сторона закрыла соединение (обычно отправляя пакет TCP / IP RST). Если вы работаете со сторонним приложением, вероятные причины следующие:
Как восстановить существующее соединение, принудительно закрытое удаленным хостом:
Устранение неполадок при использовании Traceroute
Используйте редактор реестра
Откройте редактор реестра и создайте две записи реестра в этих двух местах:
HKLM \ SYSTEMESYSTEM \ Текущий набор заказов \ Control \ Поставщик безопасности \ SCHANNEL \ Protocols \ TLS 1.0 \ Server
HKLM \ SYSTEM \ Все текущие заказы \ Контроль \ Провайдер безопасности \ SCHANNEL \ Протоколы \ TLS 1.0 \ Клиент
Имя: DisableByDefault
Тип: REG_DWORD
Дата: 0
Имя: включено
Тип: REG_DWORD
Даты: 1
Включить криптографию
Если на вашем компьютере отключена криптография, использование TLS 1.2 запрещено. Вот почему мы активируем криптографию на этом этапе. Для этого:
Заключение
Вероятно, всегда будет «исключение первого шанса» для сброса соединения, так что сбросы можно отличить от плавного завершения соединения. Обычно это не очень важно для HTTP-соединений, так как можно определить, было ли соединение закрыто преждевременно, посмотрев на такие вещи, как заголовок Content-Length, но Kestrel утверждает, что это больше, чем просто HTTP-сервер.
Кроме того, неполное тело запроса всегда вызывает удаление исключения с помощью HttpContext.Request.Body.ReadAsync (), независимо от того, основано ли оно на сбросе соединения, поскольку сервер приложений указывает, что загрузка тела запроса не имеет был успешным
CCNA, веб-разработчик, ПК для устранения неполадок
Я компьютерный энтузиаст и практикующий ИТ-специалист. У меня за плечами многолетний опыт работы в области компьютерного программирования, устранения неисправностей и ремонта оборудования. Я специализируюсь на веб-разработке и дизайне баз данных. У меня также есть сертификат CCNA для проектирования сетей и устранения неполадок.
Как исправить ошибку удаленного рабочего стола не удается подключиться к удаленному компьютеру
Подключение к удаленному рабочему столу позволяет подключаться к компьютерам с удаленным рабочим столом для устранения неполадок и других целей. Однако при попытке установить или установить соединение вы можете столкнуться с ошибкой «Удаленному рабочему столу не удается подключиться к удаленному компьютеру».
Эта ошибка может возникнуть по нескольким причинам, в основном из-за неправильной конфигурации и проблем с сетью. В этой статье мы рассмотрим причины и некоторые советы по устранению неполадок, которые помогут вам снова заставить RDC работать.
Причины, по которым удаленный рабочий стол не может подключиться к удаленному компьютеру?
Эта ошибка может возникнуть по нескольким причинам:
На главном компьютере должен быть включен удаленный рабочий стол. Эта функция доступна только в Windows 10 Pro и более поздних версиях.
На исходящие и входящие соединения может влиять наличие антивируса на вашем компьютере. Убедитесь, что ваш брандмауэр не блокирует RDP-соединение, и при необходимости добавьте его в белый список.
Убедитесь, что у вашей учетной записи достаточно прав для запуска подключения с исходного компьютера.
У вас неправильная конфигурация прослушивающих портов, поврежденные учетные данные RDC или некоторые проблемы, связанные с сетью.
Теперь, когда вы знаете потенциальные причины, давайте рассмотрим несколько исправлений, которые вы можете использовать, чтобы устранить эту ошибку на своем компьютере.
1. Включите удаленный рабочий стол на вашем компьютере.
Прежде чем пытаться исправить что-либо в этой статье, убедитесь, что на вашем компьютере включен удаленный рабочий стол.
Чтобы включить удаленный рабочий стол в Windows 10:
Перейдите в Пуск> Настройки> Система> Удаленный рабочий стол.
Переключите переключатель в разделе «Включить удаленный рабочий стол», чтобы включить службу.
Следуйте нашему руководству по включению и настройке подключения к удаленному рабочему столу в Window 10 для получения дальнейших инструкций.
Если удаленный рабочий стол уже включен, выключите его и перезагрузите компьютер. После перезагрузки компьютера снова включите удаленный рабочий стол и проверьте наличие улучшений.
2. Проверьте правила брандмауэра.
В зависимости от того, как вы настроили политику своего брандмауэра, он может блокировать некоторые входящие и исходящие сообщения. Проверьте настройки брандмауэра Защитника Windows, чтобы узнать, не заблокировано ли подключение к удаленному рабочему столу. Если да, добавьте приложение в список разрешенных.
Чтобы разблокировать удаленный рабочий стол в брандмауэре Защитника Windows:
Введите Защитник Windows в строке поиска Windows и нажмите Брандмауэр Защитника Windows.
В появившемся окне нажмите Разрешить приложение или функцию через брандмауэр Защитника Windows.
Нажмите «Изменить настройки», чтобы добавить или изменить разрешения приложений. Он покажет список приложений и функций, которые разрешены для входящих и исходящих подключений.
Прокрутите вниз и установите флажок Удаленный рабочий стол для столбцов Private и Public.
Щелкните ОК, чтобы применить изменения.
3. Измените свой сетевой профиль.
В Windows 10 вы можете сделать свой сетевой профиль общедоступным или частным. В общедоступной сети Windows отключает функцию сетевого обнаружения, чтобы скрыть ваш компьютер от других компьютеров.
Попробуйте изменить свою сеть на частную, чтобы проверить, сможете ли вы установить соединение с включенной функцией сетевого обнаружения. Вот как это сделать.
Нажмите Win + I, чтобы открыть Настройки.
Зайдите в Сеть и Интернет. На вкладке «Статус» проверьте статус своей сети.
Чтобы изменить статус, нажмите кнопку «Свойства», а затем установите для своего сетевого профиля значение «Частный». Если он уже установлен на частный, измените его на общедоступный и проверьте наличие улучшений.
4. Сбросьте учетные данные для подключения к удаленному рабочему столу.
Когда вы впервые устанавливаете новое подключение к удаленному рабочему столу, клиент сохраняет учетные данные для быстрого входа в систему. Однако поврежденные или измененные учетные данные часто могут приводить к невозможности подключения удаленного рабочего стола к удаленному компьютеру.
Эту ошибку может решить быстрый сброс сохраненных учетных данных. Вот как это сделать.
Введите «Подключение к удаленному рабочему столу» в строке поиска Windows и откройте клиент.
Щелкните раскрывающийся список Компьютер и выберите свой удаленный компьютер.
Щелкните ссылку «Удалить» в разделе «Имя пользователя» и нажмите «Да», чтобы подтвердить действие.
После сброса учетных данных перезапустите клиент подключения к удаленному рабочему столу и попробуйте подключиться снова.
5. Добавьте адрес удаленного компьютера в файл Hosts.
Другой способ устранить ошибку «Удаленный рабочий стол не может подключиться к удаленному компьютеру» — это добавить удаленный IP-адрес в файл hosts на вашем ПК. Файл Hosts Windows содержит информацию для сопоставления связи между IP-адресом и доменным именем.
Добавление адреса удаленного ПК в файл hosts вручную может помочь вам решить любые проблемы, которые могут возникнуть из-за разрешения доменного имени. Вот как это сделать.
Нажмите Win + I, чтобы открыть проводник, и перейдите в следующее место: C: Windows System32 drivers etc.
В папке etc щелкните правой кнопкой мыши файл hosts, выберите «Открыть с помощью» и выберите «Блокнот» из списка приложений.
Вы можете увидеть несколько закомментированных записей в файле hosts. Все, что вам нужно сделать, это добавить IP-адрес удаленного компьютера, к которому вы хотите подключиться, и сохранить файл (Ctrl + S).
6. Включите протокол RDP на удаленном компьютере с помощью редактора реестра.
Для работы подключения к удаленному рабочему столу в реестре должен быть включен протокол RDP. Проверьте запись реестра, связанную с протоколом RDP, чтобы убедиться, что он включен в вашей системе. Вот как это сделать.
Нажмите Win + R, чтобы открыть Выполнить.
Введите regedit и нажмите ОК, чтобы открыть редактор реестра.
Затем перейдите по следующему пути. Вы также можете скопировать и вставить то же самое для быстрой навигации: HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Terminal Server.
Щелкните правой кнопкой мыши значение fDenyTSConnection и выберите «Изменить».
В появившемся всплывающем окне введите 1 в поле «Значение».
Щелкните ОК, чтобы сохранить изменения.
Закройте редактор реестра, а затем запустите подключение к удаленному рабочему столу, чтобы проверить, устранена ли ошибка. Если проблема не исчезнет, проверьте конфигурацию порта прослушивания RDP в редакторе реестра.
Связано: Что такое реестр Windows и как его редактировать?
7. Проверьте и настройте порт прослушивания RDP.
RDP использует 3389 как порт прослушивания по умолчанию. Подобно статусу RDP, вы также можете настроить порт прослушивания с помощью редактора реестра. Вот как это сделать.
Откройте редактор реестра и перейдите в следующее расположение: Computer HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Terminal Server WinStations RDP-Tcp
Выберите ключ RDP-Tcp. Затем на правой панели щелкните правой кнопкой мыши PortNumber и выберите Edit.
Установите значение 3389 и нажмите ОК.
8. Включите службы удаленных рабочих столов в редакторе групповой политики.
Если проблема не исчезнет, возможно, объект групповой политики блокирует соединение с вашим локальным компьютером. Здесь вам нужно будет вручную включить службу с помощью редактора групповой политики. Вот как это сделать.
Нажмите Win + R, чтобы открыть Выполнить. Введите gpedit.msc и нажмите ОК. Откроется редактор групповой политики. В Windows 10 Home Edition вам нужно будет включить GPE вручную, прежде чем вы сможете получить доступ к инструменту.
В редакторе групповой политики перейдите в следующее расположение: Конфигурация компьютера Административные шаблоны Компоненты Windows Службы удаленного рабочего стола Узел сеанса удаленного рабочего стола Подключения.
В разделе «Параметры» найдите и дважды щелкните «Разрешить пользователям подключаться удаленно с помощью служб удаленных рабочих столов».
Выберите «Включено», нажмите «Применить» и «ОК», чтобы сохранить изменения.
Закройте редактор групповой политики и откройте командную строку от имени администратора. Для этого введите cmd в строке поиска Windows, щелкните правой кнопкой мыши командную строку и выберите «Запуск от имени администратора».
В командной строке введите gpupdate force и нажмите Enter. Это приведет к недавним изменениям, внесенным в GPO.
9. Проверьте статус ваших служб RDP.
Службы в ОС Windows — это программные приложения без пользовательского интерфейса, которые работают в фоновом режиме и обычно запускаются автоматически по расписанию. Чтобы удаленный рабочий стол работал, службы, связанные с RDP, должны работать как в удаленной, так и в клиентской системе.
Чтобы перезапустить службы RDP:
Нажмите Win + R, чтобы открыть Выполнить. Затем введите services и нажмите OK.
В окне «Службы» найдите и щелкните правой кнопкой мыши службу «Службы удаленных рабочих столов» (TermService) и выберите «Свойства».
В окне «Свойства» установите для параметра «Тип запуска» значение «Автоматический» и нажмите «Применить».
Снова щелкните службу правой кнопкой мыши и выберите «Перезагрузить».
Повторите шаги для службы перенаправителя портов пользовательского режима служб удаленных рабочих столов.
10. Добавьте ключ RDGClientTransport в реестр.
Еще один способ решения проблем, связанных с подключением к удаленному рабочему столу, — настроить редактор реестра для добавления ключа RDGClientTransport. Это заставит протокол удаленного рабочего стола использовать соединение RPC / HTTP вместо HTTP / UDP.
Чтобы добавить ключ RDGClientTransport:
Нажмите Win + R, чтобы открыть Выполнить. Введите regedit и нажмите ОК, чтобы открыть редактор реестра.
В редакторе реестра перейдите в следующее место. Компьютер HKEY_CURRENT_USER SOFTWARE Microsoft Клиент терминального сервера
Щелкните правой кнопкой мыши ключ клиента сервера терминалов и выберите «Создать»> «Значение DWORD (32-разрядное)».
Переименуйте значение как RDGClientTransport.
Затем дважды щелкните вновь созданные значения и введите 1 в поле «Значение данных». Щелкните ОК, чтобы сохранить изменения.
Теперь вы можете подключиться к удаленному рабочему столу без ошибок
Удаленный рабочий стол — удобный инструмент, доступный в Pro-версии Windows 10. Однако иногда вы можете столкнуться с проблемами, связанными с подключением, по разным причинам, включая отключенный удаленный рабочий стол, автономный хост-компьютер и проблемы с сетью. В зависимости от состояния вашего компьютера вам может потребоваться выполнить один или несколько шагов по устранению неполадок, чтобы устранить эту ошибку.
Преодоление разрыва удаленного соединения при отсутствии действий пользователя
При работе с GUI и терминальными приложениями нередко случается, что пользователь, работая в режиме удаленного доступа (как правило, через Интернет), покинув компьютер минут на 15, по возвращении обнаруживает, что программа зависла. На любое действие она отвечает ошибкой, содержащей примерно такие фразы: «Потеряна связь с сервером», «[WINSOCK] virtual circuit reset by host» и т.п. Наблюдается такое и при выполнении «долгоиграющих» методов (запросов к серверу), в которых не предусмотрен вывод прогресс-бара или какая-либо интерактивность.
Данная проблема характерна не только для GUI и терминальных решений на базе СУБД Caché и Ensemble компании InterSystems, а вообще для любого клиент-серверного взаимодействия по протоколу TCP/IP. Обычно она решается на прикладном уровне путём периодического обмена пустыми сообщениями специального вида, предназначенными лишь для того, чтобы просигнализировать о том, что приложение «живо».
Ниже о том, как можно решать эту проблему без программирования.
Источник проблемы
Источник проблемы лежит в природе протокола TCP/IP. Как правило, источник сеанса TCP/IP и его приемник находятся в различных сетях, и на пути сеанса встречается несколько маршрутизаторов. Хотя бы один из них обычно выполняет NAT-преобразование адресов. Ресурсы маршрутизатора всегда ограничены, поэтому некоторые из них выполняют очистку NAT-таблиц от «мёртвых» сеансов. Сеанс считается «мёртвым», если по нему не передавались пакеты в течение некоторого заданного интервала времени (назовем его интервал очистки). Таким образом, «молчаливый» сеанс может быть принят за «мёртвый» и вычищен из NAT-таблицы. При этом ни источник, ни приемник об этом не уведомляются («не царское дело»), и оба они остаются в уверенности, что сеанс ещё «жив» (в чем легко убедиться командой netstat, выполнив ее на клиенте или на сервере в момент возникновения ошибки, но до нажатия на ОК). Когда пользователь, получивший сообщение об ошибке, нажмет на ОК, о разрыве сеанса узнает клиент; серверный же процесс завершится, когда «умерший» сеанс распознает ОС.
Экспериментально установлено, что интервал очистки у многих маршутизаторов (по крайней мере, с прошитым Linux 2.4/iptables) составляет около 10 минут. Постараемся заставить наш TCP-сеанс автоматически поддерживать себя в активном состоянии, даже когда не передается никаких пакетов с данными.
Предлагаемое решение
На уровне ОС обнаружением разорванных TCP-соединений управляют следующие параметры ядра, управляющие работой механизма tcp_keepalive [1]:
• tcp_keepalive_time — интервал времени с момента отправки последнего пакета с данными; по истечении этого срока соединение помечается как требующее проверки; после начала проверки параметр не используется;
• tcp_keepalive_intvl — интервал между проверочными пакетами (отправка которых начинается по истечении tcp_keepalive_time);
• tcp_keepalive_probes — количество неподтвержденных проверочных пакетов; по исчерпании этого счетчика соединение считается разорванным.
Надо сказать, что механизм tcp_keepalive имеет двойное назначение: он может использоваться как для искусственного поддержания активности соединения, так и для выявления разорванных (так называемых «полуоткрытых») соединений. В данной статье обсуждается в основном первое применение, о втором применении, возможно, речь пойдёт в следующей статье на эту тему.
Для того чтобы механизм tcp_keepalive был задействован для TCP-соединений, необходимы два условия:
• поддержка на уровне ОС; к счастью, и в Windows, и в Linux она имеется;
• на одном из концов соединения сокет должен быть открыт с параметром SO_KEEPALIVE. Как оказалось, сервисы Caché открывают сокеты с этим параметром, а сервис OpenSSH несложно заставить поступать аналогично.
Наибольший интерес для нас представляет первый параметр (tcp_keepalive_time), так как именно от него зависит, насколько часто будет выполняться проверка неактивных (с точки зрения отсутствия трафика) соединений. Его значение по умолчанию — и в Windows, и в Linux — равно двум часам (7200 с). Типичное же время бездействия, после которого наступает разрыв, составляет около 10 минут. Поэтому предлагается установить значение параметра в 5 минут, что позволит искусственно поддерживать активность TCP-сеансов, не перегружая сеть избыточным трафиком (5 минут — это не 5 секунд).
Установка параметров tcp_keepalive на сервере Windows
Вы должны обладать правами Администратора к серверу. В разделе реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
создайте параметр DWORD с именем KeepAliveTime и значением 300000 (десятичным). Параметр задаётся в миллисекундах, поэтому предлагаемое значение — это 5 минут. После чего остановите Caché и перезагрузите сервер.
Что касается двух других параметров tcp_keepalive, то их умолчания в Windows таковы:
KeepAliveInterval
Key: Tcpip\Parameters
Value Type: REG_DWORD—time in milliseconds
Valid Range: 0–0xFFFFFFFE
Default: 1000 (1 секунда)
KeepAliveProbes
Такого параметра (устанавливающего количество неподтвержденных проверочных пакетов), в реестре не существует. Согласно [2], в Windows 2000 / XP / 2003 в этом качестве используется значение параметра TcpMaxDataRetransmission (умолчание — 5), а в более поздних версиях [3] — фиксированное значение, равное 10. Поэтому, если менять только значение первого параметра (с 7200 на 300), сохраняя умолчание для второго, сервер Windows 2008 будет узнавать о разрыве TCP-соединения через 1*10 + 300 = 310 секунд.
Установка параметров tcp_keepalive на сервере Linux
Изменить значения параметров можно «на ходу», не перезагружая сервер. Зайдите как root и выполните:
Чтобы сделать изменение долговечным по отношению к возможным перезагрузкам сервера, проще всего отредактировать файл параметров ядра /etc/sysctl.conf, добавив в него строку (лучше две):
Обратите внимание, что в отличие от Windows, значение параметра задается в секундах.
Что касается остальных двух параметров tcp_keepalive, то их умолчания в Linux таковы:
Если менять только значение первого параметра (с 7200 на 300), сохраняя умолчания для остальных двух, сервер Linux будет узнавать о разрыве соединения только через 75*9 + 300 = 975 секунд.
Установка параметра TCPKeepAlive в конфигурации СУБД Caché
Начиная с версии 2008.2, в Caché для платформ Windows и Linux появилась возможность задавать tcp_keepalive_time на уровне сокета, что удобно, так как позволяет избежать изменения настроек операционной системы. Однако «в чистом виде» эта возможность, в основном, представляет интерес лишь для независимых разработчиков сокет-серверов. К счастью, она была дополнена параметром конфигурации TCPKeepAlive=n в секции [SQL], доступным для редактирования со страницы Портала управления системой: Конфигурация > Общие Настройки SQL. Значение по умолчанию — 300 секунд (то, что доктор прописал). Действие параметра распространяется не только на SQL, но и, как нетрудно догадаться, на любые соединения с Caché, обслуживаемые сервисом %Service_Bindings. К ним относится, в частности, и объектный доступ через CacheActiveX.Factory, поэтому если ваше приложение может использовать этот протокол в качестве транспорта, не стоит упускать такую возможность.
Установка параметров KeepAlive в конфигурации сервера OpenSSH
Если вы используете SSH [4] (для работы в режиме командной оболочки или как транспорт для вашего GUI-приложения), то… скорее всего, проделанной настройки ядра будет достаточно, поскольку сервис OpenSSH (по крайней мере, в версии 5.x) по-умолчанию открывает сокет с параметром SO_KEEPALIVE.
На всякий случай стоит проверить конфигурационный файл /etc/ssh/sshd_config. Найдите в нем строку
Если нашли, то делать ничего не надо, так как значения параметров по умолчанию предоставляются в закомментированном виде.
Протокол SSH v.2 имеет альтернативные средства контроля активности сеансов, например, с помощью настройки параметров сервиса OpenSSH ClientAliveInterval и ClientAliveCountMax.
При использовании этих параметров, в отличие от TCPKeepAlive, запросы KeepAlive отправляются через защищённый SSH канал и не могут быть подменены. Приходится признать, что альтернативные средства являются более безопасными, нежели традиционный механизм TCPKeepAlive, для которого существует опасность анализа KeepAlive-пакетов и организации DoS-атак [5].
Устанавливает время ожидания в секундах, по истечении которого, если не поступает информация со стороны клиента, sshd отправляет ему запрос отклика через защищённый канал. По умолчанию используется 0, что означает, что клиенту не будет направлен такой запрос.
Устанавливает количество запросов клиенту, которые могут быть отправлены sshd без получения на них отклика. Если предел достигнут, sshd разъединяется с клиентом и завершает сеанс. Значение по умолчанию: 3. Если вы установите значение параметра ClientAliveInterval равным 60, оставив ClientAliveCountMax без изменений, то не отвечающие ssh-клиенты будут отключены примерно через 180 секунд. При этом следует отключить механизм TCP KeepAlive, установив
Всегда ли это работает?
Существуют категории сетевых проблем, в которых описанный подход может быть малоэффективен.
Одна из них имеет место, когда из-за низкого качества сетевого обслуживания связь может физически пропадать в течение коротких промежутков времени. Если сеанс бездействует, а связь временно пропадает и восстанавливается до того, как клиент или сервер попытаются что-то друг другу послать, то никто из них ничего «не замечает», и TCP-сеанс сохраняется. В случае периодических проверок TCPKeepAlive возрастает вероятность обращения сервера к клиенту в моменты временного исчезновения связи, что может вести к принудительным разрывам TCP-соединения. В такой ситуации можно попробовать увеличить на сервере KeepAliveInterval до 60-75 секунд (вспомнив, что в Windows умолчание — 1 секунда) при максимальном количестве повторов равным 10, в надежде, что за 10 минут любая временная сетевая проблема самоустранится. Правда, если повторные передачи будут длиться слишком долго, и окажется, что
KeepAliveTime + (KeepAliveInterval * кол-во_повторов) > 10 минут
то TCP-сеанс, несмотря на все предпринятые усилия, может быть принят за «мёртвый» и вычищен из NAT-таблицы.
Другая категория проблем связана с недостаточной пропускной способности используемых маршрутизаторов и/или каналов связи, когда при перегрузке могут теряться любые пакеты, в том числе и KeepAlive. В случае маршрутизаторов такие проблемы иногда решаются сменой прошивки (мне, например, это помогло победить Acorp ADSL XXXX), или, в худшем случае, заменой его на более производительную модель. В случае «слишком узких» каналов связи не остаётся ничего другого, кроме как их расширять.
Заключение
Предложенный подход позволяет искусственно поддерживать активность сеансов TCP/IP, по которым в текущий момент не передается никаких данных, исключительно на системном уровне, не внося каких-либо изменений в прикладной код. На сегодня он проверен и успешно используется в Caché for UNIX (Red Hat Enterprise Linux 5 for x86-64) 2010.1.4 (Build 803), Caché for Windows (x86-64) 2010.1.4 (Build 803), а также в более поздних версиях.
Следует признать, что он эффективно работает, если сетевое соединение физически устойчиво, и кроме разрыва неактивных сеансов других сетевых проблем у вас нет.
При развёртывании приложения в агрессивной среде (удалённый доступ, распределённые системы и т.д.), подумайте о реализации KeepAlive не на уровне TCP, а на уровне защищённого протокола более высокого уровня; хорошим кандидатом здесь оказывается SSH.