Как проверить работу ipsec в туннеле l2tp с динамической маршрутизацией?

Question

[Андрей]

Добрый день, коллеги!
Прошу Вашей помощи в таком хитром деле.
На первый взгляд, банальная схема. Клиент подключается к серверу с помощью l2tp, получает маршрут с помощью ospf и всё начинает замечательно работать.
Захотел к этому делу прикрутить ipsec(в транспортном режиме) повесив его на начало 10.10.183.1 и конец 10.10.183.2 туннеля.
В Remote Peers соединение есть.
В Installed SAs пусто. В политиках в статистике то же пусто.
В логах тишина.
Пинги ходят всегда…
Подскажите, работает ли шифрование в туннеле? Как это можно проверить?

Вот вывод лога при разрыве ipsec соединения:

echo: ipsec,debug,packet sockname 10.10.183.2[500]
echo: ipsec,debug,packet send packet from 10.10.183.2[500]
echo: ipsec,debug,packet send packet to 10.10.183.1[500]
echo: ipsec,debug,packet src4 10.10.183.2[500]
echo: ipsec,debug,packet dst4 10.10.183.1[500]
echo: ipsec,debug,packet 1 times of 92 bytes message will be sent to 10.10.183.1[500]
echo: ipsec,debug,packet 19fed9a5 04920b51 8025d5c9 bc00b14e 08100501 e9224332 0000005c 6f6a7e9e
echo: ipsec,debug,packet 06b94d13 171561db 81b1f730 88fff274 dc2679f9 e0ae2193 65cfa70c 3e3415a0
echo: ipsec,debug,packet cc807fb9 8e2935a7 a0442735 72c1499d f09747f4 5c851c6e bdb76bd8
echo: ipsec,debug,packet sendto Information delete.
echo: ipsec,debug,packet an undead schedule has been deleted.
echo: ipsec,debug,packet an undead schedule has been deleted.
[p@TTK-JD-POST_LEN] > 
  (228 messages discarded)
echo: ipsec,debug,packet 545ebc84 110f817b 1a08fdea 34082bb7 00000001 00000001 00000030 01010001
echo: ipsec,debug,packet 00000028 01010000 800b0001 000c0004 00015180 80010007 800e0080 80030001
echo: ipsec,debug,packet 80020002 80040002 011101f4 0a0ab701
echo: ipsec,debug,packet hmac(hmac_sha1)
echo: ipsec,debug,packet HASH computed:
echo: ipsec,debug,packet c33e3da8 72b6abb0 565b5d7d e55d6a64 4d763d94
echo: ipsec,debug,packet HASH for PSK validated.
echo: ipsec,debug,packet peer's ID:
echo: ipsec,debug,packet 011101f4 0a0ab701
echo: ipsec,debug,packet ===
echo: ipsec,debug ISAKMP-SA established 10.10.183.2[500]-10.10.183.1[500] spi:1a08fdea34082bb7:545ebc84110f817b
echo: ipsec,debug,packet ===
[p@TTK-JD-POST_LEN] >

Вот, что ещё появляется периодически:

[p@TTK-JD-POST_LEN] > 
  (151 messages discarded)
echo: ipsec,debug,packet c9b4ebb7 00000020 00000001 01108d29 1a08fdea 34082bb7 545ebc84 110f817b
echo: ipsec,debug,packet 00000f2c
echo: ipsec,debug,packet hmac(hmac_sha1)
echo: ipsec,debug,packet HASH computed:
echo: ipsec,debug,packet 67adda30 5845fc95 da6b43f7 e9be928c 2c2d9326
echo: ipsec,debug,packet hash validated.
echo: ipsec,debug,packet begin.
echo: ipsec,debug,packet seen nptype=8(hash)
echo: ipsec,debug,packet seen nptype=11(notify)
echo: ipsec,debug,packet succeed.
echo: ipsec,debug,packet DPD R-U-There-Ack received
echo: ipsec,debug,packet received an R-U-THERE-ACK

Answer 1

[CityCat4]

Если в SA пусто, значит SA не установилась, значит ipsec не работает. Включите подробный лог ipsec, там правда непросто ориентироваться (в микротике стоит racoon, он вываливает столько отладки, что просто аще), но лучше много чем нисколько.

Comments

[Андрей]

Спасибо, за подсказку с выводом лога! Добавил его в вопрос. Судя по логу, всё работает. 8-0
Или нет? В туннельном режиме, SA есть. А в транспортном они должны быть?

[CityCat4]

Андрей: Первая фаза да, прошла. Но второй фазы я не вижу. А собственно после нее и начинается обмен данными. Надо дальнейшие ошибки вылавливать - шифронаборы могут не сходиться, например. Микротики с обеих сторон или с другой стороны линух?

[Андрей]

CityCat4: С двух сторон микротики. Прошивки разные 6.30 и 6.37.
Настройки перепроверил, парольные фразы везде одинаковые.

[CityCat4]

Андрей: Ээээ, тут не только в парольных фразах может быть дело. Политика в настройках, которая задает шифронабор. IPSec в микротике настраивается связкой из proposal, policy и remote-peer. Сначала настраивается proposal, потом на его основе создается policy, а потом настраивается remote-peer. Нужно проверить, что оба микротика предлагают друг другу шифронаборы, которые имеют хотя бы один общий. В логе несовпадение наборов должно отмечаться. Чтобы не ловить это место по всему логу можно на одном из них временно peer заблокировать, когда соединение на втором отвалится, заново его включить и ловить момент прохождения второй фазы в логе.

[Андрей]

CityCat4: УРА, благодаря Вам, я всё перепроверил, и не найдя ничего, решил обновить прошивку. На одном была 6.37, на другом 6.30. (отклоняясь от темы, hAp lite из 16 мегов, свободно только 7.9... чем занято остальное место не понятно....и каким-то чудом, я обновил его до 6.38) После обновления SA появились

22:14:49 echo: ipsec IPsec-SA established: ESP/Transport 10.10.183.2[500]->10.10.183.1[500] spi=0xd2a7c2d

Но счетчик current bytes по нулям :(

Ну что же это такое... :(

Пинги и всё остальное ходит. Такое ощущение, что трафик идёт в обход ipsec...не попадает под политику. В туннеле торчем видно адреса туннеля 10.10.183.1,2 и подсетей...

[CityCat4]

Андрей: Трафик вполне может идти в обход IPSec, если политика не предписывает его туда направить. Появились две SA?

[Андрей]

CityCat4: SA появились, но данные не шифруются. Счетчик current bytes = 0. :( Спасибо Вам, CityCat4 за помощь! Ответ на мой вопрос найден. Если под политики попадёт, то будут SA и счетчик зашифрованных данных будет больше 0.

[Kenny00]

CityCat4, подскажите, а если Tunnel - NO , это плохо, при таком раскладе:

[CityCat4]

Kenny00, Нет, это означает политику транспортного уровня. Туннельный и транспортный уровни и многое другое