Когда системы сталкиваются с проблемами, что иногда случается, вам необходимо найти способ их решения и восстановить их до нормального рабочего состояния. В этом разделе мы сосредоточимся на фундаментальных навыках устранения неполадок в сети, которыми должен обладать любой системный администратор Linux.
В большинстве случаев существует большой разрыв между администраторами сети и системными администраторами. Системные администраторы, которым не хватает видимости сети, обычно винят сетевые администраторы на случай перебоев в работе и простои, в то время как администраторы сети будут недостаточно осведомлены о сервере, часто винят системных администраторов в отказе оконечного устройства. Однако поиск виноватых не помогает решать проблемы, а в рабочей среде это может ухудшить отношения между коллегами.
Если вы системный администратор, то фундаментальные знания в области устранения неполадок в сети помогут быстрее решать проблемы и способствовать созданию сплоченной рабочей среды. По этой причине мы собрали этот раздел, чтобы выделить некоторые из
основные советы по устранению неполадок в сети это пригодится при диагностике сетевых проблем.В нашей предыдущей теме про Серия LFCAмы посмотрели на Концептуальная модель TCP / IP который показывает передачу данных в компьютере и протоколы, которые находятся на каждом уровне.
Другой не менее важной концептуальной моделью является Модель OSI (Взаимодействие открытых систем) модель. Это 7-уровневая структура TCP / IP, которая разрушает сетевую систему, и вычислительные функции функционируют как каждый уровень.
в OSI В модели эти функции сегментированы на следующие уровни, начиная снизу. Физический уровень, уровень канала передачи данных, сетевой уровень, транспортный уровень, сеансовый уровень. Уровень представления и, наконец, уровень приложения на самом верху.
Невозможно говорить об устранении неполадок в сети без ссылки на модель OSI. По этой причине мы проведем вас через каждый уровень и выясним различные используемые сетевые протоколы и способы устранения неисправностей, связанных с каждым уровнем.
Вероятно, это один из самых недооцененных слоев, но он является одним из наиболее важных уровней, необходимых для любого взаимодействия. Физический уровень включает в себя физические сетевые компоненты ПК, такие как сетевые карты, кабели Ethernet, оптические волокна и т. Д. Большинство проблем начинаются здесь и в основном вызваны:
На этом уровне возникают следующие вопросы:
Чтобы проверить состояние ваших сетевых интерфейсов, запустите команда ip:
Показать ссылку $ ip.
Из выходных данных выше у нас есть 2 интерфейса. Первый интерфейс - вот
- это адрес обратной связи и обычно не используется. Активный сетевой интерфейс, обеспечивающий подключение к сети и Интернету, является enp0s3
интерфейс. Из вывода видно, что состояние интерфейса ВВЕРХ.
Если сетевой интерфейс не работает, вы увидите состояние ВНИЗ выход.
Если это так, вы можете запустить интерфейс с помощью команды:
$ sudo ip link set enp0s3 up.
В качестве альтернативы вы можете запустить команда ifconfig показано ниже.
$ sudo ifconfig enp0s3 up. Показать ссылку $ ip.
Просто чтобы убедиться, что ваш компьютер выбрал IP-адрес от маршрутизатора или DHCP-сервера, запустите команда ifconfig.
$ ifconfig.
В IPv4 адрес предваряется параметром inet, как показано. Например, IP-адрес этой системы 192.168.2.104 с подсетью или маской сети 255.255.255.0.
$ ifconfig.
В качестве альтернативы вы можете запустить айпи адрес выполните следующую команду, чтобы проверить IP-адрес вашей системы.
$ ip-адрес.
Чтобы проверить IP-адрес шлюза по умолчанию, выполните команду:
$ ip маршрут | grep по умолчанию.
IP-адрес шлюза по умолчанию, который в большинстве случаев является DHCP-сервером или маршрутизатором, указан, как показано ниже. В IP-сети вы должны иметь возможность проверить связь со шлюзом по умолчанию.
Чтобы проверить используемые DNS-серверы, выполните следующую команду в системах systemd.
$ systemd-resolve --status.
Лучший способ проверить используемые DNS-серверы - запустить команда nmcli показано
$ (nmcli dev list || 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 Neighbor show.
Как видите, MAC-адрес маршрутизатора заполнен. Если есть проблема с разрешением, команда не возвращает никаких результатов.
Это слой, с которым вы работаете исключительно IPv4 адреса, знакомые системным администраторам. Он предоставляет несколько протоколов, таких как ICMP и ARP которые мы рассмотрели и другие, такие как РВАТЬ (Протокол маршрутной информации).
Некоторые из распространенных проблем включают неправильную конфигурацию устройства или проблемы с сетевыми устройствами, такими как маршрутизаторы и коммутаторы. Хорошее место для начала устранения неполадок - проверить, выбрала ли ваша система IP-адрес следующим образом:
$ ifconfig.
Также вы можете использовать команда ping чтобы проверить подключение к Интернету, отправив ICMP эхо-пакет в DNS Google. В -c
флаг обозначает количество отправляемых пакетов.
$ 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.
В команда копать это еще одна команда, используемая для запроса 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, начиная с нижнего уровня. Это дает вам представление о том, что происходит не так, и помогает сузить круг проблем.