50240 (Комп’ютерні мережі. Аналіз роботи і оптимізація), страница 2

Сервер – це об'єкт, що надає сервіс іншим об'єктам мережі за їхніми запитами. Сервіс – це процес обслуговування клієнтів.

Сервер працює за завданнями клієнтів і керує виконанням їхніх завдань. Після виконання кожного завдання сервер відсилає отримані результати клієнтові, що відправив це завдання.

Сервісна функція в архітектурі клієнт - сервер описується комплексом прикладних програм, відповідно до якого виконуються різноманітні прикладні процеси.

Процес, який викликає сервісну функцію за допомогою певних операцій, називається клієнтом. Ним може бути програма або користувач. На рис. 1.6 приведений перелік сервісів в архітектурі клієнт - сервер.

Клієнти – це робочі станції, які використовують ресурси сервера і надають зручні інтерфейси користувача. Інтерфейси користувача це процедури взаємодії користувача з системою або мережею.

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

У мережах з виділеним файловим сервером на виділеному автономному ПК встановлюється серверна мережева операційна система. Цей ПК стає сервером. Програмне забезпечення (ПЗ), встановлене на робочій станції, дозволяє їй обмінюватися даними з сервером. Найбільш поширені мережеві операційна системи:

• NetWare фірми Novel;

• Windows NT фірми Microsoft;

• UNIX фірми AT&T;

• Linux.

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

Мережі на базі серверів мають кращі характеристики і підвищену надійність. Сервер володіє головними ресурсами мережі, до яких звертається решта робочих станцій [7].

У сучасній клієнт - серверній архітектурі виділяється чотири групи об'єктів: клієнти, сервери, дані і мережеві служби. Клієнти розташовуються в системах на робочих місцях користувачів. Дані в основному зберігаються в серверах. Мережеві служби спільно використовуються серверами і даними. Крім того служби керують процедурами обробки даних.

Мережі клієнт - серверної архітектури мають наступні переваги:

• дозволяють організовувати мережі з великою кількістю робочих станцій;

• забезпечують централізоване управління обліковими записами користувачів, безпекою і доступом, що спрощує мережеве адміністрування;

• ефективний доступ до мережевих ресурсів;

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

Разом з перевагами мережі клієнт - серверної архітектури мають і ряд недоліків:

• несправність сервера може зробити мережу непрацездатною, як мінімум втрату мережевих ресурсів;

• вимагають кваліфікованого персоналу для адміністрування;

• мають вищу вартість.

1.3.4 Вибір архітектури мережі

Вибір архітектури мережі залежить від призначення мережі, кількості робочих станцій і від виконуваних нею дій [1].

Слід вибрати однорангову мережу, якщо:

• кількість користувачів не перевищує десяти;

• всі машини знаходяться близько одна від одної;

• мають місце невеликі фінансові можливості;

• немає необхідності в спеціалізованому сервері, такому як сервер БД, факс-сервер, або який-небудь інший;

• немає можливості, або необхідності в централізованому адмініструванні.

Слід вибрати клієнт-серверну мережу, якщо:

• кількість користувачів перевищує десяти;

• потрібне централізоване управління, безпека, управління ресурсами, або резервне копіювання;

• необхідний спеціалізований сервер;

• потрібний доступ до глобальної мережі;

• потрібно розділяти ресурси на рівні користувачів.

Розділ ІІ. Пошук несправностей в мережах на базі OC Windows

2.1 Проблеми реєстрації робочої станції

Одна з найбільш поширених проблем з’єднання в мережі виникає, коли робоча станція не може зареєструватися в домені. Це може бути через безліч причин:

• конфігурація протоколу;

• дозвіл імені;

• дозвіл імені NetBIOS;

• повноваження.

2.1.1 Команда ,,ping”

