Помилка мережі PuTTY: з’єднання, спричинене програмним забезпеченням, перервано

У мене є дивна проблема: Коли я використовую PuTTY з SSH для підключення до сервера Linux, розміщеного в VMware в моїй локальній Windows 7 , я часто отримую повідомлення про помилку, "Network error: Software caused connection abort"і тоді вікно PuTTY SSH неактивне. Зазвичай я можу зайти на сервер за допомогою PuTTY і зробити щось, але після випадкового часу (приблизно одну-дві хвилини) я отримую цю помилку. І іноді я навіть не можу увійти, отримуючи помилку, кажучи про таймаут.

Я думаю, що з моїм плеєром VMware щось не так, тому що у мене є ще один робочий стіл Ubuntu, розміщений у VMware, як сервер сховища коду, і він частіше за все має помилку очікування, коли я роблю оновлення / фіксацію SVN. Однак я також здогадуюсь, що в Windows 7 є певна химерність, оскільки той самий сервер Ubuntu, розміщений у VMware, як сховище коду, працює дуже добре, коли в Windows Vista! Здається, все погане трапляється після переходу з Windows XP на Windows Vista, а потім на Windows 7!

Що може бути причиною цієї проблеми та як її виправити?

Доплата :

Я здійснив пошук у Google і застосував усі методи допомоги, зокрема:

1. Увімкнути sshd TCPKeepAlive
2. Встановіть SSHd ClientAliveIntervalв 900і ClientAliveCountMaxдо3
3. Встановіть для параметра підключення PuTTY "секунди між збереженнями" на " 5.

Але це все не працює! А сеанс SSH у PuTTY все-таки переривається після закінчення!

Я вимкнув і брандмауер сервера Linux, і клієнтський брандмауер Windows 7, але вхід все ще вичерпано! Це дійсно дратує!

Здається, іноді я можу ввійти, але іноді виходжу з часом! Я справді не знаю, чому. Це зводить мене з розуму!

Я мушу зазначити одне, що коли я використовую PuTTY SSH для підключення до віддаленого сервера, і все в порядку!

Коли я не зміг увійти, пінг також не вдався! Але, як це може статися? Я використовую програвач VMware для розміщення сервера Linux на моїй локальній машині!

У Putty є функція, яка намагається виправити цю проблему:

Network Error: Software caused connection abort

1. Початкова шпаклівка
2. Завантажте свої настройки з'єднання, якщо ви їх зберегли
3. Клацніть на "З'єднання"
4. У розділі "Надсилання нульових пакетів для активного сеансу" змінено його на 5 секунд. 300 секунд може бути краще, якщо проблеми з мережею є вашою проблемою, детальніше читайте нижче.

Як зберегти перешкоди для відключення з Putty:

Деякі мережеві маршрутизатори та брандмауери повинні відслідковувати всі з'єднання через них. Зазвичай ці брандмауери вважають, що з'єднання недійсне, якщо дані не передаються в будь-якому напрямку через певний проміжок часу. Це може призвести до несподіваного закриття брандмауера сеансів PuTTY, якщо протягом сеансу протягом певного часу не спостерігається трафік.

Параметр keepalive ("Секунди між збереженнями") дозволяє налаштувати PuTTY для надсилання даних через сеанс через рівні проміжки часу таким чином, що не порушує фактичний термінальний сеанс. Якщо ви виявите, що ваш брандмауер відключає непрацюючі з'єднання, ви можете спробувати ввести в це поле ненульове значення. Значення вимірюється в секундах; так, наприклад, якщо ваш брандмауер відключає з'єднання через десять хвилин, то, можливо, ви захочете ввести в поле 300 секунд (5 хвилин).

Зменшіть проблему, використовуючи автоматичний шпаклівка та інструмент «екран»

Шпаклівка не може впоратися з хитрим Wi-Fi, який втрачає можливість підключення протягом декількох хвилин. Робота навколо полягає у використанні автологічного входу та екрану.

Шпаклівка - це нетривіальна проблема, щоб повторно синхронізувати свій термінал після хвилинної втрати в Інтернеті. Ви ризикуєте людиною посеред атаки під час відключення. Вам все одно доведеться повторно засвідчити автентифікацію. Шпаклівка не нав'язує цього вам, а просто скидає вас.

Тому використовуйте autologin, щоб шпаклівка могла автоматично увійти від вашого імені.

1. Створіть приватний ключ за допомогою інструменту puttygen на комп'ютері, на якому ви шпаклівка.
2. Вставте відкритий ключ у свою /home/youruser/.ssh/authorized_keysсторону на сервері, на сервері, для якого ви використовуєте шпаклівку, увійдіть у систему.
3. Зробіть приватний ключ доступним для шпаклівки в налаштуваннях шпаклівки З'єднання-> SSH-> Авт
4. Додайте приватний ключ, вказавши файл приватного ключа в розділі "Файл приватного ключа для аутентифікації".
5. Збережіть налаштування з'єднання шпаклівки.

