Назад | Перейти на главную страницу

tcpdump http, содержащий непредвиденные байты полезной нагрузки

Я отслеживаю ссылку openvpn с помощью tcpdump а-ля tcpdump -i tun5 -w capture.dump -W 100 -C 100M -s 0 -n По этой ссылке проходит http / xml-трафик, который в основном закаптирован. Однако некоторые пакеты содержат байты, которых я не ожидал. См. Этот пример:

No.     Time           Source                Destination           Protocol Length Info
     15 0.021249       10.150.1.7            10.150.9.6            TCP      1355   8180 → 53327 [ACK] Seq=32056 Ack=1 Win=513 Len=1315

Frame 15: 1355 bytes on wire (10840 bits), 1355 bytes captured (10840 bits)
Raw packet data
Internet Protocol Version 4, Src: 10.150.1.7, Dst: 10.150.9.6
Transmission Control Protocol, Src Port: 8180 (8180), Dst Port: 53327 (53327), Seq: 32056, Ack: 1, Len: 1315

0000   45 00 05 4b 6a c8 40 00 7f 06 6c ac 0a 96 01 07  E..Kj.@...l.....
0010   0a 96 09 06 1f f4 d0 4f ff 91 41 fc b2 6c 8e b9  .......O..A..l..
0020   50 10 02 01 8c fc 00 00 65 63 74 65 64 41 72 72  P.......ectedArr
0030   69 76 61 0d 0a 32 30 30 30 0d 0a 6c 54 69 6d 65  iva..2000..lTime
0040   3e 32 30 31 36 2d 30 33 2d 31 31 54 31 33 3a 31  >2016-03-11T13:1
0050   32 3a 34 37 2b 30 32 3a 30 30 3c 2f 45 78 70 65  2:47+02:00</Expe
0060   63 74 65 64 41 72 72 69 76 61 6c 54 69 6d 65 3e  ctedArrivalTime>
0070   0a 20 20 20 20 20 20 20 20 20 20 20 20 3c 2f 4f  .            </O
0080   6e 77 61 72 64 43 61 6c 6c 3e 0a 20 20 20 20 20  nwardCall>
[...]

В самом начале у нас есть в ASCII:

ectedArriva..2000..lTime> 2016-03-11T13: 12: 47 + 02: 00 ....

Этого "..2000 .." или 61 0d 0a 32 30 30 30 0d 0a в шестнадцатеричном формате просто не должно быть. И я совершенно уверен, что отправитель этого не отправляет. Кто-нибудь знает, что это такое или может быть?

С уважением, Алекс

Для записи, это был http / chunked трафик, и я вижу заголовок chunk. При открытии в wirehark эти пакеты будут перечислены как сегменты TCP повторно собранного PDU. Переходя к последнему пакету вызова, wirehark декодирует для нас HTTP-трафик, сообщая нам, что 2000 ASCII = 8192 (целое число), размер блока. Не имеет отношения к openvpn и совсем не баг;)

Я подозреваю, что 1) ваша уверенность неуместна и 2) этот пакет является продолжением HTTP-запроса или ответа от более раннего сегмента TCP в том же направлении в том же соединении, поэтому даже если он не похож на то, что было бы отправлено отправителем, это часть чего-то, что будет отправлено отправителем.

Попробуйте включить повторную сборку TCP для HTTP, если она еще не включена. Откройте настройки (Edit -> Preferences или, если это Wireshark 2.x в OS X, Wireshark -> Preferences), откройте Protocols, выберите TCP, убедитесь, что установлен флажок «Allow subdissector to reassemble TCP streams», затем выберите HTTP и убедитесь, что отмечены флажки «Повторная сборка заголовков HTTP, охватывающих несколько сегментов TCP» и «Повторная сборка тел HTTP, охватывающих несколько сегментов TCP». Затем он должен повторно собрать все части HTTP-запроса или ответа, включая этот текст, и показать его вам как повторно собранный HTTP-запрос или ответ.