Якщо робоча станція має проблеми з реєстрацією в домені, перш за все необхідно перевірити з’єднання. Для цього використовується утиліта ping-. Як показано на роздруківці нижче, спочатку виконується ping за іменем щоб перевірити дозвіл на ім’я. Вона вертається назад з відповіддю. Потім виконується ping за визначеною ІР-адресою, щоб перевірити чи є доступ до того ж місця призначення. В останню чергу посилається великий пакет для перевірки того, що пакети великих розмірів можуть дістатися до місця призначення. Утиліта рing за замовчуванням посилає дуже малий 32-бітний пакет, який може дістатися до місця призначення, в той час як великий за об’ємом трафік реєстрації може не пройти через маршрутизатор.

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

Додати значення в наступний ключ :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcipip\Parameters_

Ім’я значення : TcpSendSegmentSize

Тип буде Reg_Dword

За замовчуванням використовується 1460 байт

Ці зміни можуть впливати на всю комунікацію ТСР/ІР і повинні робитися тільки після детального тестування. Перед тим як робити зміни в реєстрі, необхідно переконатися, що існує детально перевірена і актуальна резервна копія. Найпростіше, що можна зробити – це експортувати ключі [2].

Для аналізу проблеми використаємо програму Netmon, вибравши необхідну робочу станцію і сервер. Наступним кроком потрібно повторити команди ping і в додаток до команд ping необхідно також виконати команди:

• net view\\ ім’я_сервера

• net user\\ ім’я_сервера\ipc$

Якщо дві команди повертаються з повідомленням про помилку, то має місце проблема. Необхідно скористатись Netmon і перевірити чи можливо знайти джерело проблеми. Із отриманих даних видно, що команда ping працює фактично без будь-яких проблем. Це показано на роздруківці нижче. Пакет ICMP є ехо-пакетом і його розмір 32 байти. Цей розмір використовується за замовчуванням в команді ping.

За ехо-пакетом ІСМР слідує пакет відповіді ІСМР, який пердставлений на роздруківці нижче. Цей пакет повертається із місця призначення як пакет ехо-відповідь. Він також має 32 байти. Це говорить про те, що існує елементарна комунікація між робочою станцією і сервером.

Після цього командою net view\\ ім’я_сервера перевіряється мережу, що приводить до трьохходового підтвердження прийому даних (квитування) між робочою станцією і сервером. Трьохходове квитування відбувається між робочою станцією і портом 139, службою сеансу NetBIOS на сервері. В даному випадку все працює нормально, тому необхідно подивитися розділ NBT наступного кадру, що показаний на роздруківці нижче. Кадр із робочої станції на сервер виглядає правильним. Видно, що тип пакету вказується як запит сеансу (session request). Він вміщує ім’я викликаного сервера і ім’я робочої станції яка викликає. є унікальним суфіксом NetBIOS, який вказує службу робочої станції. Можна знайти реєстрацію для цієї машини в базі даних WINS. Реєстрація в базі даних WINS полегшує NetBIOS комунікацію між машинами.

Так як запит сеансу NTB пройшов успішно, тоді необхідно подивитись на відповідь, яка приходить з сервера. Вона міститься на роздруківці нижче і дає деяку корисну інформацію.

Отримана відповідь з відмовою сеансу (Negative Session Response), і код помилки служби сеансу говорить про те, що ім’я, яке викликається, відсутнє. Завдяки цьому стає зрозуміло, що проблема не в робочій станції, а в сервері. Інші робочі станції будуть стикатися з такою ж проблемою. Тепер необхідно перевірити, що відбувається на сервері. Але спочатку необхідно глянути, чи можна отримати яку-небудь додаткову інформацію із щойно зробленого трасування Netmon.

На роздруківці нижче наведено декілька запитів контролера первинного домену, але немає відповіді. Це відбувається як SMB C transact в \mailslot\net\netlogon. Можливо існує також проблема із службою netlogon.

