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 в шестнадцатеричном формате просто не должно быть. И я совершенно уверен, что отправитель этого не отправляет. Кто-нибудь знает, что это такое или может быть?
с уважением Alex
Для протокола, это был http/грузовой трафик, и то, что я вижу, это заголовок кусочка. При открытии в wireshark, эти пакеты будут перечислены как TCP-сегмент собранного PDU. Перейдя к последнему пакету вызова, wireshark расшифрует http трафик для нас, сообщив, что 2000 ASCII = 8192 (целое число), размер чанка. Не имеет отношения к openvpn, и вообще не является ошибкой ;)
.Я подозреваю, что 1) ваша уверенность неуместна и 2) что пакет является продолжением HTTP запроса или ответа от более раннего TCP сегмента в том же направлении по тому же самому соединению, так что даже если это не выглядит как что-то, что будет отправлено отправителем, это часть чего-то, что будет отправлено отправителем.
Попробуйте включить TCP сборку для HTTP, если это еще не включено. Откройте Параметры (Редактирование -> Параметры или, если это Wireshark 2.x в OS X, Wireshark -> Параметры), откройте Протоколы, выберите TCP, убедитесь, что "Разрешить поддиссектору собирать TCP потоки" отмечен, затем выберите HTTP и убедитесь, что "Повторная сборка HTTP заголовков, охватывающих несколько TCP сегментов" и "Повторная сборка HTTP тел, охватывающих несколько TCP сегментов" отмечен оба. Затем он должен собрать все части запроса HTTP или ответ, включая этот текст, и показать его вам, как собранный запрос HTTP или ответ.
.