Помогите, Уважаемые. Что-то у меня лыжи уже 3-й день не едут с расшифровкой одного значения пакета, перехваченного tcpdump-ом.клиент подключается по VPN (Linux, poptop, шифрование не используетя).
схема соединения:
[CLIENT 192.168.0.2 (192.168.10.2)]<->
[192.168.0.1 (192.168.200.1) SERVER NAT]<->
[77.234.201.242 OPENNET.RU]в круглых скобках указанны адреса, используемые для текущего VPN-соединения.
ловим пакет на ethernet-интерфейсе, ч/з который подключен VPN-клиент:
tcpdump -t -n -e -i eth1 -X "dst host 192.168.0.2 and proto 47"
00:14:d1:52:78:e4 > 00:17:31:58:dc:fd, ethertype IPv4 (0x0800), length 317: IP 192.168.0.1 > 192.168.0.2: call 0 seq 2293 gre-ppp-payload
0x0000: 4500 012f be49 4000 402f fa02 c0a8 0001 E../.I@.@/......
0x0010: c0a8 0002 3001 880b 010f 0000 0000 08f5 ....0...........
0x0020: 2145 0001 0e97 d140 0035 06ca 914d eac9 !E.....@.5...M..
0x0030: f2c0 a80a 0200 509e 64e2 6f8c fd26 95ac ......P.d.o..&..
0x0040: 0250 18ff ff90 cd00 0048 5454 502f 312e .P.......HTTP/1.
0x0050: 3120 1.анализируем:
-----------------------------
IP
-----------------------------0x0000: 45..
=>
- версия протокола 4
- длина заголовка 5-ть 32-х битных слов (т.е заголовок без опциональных полей).=>
данные заголовка:
0x0000: 4500 012f be49 4000 402f fa02 c0a8 0001
0x0010: c0a8 0002как и ожидалось:
инкапсуляция = 0x2f = 47 (GRE)
IP src = 0xc0 a8 00 01 = 192.168.0.1
IP dst = 0xc0 a8 00 02 = 192.168.0.2-----------------------------
GRE:
-----------------------------0x0010: .... .... 3001
=>
SF = 0x30 >> 4 & 1 = 1 (+2 слова к заголовку)
AF = 0x01 >> 7 & 1 = 0 (+0 слов к заголовку)=>
данные заголовка:
0x0010: .... .... 3001 880b 010f 0000 0000 08f5версия GRE = 0x01 & 7 = 1
инкапсуляция = 0x880b = PPP
...-----------------------------
ВНИМАНИЕ - ВОПРОС!!!
-----------------------------0x0020: 21.. сразу после заголовка GRE.
уже тучу RFC перерыл и инета...
собственно с расшифровкой этого значения и застопорился. что за 0x21, откуда оно берется, что значит и какому заголовку относится?
по идее на этом месте должен быть PPP-заголовок?
далее опять все понятно и ожидаемо...
-----------------------------
IP
-----------------------------0x0020: ..45
=>
- версия протокола 4
- длина заголовка 5-ть слов=>
данные заголовка:
0x0020: ..45 0001 0e97 d140 0035 06ca 914d eac9
0x0030: f2c0 a80a 02..инкапсуляция = 0x06 = 6 (TCP)
IP src = 0x4d ea c9 f2 = 77.234.201.242
IP dst = 0xc0 a8 0a 02 = 192.168.10.2-----------------------------
TCP
-----------------------------src port = 0x0050 = 80
...собственно вот этот байт 0x21 @ 0x0020 никуда приткнуть и не могу. остальные поля во всех заголовках нормально расшифровываются, хоть я их и не приводил.
подскажите, где я лыжи не смазал?
up.
http://www.faqs.org/rfcs/rfc1661.html
http://www.faqs.org/rfcs/rfc1332.html
> http://www.faqs.org/rfcs/rfc1661.html
> http://www.faqs.org/rfcs/rfc1332.htmlа зачем вы все это делаете???я вот вообще первый раз вижу, что кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные значения, что чему соответствует, где читали? интересно было бы почитать
>> http://www.faqs.org/rfcs/rfc1661.html
>> http://www.faqs.org/rfcs/rfc1332.html
> а зачем вы все это делаете???я вот вообще первый раз вижу, что
> кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные
> значения, что чему соответствует, где читали? интересно было бы почитатьДля меня в данном конкретном случае -- спортивный интерес. А так иногда бывает, что какой-нибудь сервис не работает как нужно и в логи ничего толком не пишет (вспоминается Samba старых версий). И как назло в tcpdump/wireshark нет диссектора (или он неполон) для этого протокола.
Или это вообще не сетевой протокол, а какой-нибудь файл в специфическом формате (вспоминается xls/doc/dbf и т.п.) и библиотек под нужный ЯП либо нет, либо они не умеют делать, то что тебе нужно (такое правда у меня было давно).
>[оверквотинг удален]
>> кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные
>> значения, что чему соответствует, где читали? интересно было бы почитать
> Для меня в данном конкретном случае -- спортивный интерес. А так иногда
> бывает, что какой-нибудь сервис не работает как нужно и в логи
> ничего толком не пишет (вспоминается Samba старых версий). И как назло
> в tcpdump/wireshark нет диссектора (или он неполон) для этого протокола.
> Или это вообще не сетевой протокол, а какой-нибудь файл в специфическом формате
> (вспоминается xls/doc/dbf и т.п.) и библиотек под нужный ЯП либо нет,
> либо они не умеют делать, то что тебе нужно (такое правда
> у меня было давно).для меня тоже больше спортивный в данном случае.
задача стояла настроить шейпинг poptop-клиентов, которые без шифрования подключаются. неиспользуемая ширина канала должна распределяться м/ду клиентами без использования imq (его просто нет - сервак старый, ядро старое и пересобирать все - себе дороже). поэтому ясное дело - единственный выход ставить фильтры на физический интерфейс. в принципе фильтра вида:
u32 match ip protocol 47 0xff match ip dst $LAN_DST/32
вполне достаточно для решения задачи. чем там клиент грузит выделенную ему полосу внутри туннеля - его дело.
просто ради интереса задумался о возможности анализа пакетов внутри этого туннеля (он ведь не шифрованный) для приоритезации определенных сервисов (HTTP например).
ИМХО в принципе задача решаема, но кучу фильтров ставить надо будет. еще следует учитывать, что заголовки пакетов могут иметь разную длину (теоритически. фактически - это скорее исключение в данной реализации), что либо еще фильтров добавит, либо просто некоторая (очень небольшая часть) нужного пройдет мимо фильтра. в общем даже такое извращение похоже можно реализовать...
>Что-то у меня лыжи уже 3-й день не едут с расшифровкой одного значения пакета, перехваченного tcpdump-ом
>> для меня тоже больше спортивный в данном случае.Люди, а не проще было бы сделать стенд (хоть на виртуалках), запустить снифер (вирешарк например), который все поля в соответствие с RFC сам разбирает и описывает их?
>> http://www.faqs.org/rfcs/rfc1661.html
>> http://www.faqs.org/rfcs/rfc1332.html
> а зачем вы все это делаете???я вот вообще первый раз вижу, что
> кто-то эти значения расшифровывает. Кстати, как так научились разбирать эти 16-ричные
> значения, что чему соответствует, где читали? интересно было бы почитатьА разбирать в основном описания протоколов и форматов либо открыты, либо в Сети можно найти их описание.
> http://www.faqs.org/rfcs/rfc1661.html
> http://www.faqs.org/rfcs/rfc1332.htmlспасибо конечно за ссылки), но я уже писал, что rfc читал (не один год их уже читаю) - этому свидетельство моя приведенная расшифровка пакета. к тому же, учитывая наличие GRE и его несколько специфичную реализацию в poptop, данных ссылок явно недостаточно для ответа.
вопрос уперся только в одно значение, которое я понять не могу. не надо ссылок - просто если знаете (или есть предположения), то просто скажите что это такое.
>> http://www.faqs.org/rfcs/rfc1661.html
>> http://www.faqs.org/rfcs/rfc1332.html
> спасибо конечно за ссылки), но я уже писал, что rfc читал (не
> один год их уже читаю) - этому свидетельство моя приведенная расшифровка
> пакета. к тому же, учитывая наличие GRE и его несколько специфичную
> реализацию в poptop, данных ссылок явно недостаточно для ответа.
> вопрос уперся только в одно значение, которое я понять не могу. не
> надо ссылок - просто если знаете (или есть предположения), то просто
> скажите что это такое.Из того, что я понял:
После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит из поля протокола, занимающего 1 или 2 байта и всякого мусора. Значение 0x21 для поля протокола: IP-пакет (вторая ссылка).
>[оверквотинг удален]
>> один год их уже читаю) - этому свидетельство моя приведенная расшифровка
>> пакета. к тому же, учитывая наличие GRE и его несколько специфичную
>> реализацию в poptop, данных ссылок явно недостаточно для ответа.
>> вопрос уперся только в одно значение, которое я понять не могу. не
>> надо ссылок - просто если знаете (или есть предположения), то просто
>> скажите что это такое.
> Из того, что я понял:
> После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит
> из поля протокола, занимающего 1 или 2 байта и всякого мусора.
> Значение 0x21 для поля протокола: IP-пакет (вторая ссылка).подробней можно по 2-й ссылке (цитату) - у меня видимо лыжи не едут совсем на этот вопрос... глаз замылился. 0x21 - ОДИН байт (не 0x0021). где там оно в rfc?
хотя думаю, что скорее всего Вы правы. надо просто исходник poptop поглядеть (так не хотелось, но придется - дело принципа :)). наверное дело в реализации... спасибо.
>> Из того, что я понял:
>> После заголовка GRE, идет заголовок PPP-инкапсуляции (первая ссылка), который состоит
>> из поля протокола, занимающего 1 или 2 байта и всякого мусора.
>> Значение 0x21 для поля протокола: IP-пакет (вторая ссылка).
> подробней можно по 2-й ссылке (цитату) - у меня видимо лыжи не
> едут совсем на этот вопрос... глаз замылился. 0x21 - ОДИН байт
> (не 0x0021). где там оно в rfc?
> хотя думаю, что скорее всего Вы правы. надо просто исходник poptop поглядеть
> (так не хотелось, но придется - дело принципа :)). наверное дело
> в реализации... спасибо.Из 1-й ссылки про поле протокола:
The Protocol field is one or two octets, and its value identifies
the datagram encapsulated in the Information field of the packet.
The field is transmitted and received most significant octet
first.The structure of this field is consistent with the ISO 3309
extension mechanism for address fields. All Protocols MUST be
odd; the least significant bit of the least significant octet MUST
equal "1". Also, all Protocols MUST be assigned such that the
least significant bit of the most significant octet equals "0".
Frames received which don't comply with these rules MUST be
treated as having an unrecognized Protocol.
Из второго абзаца я понял, что первый байт из 0x0021 можно опускать, если он равен 0x00.
>[оверквотинг удален]
> equal "1". Also, all Protocols
> MUST be assigned such that the
> least significant bit of the most
> significant octet equals "0".
> Frames received which don't comply with
> these rules MUST be
> treated as having an unrecognized Protocol.
>
Мой земной поклон и благодарность. Глаз замылился/читал книгу - фидел фигу/итд ). Еще раз спасибо огромное.