Прочитал статейку http://www.lissyara.su/?id=1050
В коментах нашёл такое
Есть у меня проблемка именно с IPsec и tcpdump...Одно дело - сиськи, а другое - черти))
Ну нету на цисках tcpdump - а все проблемы я решал именно им...
Моя конфигурация Ipsec построена схожим образом. Но без gif интерфейсов.
Отчасти от того что я посчитал их тогда не нужными и от того что на другой стороне стоит не FreeBSD а железяка по имени Dlink Router 808hv. Железяка дешовая и умная, но не на стоко чтобы уметь подымать виртуальные интерфейсы. Но 40 IPsec соединений держит (в мануале так написанно но я тихо сомневаюсь
)Так вот, после того как было настроено и установлено IPsec соединение была понята вся выгода от такой конфигурации, было закуплено Н-ое количество Dlink-ов и разбросанно по миру для соединения всех частей нашего большого офиса в единую
частную сеть..
Получилась конфигурация N-e количество Dlinл-ов с одной стороны, которые соединяются через Ipsec с Единым сервером FreeBSD 5.14 с другой стороны.
Но вот какая проблема дорогие камрады...
Отсутсвие gif интерфейса для каждого IPsec соединения делает затруднительтым просмотр трафика через tcpdump или други утилиты.. Т.Е. поскоку за каждым Dlink-oм и за FreeBSD есть сетки со своими кампами и феховыми адресами то можно определённую часть трафика пользователей посмотреть на фейховом адресе Freebsd.
Но ту часть трафика которая приходит из сетки за Dlink-ами и предназначена для Самой FreeBSD (почта pop3 smtp www ну много всего) остаётся скрытой от глаз зоркого сисадмина.
Т.Е. Задача стоит такая:
Необходимо увидеть пакеты которые приходят
для внутреннего xxx.xxx.xxx.xxx интерфейса FreeBSD через IPsec тунель на внешнем интерфейсе.
XXX.XXX.XXX.XXX – внешний FreeBSD xxx.xxx.xxx.xxx – внутренний FreeBSD
YYY.YYY.YYY.YYY – внешний Dlink yyy.yyy.yyy.yyy – внутренний Dlink
tcpdump естесно видит такое на внешнем tun0 интерфейсе
free# tcpdump -ni tun0 | grep YYY.YYY.YYY.YYY
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes
18:24:30.486446 IP YYY.YYY.YYY.YYY > XXX.XXX.XXX.XXX: ESP(spi=0x024b97c5,seq=0x9dc)
18:24:30.486706 IP XXX.XXX.XXX.XXX > YYY.YYY.YYY.YYY: ESP(spi=0xd2170010,seq=0x75f)
18:24:31.356931 IP YYY.YYY.YYY.YYY > XXX.XXX.XXX.XXX: ESP(spi=0x024b97c5,seq=0x9dd)
18:24:31.357198 IP XXX.XXX.XXX.XXX > YYY.YYY.YYY.YYY: ESP(spi=0xd2170010,seq=0x760)
18:24:32.403817 IP YYY.YYY.YYY.YYY > XXX.XXX.XXX.XXX: ESP(spi=0x024b97c5,seq=0x9de)
Трафик обезличен и кто что куда шлёт не понятно... Т.Е. понятно что Офис с
YYY.YYY.YYY.YYY шлёт что то в офис XXX.XXX.XXX.XXX или на оборот.
Часть из этих пакетов уходит через FreeBSD дальше внутрь сетки
их можно увидеть на внутренем xl0 интерфейсе FreeBSD и с этим проблем нет.
Но что именно и от коко конкретно из офиса YYY.YYY.YYY.YYY застряёт на FreeBSD
непонятно. И станет понятно, имхо, только после расшифровки пакетов
принятых на внешнем tun0 интерфейсе.
Чтение мана tcpdump, особенно в следующей части
-E Use spi@ipaddr algo:secret for decrypting IPsec ESP packets that
are addressed to addr and contain Security Parameter Index value
spi. This combination may be repeated with comma or newline
seperation.
Говорит о том, что существует возможность расишифровки пакетов. Скажем spi и algo для каждого соединения можно взять из setkey -D, ipadrr имеется ввиду внешний IP адресс того кому данный пакет адресован. Что такое secret мне не понятно, но возможно это первичный ключ из файла racoon-a psk.key.
Все мои попытки расшифровать
tcpdump -ni tun0 -E c7f3a6a4199db7fb9f3e8cfdd2fe73e4d78ea80c2d089ec594e20b43b963c026c2124f6f2b66d8eb@YYY.YYY.YYY.YYY,3des-cbc:SECRET
Приводят к
16:05:47.634011 IP XXX.XXX.XXX.XXX> YYY.YYY.YYY.YYY: ESP(spi=0x3c1d0010,seq=0x811)failed to decode espsecret: c7f3a6a4199db7fb9f3e8cfdd2fe73e4d78ea80c2d089ec594e20b43b963c026c2124f6f2b66d8eb@YYY.YYY.YYY.YYY
Подозреваю что ввожу неверный espsecret
.Но где взять верный если не в setkey -Dдаже и не подозреваю... Или где то конкретно туплю...
Идеи есть?
