Какие средства устранения неполадок доступны на каждом уровне сети?
В своей предыдущей статье я говорил о том, почему сеть в Linux многоуровневая. Если вы читаете эту статью, у вас должно быть относительно четкое понимание того, почему сеть должна быть многоуровневой и почему она должна быть многоуровневой именно таким образом. Я также представил основную концепцию каждого слоя.
В этой статье давайте рассмотрим доступные инструменты устранения неполадок на каждом сетевом уровне.
Уровень 7 — прикладной уровень
На прикладном уровне слишком много инструментов для устранения неполадок. Давайте выберем основное приложение для расширения и поговорим об инструменте устранения неполадок для HTTP-приложений.
В настоящее время основным браузером является Chrome от Google, который сам имеет встроенные инструменты разработчика. Нажмите F12
в интерфейсе Chrome или, если вы используете систему Apple, вы также можете нажать комбинацию клавиш option + command + I
, чтобы запустить инструменты разработчика.
На самом деле подобные инструменты есть и в других браузерах, таких как Firefox и Edge. А поскольку Edge основан на ядре браузера Chromium, его инструменты разработчика очень похожи на инструменты Chrome.
С помощью инструментов разработчика мы можем очень удобно делать многие вещи, например следующие.
Найдите проблемный IP-адрес сервера
Например, некоторые пользователи сообщают, что не могут получить доступ к вашему сайту, но вы прекрасно знаете, что доменное имя этого сайта соответствует множеству IP-адресов. Как узнать, к какому IP подключен пользователь?
Вы можете сделать это: позволить клиенту включить инструменты разработчика, найти объект домашней страницы на странице «Сеть», а в его разделе «Заголовки» вы можете увидеть «Удаленный адрес», где IP — это IP-адрес текущего подключения, например, следующий:
Однако из-за разрешения DNS весьма вероятно, что IP-адрес не будет таким же при повторном подключении в следующий раз, поэтому вам следует каждый раз повторно подтверждать эту информацию.
Этот метод особенно полезен при устранении неполадок с доступом к общедоступной сети. Вы знаете, теперь, когда сайты с более высокой посещаемостью уже размещены в CDN, должны быть десятки или сотни терминальных узлов CDN по всей стране и даже по всему миру, предоставляющие услуги посетителям поблизости.
Если кто-то говорит, что не может получить доступ к определенному сайту, то, пожалуйста, позвольте ему использовать инструмент разработчика, чтобы найти удаленный IP-адрес, к которому он подключен, и тогда вы можете начать расследование на основе этой информации.
Помощь в устранении неполадок медленных веб-страниц
Если доступ к странице кажется очень медленным, вы можете использовать функцию статистики времени инструмента разработчика, чтобы найти объекты ресурсов HTTP, требующие больших затрат времени, а затем провести целевое исследование.
Например, я думаю, что доступ к https://github.com очень медленный, поэтому я могу сначала открыть инструменты разработчика, затем посетить сайт, а после завершения загрузки перейти на страницу Сеть, чтобы проверить загрузку. время этих HTTP-объектов.
Однако этот метод может только проверить, какой ресурсный объект занимает больше времени, но для дальнейшего исследования, например, «почему время загрузки этого объекта больше, чем у других объектов», средствам разработчика сложно ответить.
Уровень 6, 5 — уровень представления и уровень сеанса
В предыдущем разделе о сетевом уровне я упомянул, что на уровне представления и сеансовом уровне не так много протоколов, и TLS можно разделить на эти два уровня. Для устранения проблем с TLS я рекомендую вам два инструмента.
Во-первых, это предварительная проверка на основе браузера, в основном вокруг самого сертификата. В адресной строке браузера есть кнопка, нажав на нее, можно просмотреть сертификат TLS и другую информацию:
В приведенном выше меню продолжайте нажимать кнопку «Соединение защищено», а затем нажмите кнопку «Сертификат действителен», чтобы просмотреть сертификат.
Кроме того, с помощью меню «Безопасность» инструментов разработчика вы также можете просмотреть более подробную информацию о TLS, включая версию протокола, алгоритм обмена ключами, срок действия сертификата и многое другое.
Второй — использовать tcpdump
и Wireshark
для проверки рукопожатия TLS, обмена ключами, передачи зашифрованного текста и т. д. В Wireshark
детали TLS можно просмотреть более полно.
Например, мы можем напрямую видеть набор шифров, отображаемый обеими сторонами во время процесса согласования на этапе рукопожатия TLS, в то время как в инструментах разработчика мы можем видеть параметры только после завершения согласования.
Уровень 4 — Транспортный уровень
Транспортный уровень, несомненно, имеет наивысший приоритет, и существует множество инструментов. Мы представим инструменты в соответствии со сценариями устранения неполадок.
Проверка доступности пути
Если мы хотим протестировать рукопожатие TCP, у нас есть два общих инструмента, telnet
и nc
. Например телнет:
$ telnet google.com 443 Trying 142.250.80.46... Connected to google.com. Escape character is '^]'. ^] telnet> q Connection closed.
С помощью nc вы можете сделать это:
$ nc -w 2 -zv google.com 443 Connection to google.com port 443 [tcp/https] succeeded!
Просмотр текущего состояния подключения
Команда netstat
— это классическая команда, и многие учащиеся будут использовать ее для получения информации о текущем соединении TCP, UDP и т. д., например:
$ netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 280 10.0.2.15:22 10.0.2.2:56669 ESTABLISHED tcp6 0 0 :::22 :::* LISTEN
Просмотр скорости передачи текущего соединения
Иногда ваша сеть очень загружена, но вы не знаете, какое соединение занимает наибольшую пропускную способность? Вы можете использовать iftop
. Этот инструмент не поставляется с системой по умолчанию, его необходимо установить, а затем выполнить iftop
.
Кстати, у вас должны быть права sudo, то есть выполнить sudo iftop
, и тогда вы сможете увидеть скорости передачи разных соединений, и найти соединение, которое потребляет вашу пропускную способность. Например следующее:
Просматривать статистику по потерям и выходу пакетов из строя
Фактически, в дополнение к получению состояния соединения в реальном времени с помощью netstat
вы также можете получить историческую статистическую информацию. Например, если вы подозреваете, что сеть машины нестабильна, помимо простого теста с пингом, вы также можете использовать netstat -s
для получения более подробной статистики.
Например, значения количества потерянных и неупорядоченных пакетов TCP могут помочь вам определить состояние транспортного уровня. Вот вывод перехваченной мной команды netstat -s
:
$ netstat -s ...... Tcp: 16 active connection openings 1 passive connection openings 8 failed connection attempts 1 connection resets received 1 connections established 6254 segments received 4035 segments sent out 1 segments retransmitted 0 bad segments received 3 resets sent ...... TcpExt: 1 ICMP packets dropped because socket was locked 3 TCP sockets finished time wait in fast timer 8 delayed acks sent 4674 packet headers predicted 10 acknowledgments not containing data payload received 1008 predicted acknowledgments TCPTimeouts: 1 TCPBacklogCoalesce: 140 1 connections reset due to early user close TCPRcvCoalesce: 2187 TCPAutoCorking: 110 TCPSynRetrans: 1 TCPOrigDataSent: 1041 TCPDelivered: 1049
Использование СС
Команда ss
— это команда в пакете Iproute2
и «замена» для netstat
. Он предоставляет богатую статистику по сокетам. Например, я часто использую следующую команду для просмотра статистики текущего соединения:
$ ss -s Total: 164 TCP: 5 (estab 1, closed 0, orphaned 0, timewait 0) Transport Total IP IPv6 RAW 1 0 1 UDP 2 2 0 TCP 5 4 1 INET 8 6 2 FRAG 0 0 0
Уровень 3 — сетевой уровень
На этом уровне, в дополнение к использованию ping
, который является очень простым инструментом, вы также должны освоить две другие команды, предоставляющие более мощные возможности устранения неполадок, traceroute
и mtr
.
Просмотр состояния сетевого пути
Вот типичный вывод простого вывода traceroute
:
$ traceroute google.com traceroute to google.com (142.250.80.46), 64 hops max, 52 byte packets 1 g3100 (192.168.1.1) 2.324 ms 1.108 ms 0.978 ms 2 * * * 3 100.41.25.94 (100.41.25.94) 8.645 ms 100.41.25.96 (100.41.25.96) 8.117 ms 100.41.25.94 (100.41.25.94) 8.137 ms 4 0.csi1.whplnywp-mse01-bb-su1.alter.net (140.222.3.212) 7.873 ms 11.703 ms 12.035 ms 5 * * * 6 * * * 7 0.et-10-1-5.gw15.nyc1.alter.net (140.222.230.217) 6.660 ms 20.782 ms 0.et-9-0-2.gw15.nyc1.alter.net (140.222.1.43) 10.109 ms 8 
.20.148.204.in-addr.arpa (204.148.20.6) 6.696 ms 72.14.208.130 (72.14.208.130) 7.677 ms 7.520 ms 9 * 108.170.248.97 (108.170.248.97) 8.115 ms 6.994 ms 10 142.251.65.92 (142.251.65.92) 8.938 ms 108.170.236.88 (108.170.236.88) 8.210 ms 142.251.65.97 (142.251.65.97) 8.340 ms 11 108.170.248.20 (108.170.248.20) 7.115 ms 108.170.248.84 (108.170.248.84) 8.103 ms 142.251.65.97 (142.251.65.97) 8.934 ms 12 lga34s34-in-f14.1e100.net (142.250.80.46) 8.008 ms 8.151 ms 9.326 ms
По умолчанию traceroute
использует UDP
в качестве протокола обнаружения, но многие сетевые устройства не отвечают на UDP, поэтому иногда вы видите *
. Однако у traceroute
есть и очевидный недостаток: он не может проверять путь несколько раз подряд.
В дополнение к функциям traceroute
mtr
также может создавать расширенные отчеты об обнаружении. Например:
$ mtr google.com -r -c 10 Start: 2022-01-07T04:05:02+0000 HOST: victorebpf Loss% Snt Last Avg Best Wrst StDev 1.|-- _gateway 0.0% 10 0.3 0.4 0.2 1.2 0.3 2.|-- 192.168.1.1 0.0% 10 1.6 1.8 1.4 3.2 0.5 3.|-- 100.65.0.1 0.0% 10 3.8 7.0 3.8 10.3 2.0 4.|-- 61.152.54.125 0.0% 10 4.0 4.3 3.6 5.1 0.5 5.|-- 61.152.25.110 30.0% 10 5.0 6.8 4.4 18.9 5.4 6.|-- 202.97.101.30 20.0% 10 7.8 6.6 5.4 7.8 0.8 7.|-- 58.213.95.110 80.0% 10 10.0 9.8 9.6 10.0 0.3 8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 9.|-- 58.213.96.74 0.0% 10 10.5 12.7 9.9 24.7 4.9 10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 11.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 12.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0 13.|-- 180.101.49.12 0.0% 10 9.4 9.1 8.3 9.7 0.5
Просмотр маршрутизации
Команда route может просматривать таблицу маршрутизации, но эта команда немного старше:
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.2.2 0.0.0.0 UG 100 0 0 enp0s3 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s3 10.0.2.2 0.0.0.0 255.255.255.255 UH 100 0 0 enp0s3 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
Или команда ip
:
$ ip route default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100 10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
Уровень 2, 1 — уровень канала передачи данных и физический уровень
Этот уровень находится далеко от прикладного уровня, и обычно за него отвечает штатная сетевая группа. Если на этом уровне возникнут проблемы, это напрямую отразится на производительности сетевого уровня.
Например, IP будет иметь потерю пакетов и задержку, а затем вызовет исключения транспортного уровня (такие как потеря пакетов, нарушение порядка, повторная передача и т. д.). Следовательно, стабильный канальный уровень и даже физический уровень являются краеугольным камнем надежности сети.
Однако, если вы хотите проверить состояние этих двух слоев, вы можете использовать инструмент ethtool
. Например:
# ethtool -S enp0s3 NIC statistics: rx_packets: 45897 tx_packets: 9457 rx_bytes: 59125524 tx_bytes: 834625 rx_broadcast: 0 tx_broadcast: 17 rx_multicast: 0 tx_multicast: 59 rx_errors: 0 tx_errors: 0 tx_dropped: 0
Его принцип заключается в том, что драйвер сетевой карты зарегистрирует в ядре callback-функцию ethtool
, а затем мы сможем использовать команду ethtool
для просмотра этой информации.
Поскольку информация предоставляется драйвером сетевой карты, она очень «приземлена». Если вы видели четкую информацию о нестабильности канала в средствах устранения неполадок на транспортном уровне и на сетевом уровне, обратитесь непосредственно к сетевой группе, чтобы решить эту проблему.