Тоді ви зможете двічі клацнути своє з'єднання через шпаклівку, і він повинен перенести вас прямо до терміналу, не вводячи ім’я користувача / пароль.

Отже , тепер ви можете підключити логін зашпаклювати на зв'язку з цим з комбінацією клавіатури , як F6. Тож, коли Wi-Fi стає поганим, і вас опускають. Ви замішуєте F6 і ви знову ввійшли в систему.

Але ви все одно втрачаєте стан свого терміналу! Як це виправити? Використовуйте програму "екран". Створіть новий екран, ввівши "екран". Створено новий екран.

Коли вас виганяють та автоматично входять у систему, ви можете знову приєднатись до екрана. Ось підручник про те, як це зробити: http://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/

Вдавати screenі знову підключатись під час кожного потрапляння вас буде клопоту . Таким чином, ви можете написати сценарій, який "автоматично поверне вас до останнього доступного екрана", щоб зробити його прозорим.

Тож тоді, коли термінал шпаклівки замерзне. Це виглядає так: Ви викликаєте зневагу зневаги, збиваєте Alt + F4, щоб закрити шпаклівку, Збийте F6. І через 6 секунд ви знову там, де ви зупинилися.

Ще краще рішення, теоретично

Теоретично ви могли виписати весь цей вище процес, тому термінал визначає, коли він був відкинутий, і виконує всі вищезазначені кроки для вас відновлення підключення до Інтернету. Якщо хтось знає програму, яка робить це автоматично, дайте мені знати. Це було б акуратно.

Джерела:

http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-keepalive

http://rafaelwolf.com/?p=516

Усунення помилок у мережі PuTTY

Software caused connection abort

Прочитайте, що PuTTY має сказати про помилку

Це загальна помилка, викликана мережевим кодом Windows, коли вона чомусь вбиває встановлене з'єднання. Наприклад, це може статися, якщо витягнути мережевий кабель із задньої частини комп’ютера, підключеного до Ethernet, або якщо Windows має будь-які інші подібні причини вважати, що вся мережа стала недосяжною.

Windows також генерує цю помилку, якщо вона відмовилася від машини на іншому кінці з'єднання, що відповідає на неї. Якщо мережа між вашим клієнтом і сервером знизиться, а ваш клієнт потім намагається надіслати деякі дані, Windows зробить кілька спроб надіслати дані, а потім відмовиться і припинить з'єднання. Зокрема, це може статися, навіть якщо ви нічого не вводили, якщо ви використовуєте SSH-2 і PuTTY намагається повторно обмінятися ключами.

(Це також може статися, якщо ви використовуєте кепалів у вашому зв’язку. Інші люди повідомили, що кипаливи виправляють цю помилку за них. (Є плюси і мінуси кепалів.))

Ми не знаємо жодної причини, чому може статися ця помилка, яка б представляла помилку в PuTTY. Проблема полягає між вами, системою Windows, вашою мережею та віддаленою системою.

Спробуйте іншого клієнта SSH

