Отслеживание и диагностика трафика на сетевых интерфейсах с помощью утилиты tcpdump

Часто при отладке какой-нибудь сетевой схемы можно столкнуться с ситуацией, когда всё настроено правильно, однако трафик по какой-то причине не идёт или нет подключения на какой-то порт роутера. В этом случае для определения причин данных проблем необходимо провести диагностику сети.

В роутерах RTU существует возможность отслеживать прохождение и направление трафика по всем интерфейсам, либо по каждому в отдельности с помощью tcpdump.

В данной статье будут описаны некоторые команды использования tcpdump.

Рассмотрим следующую схему подключения:

Схема подключения

На примере данной схемы будут рассмотрены команды tcpdump.

Просмотреть трафик со всех интерфейсов можно командой tcpdump:

Команда tcpdump

Однако, в этом случае, будет показан весь трафик со всех интерфейсов, что может мешать просматривать какой-то конкретный трафик. В этом случае можно указать в команду, какой именно трафик нужно показывать.

Просмотрим подключение на 80-й порт RTU с хоста 172.26.19.16:

tcpdump -i 3g-internet port 80 and host 172.26.19.16

Где, -i 3g-internet - название Wan интерфейса.

Попробуем подключиться на порт 80 роутера RTU с помощью утилиты "Netcat":

root@LT40:~# nc 172.26.19.15 80
nc: can't connect to remote host (172.26.19.15): Connection refused
root@LT40:~#

Как видим, подключение было отклонено.

Посмотрим, что происходит на порту 80 на RTU1068:

root@RTUx68:~# tcpdump -i 3g-internet port 80 and host 172.26.19.16
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 3g-internet, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
07:07:04.484750 IP 172.26.19.16.53184 > 172.26.19.15.80: Flags [S], seq 3130758208, win 29200, options [mss 1460,sackOK,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,wscale 5], length 0
07:07:04.503751 IP 172.26.19.15.80 > 172.26.19.16.53184: Flags [R.], seq 0, ack 3130758209, win 0, length 0
2 packets captured
3 packets received by filter
0 packets dropped by kernel
root@RTUx68:~#

RTU получил от LT пакет установки соединения с флагом SYN, в правиле данный флаг указан как [S]. Однако RTU отклонил соединение, отправив ответ с флагом RST: в правиле данный флаг указан как [R.].

В данном случае такое поведение было вызвано тем, что порт 80 на RTU1068 закрыт и входящее соединение было отклонено политикой по умолчанию "REJECT", с отправкой удалённой стороне ICMP сообщения о недоступности порта.

Если политикой по умолчанию будет стоять DROP, RTU1068 будет отклонять подключение и не будет отправлять ответ ICMP о недоступности порта.

С помощью tcpdump можно просматривать трафик, фильтруя его по протоколам:

Попробуем отследить передачу GRE пакетов на Wan интерфейсе:

Выполним пинг с LT40 на RTU1068 через GRE тоннель:

root@LT40:~# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=752.683 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=89.256 ms
64 bytes from 10.0.0.1: seq=2 ttl=64 time=188.509 ms
64 bytes from 10.0.0.1: seq=3 ttl=64 time=207.885 ms
^C
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 89.256/309.583/752.683 ms

Просмотрим трафик GRE на RTU с помощью команды:

tcpdump -i 3g-internet proto gre

root@RTUx68:~# tcpdump -i 3g-internet proto gre
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on 3g-internet, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
08:24:33.059063 IP 172.26.19.16 > 172.26.19.15: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 26394, seq 0, length 64
08:24:33.086216 IP 172.26.19.15 > 172.26.19.16: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 26394, seq 0, length 64
08:24:33.431356 IP 172.26.19.16 > 172.26.19.15: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 26394, seq 1, length 64
08:24:33.439461 IP 172.26.19.15 > 172.26.19.16: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 26394, seq 1, length 64
08:24:34.540031 IP 172.26.19.16 > 172.26.19.15: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 26394, seq 2, length 64
08:24:34.549479 IP 172.26.19.15 > 172.26.19.16: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 26394, seq 2, length 64
08:24:35.500180 IP 172.26.19.16 > 172.26.19.15: GREv0, length 88: IP 10.0.0.2 > 10.0.0.1: ICMP echo request, id 26394, seq 3, length 64
08:24:35.538593 IP 172.26.19.15 > 172.26.19.16: GREv0, length 88: IP 10.0.0.1 > 10.0.0.2: ICMP echo reply, id 26394, seq 3, length 64
8 packets captured
8 packets received by filter
0 packets dropped by kernel
root@RTUx68:~#

Некоторые протоколы не требуют указывания proto в команде, и достаточно подать следующую команду:

tcpdump -i 3g-internet esp

или

tcpdump -i 3g-internet tcp

Таким образом, tcpdump позволяет более детально просматривать трафик на интерфейсах, что упрощает мониторинг и поиск неисправностей при отладке сети.