Содержание
Проверка состояния сети
# mii-tool -v eth0 eth0: negotiated 100baseTx-FD, link ok product info: vendor 00:50:43, model 2 rev 3 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
Или с помощью ethtool:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Поиск ошибок в передаче данных
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:50:56:99:17:42
inet addr:10.249.140.239 Bcast:10.249.140.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fe99:1742/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:89633815 errors:0 dropped:0 overruns:0 frame:0
TX packets:109218677 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:78134000640 (72.7 GiB) TX bytes:127090915197 (118.3 GiB)
Или более подробно с помощью ethtool:
# ethtool -S eth0
NIC statistics:
rx_packets: 89638930
tx_packets: 39719720
rx_bytes: 78504132841
tx_bytes: 123421371192
rx_broadcast: 0
tx_broadcast: 0
rx_multicast: 0
tx_multicast: 0
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 136
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 10820554
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 78504132841
rx_csum_offload_good: 84998213
rx_csum_offload_errors: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
Либо с помощью netstat:
# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 89634605 0 0 0 109219080 0 0 0 BMRU lo 16436 0 51910911 0 0 0 51910911 0 0 0 LRU
Возможные типы и причины ошибок в сети
- Collisions: может возникать в режиме полудуплекса, если сетевая карта обнаруживает что она и другое сетевое устройство в сети отправляет данные одновременно; коллизии (“противоречие“) можно считать обычным явлением в сети, и её уровень как правило менее 0.1% от общего числа пакетов; более высокое значение может означать неисправную сетевую карту или плохо подключенные кабели;
- CRC Errors: кадры отправлены, но были повреждены во время передачи; наличие ошибок CRC (Cyclic Redundancy Check) при небольшом значении ошибок Collisions может возникать в случае електромагнитных шумов; убедитесь, что используется правильный тип кабеля, что сам кабель не повреждён и что коннекторы правильно закреплены в портах;
- FIFO and Overrun Errors: количество неудачных попыток переместить данные в память; как правило возникает при чрезмерно большом трафике;
- Length Errors: полученная длина кадра меньше или больше, чем предусмотрено стандартом Ethernet; это наиболее частая ошибка из-за несовместимых натроек дуплекса;
- Carrier Errors: возникают, когда сетевой интерфейс теряет связь с другим устройсвом (свичём, роутером);
Проверка MAC-адреса
Бывают случаи, когда пропадает линк к серверу, который напрямую подключен к вашей локальной сети. Просмотр ARP-таблицы с другого устройства в этой сети (другого вашего сервера) поможет определить отвечает ли удалённый сервер хоть на какие-то запросы с вашего сервера. В случае проблем на этом уровне может означать следующее:
- удалённый сервер отключен от сети вообще;
- проблемы с кабелями;
- сетевой интерфейс на удалённом серве может быть отключен;
- на удалённом сервер работает фильтрация firewall-ом; как правило, в таком случае, вы можете увидеть его MAC-адрес, но нормального обмена данными не происходит.
Примеры того, как можно получить данные ARP-таблицы.
ifconfig -a – отобразит ваши IP и MAC-адреса:
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:50:56:99:17:42
inet addr:10.249.140.239 Bcast:10.249.140.255 Mask:255.255.255.0
arp -a – отобразит вашу таблицу ARP:
# arp -a cc8-gw.dc.***.com (77.***.***.1) at 00:00:0c:07:ac:0d [ether] on eth0
Примечание: Что бы проверить удалённый хост, используя не ICMP-запросы (обычный ping), а ARP – можно воспользоваться утилитой arping:
# arping -s 10.***.***.239 10.***.***.1 ARPING 10.***.***.1 from 10.249.140.239 eth0 Unicast reply from 10.***.***.1 [4C:4E:35:C0:B6:47] 11.688ms Unicast reply from 10.***.***.1 [4C:4E:35:C0:B6:47] 7.546ms
Проверка сайтов с помощью curl
curl работает как текстовый браузер, и позволяет получать всю страницу целиком или только заголовки от веб-сервера:
# curl -I http://ya.ru HTTP/1.1 200 Ok Server: nginx Date: Fri, 22 Aug 2014 12:25:27 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 8186 Connection: close Cache-Control: no-cache,no-store,max-age=0,must-revalidate Expires: Fri, 22 Aug 2014 12:25:28 GMT Last-Modified: Fri, 22 Aug 2014 12:25:28 GMT P3P: policyref="/w3c/p3p.xml", CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI" Set-Cookie: yandex_gid=143; Expires=Sun, 21-Sep-2014 12:25:27 GMT; Domain=.ya.ru; Path=/ Set-Cookie: yp=; Expires=Tue, 24-Aug-2004 12:25:27 GMT; Path=/ Set-Cookie: yp=; Expires=Tue, 24-Aug-2004 12:25:27 GMT; Domain=.ya.ru; Path=/ Set-Cookie: yp=1411302328.ygu.1; Expires=Mon, 19-Aug-2024 12:25:27 GMT; Domain=.ya.ru; Path=/ Set-Cookie: yandexuid=7178152981408710328; Expires=Mon, 19-Aug-2024 12:25:27 GMT; Domain=.ya.ru; Path=/ X-Frame-Options: DENY X-XRDS-Location: http://openid.yandex.ru/server_xrds/
Проверка сети с помощью netstat
Как и вышеупомянутые утилиты, netstat может помочь в определении источника проблем в сети. С помощью опций -an можно отобразить все открытые порты и активные соединения:
# netstat -an
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:2222 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:783 0.0.0.0:* LISTEN ...
Подробнее про netstat – netstat: примеры использования, опции.
Использование traceroute для проверки сети
Ещё одна утилита – traceroute. Она предоставляет информацию обо всех узлах между вашим сервером и удалённым сервером.
Как работает traceroute?
traceroute отправляет UDP-пакеты с TTL=0 (кол-во итераций или пересылок пакетов). Первый маршрутизатор получает такое значение, считает что TTL истёк, и отбрасывает пакет, но возвращает ICMP-ответ “time exceeded“. traceroute записывает IP и/или имя хоста этого узла, а затем отправлет новый пакет, уже с TTL=1. Первый узел его пропускает, но уменьшает значение до 0, и пересылает пакет следующему узлу. Второй узел, видя TTL=0 отбрасывает пакет и возвращает ICMP-ответ “time exceeded“. Таким образом – traceroute gполучает IP и второго узла, после чего продолжает отправку пакетов с увеличением TTL до тех пор, пока не получит ответ от хоста назначения:
# traceroute ya.ru traceroute to ya.ru (93.158.134.3), 30 hops max, 60 byte packets 1 v513.mars.dc.***.com (77.***.***.4) 0.342 ms 0.442 ms 0.475 ms 2 be12.257.cr-1.f17.kiev.***.net (82.***.***.6) 0.688 ms 0.742 ms 0.897 ms 3 be1.206.cr-2.g50.kiev.***.net (77.***.1.130) 2.081 ms 2.079 ms 2.170 ms 4 yandex-2-ix.giganet.ua (91.245.221.101) 0.677 ms 0.664 ms 0.760 ms 5 fol2-c4-xe-2-1-3.yndx.net (213.180.213.6) 19.765 ms 19.777 ms 19.763 ms 6 ugr-p3-be9.yndx.net (213.180.213.32) 66.093 ms 19.752 ms 65.499 ms 7 www.yandex.ru (93.158.134.3) 19.916 ms 19.837 ms 19.924 ms
Некоторые узлы отбрасывают пакеты от traceroute. В таком случае, с помощью опции -I можно использовать протокол ICMP:
# traceroute -I ya.ru traceroute to ya.ru (213.180.204.3), 30 hops max, 60 byte packets 1 v513.mars.dc.volia.com (77.***.***.4) 0.428 ms 0.449 ms 0.481 ms 2 be12.257.cr-1.f17.kiev.volia.net (82.***.***.6) 0.665 ms 0.880 ms 0.993 ms 3 be1.206.cr-2.g50.kiev.volia.net (77.***.1.130) 2.387 ms 2.393 ms 2.392 ms 4 yandex-2-ix.giganet.ua (91.245.221.101) 0.811 ms 0.816 ms 0.921 ms 5 fol2-c4-xe-2-1-3.yndx.net (213.180.213.6) 19.769 ms 19.776 ms 19.776 ms 6 iva-p2-be4.yndx.net (87.250.239.60) 21.074 ms 21.351 ms 21.715 ms 7 www.yandex.ru (213.180.204.3) 20.453 ms 20.499 ms 20.491 ms
Утилита MTR
MTR (Matt’s Traceoute) – утилита, которая в режиме реального времени отображает работу traceroute:
# mtr ya.ru
My traceroute [v0.75]
venti.***.org.ua (0.0.0.0) Fri Aug 22 16:18:11 2014
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. v513.mars.dc.***.com 0.0% 6 0.4 0.4 0.4 0.4 0.0
2. be12.257.cr-1.f17.kiev.***.net 0.0% 6 0.7 0.7 0.6 0.7 0.0
3. be1.206.cr-2.g50.kiev.***.net 0.0% 5 1.1 1.3 1.0 2.7 0.7
4. yandex-2-ix.giganet.ua 0.0% 5 0.6 0.8 0.6 1.3 0.3
5. fol2-c4-xe-2-1-3.yndx.net 0.0% 5 19.7 19.9 19.7 20.5 0.3
6. ugr-p3-be9.yndx.net 0.0% 5 19.8 19.8 19.8 19.9 0.0
7. www.yandex.ru 0.0% 5 19.9 19.9 19.9 20.0 0.1
Просмотр трафика с помощью tcpdump
Утилита tcpdump – одна из самых популярных для просмотра трафика на сетевом интерфейсе.
Наиболее используемый вариант – это определение наличия базового двухсторонннего обмена. Проблемы с этим могут возникать в случае:
- неправильного роутинга пакетов;
- проблем с интерфейсами, устройствами;
- удалённый сервер не прослушивает указанынй порт (не запущен соответствующий сервис);
- сетевое устройство на пути следования пакета блокирует передачу пакетов (файерволы, ACL и т.п.).
Подробнее – в статье tcpdump: примеры использования.
Поиск проблем в сети с помощью tshark
Опции и вид выдаваемой tshark информации очень схож с tcpdump, однако tshark имеет больше возможностей.
Например, tshark умеет записывать данные в файл, как и tcpdump , но при этом он умеет создавать новый файл для записи, когда предыдущий достигнет заданного размера. Кроме того, ему можно указать количество создаваемых файлов, после достиджения которого он начнёт перезаписывать первый созданный файл.
# tshark -i eth0 tcp port 80 Capturing on eth0 0.000037 77.***.***.20 -> 77.***.***.40 TCP 66 http > 25743 [ACK] Seq=1 Ack=1173 Win=2003 Len=0 TSval=2966389358 TSecr=3148468854 2.756875 77.***.***.20 -> 77.***.***.40 HTTP 596 HTTP/1.1 200 OK (text/plain) 2.852136 77.***.***.40 -> 77.***.***.20 TCP 66 25743 > http [ACK] Seq=1173 Ack=531 Win=1040 Len=0 TSval=3148471706 TSecr=2966392115
Для установки tshark на CentOS – используйте:
# yum -y install wireshark
Использование утилиты nmap
Вы можете сипользовать утилиту nmap для определения всех открытых портов на удалённом сервере. Это может быть использовано, например, для поиска уязвимостей в вашей сети, например – сервера, на которых запущены неизвестные сетевые приложения.
# nmap -sT -T 5 -p 1-5000 localhost Starting Nmap 5.51 ( http://nmap.org ) at 2014-08-22 17:28 EEST Nmap scan report for localhost (127.0.0.1) Host is up (0.00042s latency). Not shown: 4992 closed ports PORT STATE SERVICE 25/tcp open smtp 80/tcp open http 110/tcp open pop3 143/tcp open imap 250/tcp open unknown 783/tcp open spamassassin 2222/tcp open EtherNet/IP-1 3306/tcp open mysql Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds
Полный текст статьи можно найти тут>>>.
