Перевірка роботи і усунення основних несправностей nat
При проблемах з підключенням по IP в оточенні NAT часто важко визначити причину проблеми. Відповідальність за це часто помилково покладається на NAT, тоді як насправді причина криється глибше. Цей документ показує, як перевірити роботу NAT за допомогою засобів, доступних на маршрутизаторах Cisco. У цьому документі також ілюструється виконання основного пошуку та усунення несправностей NAT і описано, як не допустити типових помилок під час пошуку та усунення несправностей NAT.
Для цього документа відсутні особливі вимоги.
Цей документ не має жорсткої прив'язки до яких-небудь конкретних версій програмного забезпечення і устаткування.
Відомості, представлені в цьому документі, були отримані від пристроїв, що працюють в спеціальній лабораторній середовищі. Всі пристрої, описані в цьому документі, були запущені з чистою (стандартної) конфігурацією. У робочій мережі необхідно вивчити потенційний вплив всіх команд до їх використання.
Коли ви намагаєтеся визначити причину неполадки IP-підключення, вона допомагає виключати NAT. Для перевірки правильності роботи NAT виконайте наступні дії:
Переконайтеся, що в таблиці перетворень існують правильні перетворення.
Щоб переконатися в тому, що перетворення відбувається, використовуйте команди show і debug.
Аналіз докладно, що відбувається з пакетом і перевіряє, що маршрутизатори мають правильні відомості про маршрутизації для переміщення пакета вперед.
Нижче деякі приклади проблеми, в яких ми використовуємо вищезгадані кроки, щоб допомогти визначати причину проблеми.
У цій схемі мережі маршрутизатор 4 може пропінгувати маршрутизатор 5 (172.16.6.5), але не маршрутизатор 7 (172.16.11.7):
Немає ніяких протоколів маршрутизації, що працюють ні в одному з маршрутизаторів, і маршрутизатор 4 має маршрутизатор 6 як свій шлюз за замовчуванням. Маршрутизатор 6 налаштований з NAT цим способом:
Тепер, гарантуйте, що ця трансляція має місце коли вихідний IP - трафік маршрутизатора 4. Для цього на маршрутизаторі 6 можна використовувати два методи: виконати команду NAT debug або простежити статистику NAT за допомогою команди show ip nat statistics. Так як команди debug повинні використовуватися в крайньому випадку, починати слід з команди show.
Після використання команди ping 172.16.11.7 на 4-му маршрутизаторе статистика NAT на 6-му маршрутизаторі буде наступною:
З повідомлень команди show видно, що число звернень зросла на 5. У випадку успішного виконання луна-тесту маршрутизатора Cisco число звернень збільшується на 10. П'ять луни Протоколу ICMP, переданого вихідним маршрутизатором (маршрутизатор 4), має бути перетворено, і ці п'ять пакетів відлуння -Відповісти від маршрутизатора призначення (маршрутизатор 7) повинні також бути перетворені для в цілому десяти відповідностей. У зникненні п'яти ping-сигналів швидше за все винні луна-відповіді, які або не були трансльовані, або не відправлені на маршрутизатор 7.
Ви бачите, що таблиця маршрутизації маршрутизатора 7 не має маршруту для 172.16.6.14. Як тільки ви додаєте цей маршрут, луна-запит добре працює.
Зверніть увагу, що в цих простих лабораторних умовах корисно відстежити статистику операцій NAT за допомогою команди show ip nat statistics.Однако в більш складному середовищі NAT з декількома виконуються перетвореннями, команда show не буде настільки полезна.В такому випадку, можливо, знадобиться використовувати на маршрутизаторі команду debug.В наступному сценарії проблемної ситуації показано використання команд debug.
Примітка: При використанні будь-якої команди налагодження на маршрутизаторі ви могли перевантажити маршрутизатор, який змушує її ставати неоперабельний. Завжди будьте дуже уважні і, якщо можливо, ніколи не вдавайтеся до використання команди debug при роботі з критично важливими маршрутизаторами без участі фахівця Служби технічної підтримки Cisco.
Спочатку ви ясно визначили, який NAT передбачалося досягти. По-друге, перевірено наявність необхідних правил перетворення в таблиці перетворення. По-третє, використовувалася команда debug або show, яка дозволила переконатися, що перетворення дійсно мало місце. Нарешті, був детально розглянутий процес передачі пакета, а також дії маршрутизатора по його пересилання або написанні відповіді.
Тепер, коли у вас є базова процедура для виявлення причини неполадок підключення, ось деякі чек-листи для усунення проблем загальних проблем.
Якщо буде виявлено, що відповідна трансляція не встановлена в таблиці трансляцій, переконайтеся в наступному:
Немає ніяких списків доступу на вхід, які забороняють пакети від введення маршрутизатора NAT.
У маршрутизатора NAT є відповідний маршрут в таблиці маршрутизації, якщо пакет йде зсередини назовні. Додаткова інформація міститься в документі "Порядок роботи NAT".
Список доступу, на який посилається команда NAT, дозволяє всі необхідні мережі.
Що інтерфейси маршрутизатора правильно визначені як інтерфейси з внутрішнім NAT або зовнішнім NAT.
Якщо запис правильного перетворення встановлена в таблиці перетворення, але не використовується, перевірте їх:
Перевірте, що немає ніяких списків доступу на вхід, які забороняють пакети від введення маршрутизатора NAT.
Для пакетів, які передаються з внутрішньої мережі в зовнішню, слід переконатися в наявності маршруту до одержувача, так як ця перевірка виконується до перетворення. Додаткова інформація міститься в документі "Порядок роботи NAT".
Якщо NAT працює правильно, почніть усувати неполадки неполадок підключення наступним чином:
Перевірте підключення рівня 2.
Перевірте відомості маршрутизації третього рівня.
Пошук фільтрів пакетів, які можуть викликати проблему.
Перетворення NAT для порту 80 не працює, але трансрасположеніе крил для інших портів зазвичай працює.
Щоб вирішити цю проблему, виконайте такі дії:
Виконайте трансляції debug ip nat і команди debug ip packet. щоб бачити, чи коректні трансляції, і запис правильного перетворення встановлена в таблиці перетворення.
Перевірте, що відповідає сервер.
Вимкніть сервер HTTP.
Очистіть NAT і таблиці ARP.
Коли команда показу. віднесена до NAT або show running config або команді write memory. виконується, повідомлення про помилки% NAT: System busy. Try later з'являється. Ця проблема відбувається через збільшення розміру таблиці NAT. Коли розмір збільшень таблиці NAT, маршрутизатор вичерпує пам'ять.
Повторно завантажте маршрутизатор для вирішення цієї проблеми. Якщо повідомлення про помилки з'являється, коли SNAT HSRP налаштований, налаштуйте ці команди для вирішення питання:
Хост може передати сотні трансляцій, який в свою чергу призводить до високого завантаження ЦП. Іншими словами, це може зробити таблицю настільки великий, що це змушує ЦП досягати 100 відсотків. Команда ip nat translation max-entries 300 робить 300 на межу хоста або складовою межа суми трансляцій на маршрутизаторі. Обхідний шлях повинен використовувати команду ip nat translation max-entries all-hosts 300.
Перераховані вище проблеми показують, що причиною неполадок IP-з'єднання не завжди є NAT. У багатьох випадках причина - щось інше, ніж NAT і вимагає додаткового дослідження. Даний документ містить опис основних дій, які необхідно вжити для усунення несправностей і перевірки функціонування NAT. Дані кроки включають:
Ясно визначте те, чого NAT, як передбачається, досягає.
Перевірте, що правильні перетворення існують в таблиці перетворення.
Щоб переконатися в тому, що перетворення відбувається, використовуйте команди show і debug.
Аналіз докладно, що відбувається з пакетом і перевіряє, що маршрутизатори мають правильні відомості про маршрутизації для переміщення пакета вперед.
Це повідомлення про помилки є просто інформаційним повідомленням і не впливає на нормальну поведінку пристрою.
Якщо пакет пошкоджений або сервер FTP, або у клієнта є malforming команди, NAT не може належним чином обчислити трансляцію, і це генерує ту помилку. Пропозиція повинна встановити клієнта FTP в "пасивний" так, щоб воно ініціювало обидва канали. Це іноді допомагає з FTP через NAT.