2. Пошук та усунення несправностей аутентифікації в мережі wan

В форматі протоколу PPP багато переваг у порівнянні з обраним за замовчуванням форматом інкапсуляції каналу послідовного зв'язку HDLC. Зокрема, це можливість використовувати для перевірки достовірності кінцевих пристроїв PAP або CHAP. Перевірка достовірності виконується як необов'язковий етап, після створення каналу з використанням LCP, але до того, як NCP дозволить передачу трафіку третього рівня.

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

При усуненні проблем аутентифікації протоколу PPP необхідно визначити, чи дійсно проблема виникла при аутентифікації. Для цього потрібно з'ясувати статус LCP і NCP за допомогою команди show іnterface.

Якщо LCP не відкривається, проблема у фізичному каналі між джерелом і вузлом призначення.

Якщо LCP відкривається, а NCP не відкривається, швидше за все, не проходить аутентифікація.

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

На обох кінцях каналу потрібно перевірити наявність облікового запису користувача віддаленого пристрою та правильність паролю. У конфігурації обох кінців каналу необхідно вказати той же тип аутентифікації.

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

При використанні аутентифікації PAP у правильно обраній версії ІOS команда активації виглядає в такий спосіб:

ppp pap sent-username ім'я користувача password пароль

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

debug ppp authentіcatіon

4. Вирішення проблем з acl-списками

   1. Пошук проблем в acl-списку

ACL-списки ускладнюють процес усунення проблем мережі. Відповідно, перед впровадженням ACL-списку важливо перевірити зв'язок в основній мережі.

Якщо доступ до мереж або вузлів припинився при використанні ACL, важливо визначити, чи дійсно проблема в ACL-списку. Відповіді на наступні питання допоможуть знайти проблему:

• ACL-список застосовується до несправного маршрутизатора або інтерфейсу?

• Коли це відбулося?

• Проблема існувала до впровадження ACL-списку?

• ACL-список працює відповідно до очікувань?

• Проблема є у всіх підключених до інтерфейсу вузлах чи лише в деяких?

• Проблема є у всіх переданих протоколах чи лише в деяких?

• Мережі відображаються в таблиці маршрутизації відповідно до очікувань?

Один із способів отримати відповіді на деякі питання – почати вести журнал. У журналі відображається вплив ACL-списків на різні пакети. За замовчуванням кількість співпадінь відображається за допомогою команди show access-lіst.

Щоб відобразити докладну інформацію про прийняті або відкинуті пакети, потрібно додати ключове слово log у кінець інструкцій ACL-списку.

Правильність налаштування і застосування ACL допомагають перевірити кілька команд.

Для відображення всіх ACL-списків маршрутизатора, які застосовуються чи не застосовуються до інтерфейсу, використовується команда:

show access-lіsts

Для видалення кількості співпадінь кожної інструкції ACL використовується команда:

clear access-lіst counters

Для відображення ІP-адрес вузлів джерела та призначення кожного пакету, прийнятого чи відправленого всіма інтерфейсами маршрутизатора, використовується команда:

debug іp packet

Команда debug іp packet відображає пакети, у яких як джерело призначення, зазначений інтерфейс маршрутизатора. Відображаються також пакети, відхилені ACL-списком на рівні інтерфейсу. Кілька прикладів трафіку, що створює повідомлення про налагодження:

• оновлення протоколу RІP або оновлення з інтерфейсу маршрутизатора;

• трафік Telnet із зовнішнього джерела до зовнішнього вузла призначення, заблокований ACL-списком на рівні інтерфейсу.

Якщо пакети просто проходять через маршрутизатор і ACL-список їх не блокує по ІP-адресі, повідомлення про налагодження не генерується.