Я отслеживаю ссылку 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-запрос или ответ.