Можливо, ви стикалися з цим неодноразово: один комп'ютер невідомо чому не може зв'язатися з іншими. Система управління знаходиться в одному сегменті мережі з маршрутизацією, підключеного до інших сегментів мережі за допомогою маршрутизатора, наприклад сервера Microsoft Internet Security and Acceleration (ISA) Server або іншого пристрою. При управлінні десятьма, двадцятьма і навіть сотнею системам ніяких неполадок не виникає. Але при спробі керувати 500 системами ваш комп'ютер не може зв'язатися по мережі з іншими комп'ютерами за винятком тих, до яких вже відкриті підключення. Неможливо обмінюватися даними з іншими системами, неможливо вийти в Інтернет, але ні в кого у всій мережі, в тому числі і в вашому сегменті, немає таких неполадок. Де насамперед варто шукати причину?
У такій ситуації перш за все слід припустити збій програми, що управляє системами. Багато засобів управління можуть підключатися до інших комп'ютерів і керувати ними, але іноді такі кошти самі можуть викликати неполадки, які ви намагаєтеся усунути. Причина полягає в тому, що кошти управління можуть створювати тисячі підключень до пристроїв з метою управління. У Windows® ці підключення за замовчуванням залишаються відкритими протягом двох хвилин навіть в разі простою, якщо тільки будь-яка програма, додаток або служба не продовжить термін дії цих підключень. Це означає, що навіть якщо система управління не зверталася до інших комп'ютерів протягом двох хвилин, може бути як і раніше більше 1000 відкритих підключень. (Щоб побачити відкриті з'єднання, можна виконати в командному рядку команду NETSTAT. За допомогою цієї команди можна побачити всі відкриті, які очікують і закриваються підключення до системи і їх стан. Описи повідомлень про стан приведені в документі RFC 793)
Щоб визначити, що саме система управління викликає збій, можна створити пакетний файл, який встановлює підключення до віддалених систем. Якщо така ж проблема виникне при запуску пакетного файлу, то система управління не має відношення пов'язаних із ними. Ось приклад вмісту такого пакетного файлу:
Net use \\ system01 \ ipc $ Net use \\ system02 \ ipc $ Net use.
Якщо програма управління використовує свій власний мережевий стек і стек перевірки автентичності, причина неполадки може полягати в цій програмі, проте в рішеннях без агентів, таких як більшість систем управління, для виконання дій в мережі використовуються системні стеки мережі і перевірки автентичності. Застосування пакетного файлу, що запускає стільки ж здійснювати підключення до мережі без збоїв, означатиме, що проблема викликана не тим, як програма використовує стеки операційної системи (мережевий і перевірки автентичності), оскільки пакетний файл використовує їх правильно.
Якщо журнали і повідомлення про помилки не допомагають
Можливо, ви звернули увагу, що коли почалися неполадки в мережі, на комп'ютері з'явилися повідомлення про помилки: помилка 53 - мережевий шлях не знайдений, помилка 64 - ім'я в мережі видалено, помилка 1203 - постачальник мережі не прийняв зазначений мережевий шлях. Всі ці повідомлення можуть правильно вказувати на наявність відповідних помилок, але ж на інших комп'ютерах немає ніяких проблем з дозволом імен та підключенням до тих же самим системам. Щоб перевірити правильність параметрів комп'ютера і переконатися, що неполадка викликана не ними, просто виконайте команду ipconfig.
Тепер, оскільки проблема існує тільки у вашій системі управління, варто заглянути в журнали подій. Пошук журналів додатків марний, але в системному журналі виявиться подія попередження з кодом 4226 з джерела TCP / IP, що означає, що досягнуто граничне число підключень (див. Рис. 1).
TCP connection limit has been reached
Залежно від середовища зміна цих параметрів реєстру може призвести до деякого підвищення продуктивності роботи системи. Для усунення обмежень можна також змінити файл TCPIP.sys, але це вплине тільки на роботу P2P-додатків.
Запис мережевих даних
Якщо більше нічого не допомагає, можна спробувати записати мережеві дані з комп'ютерів. При запуску мережевого монітора (Netmon) записані дані в точності відповідали результатами, які були очевидні при запуску засобів управління і тестових сценаріїв: спочатку все працює, а потім перестає працювати без будь-яких вказівок на помилки.
На рис. 2 показаний результат запуску Netmon - успішна зв'язок між першими і системами. Зверніть увагу, що я отримую підтвердження запитів віддаленого виклику процедур. Це саме те, що потрібно побачити - успішний двосторонній обмін даними.
Successful communication in Netmon
Attempts to connect to the system over port 445 yield no response
На цьому етапі ви, напевно, вже втратите надію, але ще є можливості все виправити. Зазвичай мало хто звертає увагу на інфраструктуру підключень через те, як саме виникає проблема: ваш комп'ютер - єдиний з усіх, якому не вдається підключитися до іншої мережі, і навіть журнали подій свідчать, що на комп'ютері досягнуто граничне число підключень, тому навряд чи причиною неполадки є архітектура мережі.
Незважаючи на те, що тисячі підключень, що створюються системою управління, створюються не одночасно, через часу очікування передачі даних і підключень може виникнути дуже велике число одночасно відкритих підключень. Тому потрібно звернути увагу на системи, за допомогою яких ваш комп'ютер підключений до іншої мережі.
А справа ось у чому. Як я вже говорив вище, весь трафік у вашій мережі проходить через комутатори, маршрутизатори і, ймовірно, через міжмережеві екрани. У будь-якому з цих елементів, зазвичай в маршрутизаторах або міжмережевих екранах, можуть застосовуватися системи виявлення вторгнення. У керованих комутаторах і маршрутизаторах також може бути включена фільтрація трафіку. Тим, хто керує цими пристроями, потрібно перевірити їх журнали - можливо, в них будуть помилки або попередження. Неполадки зв'язку цілком можуть бути викликані саме цими системами.
Ви підключаєтеся з внутрішньої системи до інших внутрішніх систем, тому оповіщення не створюються: створення сповіщень може бути не налаштоване на пристроях, або тому що явище виникає надто часто розглядається як вторгнення або атака типу «відмова в обслуговуванні». Отже, знову почнемо з журналів. Як приклад використовуватимемо ISA Server. В цьому випадку журнали будуть знаходитися в консолі управління ISA Server в розділі Масиви \ \ Спостереження \ Ведення журналу.
* 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
* 0xc004000d FWX_E_POLICY_RULES_DENIED
* 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
Якщо ви їх виявили, то причина неполадок в мережі знайдена.
Отже, тепер проблема встановлена, рішення може бути простим, але політика відділу може утруднити застосування цього рішення. Перед внесенням будь-яких змін переконайтеся, що у вас є на це дозвіл, оскільки створення виключень в конфігурації безпеки міжмережевих екранів, маршрутизаторів і систем виявлення вторгнень може бути заборонено.
На прикладі ISA Server подивимося, як збільшити максимальну кількість підключень для даного вузла або для всіх комп'ютерів мережі (див. Рис. 4). Відкрийте консоль управління ISA Server і перейдіть в розділ Масиви \ \ Конфігурація \ Загальні \ Налаштуйте параметри запобігання Flood-атаки.
Increase the maximum number of connections for one host or all machines using ISA Server
Як ми вже обговорили вище, в Windows підключення за замовчуванням залишається активним протягом двох хвилин, якщо не вживаються ніякі дії, щоб продовжити термін дії підключення, навіть якщо воно не використовується. Це означає, що підключення до будь-якого комп'ютера залишиться активним навіть після того, як всі дії з управління цим комп'ютером вже виконані і обмінюватися з ним даними більше не потрібно. Це відкрите підключення залишається одним з безлічі відкритих підключень. Якщо повторити цей процес більш 160 раз, не видаляючи підключення, то виявиться, що всі подальші спроби підключень будуть відхилені маршрутизатором. Навіть якщо програма управління активно завершує сеанс, операційна система Windows може залишити підключення в стані time_wait, чекаючи від другого комп'ютера відповіді зі згодою на відключення.
Default connection limit and custom connection limit
Internal networks properties settings
Enter computer name, IP address, and description to ensure your system is not removed
Спробуйте знову запустити систему управління. Ви побачите, що продуктивність стала набагато вище, а підключення працюють без неполадок (у всякому разі, без неполадок, викликаних мережевим трафіком). Таким чином, в результаті з'ясувалося, що проблема була викликана не числом підключень, викликаних програмою, а неправильним їх плануванням.
Одна з найбільших неприємностей в сфері ІТ - виникнення і усунення проблем, причину яких важко виявити. Ці неполадки не викликані діями користувачів або серверної групи, служба підтримки виявиться не в курсі, але ви можете відповідати за їх усунення. Існують засоби, які допоможуть виявити неполадки, виявити їх і усунути, але іноді їх недостатньо. Іноді вони працюють неправильно. Іноді вам потрібно бути розумнішими таких коштів.
Якщо раптом виникне ситуація, коли у вашого комп'ютера почнуться неполадки з мережевими підключеннями без будь-яких очевидних причин, спробуйте зробити те, про що я розповів вище. Цілком ймовірно, що, виконавши описані дії, уважно вивчивши роботу системи управління і правильно налаштувавши дозволені підключення, ви успішно вирішите проблему.