Недавно разобрались с настройками сети в Linux, на примере CentOS (тут). А сегодня рассмотрим, как решать проблемы с ней. Чтобы эффективнее решать проблемы связанные с сеткой, и не только в CentOS, а в любом другом дистрибутиве Linux, проблему надо сначала найти, понять к какой категории она относится, а уже затем пытаться её решить. Путем внесения изменений в файлы настройки и проверки результата. Помним что проблем может быть несколько и что из-за первой вы не видите все остальные.

Основные виды возникающих проблем, средства их обнаружения и способы их решения:

Полезные команды для диагностики проблем:

ping — проверяет доступность удаленного сервера, используется так:

ping -c 2 google.com 
PING google.com (216.58.212.174) 56(84) bytes of data.
64 bytes from google.com (216.58.212.174): icmp_seq=1 ttl=128 time=63.4 ms
64 bytes from google.com (216.58.212.174): icmp_seq=2 ttl=128 time=69.2 ms

--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 63.410/66.343/69.276/2.933 ms

В данном примере мы проверяем доступность сервера google.com, а ключ -c устанавливает количество, сколько раз это сделать. В ответ выводится отчет проделанных работ. Каждой попытке выделяется отдельная строка, тут и количество байт пересланных, и адрес удаленного сервера, и сколько времени заняла каждая проверка. Ну и общий отчет, о том сколько попыток было успешно, а сколько нет. Там же минимальное, максимальное и среднее время проверки.

ip addr show eth0 — отображает информацию о интерфейсе eth0, вот пример:

ip addr show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:0c:32:cb brd ff:ff:ff:ff:ff:ff
    inet 172.16.58.128/24 brd 172.16.58.255 scope global dynamic ens33
       valid_lft 1157sec preferred_lft 1157sec
    inet6 fe80::2ab5:3843:d9f4:800b/64 scope link 
       valid_lft forever preferred_lft forever

Тут находится ip адрес и настройки самого интерфейса. Сразу понятно куда и как вы подключились.

traceroute или tracepath — отображает путь до сервера, и работает это так:

tracepath google.com
 1?: [LOCALHOST]                                         pmtu 1500
 1:  gateway                                               0.264ms 
 1:  gateway                                               0.355ms 
 2:  Broadcom.Home                                         3.328ms asymm  1 
 3:  Broadcom.Home                                         2.440ms pmtu 1492
 3:  82.102.128.60                                         4.141ms asymm  1 
 4:  no reply
 5:  82.102.132.78                                         4.624ms asymm  1 
 6:  80.179.166.85.static.012.net.il                      61.888ms asymm  1 
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply

Обе команды принимают имя сервера как параметр. traceroute более старая команда и была доступна в CentOS 6, а вот в CentOS 7 используется tracepath. Но обе они выводят список сетевых узлов которые надо пройти что бы дойти до нужного вам сервера. В примере я пытаюсь дойти до google.com. И вот что видно: первым делом с моего лэптопа связь идет на мой WiFi роутер, Затем на оптический модем. Тут почему-то gateway и Broadcom.Home отображаются дважды, наверное из-за преобразования сигналов между входом и выходом на каждом устройстве. Ну и как вы видите некоторые узлы, чаще всего высоко нагруженные, вообще не отвечают на такие запросы.

ip route — отображает таблицу маршрутизации

ip route
default via 172.16.58.2 dev ens33  proto static  metric 100 
172.16.58.0/24 dev ens33  proto kernel  scope link  src 172.16.58.128  metric 100

Тут таблица маршрутизации, через какой ip на какой интерфейс выходить. У меня очень простой пример я подключен к домашней сети по WiFi. Плюс у меня есть виртуальные машины которые как раз сидят в сетке 172.16.58.0/24 и выходят наружу через виртуальный сетевой маршрутизатор 172.16.58.128. Но об этом много что можно сказать так, что отдельно.

dig — отображает информацию о доменном имине

Для использования данной команды может понадобиться установить пакет bind-utils, вот так:

yum install bind-utils

А затем например если вы заходите «капнуть» информацию, о доменном имени google.com например, попробуйте вот это:

dig google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39248
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0005 , udp: 4096
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     5   IN  A   172.217.20.78

;; Query time: 5 msec
;; SERVER: 172.16.58.2#53(172.16.58.2)
;; WHEN: Thu May 31 13:53:41 EDT 2018
;; MSG SIZE  rcvd: 55

И не пугайтесь сильно, если запустив вышеуказанную команду несколько раз получите, что ip google.com меняется, это действительно так и есть.

Второй возможностью проверить перевод доменного имени в ip адрес это команда nslookup которая работает вот так:

nslookup google.com
Server:     172.16.58.2
Address:    172.16.58.2#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.20.78

Конечно же между разными дистрибутивами Linux есть довольно ощутимая разница в настройках и командах. Но принципы везде похожи. Так что даже если вы работаете в Ubuntu все должно быть очень похоже, так что дерзайте.