Швидше за все, проблема існує десь між PuTTY та цільовим сервером SSH. Щоб надати докази цього, використовуйте іншого клієнта SSH, як-от ( http://kitty.9bis.net ), і переконайтеся, що проблема також виникає. Це, ймовірно, дозволить ізолювати проблему від PuTTY.

Підозрілий плямистий інтернет

Проблемою може бути плямисте підключення до Інтернету. Підключення до Інтернету Моніторинг безперервного часу підключення до Інтернету - це хороший спосіб визначити, чи втрачає ваш Інтернет-провайдер пакети і винен у тому, що PuTTY знижується. Отримайте деяке програмне забезпечення, яке перевіряє час роботи інтернету. Наприклад, http://code.google.com/p/internetconnectivitymonitor/. Часті та тривалі відключення від Інтернету - це порушення вимог до послуг ISP. Якщо це так, важко буде довести, що він провідний в провайдері, оскільки технічна підтримка автоматично звинувачує такі проблеми на вашому комп'ютері, ОС, маршрутизаторі та проводці у вашому домі. Якщо ви користуєтесь кабельним Інтернетом і перебуваєте в бунгах, можливо, що несправне обладнання в будинках вашого сусіда може надсилати статику на лінію протягом декількох секунд / хвилин, коли вони вперше включають її. Нарешті, можливо, у мережі провайдера до вашого будинку є несправне обладнання. Вартість Інтернет-провайдерів на заміну свого обладнання є настільки високою, що часто вони цього не роблять, якщо в районі немає достатньої кількості передплатників, які б відповідали за витрати.

Підозрюйте провідний / бездротовий маршрутизатор

Ви підключаєтесь через дротовий / бездротовий маршрутизатор? Скільки йому років? Можливо, проблема з вашим маршрутизатором. Старі бездротові та дротові технології можуть епізодично отримувати старі та переривати з'єднання та перезапускати їх, внаслідок чого PuTTY гине. Вийміть ці компоненти з рівняння і подивіться, чи це вирішує проблему. Спробуйте дротове підключення та / або інший маршрутизатор, щоб побачити, чи це усуває проблему. У мене був бездротовий маршрутизатор Linksys, який переживає цю повільну загибель і падіння з’єднань, і перезапустити їх.

Запідозріть операційну систему, що забезпечує з'єднання SSH

На комп'ютері, до якого ви підключаєтесь із SSH, існує політика протягом декількох секунд, щоб підтримувати з'єднання SSH. З міркувань безпеки це число встановлено низьким, і ви можете його збільшити. Де ця настройка залежить від того, яку операційну систему ви використовуєте, яка надає SSH.

Якщо ви використовуєте PuTTY через віртуальну машину

Якщо ви використовуєте PuTTY, що проходить через віртуальну машину, на віртуальній машині може бути політика, яка порушує ваше з'єднання SSH з сервером, коли він вважає, що це неактивне. Збільшення цих значень залежить від того, яке програмне забезпечення віртуальної машини та операційну систему ви використовуєте.

Якщо підключення до Інтернету погано, клієнтське з'єднання SSH вирішує:

Якщо ваш провайдер надає нестабільне з'єднання, ви можете зробити роз'єднання менш болісними за допомогою "ssh autologin". Що ви робите, це генерувати відкритий та приватний ключ. І ви скажете своєму іноземному серверу автоматично вводити кожного, хто надає точний приватний ключ. Це повністю не вирішує вашу проблему, але коли відбувається відключення в Інтернеті, все, що ви робите, це закрити вікно, двічі клацнути піктограму, і вас негайно повернуть у командний рядок домашньої папки, не вводячи ім’я користувача / пароль.

Це допоможе вам у цьому: Чи є спосіб "авторизуватися" в PuTTY паролем?

У командному рядку підвищеного рівня запустіть наступне:

C:\Windows\system32>netsh int tcp show global

Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled

Chimney Offload State               : automatic

NetDMA State                        : enabled

Direct Cache Acess (DCA)            : disabled

Receive Window Auto-Tuning Level    : normal

Add-On Congestion Control Provider  : none

ECN Capability                      : disabled

RFC 1323 Timestamps                 : disabled

Якщо Receive Window Auto-Tuning Levelце нормально, то у вас виникнуть проблеми. Вимкніть його, і тоді все має працювати так, як раніше:

C:\Windows\system32>netsh int tcp set global autotuninglevel=disabled

Я працював із серверами CentOS з ПК під керуванням Windows, і у мене була та сама проблема з PuTTY. Сеанс тривав не більше 1-5 хвилин. Я спробував пограти з налаштуваннями PuTTY (кеепалів тощо), але це зовсім не допомогло.

Нарешті я знайшов рішення для своєї справи. Я записав скиди TCP і на клієнті, і на сервері. Я виявив, що протягом 25-30 секунд перед відключенням відбувається кілька повторних передач сегментів TCP на дамп клієнта (як з клієнта, так і з боку сервера), і нарешті PuTTY посилає RST і закриває сеанс з цією помилкою. У дамп сервера я не бачив жодних сегментів від клієнта в цей період, навіть RST. Це означає, що час від часу на сервер не доставляються сегменти TCP від ​​клієнта, і цей період становить приблизно 30-60 секунд. Я реєстрував справу кілька разів, і завжди були повторні передачі та остаточний RST від PuTTY. Можливо, десь на маршрутних пакетах було скинуто мережеве обладнання.

Щоб вирішити проблему, я збільшив максимальну кількість повторних передач даних зі значення за замовчуванням 5 до 16. Це може запобігти занадто швидкому відключенню PuTTY. Змінна - "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Параметри \ TcpMaxDataRetransmissions". Я додав цю змінну вручну, вона спочатку не була визначена в реєстрі моєї Windows. Це допомогло! Тепер я бачу, що час від часу висить PuTTY, але він завжди повертається до роботи.

Щоб вирішити проблему: 1. Запишіть дамп TCP та шукайте повторні передачі та RST перед відключенням. 2. Якщо ви знайдете однакові сегменти повторної передачі / RST, відрегулюйте кількість повторень на стороні сервера або клієнта (це залежить від сторони RST).

Будьте уважні: зміна параметрів TCP стосується всього програмного забезпечення та самої ОС.

Помилка Мережева помилка: програмне забезпечення, яке спричиняє припинення з'єднання з PuTTY, є наслідком, якщо в мережі виникає конфлікт IP-адреси (два чи більше комп'ютерів мають однакову IP-адресу). (У мене була ця проблема з Raspberry Pi, який отримав ту саму IP-адресу, призначену сервером DHCP, як і деякі негідні пристрої / комп’ютери, створені вручну для використання тієї самої IP-адреси.)

