Estou monitorando um link openvpn com o tcpdump a la tcpdump -i tun5 -w capture.dump -W 100 -100M -s 0 -n Existe um tráfego http / xml passando por esse link que é basicamente muito bom. No entanto, alguns pacotes contêm bytes que eu não esperava. Veja este exemplo:
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 [email protected].....
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>
[...]
Apenas no começo, temos em ASCII:
ectArriva..2000..lTime > 2016-03-11T13: 12: 47 + 02: 00 ....
Este "..2000 .." ou 61 0d 0a 32 30 30 30 0d 0a em hexadecimal não deveria estar lá. E estou certo de que o remetente não envia isso. Alguém tem idéia do que é ou poderia ser?
considera Alex
Para o registro, este foi o tráfego http / chunked e o que estou vendo é o cabeçalho do chunk. Ao abrir no wireshark, ele listará esses pacotes como um segmento TCP de uma PDU remontada. Indo para o último pacote da chamada, o wireshark irá decodificar o tráfego http para nós, informando que 2000 ASCII = 8192 (inteiro), o tamanho do bloco. Não relacionado ao openvpn, e nem um bug;)
Eu suspeito que 1) a sua certeza é equivocada e 2) que o pacote é uma continuação de uma solicitação ou resposta HTTP de um segmento TCP anterior na mesma direção na mesma conexão, então mesmo que não pareça algo que seria enviado pelo remetente, é parte de algo que seria enviado pelo remetente.
Tente ativar a remontagem TCP para HTTP, se ainda não estiver ativada. Abra Preferências (Editar - > Preferências ou, se for Wireshark 2.x no OS X, Wireshark - > Preferências), abra os Protocolos, selecione TCP, certifique-se de que "Permitir subdissector para remontar os fluxos TCP" esteja marcada, então selecione HTTP e verifique se "Remontar cabeçalhos HTTP abrangendo vários segmentos TCP" e "Remontar corpos HTTP abrangendo vários segmentos TCP" estão marcados. Em seguida, ele deve remontar todas as partes da solicitação ou resposta HTTP incluindo esse texto e mostrá-lo a você como uma solicitação ou resposta HTTP reagrupada.