По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Tcpdump - это утилита командной строки, которая позволяет вам захватывать и анализировать сетевой трафик, проходящий через вашу систему. Он часто используется для устранения неполадок в сети, а также для обеспечения безопасности. Это мощный и универсальный инструмент, который включает в себя множество опций и фильтров. Поскольку это инструмент командной строки, он идеально подходит для работы на удаленных серверах или устройствах, для которых GUI недоступен, для сбора данных, которые могут быть проанализированы позже, поскольку результаты можно сохранять в отдельный файл. Он также может быть запущен в фоновом режиме или как запланированное задание с использованием таких инструментов, как cron. В этой статье мы рассмотрим некоторые из наиболее распространенных функций tcpdump. Установка Tcpdump Tcpdump включен в несколько дистрибутивов Linux, так что скорее всего, он у вас уже установлен. Проверьте, установлен ли tcpdump в вашей системе, например, с помощью командыwhich: which tcpdump Мы должны получить примерно такой вывод: /usr/sbin/tcpdump Если tcpdump не установлен, вы можете установить его, но используя менеджер пакетов вашего дистрибутива. В CentOS или Red Hat Enterprise Linux: sudo yum install -y tcpdump Для Ubuntu and Debian: sudo apt update && sudo apt install tcpdump Для Arch Linux: sudo pacman -S tcpdump Tcpdump требует libpcap, который является библиотекой для захвата сетевых пакетов. Если он не установлен, он будет автоматически добавлен как зависимость. Захват пакетов с Tcpdump Синтаксис Tcpdump выглядит следующим образом: tcpdump [options] [expression] Команда options позволяют вам контролировать поведение команды. Фильтр expression определяет какие пакеты будут захвачены Для захвата пакетов для траблшутинга или анализа tcpdump требуются повышенные разрешения, поэтому в следующих примерах большинство команд имеют префикс sudo. Для начала используйте команду tcpdump -D, чтобы увидеть, какие интерфейсы доступны для захвата: sudo tcpdump -D 1.eth0 2.virbr0 3.eth1 4.any (Pseudo-device that captures on all interfaces) 5.lo [Loopback] В приведенном выше примере вы можете увидеть все интерфейсы, доступные на компьютере. Специальный интерфейс any позволяет захватывать на всех активных интерфейсах. Давайте использовать его, чтобы поймать немного пакетов: sudo tcpdump -i any tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 09:56:18.293641 IP rhel75.localdomain.ssh > 192.168.64.1.56322: Flags [P.], seq 3770820720:3770820916, ack 3503648727, win 309, options [nop,nop,TS val 76577898 ecr 510770929], length 196 09:56:18.293794 IP 192.168.64.1.56322 > rhel75.localdomain.ssh: Flags [.], ack 196, win 391, options [nop,nop,TS val 510771017 ecr 76577898], length 0 09:56:18.295058 IP rhel75.59883 > gateway.domain: 2486+ PTR? 1.64.168.192.in-addr.arpa. (43) 09:56:18.310225 IP gateway.domain > rhel75.59883: 2486 NXDomain* 0/1/0 (102) 09:56:18.312482 IP rhel75.49685 > gateway.domain: 34242+ PTR? 28.64.168.192.in-addr.arpa. (44) 09:56:18.322425 IP gateway.domain > rhel75.49685: 34242 NXDomain* 0/1/0 (103) 09:56:18.323164 IP rhel75.56631 > gateway.domain: 29904+ PTR? 1.122.168.192.in-addr.arpa. (44) 09:56:18.323342 IP rhel75.localdomain.ssh > 192.168.64.1.56322: Flags [P.], seq 196:584, ack 1, win 309, options [nop,nop,TS val 76577928 ecr 510771017], length 388 09:56:18.323563 IP 192.168.64.1.56322 > rhel75.localdomain.ssh: Flags [.], ack 584, win 411, options [nop,nop,TS val 510771047 ecr 76577928], length 0 09:56:18.335569 IP gateway.domain > rhel75.56631: 29904 NXDomain* 0/1/0 (103) 09:56:18.336429 IP rhel75.44007 > gateway.domain: 61677+ PTR? 98.122.168.192.in-addr.arpa. (45) 09:56:18.336655 IP gateway.domain > rhel75.44007: 61677* 1/0/0 PTR rhel75. (65) 09:56:18.337177 IP rhel75.localdomain.ssh > 192.168.64.1.56322: Flags [P.], seq 584:1644, ack 1, win 309, options [nop,nop,TS val 76577942 ecr 510771047], length 1060 ---- SKIPPING LONG OUTPUT ----- 09:56:19.342939 IP 192.168.64.1.56322 > rhel75.localdomain.ssh: Flags [.], ack 1752016, win 1444, options [nop,nop,TS val 510772067 ecr 76578948], length 0 ^C 9003 packets captured 9010 packets received by filter 7 packets dropped by kernel Ключ -i показывает что мы захватываем пакеты с определенного (хоть и псевдо) интерфейса. Вы можете прервать захват, нажав Ctrl + C. Как вы видите, мы перехватили OVER 9000 пакетов. Но так много нам не нужно Чтобы ограничить количество перехваченных пакетов и остановить tcpdump, используйте параметр -c: sudo tcpdump -i any -c 5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 11:21:30.242740 IP rhel75.localdomain.ssh > 192.168.64.1.56322: Flags [P.], seq 3772575680:3772575876, ack 3503651743, win 309, options [nop,nop,TS val 81689848 ecr 515883153], length 196 11:21:30.242906 IP 192.168.64.1.56322 > rhel75.localdomain.ssh: Flags [.], ack 196, win 1443, options [nop,nop,TS val 515883235 ecr 81689848], length 0 11:21:30.244442 IP rhel75.43634 > gateway.domain: 57680+ PTR? 1.64.168.192.in-addr.arpa. (43) 11:21:30.244829 IP gateway.domain > rhel75.43634: 57680 NXDomain 0/0/0 (43) 11:21:30.247048 IP rhel75.33696 > gateway.domain: 37429+ PTR? 28.64.168.192.in-addr.arpa. (44) 5 packets captured 12 packets received by filter 0 packets dropped by kernel В этом случае tcpdump прекратил захват автоматически после захвата пяти пакетов. Это полезно в разных сценариях - например, если вы устраняете неполадки с подключением и захватываете несколько начальных пакетов, этого достаточно. Это еще более полезно, когда мы применяем фильтры для захвата определенных пакетов. По умолчанию tcpdump разрешает (ресолвит) IP-адреса и порты в имена, как показано в предыдущем примере. Однако при устранении неполадок в сети часто проще использовать IP-адреса и номера портов. Отключите разрешение имен, используя опцию -n и разрешение портов с -nn: sudo tcpdump -i any -c5 -nn tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 23:56:24.292206 IP 192.168.64.28.22 > 192.168.64.1.35110: Flags [P.], seq 166198580:166198776, ack 2414541257, win 309, options [nop,nop,TS val 615664 ecr 540031155], length 196 23:56:24.292357 IP 192.168.64.1.35110 > 192.168.64.28.22: Flags [.], ack 196, win 1377, options [nop,nop,TS val 540031229 ecr 615664], length 0 23:56:24.292570 IP 192.168.64.28.22 > 192.168.64.1.35110: Flags [P.], seq 196:568, ack 1, win 309, options [nop,nop,TS val 615664 ecr 540031229], length 372 23:56:24.292655 IP 192.168.64.1.35110 > 192.168.64.28.22: Flags [.], ack 568, win 1400, options [nop,nop,TS val 540031229 ecr 615664], length 0 23:56:24.292752 IP 192.168.64.28.22 > 192.168.64.1.35110: Flags [P.], seq 568:908, ack 1, win 309, options [nop,nop,TS val 615664 ecr 540031229], length 340 5 packets captured 6 packets received by filter 0 packets dropped by kernel Как показано выше, вывод захвата теперь отображает IP-адреса и номера портов. Это также не позволяет tcpdump выдавать DNS-запросы, что помогает снизить сетевой трафик при устранении неполадок в сети. Теперь, когда вы можете захватывать сетевые пакеты, давайте рассмотрим, что означает этот вывод. Понимание формата вывода Tcpdump способен захватывать и декодировать множество различных протоколов, таких как TCP, UDP, ICMP и многие другие. Хотя мы не можем охватить все их здесь, чтобы помочь вам начать, давайте рассмотрим пакет TCP. Вы можете найти более подробную информацию о различных форматах протокола на страницах руководства tcpdump. Типичный пакет TCP, захваченный tcpdump, выглядит следующим образом: 08:41:13.729687 IP 192.168.64.28.22 > 192.168.64.1.41916: Flags [P.], seq 196:568, ack 1, win 309, options [nop,nop,TS val 117964079 ecr 816509256], length 372 Поля могут различаться в зависимости от типа отправляемого пакета, но общий формат tcpdump выглядит так: [Timestamp] [Protocol] [Src IP].[Src Port] > [Dst IP].[Dst Port]: [Flags], [Seq], [Ack], [Win Size], [Options], [Data Length] Первое поле, 08:41:13.729687, представляет метку времени полученного пакета согласно местным часам, в форматечасы:минуты:секунды.фракция где фракция - доли секунды с полуночи. Затем IP представляет протокол сетевого уровня - в данном случае IPv4. Для пакетов IPv6 это значение IP6. Следующее поле, 192.168.64.28.22, - это IP-адрес и порт источника. Далее следуют IP-адрес и порт назначения (разделенные точкой), представленные как 192.168.64.1.41916. После источника и назначения вы можете найти флаги TCP Flags [P.]. Типичные значения для этого поля включают в себя: [.] - ACK (Acknowledgment) [S] - SYN (Start Connection) [P] - PSH (Push Data) [F] - FIN (Finish Connection) [R] - RST (Reset Connection) [S.] - SYN-ACK (SynAcK Packet) Далее идет порядковый номер данных, содержащихся в пакете. Для первого захваченного пакета это абсолютное число. Последующие пакеты используют относительное число, чтобы упростить отслеживание. В этом примере последовательность seq 196:568, что означает, что этот пакет содержит байты с 196 по 568 этого потока. За этим следует номер подтверждения: ack 1. В данном случае это 1, поскольку сторона отправляет данные. Для стороны, получающей данные, это поле представляет следующий ожидаемый байт (данные) в этом потоке. Например, номер Ack для следующего пакета в этом потоке будет 568. Следующее поле - это размер окна win 309, который представляет количество байтов, доступных в приемном буфере, за которыми следуют такие параметры TCP, как MSS (максимальный размер сегмента - Maximum Segment Size) или масштаб окна. nop - заполнение, используемое для того, чтобы сделать заголовок TCP кратным 4 байтам. TS val - это временная метка TCP. ecr - обозначает эхо-ответ. Наконец, у нас есть длина пакета, length 372, которая представляет длину в байтах данных полезной нагрузки. Длина - это разница между последним и первым байтами порядкового номера. Теперь давайте узнаем, как фильтровать пакеты, чтобы сузить результаты и упростить устранение конкретных проблем. Фильтрация пакетов Как упоминалось выше, tcpdump может перехватывать слишком много пакетов, некоторые из которых даже не связаны с проблемой, которую вы устраняете. Например, если вы устраняете проблему с подключением к веб-серверу, вас не интересует трафик SSH, поэтому удаление пакетов SSH из выходных данных облегчает работу с реальной проблемой. Одной из самых мощных функций tcpdump является его способность фильтровать захваченные пакеты с использованием различных параметров, таких как IP-адреса источника и назначения, порты, протоколы и так далее. Давайте рассмотрим некоторые из наиболее распространенных. Протокол Для фильтрации пакетов на основе протокола, указав протокол в командной строке. Например, перехватывайте ICMP-пакеты только с помощью этой команды: sudo tcpdump -i any -c5 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes В другом терминале попробуйте пропинговать другой компьютер: ping wiki.merionet.ru PING wiki.merionet.ru(54.204.39.132) 56(84) bytes of data. 64 bytes from ec2-54-204-39-132.compute-1.amazonaws.com (54.204.39.132): icmp_seq=1 ttl=47 time=39.6 ms Вернувшись в захват tcpdump, обратите внимание, что tcpdump захватывает и отображает только пакеты, связанные с ICMP. В этом случае tcpdump не отображает пакеты разрешения имен, которые были сгенерированы при разрешении имени wiki.merionet.ru: 09:34:20.136766 IP rhel75 > ec2-54-204-39-132.compute-1.amazonaws.com: ICMP echo request, id 20361, seq 1, length 64 09:34:20.176402 IP ec2-54-204-39-132.compute-1.amazonaws.com > rhel75: ICMP echo reply, id 20361, seq 1, length 64 09:34:21.140230 IP rhel75 > ec2-54-204-39-132.compute-1.amazonaws.com: ICMP echo request, id 20361, seq 2, length 64 09:34:21.180020 IP ec2-54-204-39-132.compute-1.amazonaws.com > rhel75: ICMP echo reply, id 20361, seq 2, length 64 09:34:22.141777 IP rhel75 > ec2-54-204-39-132.compute-1.amazonaws.com: ICMP echo request, id 20361, seq 3, length 64 5 packets captured 5 packets received by filter 0 packets dropped by kernel Либо, если вы знаете идентификатор протокола, то вы можете использовать фильтр proto. Например, для OSFP пакетов: sudo tcpdump -n proto 89 Хост Ограничьте захват только пакетами, относящимися к определенному хосту, используя фильтр host: sudo tcpdump -i any -c5 -nn host 54.204.39.132 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 09:54:20.042023 IP 192.168.122.98.39326 > 54.204.39.132.80: Flags [S], seq 1375157070, win 29200, options [mss 1460,sackOK,TS val 122350391 ecr 0,nop,wscale 7], length 0 09:54:20.088127 IP 54.204.39.132.80 > 192.168.122.98.39326: Flags [S.], seq 1935542841, ack 1375157071, win 28960, options [mss 1460,sackOK,TS val 522713542 ecr 122350391,nop,wscale 9], length 0 09:54:20.088204 IP 192.168.122.98.39326 > 54.204.39.132.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 122350437 ecr 522713542], length 0 09:54:20.088734 IP 192.168.122.98.39326 > 54.204.39.132.80: Flags [P.], seq 1:113, ack 1, win 229, options [nop,nop,TS val 122350438 ecr 522713542], length 112: HTTP: GET / HTTP/1.1 09:54:20.129733 IP 54.204.39.132.80 > 192.168.122.98.39326: Flags [.], ack 113, win 57, options [nop,nop,TS val 522713552 ecr 122350438], length 0 5 packets captured 5 packets received by filter 0 packets dropped by kernel В этом примере tcpdump захватывает и отображает только пакеты с хоста 54.204.39.132 и на него. Также можно фильтровать не только по одному хосту, но и по целым подсетям. Для этого нужно использовать фильтр net. Например, чтобы вывести только пакеты, относящиеся только к 192.168.1.0/24, нужно использовать: sudo tcpdump -n net 192.168.1 Порт Для фильтрации пакетов на основе желаемой услуги или порта используйте фильтр port. Например, перехватите пакеты, относящиеся к веб-службе HTTP c 80 порта, с помощью этой команды: sudo tcpdump -i any -c5 -nn port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 09:58:28.790548 IP 192.168.122.98.39330 > 54.204.39.132.80: Flags [S], seq 1745665159, win 29200, options [mss 1460,sackOK,TS val 122599140 ecr 0,nop,wscale 7], length 0 09:58:28.834026 IP 54.204.39.132.80 > 192.168.122.98.39330: Flags [S.], seq 4063583040, ack 1745665160, win 28960, options [mss 1460,sackOK,TS val 522775728 ecr 122599140,nop,wscale 9], length 0 09:58:28.834093 IP 192.168.122.98.39330 > 54.204.39.132.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 122599183 ecr 522775728], length 0 09:58:28.834588 IP 192.168.122.98.39330 > 54.204.39.132.80: Flags [P.], seq 1:113, ack 1, win 229, options [nop,nop,TS val 122599184 ecr 522775728], length 112: HTTP: GET / HTTP/1.1 09:58:28.878445 IP 54.204.39.132.80 > 192.168.122.98.39330: Flags [.], ack 113, win 57, options [nop,nop,TS val 522775739 ecr 122599184], length 0 5 packets captured 5 packets received by filter 0 packets dropped by kernel Чтобы захватывать траффик с диапазона портов используйте фильтр portrange, после которого через дефис укажите желаемый диапазон: sudo tcpdump -n portrange 11128-11142 IP адрес или имя хоста отправителя или получателя Вы также можете фильтровать пакеты на основе IP-адреса источника или назначения или имени хоста при помощи фильтра src, после которого нужно указать адрес отправителя. Например, для захвата пакетов с хоста 192.168.122.98: sudo tcpdump -i any -c5 -nn src 192.168.122.98 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 10:02:15.220824 IP 192.168.122.98.39436 > 192.168.122.1.53: 59332+ A? wiki.merionet.ru. (32) 10:02:15.220862 IP 192.168.122.98.39436 > 192.168.122.1.53: 20749+ AAAA? wiki.merionet.ru. (32) 10:02:15.364062 IP 192.168.122.98.39334 > 54.204.39.132.80: Flags [S], seq 1108640533, win 29200, options [mss 1460,sackOK,TS val 122825713 ecr 0,nop,wscale 7], length 0 10:02:15.409229 IP 192.168.122.98.39334 > 54.204.39.132.80: Flags [.], ack 669337581, win 229, options [nop,nop,TS val 122825758 ecr 522832372], length 0 10:02:15.409667 IP 192.168.122.98.39334 > 54.204.39.132.80: Flags [P.], seq 0:112, ack 1, win 229, options [nop,nop,TS val 122825759 ecr 522832372], length 112: HTTP: GET / HTTP/1.1 5 packets captured 5 packets received by filter 0 packets dropped by kernel Обратите внимание, что tcpdump захватывает пакеты с исходящим IP-адресом 192.168.122.98 для нескольких служб, таких как разрешение имен (порт 53) и HTTP (порт 80). Пакеты ответов не отображаются, так как их исходный IP адрес у них отличается. И наоборот, вы можете использовать фильтр dst для фильтрации по IP-адресу или имени хоста: sudo tcpdump -i any -c5 -nn dst 192.168.122.98 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 10:05:03.572931 IP 192.168.122.1.53 > 192.168.122.98.47049: 2248 1/0/0 A 54.204.39.132 (48) 10:05:03.572944 IP 192.168.122.1.53 > 192.168.122.98.47049: 33770 0/0/0 (32) 10:05:03.621833 IP 54.204.39.132.80 > 192.168.122.98.39338: Flags [S.], seq 3474204576, ack 3256851264, win 28960, options [mss 1460,sackOK,TS val 522874425 ecr 122993922,nop,wscale 9], length 0 10:05:03.667767 IP 54.204.39.132.80 > 192.168.122.98.39338: Flags [.], ack 113, win 57, options [nop,nop,TS val 522874436 ecr 122993972], length 0 10:05:03.672221 IP 54.204.39.132.80 > 192.168.122.98.39338: Flags [P.], seq 1:643, ack 113, win 57, options [nop,nop,TS val 522874437 ecr 122993972], length 642: HTTP: HTTP/1.1 302 Found 5 packets captured 5 packets received by filter 0 packets dropped by kernel Сложные выражения Вы также можете комбинировать фильтры с помощью логических операторов and, or и not для создания более сложных выражений. Например, чтобы отфильтровать пакеты с IP-адреса источника 192.168.122.98 и только служебного HTTP, используйте эту команду: sudo tcpdump -i any -c5 -nn src 192.168.122.98 and port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 10:08:00.472696 IP 192.168.122.98.39342 > 54.204.39.132.80: Flags [S], seq 2712685325, win 29200, options [mss 1460,sackOK,TS val 123170822 ecr 0,nop,wscale 7], length 0 10:08:00.516118 IP 192.168.122.98.39342 > 54.204.39.132.80: Flags [.], ack 268723504, win 229, options [nop,nop,TS val 123170865 ecr 522918648], length 0 10:08:00.516583 IP 192.168.122.98.39342 > 54.204.39.132.80: Flags [P.], seq 0:112, ack 1, win 229, options [nop,nop,TS val 123170866 ecr 522918648], length 112: HTTP: GET / HTTP/1.1 10:08:00.567044 IP 192.168.122.98.39342 > 54.204.39.132.80: Flags [.], ack 643, win 239, options [nop,nop,TS val 123170916 ecr 522918661], length 0 10:08:00.788153 IP 192.168.122.98.39342 > 54.204.39.132.80: Flags [F.], seq 112, ack 643, win 239, options [nop,nop,TS val 123171137 ecr 522918661], length 0 5 packets captured 5 packets received by filter 0 packets dropped by kernel Вы можете создавать более сложные выражения, группируя фильтр с круглыми скобками. В этом случае заключите все выражение фильтра в кавычки, чтобы оболочка не перепутала их с выражениями оболочки: sudo tcpdump -i any -c5 -nn "port 80 and (src 192.168.122.98 or src 54.204.39.132)" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 10:10:37.602214 IP 192.168.122.98.39346 > 54.204.39.132.80: Flags [S], seq 871108679, win 29200, options [mss 1460,sackOK,TS val 123327951 ecr 0,nop,wscale 7], length 0 10:10:37.650651 IP 54.204.39.132.80 > 192.168.122.98.39346: Flags [S.], seq 854753193, ack 871108680, win 28960, options [mss 1460,sackOK,TS val 522957932 ecr 123327951,nop,wscale 9], length 0 10:10:37.650708 IP 192.168.122.98.39346 > 54.204.39.132.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 123328000 ecr 522957932], length 0 10:10:37.651097 IP 192.168.122.98.39346 > 54.204.39.132.80: Flags [P.], seq 1:113, ack 1, win 229, options [nop,nop,TS val 123328000 ecr 522957932], length 112: HTTP: GET / HTTP/1.1 10:10:37.692900 IP 54.204.39.132.80 > 192.168.122.98.39346: Flags [.], ack 113, win 57, options [nop,nop,TS val 522957942 ecr 123328000], length 0 5 packets captured 5 packets received by filter 0 packets dropped by kernel В этом примере мы фильтруем пакеты только для службы HTTP (порт 80) и исходящих IP-адресов 192.168.122.98 или 54.204.39.132. Это быстрый способ изучения обеих сторон одного и того же потока. Проверка содержимого пакета В предыдущих примерах мы проверяли только заголовки пакетов на наличие информации, такой как источник, адресаты, порты и так далее. Иногда это все, что нам нужно для устранения проблем с сетевым подключением. Однако иногда нам необходимо проверить содержимое пакета, чтобы убедиться, что в отправляемом сообщении содержится то, что нам нужно, или что мы получили ожидаемый ответ. Чтобы увидеть содержимое пакета, tcpdump предоставляет два дополнительных флага: -X для печати содержимого в шестнадцатеричном формате (HEX) и -A для печати содержимого в ASCII. Например, проверьте HTTP-содержимое веб-запроса следующим образом: sudo tcpdump -i any -c10 -nn -A port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 13:02:14.871803 IP 192.168.122.98.39366 > 54.204.39.132.80: Flags [S], seq 2546602048, win 29200, options [mss 1460,sackOK,TS val 133625221 ecr 0,nop,wscale 7], length 0 E.. 192.168.122.98.39366: Flags [S.], seq 1877348646, ack 2546602049, win 28960, options [mss 1460,sackOK,TS val 525532247 ecr 133625221,nop,wscale 9], length 0 E.. 54.204.39.132.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 133625260 ecr 525532247], length 0 E..4..@.@.....zb6.'....P...Ao..'........... .....R.W................ 13:02:14.911808 IP 192.168.122.98.39366 > 54.204.39.132.80: Flags [P.], seq 1:113, ack 1, win 229, options [nop,nop,TS val 133625261 ecr 525532247], length 112: HTTP: GET / HTTP/1.1 E.....@.@..1..zb6.'....P...Ao..'........... .....R.WGET / HTTP/1.1 User-Agent: Wget/1.14 (linux-gnu) Accept: */* Host: wiki.merionet.ru Connection: Keep-Alive ................ 13:02:14.951199 IP 54.204.39.132.80 > 192.168.122.98.39366: Flags [.], ack 113, win 57, options [nop,nop,TS val 525532257 ecr 133625261], length 0 E..4.F@./.."6.'...zb.P..o..'.......9.2..... .R.a.................... 13:02:14.955030 IP 54.204.39.132.80 > 192.168.122.98.39366: Flags [P.], seq 1:643, ack 113, win 57, options [nop,nop,TS val 525532258 ecr 133625261], length 642: HTTP: HTTP/1.1 302 Found E....G@./...6.'...zb.P..o..'.......9....... .R.b....HTTP/1.1 302 Found Server: nginx Date: Sun, 29 Sep 2019 17:02:14 GMT Content-Type: text/html; charset=iso-8859-1 Content-Length: 207 X-Content-Type-Options: nosniff Location: https://wiki.merionet.ru/ Cache-Control: max-age=1209600 Expires: Sun, 07 Oct 2018 17:02:14 GMT X-Request-ID: v-6baa3acc-bf52-11e8-9195-22000ab8cf2d X-Varnish: 632951979 Age: 0 Via: 1.1 varnish (Varnish/5.2) X-Cache: MISS Connection: keep-alive <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://wiki.merionet.ru/">here</a>.</p> </body></html> ................ 13:02:14.955083 IP 192.168.122.98.39366 > 54.204.39.132.80: Flags [.], ack 643, win 239, options [nop,nop,TS val 133625304 ecr 525532258], length 0 E..4..@.@.....zb6.'....P....o.............. .....R.b................ 13:02:15.195524 IP 192.168.122.98.39366 > 54.204.39.132.80: Flags [F.], seq 113, ack 643, win 239, options [nop,nop,TS val 133625545 ecr 525532258], length 0 E..4..@.@.....zb6.'....P....o.............. .....R.b................ 13:02:15.236592 IP 54.204.39.132.80 > 192.168.122.98.39366: Flags [F.], seq 643, ack 114, win 57, options [nop,nop,TS val 525532329 ecr 133625545], length 0 E..4.H@./.. 6.'...zb.P..o..........9.I..... .R...................... 13:02:15.236656 IP 192.168.122.98.39366 > 54.204.39.132.80: Flags [.], ack 644, win 239, options [nop,nop,TS val 133625586 ecr 525532329], length 0 E..4..@.@.....zb6.'....P....o.............. .....R.................. 10 packets captured 10 packets received by filter 0 packets dropped by kernel Это полезно для устранения проблем с вызовами API, при условии, что вызовы используют простой HTTP. Для зашифрованных соединений этот вывод менее полезен. Сохранение файл Другая полезная функция, предоставляемая tcpdump, - это возможность сохранять захват в файл, чтобы вы могли проанализировать результаты позже. Это позволяет вам захватывать пакеты в пакетном режиме, например, ночью и проверять результаты утром. Это также помогает, когда слишком много пакетов для анализа, поскольку захват в реальном времени может происходить слишком быстро. Чтобы сохранить пакеты в файл, а не отображать их на экране, используйте параметр -w: sudo tcpdump -i any -c10 -nn -w webserver.pcap port 80 [sudo] password for ricardo: tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 10 packets captured 10 packets received by filter 0 packets dropped by kernel Эта команда сохраняет выходные данные в файле с именем webserver.pcap. Расширение .pcap расшифровывается как «packet capture» и является соглашением для этого формата файла. Как показано в этом примере, на экране ничего не отображается, и захват завершается после захвата 10 пакетов, согласно опции -c10. Если вы хотите получить обратную связь, чтобы гарантировать захват пакетов, используйте опцию -v. Tcpdump создает файл в двоичном формате, поэтому вы не можете просто открыть его в текстовом редакторе. Чтобы прочитать содержимое файла, выполните tcpdump с опцией -r: tcpdump -nn -r webserver.pcap reading from file webserver.pcap, link-type LINUX_SLL (Linux cooked) 13:36:57.679494 IP 192.168.122.98.39378 > 54.204.39.132.80: Flags [S], seq 3709732619, win 29200, options [mss 1460,sackOK,TS val 135708029 ecr 0,nop,wscale 7], length 0 13:36:57.718932 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [S.], seq 1999298316, ack 3709732620, win 28960, options [mss 1460,sackOK,TS val 526052949 ecr 135708029,nop,wscale 9], length 0 13:36:57.719005 IP 192.168.122.98.39378 > 54.204.39.132.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 135708068 ecr 526052949], length 0 13:36:57.719186 IP 192.168.122.98.39378 > 54.204.39.132.80: Flags [P.], seq 1:113, ack 1, win 229, options [nop,nop,TS val 135708068 ecr 526052949], length 112: HTTP: GET / HTTP/1.1 13:36:57.756979 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [.], ack 113, win 57, options [nop,nop,TS val 526052959 ecr 135708068], length 0 13:36:57.760122 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [P.], seq 1:643, ack 113, win 57, options [nop,nop,TS val 526052959 ecr 135708068], length 642: HTTP: HTTP/1.1 302 Found 13:36:57.760182 IP 192.168.122.98.39378 > 54.204.39.132.80: Flags [.], ack 643, win 239, options [nop,nop,TS val 135708109 ecr 526052959], length 0 13:36:57.977602 IP 192.168.122.98.39378 > 54.204.39.132.80: Flags [F.], seq 113, ack 643, win 239, options [nop,nop,TS val 135708327 ecr 526052959], length 0 13:36:58.022089 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [F.], seq 643, ack 114, win 57, options [nop,nop,TS val 526053025 ecr 135708327], length 0 13:36:58.022132 IP 192.168.122.98.39378 > 54.204.39.132.80: Flags [.], ack 644, win 239, options [nop,nop,TS val 135708371 ecr 526053025], length 0 Поскольку вы больше не захватываете пакеты непосредственно из сетевого интерфейса, sudo не требуется для чтения файла. Вы также можете использовать любой из фильтров, которые мы обсуждали, чтобы отфильтровать содержимое из файла, так же, как и с данными в реальном времени. Например, проверьте пакеты в файле захвата с исходящего IP-адреса 54.204.39.132, выполнив эту команду: tcpdump -nn -r webserver.pcap src 54.204.39.132 reading from file webserver.pcap, link-type LINUX_SLL (Linux cooked) 13:36:57.718932 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [S.], seq 1999298316, ack 3709732620, win 28960, options [mss 1460,sackOK,TS val 526052949 ecr 135708029,nop,wscale 9], length 0 13:36:57.756979 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [.], ack 113, win 57, options [nop,nop,TS val 526052959 ecr 135708068], length 0 13:36:57.760122 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [P.], seq 1:643, ack 113, win 57, options [nop,nop,TS val 526052959 ecr 135708068], length 642: HTTP: HTTP/1.1 302 Found 13:36:58.022089 IP 54.204.39.132.80 > 192.168.122.98.39378: Flags [F.], seq 643, ack 114, win 57, options [nop,nop,TS val 526053025 ecr 135708327], length 0 Если вы хотите запустить tcpdump в фоновом режиме, добавьте & в конце команды. Заключение Эти основные функции tcpdump помогут вам начать работу с этим мощным и универсальным инструментом. Чтобы узнать больше, посетите веб-сайт tcpdump и справочные страницы. Интерфейс командной строки tcpdump обеспечивает большую гибкость для захвата и анализа сетевого трафика. Если вам нужен графический инструмент для понимания более сложных потоков, посмотрите на Wireshark. Одним из преимуществ Wireshark является то, что он может читать файлы .pcap, захваченные tcpdump. Вы можете использовать tcpdump для захвата пакетов на удаленной машине, у которой нет графического интерфейса пользователя, и проанализировать файл результатов с помощью Wireshark.
img
Определение проблемного пространства Сетевые инженеры часто сталкиваются с проблемой слишком большого трафика для слишком малого канала связи. В частности, почти в каждом пути через сеть одно звено ограничивает весь путь, так же как один перекресток или одна дорога ограничивает поток трафика. Рисунок ниже иллюстрирует это. На рисунке A обменивается данными с G, а B обменивается данными с E. Если каждая из этих пар устройств использует близкую к доступной полосе пропускания на своих локальных каналах ([A, C], [B, C], [F, G] и D, E]), предполагая, что все каналы имеют одинаковую скорость, канал [C, D] будет перегружен трафиком, превратившись в узкую точку в сети. Когда канал перегружен, например канал [C, D] на рисунке ниже, по каналу будет отправлено больше трафика, чем пропускная способность канала. Во время перегрузки сетевое устройство, такое как маршрутизатор или коммутатор, должно определять, какой трафик следует перенаправить, какой отбросить и в каком порядке следует пересылать пакеты. Для решения этой проблемы были созданы различные схемы приоритезации. Управление перегрузкой каналов путем приоритизации одних классов трафика над другими входит в широкий раздел качества обслуживания (QoS). Восприятие QoS среди сетевых инженеров вызывает беспокойство по многим причинам. Например, многие реализации, даже недавние, как правило, не так хорошо продуманы, как могли бы быть, особенно в том, как они настроены и поддерживаются. Кроме того, ранние схемы не всегда работали хорошо, и QoS часто может добавить проблем в сети, а не облегчить их, и, как правило, очень трудно устранить неполадки. По этим причинам, а также из-за того, что конфигурация, необходимая для реализации схем приоритезации, имеет тенденцию к непостижимости, QoS часто считается темным искусством. Чтобы успешно реализовать стратегию QoS, вы должны классифицировать трафик, определить стратегию организации очередей для различных классов трафика и согласованно установить стратегию на всех сетевых устройствах, которые могут испытывать перегрузку каналов. Хотя можно погрузиться во множество различных функций и функций схем и реализаций QoS, результат всегда должен быть одним и тем же. Почему бы просто не сделать линии связи достаточно большими? После обдумывания ценностного предложения QoS очевидной реакцией будет вопрос, почему сетевые инженеры просто не выбирают достаточно большие линии связи, чтобы избежать перегрузки. В конце концов, если бы линии связи были достаточно большими, перегрузка исчезла бы. Если перегрузка исчезнет, исчезнет необходимость отдавать приоритет одному типу трафика над другим. Весь трафик будет доставлен, и все эти досадные проблемы, связанные с недостаточной пропускной способностью, будут устранены. Действительно, избыточное выделение ресурсов, возможно, является лучшим QoS из всех. К сожалению, стратегия избыточного обеспечения не всегда является доступным вариантом. Даже если бы это было так, самые большие доступные каналы связи не могут преодолеть определенные модели трафика. Некоторые приложения будут использовать столько пропускной способности, сколько доступно при передаче данных, создавая точку перегрузки для других приложений, совместно использующих линию связи. Другие будут передавать в микроперерывах, подавляющих сетевые ресурсы в течение короткого времени, и некоторые транспортные механизмы-такие как протокол управления передачей (TCP)-будут намеренно собирать путь время от времени, чтобы определить наилучшую скорость передачи данных. В то время как более крупная линия связи может сократить время существования состояния перегрузки, в некоторых сценариях нет такой вещи, как наличие достаточной полосы пропускания для удовлетворения всех требований. Большинство сетей построены на модели избыточной подписки, когда некоторая совокупная пропускная способность распределяется в определенных узких местах. Например, коммутатор Top of Rack (ToR) в загруженном центре обработки данных может иметь 48 портов 10GbE, обращенных к хостам, но только 4 порта 40GbE, обращенных к остальной части центра обработки данных. Это приводит к коэффициенту переподписки 480:160, который уменьшается до 3:1. Неявно, 160 Гбит/с полосы пропускания центра обработки данных является потенциальным узким местом - точкой перегрузки - для 480 Гбит/с полосы пропускания хоста. И все же соотношение переподписки 3:1 является обычным явлением в схемах коммутации центров обработки данных. Зачем? Окончательный ответ - часто деньги. Часто можно спроектировать сеть, в которой граничные порты соответствуют доступной пропускной способности. Например, в структуре центра обработки данных, приведенной выше, почти наверняка можно добавить достаточную пропускную способность канала, чтобы обеспечить 480 Гбит / с из ToR в структуру, но стоимость вполне может быть непомерно высокой. Сетевой инженер должен учитывать не только стоимость порта и оптоволокна, но и стоимость дополнительного питания, а также стоимость дополнительного охлаждения, необходимого для управления окружающей средой после добавления необходимых дополнительных устройств, и даже затраты дополнительного места в стойке и веса пола. Затраты денег на обеспечение более высокой пропускной способности сети также могут быть трудно оправданы, если сеть редко перегружена. Некоторые события перегрузки не являются достаточно частыми, чтобы оправдать дорогостоящее обновление сети. Будет ли город тратить миллионы или миллиарды долларов на улучшение транспортной инфраструктуры, чтобы облегчить движение раз в год, когда политик приезжает с визитом? Нет. Вместо этого для решения проблемы с трафиком вносятся другие корректировки. Например, компании могут наиболее остро столкнуться с этим ограничением в глобальных сетях, где каналы арендуются у поставщиков услуг (SP). Частично поставщики услуг зарабатывают деньги на объединении разрозненных географических регионов для организаций, которые не могут позволить себе прокладывать и использовать оптоволоконные кабели большой протяженности самостоятельно. Эти линии дальней связи обычно предлагают гораздо более низкую пропускную способность, чем более короткие, местные линии связи в одном кампусе или даже в одном здании. Высокоскоростное соединение в университетском городке или центре обработки данных может легко перегрузить более медленные каналы дальней связи. Организации будут устанавливать максимально возможные размеры дальних (таких как межсайтовые или даже межконтинентальные) линий связи, но, опять же, важно помнить о деньгах. В мире избыточной подписки и последующих точек перегруженности, а также временных моделей трафика, которые требуют тщательного управления, схемы приоритизации трафика QoS всегда будут необходимы. Классификация Схемы приоритизации QoS действуют на различные классы трафика, но что такое класс трафика и как он определяется? Классы трафика представляют собой агрегированные группы трафика. Потоки данных из приложений, требующих аналогичной обработки или представляющих аналогичные схемы трафика в сети, помещаются в группы и управляются политикой QoS (или классом обслуживания, CoS). Эта группировка имеет решающее значение, поскольку было бы трудно определить уникальные политики QoS для потенциально бесконечного числа приложений. С практической точки зрения сетевые инженеры обычно группируют трафик в четыре класса. Конечно, возможны и другие классы, и такие схемы существуют в производственных сетях. Однако управление системой классификации и политическими действиями становится все более утомительным по мере того, как число классов превышает четыре. Каждый пакет может быть отнесен к определенной CoS на основе адреса источника, адреса назначения, порта источника, порта назначения, размера пакета и других факторов. Предполагая, что каждое приложение имеет свой собственный профиль или набор характеристик, каждое приложение может быть помещено в определенный CoS и действовать в соответствии с локальной политикой QoS. Проблема с этим методом классификации трафика заключается в том, что классификация является только локально значимой-действие классификации относится только к устройству, выполняющему классификацию. Такая классификация пакетов требует много времени, а обработка каждого пакета потребует больших вычислительных ресурсов. Поэтому лучше не повторять эту обработку на каждом устройстве, через которое проходит пакет. Вместо этого лучше один раз классифицировать трафик, пометить пакет в этой единственной точке и действовать в соответствии с этой маркировкой на каждом последующем переходе в сети. Примечание: Несмотря на то, что пакеты и кадры в сети различны, в этой статье будет использоваться термин пакеты. Были разработаны и стандартизированы различные схемы маркировки, такие как 8-битное поле типа обслуживания (ToS), включенное в заголовок Интернет-протокола версии 4 (IPv4). Версия 6 того же протокола (IPv6) включает 8-битовое поле класса трафика, служащее аналогичной цели. Кадры Ethernet используют 3-битное поле как часть спецификации 802.1p. На рисунке показано поле ToS IPv4. В наилучшей сетевой практике классификация трафика должна приводить к одному действию и только к одному действию-маркировке. Когда пакет помечен, присвоенное значение может сохраняться и действовать на протяжении всего пути следования пакета по сетевому пути. Классификация и последующая маркировка должны быть "одноразовым" событием в жизни пакета. Лучшая практика QoS - рекомендуется маркировать трафик, как близко к источнику, насколько это возможно. В идеале трафик будет помечен в точке входа в сеть. Например, трафик, поступающий в сетевой коммутатор с персонального компьютера, телефона, сервера, устройства Интернета вещей и т. д. будет помечена, и метка будет служить классификатором трафика на пути следования пакета по сети. Альтернативная схема классификации и маркировки трафика входящим сетевым устройством заключается в том, что приложение само маркирует свой собственный трафик. Другими словами, пакет отправляется с уже заполненным байтом ToS. Это поднимает проблему доверия. Следует ли разрешить приложению ранжировать собственную важность? В худшем случае все приложения эгоистично помечают свои пакеты значениями, указывающими наивысшую возможную важность. Если каждый пакет помечен как очень важный, то на самом деле ни один пакет не является особо важным. Чтобы один пакет был более важным, чем любой другой, должна быть дифференциация. Классы трафика должны иметь разные уровни важности, чтобы схемы приоритезации QoS имели какое-либо значение. Для сохранения контроля над классификацией трафика все сети, реализующие QoS, имеют границы доверия. Границы доверия позволяют сети избежать ситуации, когда все приложения помечают себя как важные. Представьте, что произошло бы на перегруженной дороге, если бы у каждого автомобиля были мигающие аварийные огни - действительно важные автомобили не выделялись бы. В сети некоторым приложениям и устройствам доверяют отмечать свой собственный трафик. Например, IP-телефонам обычно доверяют соответствующим образом маркировать свой потоковый голосовой трафик и трафик протокола управления, то есть метки, которые IP-телефоны применяют к своему трафику, принимаются входным сетевым устройством. Другие конечные точки или приложения могут быть ненадежными, что означает, что байт ToS пакета стирается или перезаписывается при входе. По умолчанию большинство сетевых коммутаторов стирают метки, отправленные им, если они не настроены на доверие определенным устройствам. Например, производителям, помещенным в пакет сервером, часто доверяют, а маркировкам, установленным конечным хостом, - нет. На рисунке ниже показана граница доверия. На рисунке 3 пакеты, передаваемые B, помечены AF41. Поскольку эти пакеты исходят от хоста в домене доверия QoS, маркировка остается, пока они проходят через D. Пакеты, исходящие от A, помечаются EF; однако, поскольку A находится за пределами доверенного домена QoS, эта маркировка удаляется в D. Пакеты в пределах доверенного домена, исходящие из A, рассматриваются как немаркированные с точки зрения QoS. Маркировка протокола физического уровня и верхнего уровня может быть связана, а может и не быть. Например, маркировка верхнего уровня может быть скопирована в маркировку нижнего уровня, или маркировка нижнего уровня может быть перенесена через сеть, или маркировка нижнего уровня может быть удалена. Существует множество различных возможных реализаций, поэтому вы должны быть осторожны, чтобы понять, как маркировка обрабатывается на разных уровнях, а также на каждом переходе. Хотя операторы сети могут использовать любые значения, которые они выбирают в байте ToS для создания различных классов трафика, часто лучше придерживаться некоторых стандартов, таких как значения, определенные стандартами IETF RFC. Эти стандарты были определены для того, чтобы дать сетевым инженерам логическую схему, позволяющую надлежащим образом различать множество различных классов трафика. Две из этих схем "Per Hop Behavior" появляются в RFC2597, Assured Forwarding (AF), и RFC3246, Expedited Forwarding (EF), а также в различных других RFC, обновляющих или уточняющих содержание этих основополагающих документов. Оба эти RFC определяют схемы маркировки трафика, включая точные значения битов, которые должны заполнять байт ToS или байт класса трафика IP-заголовка, чтобы указать конкретный тип трафика. Они известны как точки кода дифференцированного обслуживания или значения DSCP. Например, схема гарантированной пересылки RFC2597 определяет 12 значений в побитовой иерархической схеме для заполнения восьми битов в поле байта ToS. Первые три бита используются для идентификации класса, а вторые три бита определяют приоритет отбрасывания. Последние два бита не используются. Таблица 1 иллюстрирует маркировку кода для нескольких классов AF. В таблице 1 показано значение бита DSCP для AF11, трафика класса 1 с низким приоритетом отбрасывания, равным 001 010, где "001" обозначает класс 1, а "010" обозначает приоритет отбрасывания. Изучение таблицы более глубоко раскрывает бинарный паттерн, выбранный авторами RFC. Весь трафик класса 1 помечается 001 в первых трех битах, весь класс 2-010 в первых трех битах и т. д. Весь трафик с низким приоритетом отбрасывания помечается 010 во-вторых трех битах, весь трафик со средним приоритетом отбрасывания-100 во-вторых трех битах и т. д. Схема гарантированной пересылки показана в таблице 2 для примера. Это не исчерпывающий список кодовых точек, используемых при классификации трафика QoS. Например, схема выбора класса, описанная в RFC2474, существует для обратной совместимости со схемой маркировки приоритета IP. Приоритет IP использует только первые три бита байта ToS, всего восемь возможных классов. Селектор классов также использует восемь значений, заполняя первые три бита шестибитового поля DSCP значимыми значениями (соответствующими устаревшей схеме приоритета IP), а последние три бита - нулями. В таблице 2 показаны эти селекторы классов. RFC3246 определяет требования к задержке, потерям и джиттеру трафика, который должен быть перенаправлен быстро, вместе с единственной новой кодовой точкой - EF, которой присвоено двоичное значение 101 110 (десятичное 46). Количество и разнообразие формально определенных значений DSCP может показаться ошеломляющим. Комбинированные определения AF, CS и EF сами по себе приводят к формальным определениям для 21 различных классов из возможных 64, использующих шесть битов поля DSCP. Ожидается ли, что сетевые инженеры будут использовать все эти значения в своих схемах приоритезации QoS? Следует ли разбивать трафик с такой высокой степенью детализации для эффективного QoS? На практике большинство схем QoS ограничиваются от четырех до восьми классов трафика. Различные классы позволяют обрабатывать каждую группу по-своему во время перегрузки. Например, один класс трафика может быть сформирован так, чтобы соответствовать определенному порогу пропускной способности. Другой класс трафика может иметь приоритет над всем остальным трафиком. Еще один может быть определен как критически важный для бизнеса или трафик, который важнее большинства, но менее важен, чем некоторые. Трафик сетевого протокола, критичный для стабильности инфраструктуры, можно рассматривать как очень высокий приоритет. Класс трафика scavenger может находиться в конце списка приоритетов, получая немного больше внимания, чем немаркированный трафик. Схема, включающая эти значения, вероятно, будет представлять собой сочетание кодовых точек, определенных в различных RFC, и может несколько отличаться от организации к организации. Обычно принятые значения включают EF для критического трафика с требованием своевременности, например VoIP, и CS6 для трафика управления сетью, такого как протоколы маршрутизации и резервирования на первом этапе. Немаркированный трафик (т.е. значение DSCP, равное 0) доставляется по принципу "максимальных усилий", без каких-либо гарантий уровня обслуживания (обычно это считается классом scavenger, как указано выше).
img
В статье рассматриваются примеры протоколов, обеспечивающих Interlayer Discovery и назначение адресов. Первую часть статьи про Interlayer Discovery можно прочитать тут. Domain Name System DNS сопоставляет между собой человекочитаемые символьные строки, такие как имя service1. exemple, используемый на рисунке 1, для IP-адресов. На рисунке 3 показана основная работа системы DNS. На рисунке 3, предполагая, что нет никаких кэшей любого вида (таким образом, весь процесс проиллюстрирован): Хост A пытается подключиться к www.service1.example. Операционная система хоста проверяет свою локальную конфигурацию на предмет адреса DNS-сервера, который она должна запросить, чтобы определить, где расположена эта служба, и находит адрес рекурсивного сервера. Приложение DNS операционной системы хоста отправляет DNS-запрос на этот адрес. Рекурсивный сервер получает этот запрос и - при отсутствии кешей - проверяет доменное имя, для которого запрашивается адрес. Рекурсивный сервер отмечает, что правая часть имени домена именуется example, поэтому он спрашивает корневой сервер, где найти информацию о домене example. Корневой сервер возвращает адрес сервера, содержащий информацию о домене верхнего уровня (TLD) example. Рекурсивный сервер теперь запрашивает информацию о том, с каким сервером следует связаться по поводу service1.example. Рекурсивный сервер проходит через доменное имя по одному разделу за раз, используя информацию, обнаруженную в разделе имени справа, чтобы определить, какой сервер следует запросить об информации слева. Этот процесс называется рекурсией через доменное имя; следовательно, сервер называется рекурсивным сервером. Сервер TLD возвращает адрес полномочного сервера для service1.example. Если информация о местонахождении службы была кэширована из предыдущего запроса, она возвращается как неавторизованный ответ; если фактический сервер настроен для хранения информации об ответах домена, его ответ является авторитетным. Рекурсивный сервер запрашивает информацию о www.service1.example у полномочного сервера. Авторитетный сервер отвечает IP-адресом сервера B. Рекурсивный сервер теперь отвечает хосту A, сообщая правильную информацию для доступа к запрошенной службе. Хост A связывается с сервером, на котором работает www.service1.example, по IP-адресу 2001:db8:3e8:100::1. Этот процесс может показаться очень затяжным; например, почему бы просто не сохранить всю информацию на корневом сервере, чтобы сократить количество шагов? Однако это нарушит основную идею DNS, которая заключается в том, чтобы держать информацию о каждом домене под контролем владельца домена в максимально возможной степени. Кроме того, это сделало бы создание и обслуживание корневых серверов очень дорогими, поскольку они должны были бы иметь возможность хранить миллионы записей и отвечать на сотни миллионов запросов информации DNS каждый день. Разделение информации позволяет каждому владельцу контролировать свои данные и позволяет масштабировать систему DNS. Обычно информация, возвращаемая в процессе запроса DNS, кэшируется каждым сервером на этом пути, поэтому сопоставление не нужно запрашивать каждый раз, когда хосту необходимо достичь нового сервера. Как обслуживаются эти таблицы DNS? Обычно это ручная работа владельцев доменов и доменов верхнего уровня, а также пограничных провайдеров по всему миру. DNS не определяет автоматически имя каждого объекта, подключенного к сети, и адрес каждого из них. DNS объединяет базу данных, обслуживаемую вручную, с распределением работы между людьми, с протоколом, используемым для запроса базы данных; следовательно, DNS попадает в базу данных сопоставления с классом протоколов решений. Как хост узнает, какой DNS-сервер запрашивать? Эта информация либо настраивается вручную, либо изучается с помощью протокола обнаружения, такого как IPv6 ND или DHCP. DHCP Когда хост (или какое-либо другое устройство) впервые подключается к сети, как он узнает, какой IPv6-адрес (или набор IPv6-адресов) назначить локальному интерфейсу? Одним из решений этой проблемы является отправка хостом запроса в какую-либо базу данных, чтобы определить, какие адреса он должен использовать, например DHCPv6. Чтобы понять DHCPv6, важно начать с концепции link local address в IPv6. При обсуждении размера адресного пространства IPv6, fe80:: / 10 был назван зарезервированным для link local address. Чтобы сформировать link local address, устройство с IPv6 объединяет префикс fe80:: с MAC (или физическим) адресом, который часто форматируется как адрес EUI-48, а иногда как адрес EUI-64. Например: Устройство имеет интерфейс с адресом EUI-48 01-23-45-67-89-ab. Этот интерфейс подключен к сети IPv6. Устройство может назначить fe80 :: 123: 4567: 89ab в качестве link local address и использовать этот адрес для связи с другими устройствами только в этом сегменте. Это пример вычисления одного идентификатора из другого. После того, как link local address сформирован, DHCP6 является одним из методов, который можно использовать для получения уникального адреса в сети (или глобально, в зависимости от конфигурации сети). DHCPv6 использует User Datagram Protocol (UDP) на транспортном уровне. Рисунок 4 иллюстрирует это. Хост, который только что подключился к сети, A, отправляет сообщение с запросом. Это сообщение поступает с link local address и отправляется на multicast address ff02 :: 1: 2, порты UDP 547 (для сервера) и 546 (для клиента), поэтому каждое устройство, подключенное к одному и тому же физическому проводу, получит сообщение. Это сообщение будет включать уникальный идентификатор DHCP (DUID), который формирует клиент и использует сервер, чтобы обеспечить постоянную связь с одним и тем же устройством. B и C, оба из которых настроены для работы в качестве серверов DHCPv6, отвечают рекламным сообщением. Это сообщение является одноадресным пакетом, направленным самому A с использованием link local address, из которого A отправляет запрашиваемое сообщение. Хост A выбирает один из двух серверов, с которого запрашивать адрес. Хост отправляет запрос на multicast address ff02 :: 1: 2, прося B предоставить ему адрес (или пул адресов), информацию о том, какой DNS-сервер использовать, и т. д. Сервер, работающий на B, затем отвечает ответом на изначально сформированный link local address A; это подтверждает, что B выделил ресурсы из своего локального пула, и позволяет A начать их использование. Что произойдет, если ни одно устройство в сегменте не настроено как сервер DHCPv6? Например, на рисунке 4, что, если D - единственный доступный сервер DHCPv6, потому что DHCPv6 не работает на B или C? В этом случае маршрутизатор (или даже какой-либо другой хост или устройство) может действовать как ретранслятор DHCPv6. Пакеты DHCPv6, которые передает A, будут приняты ретранслятором, инкапсулированы и переданы на сервер DHCPv6 для обработки. Примечание. Описанный здесь процесс называется DHCP с отслеживанием состояния и обычно запускается, когда в объявлении маршрутизатора установлен бит Managed. DHCPv6 может также работать с SLAAC, для предоставления информации, которую SLAAC не предоставляет в режиме DHCPv6 без сохранения состояния. Этот режим обычно используется, когда в объявлении маршрутизатора установлен бит Other. В тех случаях, когда сетевой администратор знает, что все адреса IPv6 будут настроены через DHCPv6, и только один сервер DHCPv6 будет доступен в каждом сегменте, сообщения с объявлением и запросом можно пропустить, включив быстрое принятие DHCPv6. А теперь почитайте про Address Resolution Protocol - протокол разрешения IPv4-адресов
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59