CentOS — решение сетевых проблем
Недавно разобрались с настройками сети в Linux, на примере CentOS (тут). А сегодня рассмотрим, как решать проблемы с ней. Чтобы эффективнее решать проблемы связанные с сеткой, и не только в CentOS, а в любом другом дистрибутиве Linux, проблему надо сначала найти, понять к какой категории она относится, а уже затем пытаться её решить. Путем внесения изменений в файлы настройки и проверки результата. Помним что проблем может быть несколько и что из-за первой вы не видите все остальные.
Основные виды возникающих проблем, средства их обнаружения и способы их решения:
| Описание | Проверка | Команда | Способ исправления |
| Поднялся ли сетевой интерфейс | ip адреса | ip addr | Измените настроечные файлы сетевых интерфейсов (/etc/sysconfig/network-scripts/ifcfg-*) |
| Нет интернета | перевод имени в ip | nslookup или dig | Исправить DNS сервер в /etc/resolv.conf |
| Маршрутизация | путь до сервера | ip route | Измените настроечные файлы сетевых интерфейсов (/etc/sysconfig/network-scripts/ifcfg-*) или задайте DHCP |
Полезные команды для диагностики проблем:
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 все должно быть очень похоже, так что дерзайте.