Якщо переглянути події на робочій станції, можна побачити наступне повідомлення: "Броузер не зміг отримати список серверів з мастер-броузера \PROX у мережі \Device\NetBT_E100Bl. Дані є кодом помилки". Це повідомлення просто підтверджує, що на сервері є проблема.

На сервері необхідно перевірити наступне:

• Чи служба сервера виконується на комп'ютері місця призначення. Перевірити аплет служб в панелі керування (рис.2.1). Якщо служба сервера не виконується, машина все одно відповідатиме на ping, але сеанс створити неможливо. Якщо служба сервера зупинена, то необхідно запустити її. Це пояснить повідомлення помилок броузера в журналі подій, оскільки служба броузера комп'ютера залежить від служби сервера. Крім того, служба netlogon також залежить від служби сервера. Питання, звичайно, в тому, чому служба сервера зупинена? Деяку інформацію Netmon просто не може повідомити. Можливо, настав час змінити пароль адміністратора.

Рис. 2.1. Перевірка стану служб.

• Чи відповідає сервер місця призначення. Він може бути заблокований. Сервер може відповідати на ехо-пакет ICMP, навіть якщо сеанс неможливо створити. Якщо комп'ютер заблокований і неможливо відновити керування менеджером завдань або будь-яким іншим способом, слід повідомити всіх користувачів про необхідність зберегти свої дані і по можливості вийти з системи. Можна спробувати виконати закриття системи, хоча залежно від того, що відбулося, можливо, доведеться зробити повне завантаження. Якщо відновлення не відбулося, то доведеться перевіряти процедури резервного копіювання.

• Перевірити аплет ліцензії в панелі керування і в журналі подій, щоб переконатися, що обмеження ліцензії не порушені.

• Чи використовується DNS або файл хоста. Методи дозволу імені хоста використовуються першими в ping для дозволу імені. Команди net використовують методи дозволу імені NETBIOS (lmhosts, WINS). Утиліта рing може працювати, тоді як net view може простоювати.

2.2 Пошук несправностей в мережі з виділеним DHCP сервером

Хоча DHCP полегшує життя адміністратора, іноді клієнтська машина стикається з проблемами при отриманні адреси. У таких ситуаціях інформація часто буває мізерною. Крім того факту, що робоча станція не отримала адреси, більше нічого невідомо. Тут починають відігравати роль знання процесів DHCP і Netmon.

2.2.1 Діалог з DHCP сервером

Перш за все, необхідно перевірити, що машина була зконфігурована для запиту адреси. Якщо у вікні властивостей TСР/ІР відмічена властивість "отримувати IP-адресу з сервера DHCP", то це повинно працювати. Якщо ні, необхідно переривати Netmon і проглянути діалог. У ідеалі повинні бути присутніми чотири кадри, перелічені нижче.

1. Пошук DHCP

2. Пропозиція DHCP

3. Запит DHCP

4. DHCP АСК

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

2.2.2 Аналіз діалогу комп’ютерів у мережі

Перший крок полягає в перегляді трасування і пошуку пропущеного кадру. Кадр запиту DHCP посилається за допомогою багатоадресової розсилки UDP IP з порту 68 (клієнтський порт ВООТР), в порт 67( серверний порт ВООТР). Magic cookie будуть правильними. Це чотирьохбайтна область в пакеті DHCP, яка ідентифікує початок поля, означеного постачальником для спеціальних параметрів. Якщо використовується дане поле параметрів, це наголошується IP-адресою 99.130.83.99, яка показана в трасуванні Netmon як шістнадцяткова 63 82 53 63. Параметри можуть перелічувати ідентифікатор клієнта, запитану адресу, а також інші позиції. У нашому полі параметрів ідентифікатор клієнта рівний адресі MAC комп'ютера, що робить запит - в даному випадку KENNY. Також видно, що машина KENNY запрошує ту ж адресу, якою вона володіла раніше. Якщо ця адреса доступна, то її можна буде використовувати знову.