Коли системи стикаються з проблемами, як це іноді трапляється, вам потрібно знати, як вирішити проблему та відновити їх до нормального та функціонального стану. У цьому розділі ми зосереджуємось на фундаментальних навиках усунення несправностей мережі, якими повинен володіти будь -який системний адміністратор Linux.
У більшості випадків між адміністраторами мережі та системними адміністраторами існує великий розрив. Зазвичай звинувачують системних адміністраторів, яким не видно мережі мережевих адміністраторів для відключень і простої, в той час як адміністратори мережі будуть мати недостатнє знання сервера, що часто перетворюватиме провину системних адміністраторів на несправність пристрою кінцевої точки. Однак гра на звинувачення не допомагає вирішувати проблеми, а в робочому середовищі це може порушити стосунки між колегами.
Будучи системним адміністратором, фундаментальне розуміння усунення несправностей у мережі допоможе швидше вирішити проблеми та сприятиме створенню згуртованого робочого середовища. Саме з цієї причини ми зібрали цей розділ, щоб виділити деякі з них
основні поради щодо усунення несправностей мережі що стане в нагоді при діагностуванні мережевих проблем.У нашій попередній темі Серія LFCA, ми подивились на Концептуальна модель TCP/IP що показує передачу даних на комп’ютері та протоколи, що знаходяться на кожному рівні.
Іншою не менш важливою концептуальною моделлю є Модель OSI (Взаємозв’язок відкритих систем) модель. Це 7 -шарова структура TCP/IP, яка руйнує мережеву систему та обчислює функції, як і кожен рівень.
В OSI моделі, ці функції сегментуються на наступні шари, починаючи знизу. Фізичний рівень, рівень посилання на дані, мережевий рівень, транспортний рівень, рівень сеансу. Шар презентації і, нарешті, шар додатків у самому верху.
Неможливо говорити про усунення несправностей мережі без посилання на модель OSI. З цієї причини ми проведемо вас по кожному шару та дізнаємось про різні використовувані мережеві протоколи та як усунути несправності, пов’язані з кожним шаром.
Це, мабуть, один з найбільш недооцінюваних шарів, але це один з найважливіших шарів, необхідних для будь -якої комунікації. Фізичний рівень охоплює фізичні мережеві компоненти ПК, такі як мережеві карти, кабелі Ethernet, оптичні волокна тощо. Більшість проблем починаються тут і здебільшого викликані:
У цьому шарі виникають такі питання:
Щоб перевірити стан мережевих інтерфейсів, запустіть ip команда:
$ ip посилання шоу.
З результату вище у нас є 2 інтерфейси. Перший інтерфейс - ось
- це адреса зворотного зв'язку і зазвичай не використовується. Активний мережевий інтерфейс, який забезпечує підключення до мережі та Інтернету, є enp0s3
інтерфейс. З виводу ми бачимо, що стан інтерфейсу ВГОРУ.
Якщо мережевий інтерфейс не працює, ви побачите стан ВНИЗ вихід.
Якщо це так, ви можете відкрити інтерфейс за допомогою команди:
$ sudo ip набір посилань enp0s3 вгору.
Крім того, ви можете запустити команда ifconfig показано нижче.
$ sudo ifconfig enp0s3 вгору. $ ip посилання шоу.
Щоб підтвердити, що ваш ПК вибрав IP -адресу з маршрутизатора або DHCP -сервера, запустіть команда ifconfig.
$ ifconfig.
IPv4 адреса має префікс параметра inet, як показано. Наприклад, IP -адреса цієї системи - це 192.168.2.104 з підмережею або мережевою маскою 255.255.255.0.
$ ifconfig.
Крім того, ви можете запустити IP-адреса виконайте таку команду, щоб перевірити IP -адресу вашої системи.
$ ip -адреса.
Щоб перевірити IP -адресу шлюзу за замовчуванням, виконайте команду:
$ ip маршрут | grep за замовчуванням.
IP -адреса шлюзу за замовчуванням, який у більшості випадків є сервером DHCP або маршрутизатором, вказується, як показано нижче. У мережі IP ви повинні мати можливість пінгувати шлюз за замовчуванням.
Щоб перевірити використовувані сервери DNS, виконайте таку команду в системах systemd.
$ systemd-разрешение --status.
Кращий спосіб перевірити використовувані DNS -сервери - запустити Команда nmcli показано
$ (список nmcli dev || nmcli dev show) 2>/dev/null | grep DNS.
Як ви помітили, тут відбувається величезний шматок усунення несправностей мережі.
По суті, рівень зв’язку даних визначає формат даних у мережі. Тут відбувається передача кадрів даних між хостами. Переважаючим протоколом на цьому рівні є ARP ( Протокол вирішення адрес).
ARP відповідає за виявлення адрес на рівні посилання та виконує зіставлення адрес IPv4 на рівні 3 з MAC-адресами. Зазвичай, коли хост звертається до шлюзу за замовчуванням, є ймовірність того, що він уже має IP -адресу хоста, але не MAC -адреси.
ARP протокол усуває розрив між шаром 3 і рівнем 2 шляхом трансляції 32-розрядних адрес IPv4 на рівні 3 до 48-бітних MAC-адрес на рівні 2 і навпаки.
Коли ПК підключається до локальної мережі, маршрутизатор ( шлюз за замовчуванням ) призначає йому IP -адресу для ідентифікації. Коли інший хост надсилає пакет даних, призначений для ПК, до шлюзу за замовчуванням, маршрутизатор запитує ARP шукати MAC -адресу, що йде разом з IP -адресою.
Кожна система має свою ARP таблиці. Щоб перевірити свою таблицю ARP, виконайте команду:
$ ip шоу сусідів.
Як ви можете помітити, MAC -адреса маршрутизатора заповнюється. Якщо є проблема вирішення, команда не повертає жодного результату.
Це той шар, з яким ви працюєте виключно IPv4 адреси, знайомі системним адміністраторам. Він надає кілька протоколів, таких як ICMP та ARP які ми висвітлювали та інші, наприклад RIP (Інформаційний протокол маршрутизації).
Деякі з поширених проблем включають неправильну конфігурацію пристрою або проблеми з мережевими пристроями, такими як маршрутизатори та комутатори. Хорошим місцем для початку усунення несправностей є перевірка того, чи вибрала ваша система IP -адресу наступним чином:
$ ifconfig.
Крім того, ви можете використовувати команда ping щоб перевірити підключення до Інтернету, надіславши ICMP echo -пакет до DNS Google. -в
прапор позначає кількість відправлених пакетів.
$ ping 8.8.8.8 -c 4.
Результат показує позитивну відповідь від DNS Google з нульовою втратою пакетів. Якщо у вас переривчасте з'єднання, ви можете перевірити, з якої точки пакети скидаються, за допомогою команда traceroute наступним чином.
$ traceroute google.com.
Зірочки вказують на момент, коли пакети скидаються або втрачаються.
Команда nslookup надсилає запити DNS, щоб отримати IP -адресу, пов'язану з доменом або іменем хоста. Це називається пересиланням DNS вперед.
Наприклад.
$ nslookup google.com.
Команда розкриває IP -адреси, пов’язані з доменом google.com.
Сервер: 127.0.0.53. Адреса: 127.0.0.53#53 Неавторитетна відповідь: Ім'я: google.com. Адреса: 142.250.192.14. Назва: google.com. Адреса: 2404: 6800: 4009: 828:: 200e.
команда dig це ще одна команда, яка використовується для запиту DNS -серверів, пов'язаних з доменним іменем. Наприклад, для запиту серверів імен DNS запустіть:
$ dig google.com.
Транспортний рівень обробляє передачу даних за допомогою TCP та UDP протоколи. Просто підсумовуємо, TCP є протоколом, орієнтованим на з'єднання, а UDP-без з'єднання. Запуск програми прослуховування на сокетах, які складаються з портів та IP -адрес.
Поширені проблеми, які можуть виникнути, включаючи заблоковані порти TCP, які можуть знадобитися програмам. Якщо у вас є веб -сервер і ви хочете перевірити його робочий стан, скористайтеся netstat або команда ss щоб перевірити, чи веб -служба прослуховує порт 80
$ sudo netstat -pnltu | grep 80. АБО. $ ss -pnltu | grep 80.
Іноді порт може використовуватися запущеною службою в системі. Якщо ви хочете, щоб інша служба використовувала цей порт, вас можуть змусити налаштувати його на використання іншого порту.
Якщо у вас все ще виникають проблеми, перевірте брандмауер і перевірте, чи порт, який вас цікавить, заблокований.
Більшість усунення несправностей відбуватиметься через ці 4 шари. Дуже мало усунення несправностей виконується на рівнях сеансу, презентації та програми. Це тому, що вони відіграють менш активну роль у функціонуванні мережі. Однак давайте швидко оглянемо, що відбувається в цих шарах.
Рівень сеансу відкриває канали зв'язку, які називаються сеансами, і гарантує, що вони залишаються відкритими під час передачі даних. Він також закривається після того, як зв'язок припиняється.
Також відомий як рівень синтаксису, рівень презентації синтезує дані, які будуть використовуватися шаром програми. У ньому прописано, як пристрої мають шифрувати, кодувати та стискати дані, щоб забезпечити їх хороший прийом з іншого боку.
Нарешті, у нас є прикладний рівень, який є найближчим до кінцевих користувачів і дозволяє їм взаємодіяти з прикладним програмним забезпеченням. Прикладний рівень багатий такими протоколами, як HTTP, HTTPS, POP3, IMAP, DNS, RDP, SSH, SNMP та NTP.
Під час усунення несправностей у системі Linux дуже рекомендується багатошаровий підхід із використанням моделі OSI, починаючи з нижнього шару. Це дає вам уявлення про те, що відбувається, і допомагає звузити проблему.