У цьому конкретному випадку це може бути конфлікт IP-адреси локально на комп'ютері Windows 7 або з іншим пристроєм у мережі. Wireshark можна використовувати для успішного відстеження подібних помилок.

Помилка 10053 WSAECONNABORTED(програмне забезпечення, викликане перериванням зв'язку) - це загальна помилка Winsock, яку можна видалити через будь-яку кількість причин.

Офіційне пояснення говорить:

Ця помилка може виникнути, коли система локальної мережі припиняє з'єднання, наприклад, коли Winsock закриває встановлене з'єднання після відмови повторної передачі даних (одержувач ніколи не визнає дані, що надсилаються в сокет передачі даних).

Причини цієї проблеми можуть варіюватися від несправних мережевих кабелів до простої втрати підключення. Неможливо запропонувати єдине рішення.

У мене була така ж проблема з PuTTY після встановлення нового маршрутизатора WLAN / 3G модему для підключення до Інтернету. Я спробував усі вищезгадані рішення - і всі ті, що знаходяться в меню конфігурації мого маршрутизатора - безрезультатно.

Тоді я згадав щось ще з 90-х років, коли в мене був наземний телефонний модем: MTU (максимальний блок передачі), в основному максимальний розмір переданих фрагментів даних - це помітно вплинуло на стабільність зв'язку.

Тож я перевірив конфігурацію мого маршрутизатора WLAN, знайшов налаштування MTU і змінив його з фіксованого значення 1424 на "Авто" (я мав намір спробувати менше значення, але "Авто" пролунав ще краще). Після цього у мене більше не було проблем з PuTTY - тепер це з'єднання міцно. Я сподіваюся, що це допоможе хоча б комусь із проблемою "Помилка мережі: програмне забезпечення, яке викликало зрив зв'язку", перервано.

Вкладка "Підключення": увімкнено "5" секунд та активовано

Але ще важливіше:

З'єднання -> SSH -> Kex , Максимальна хвилина до повторного введення : "2" (за замовчуванням - 60).

Мій PuTTY через деякий час втрачав свій ключ, викликаючи тайм-аут. Пониження цього значення на "2" хвилини вирішило проблему. Зараз я залишаюся на зв’язку нескінченно.

Я зіткнувся з тією ж проблемою або зі сценарієм WinSCP, або з консоллю GUI. Нарешті я виявив, що це пов'язано зі швидкістю (швидкість Інтернету - наш сервер в Інтернеті). Я перемістив сценарій в інше місце в мережі, на інший сайт, і не так, щоб GUI і Script пройшли добре.

Це було розібрано після багато аналізу та сортування.

Потрібно включити TCPKeepAliveв Linux.

Це пояснюється у поширених питаннях PuTTy на веб-сайті, коли ви шукаєте цю помилку.

Якщо віртуальна машина працює на локальному відключенні обладнання, зберігайте живі пакети.

Я фактично стикався з цим питанням багато разів. Я шукав години на вирішення проблем, але жодне з них не було ефективним. Я ділюсь рішенням, яке працювало на мене, і сподіваюся, що воно буде корисним і для інших.

У мене Windows 10 як хост O / S і Redhat-7 як гостьовий O / S, і мій VMware мав з'єднане з'єднання. Як DBA я повинен відвідувати клієнтів, і я повинен встановити свою мережну конфігурацію відповідно до приміщень клієнта. Тому щоразу, коли я залишаю клієнтські приміщення та підключаюся до іншої мережі через бездротовий та відкритий VM, я стикаюся з тією ж проблемою, що і вказана в запитанні. Тому я подумав деякий час і перевірив мою конфігурацію для локальної мережі Ethernet та Wireless Ethernet, і виявив невідповідність. Оскільки мій ВМ автоматично використовуватиме фізичну мережу серед двох для встановлення мостів. Тож коли я скинув конфігурацію мережі для LAN / Wireless Ethernet на DHCP, це працювало як шарм, і більше не припиняється з'єднання. [Ви також можете перезавантажити ваш хост-апарат після встановлення його на DHCP.]