ipsec linux<>windows
Есть windows сервер за NAT. Нужно устроить с ним ipsec в transport mode. С windows клиентов все работает хорошо, но с linux мне не удалось настроить ни racoon, ни openswan. Если я сейчас буду описывать суть проблем, это будет надолго. Я прошу всего лишь поделиться реально работающими конфигами racoon или openswan для описанного случая. Авторизация идет через сертификаты
дико интересно, подписался
Вся проблема оказалась в PFS. Виндовс ее тупо не поддерживает, по крайней мере по умолчанию. Пишут, что как-то можно включить, пока еще не разобрался. Пока сделал pfs=off и все работает. Будет настроение — покопаю дальше, чтобы включить PFS на windows. Фича очень нужная и полезная. Грубо говоря — ФБР перехватывает весь твой трафик и записывает. Потом однажды в критический момент комуниздят твой комп, берут оттуда rsa private key и расшифровывают весь записанный ранее трафик, где ты продаешь наркотики и выкладываешь ДП.
config setup nat_traversal=yes interface=%defaultroute oe=off conn myconnection type=transport left=192.168.2.5 leftcert=server.cert leftid=%fromcert leftrsasigkey=%cert leftca=myca.cert right=bananos.org rightid=CN=bananos.org authby=rsasig ike=3des-sha1;modp1024 pfs=no auth=esp dpdtimeout=120 dpddelay=30 dpdaction=restart_by_peer forceencaps=yes auto=start : RSA /etc/ipsec.d/private/server.key шо, там нету диффи-хельманов?
Я так понял, что без PFS достаточно одного приват кея, чтобы восстановить ключ сессии. С PFS нужны оба.
Не повезло вам, такой жалкий протоколишко навязали
Вообще-то, это общепринятый стандарт, а для ipv6 — обязательная часть IP протокола. Другое дело, почему в windows такая фигня по умолчанию. Если изъять оба приват ключа, то никакое самое правильное шифрование не поможет, потому что обмен ключами проходит по тому же самому каналу, что и данные.
Если потеря приват ключей критична, их нельзя хранить в виде файлов. Нужно пользоваться крипто-смарт-картами или крипто-токенами. Они никогда не отдают приват ключ, а только по запросу подписывают сообщения.
А если потеряешь смарткарту? Просто нужно хранить ключи в надёжном месте. И шифровать это место другими ключами. А их хранить в ещё более надёжном месте.
а эти ключи не страшно потерять. сертификат хоста можно перегенерить в любой момент
Ну тогда надо надёжно хранить ключи для перегенерации сертификатов хоста.
Инфы об ipsec на Linux + windows в нете совсем немного. Openswan как оказалось страдает еще одной проблемой. Через несколько минут отсутствия пакетов соединение отваливается на стороне винды. В oakley.log видим вот такое :
1-19: 13:37:28:955:310 CE Dead. sa:05585018 ce:000F35C0 status:35f0 1-19: 13:37:28:955:310 SA Dead. sa:05585018 status:35f0
В сниффере видно, как нормально со стороны linux идут NAT-T keepalive. Пока пингается — отсылаются ESP, принимаются ESP. Ждем минут 10. keep-alives по-прежнему идут, ESP отсылаются, винда на них никак не отвечает. То есть для нее мы мертвы. SA сдохло. Openswan не в состоянии распознать эту ситуацию и перенеготиэйтить SA. Dead peer detection виндой не поддерживается.
Как это лечить не знаю. Разве что параллельно с запуском SA еще и запускать вечный пинг. Но это не спасет от проблем с сетью, если вдруг по какой-то другой причине перестанут доходить пакеты.
Опять пытался ковырять racoon. Пытался включить PFS на винде. Судя по всему MS и openswan понимают под этим понятием разные вещи. Потому что даже при включенном PFS на винде с опцией pfs=on на стороне openswan ничего не работает, с racoon ситуация тоже никак не меняется. В racoon застреваем на «IDci mismatched». Openswan на этот случай применяет какой-то свой microsoft bad proposal workaround, о чем говорит в логе. А ракун тупо идет в ошибку и все застревает. Где-то пишут, что надо накладывать какие-то патчи на racoon.
Короче, надежного решения я так и не нашел. Только решение «кое-как через . »
А если генерить трафик между концами, то тоннель (при нормальной работе канала связи) не рвется?
Ждем минут 10. keep-alives по-прежнему идут, ESP отсылаются, винда на них никак не отвечает.
А в свановских логах при этом что-нибудь про попытки переподключения есть?
Dead peer detection виндой не поддерживается.
В смысле, венда не умеет отвечать на DPDшные «R_U_THERE»? Но по идее даже это не должно мешать свану принимать решения о реконнекте.
В общем, я бы уменьшил dpddelay и dpdtimeout и попробовал бы покурить, что pluto вывалит в control log. Хоть там и изрядный мозголомный адъ, конечно.
thesis ★★★★★ ( 19.01.14 15:15:32 MSK )
Последнее исправление: thesis 19.01.14 15:17:20 MSK (всего исправлений: 1)
А если генерить трафик между концами, то тоннель (при нормальной работе канала связи) не рвется?
Оставлял минут на 20. Все еще пингалось.
В смысле, венда не умеет отвечать на DPDшные «R_U_THERE»?
pluto[5180]: "winhost" #1: Dead Peer Detection (RFC 3706): not enabled because peer did not advertise it . pluto[5180]: "winhost" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode 0x5dfe1992
dpdtimeout=120 dpddelay=30 dpdaction=restart_by_peer
Но никаких действий по ним не проводится
Поймал момент отвала. Отваливается конект спустя 7 минут. На виндовой стороне :
1-19: 19:23:36:975:310 QM Deleted. Notify from driver: Src Dest InSPI 1576933778 OutSpi 1291226776 Tunnel 0 TunnelFilter 0 1-19: 19:23:36:975:310 srcEncapPort=37905, dstEncapPort=9202 1-19: 19:23:36:975:310 Leaving adjust_peer_list entry 05521F68 MMCount 0 QMCount 0 1-19: 19:23:36:975:310 constructing ISAKMP Header 1-19: 19:23:36:975:310 constructing HASH (null) 1-19: 19:23:36:975:310 Construct QM Delete Spi 1576933778 1-19: 19:23:36:975:310 constructing HASH (Notify/Delete) 1-19: 19:23:36:975:310 Not setting retransmit to downlevel client. SA 05584908 Centry 00000000 1-19: 19:23:36:975:310 1-19: 19:23:36:975:310 Sending: SA = 0x05584908 to :Type 1.61987 1-19: 19:23:36:975:310 ISAKMP Header: (V1.0), len = 68 1-19: 19:23:36:975:310 I-COOKIE 06dbb70f449bf408 1-19: 19:23:36:975:310 R-COOKIE e6a4249857082bb1 1-19: 19:23:36:975:310 exchange: ISAKMP Informational Exchange 1-19: 19:23:36:975:310 flags: 1 ( encrypted ) 1-19: 19:23:36:975:310 next payload: HASH 1-19: 19:23:36:975:310 message ID: 6e577156 1-19: 19:23:36:975:310 Ports S:9411 D:23f2 1-19: 19:23:36:975:310 PrivatePeerAddr 502a8c0 1-19: 19:24:01:803:310 ClearFragList Jan 19 19:23:40 guest pluto[5180]: |.. Jan 19 19:23:40 guest pluto[5180]: | *received 68 bytes from :4500 on eth0 (port=4500) Jan 19 19:23:40 guest pluto[5180]: | 06 db b7 0f 44 9b f4 08 e6 a4 24 98 57 08 2b b1 Jan 19 19:23:40 guest pluto[5180]: | 08 10 05 01 6e 57 71 56 00 00 00 44 b4 31 f7 3f Jan 19 19:23:40 guest pluto[5180]: | 71 42 6d 75 84 5b d9 8a 1c 33 f8 54 a0 69 a4 5c Jan 19 19:23:40 guest pluto[5180]: | 6d 67 6b 1f a9 2b 67 08 66 7d 85 02 42 e3 7f b4 Jan 19 19:23:40 guest pluto[5180]: | f7 72 28 fa Jan 19 19:23:40 guest pluto[5180]: | **parse ISAKMP Message: Jan 19 19:23:40 guest pluto[5180]: | initiator cookie: Jan 19 19:23:40 guest pluto[5180]: | 06 db b7 0f 44 9b f4 08 Jan 19 19:23:40 guest pluto[5180]: | responder cookie: Jan 19 19:23:40 guest pluto[5180]: | e6 a4 24 98 57 08 2b b1 Jan 19 19:23:40 guest pluto[5180]: | next payload type: ISAKMP_NEXT_HASH Jan 19 19:23:40 guest pluto[5180]: | ISAKMP version: ISAKMP Version 1.0 (rfc2407) Jan 19 19:23:40 guest pluto[5180]: | exchange type: ISAKMP_XCHG_INFO Jan 19 19:23:40 guest pluto[5180]: | flags: ISAKMP_FLAG_ENCRYPTION Jan 19 19:23:40 guest pluto[5180]: | message ID: 6e 57 71 56 Jan 19 19:23:40 guest pluto[5180]: | length: 68 Jan 19 19:23:40 guest pluto[5180]: | processing version=1.0 packet with exchange type=ISAKMP_XCHG_INFO (5) Jan 19 19:23:40 guest pluto[5180]: | ICOOKIE: 06 db b7 0f 44 9b f4 08 Jan 19 19:23:40 guest pluto[5180]: | RCOOKIE: e6 a4 24 98 57 08 2b b1 Jan 19 19:23:40 guest pluto[5180]: | state hash entry 9 Jan 19 19:23:40 guest pluto[5180]: | peer and cookies match on #2, provided msgid 00000000 vs 58f25d7b/00000000 Jan 19 19:23:40 guest pluto[5180]: | p15 state object not found Jan 19 19:23:40 guest pluto[5180]: | ICOOKIE: 06 db b7 0f 44 9b f4 08 Jan 19 19:23:40 guest pluto[5180]: | RCOOKIE: 00 00 00 00 00 00 00 00 Jan 19 19:23:40 guest pluto[5180]: | state hash entry 16 Jan 19 19:23:40 guest pluto[5180]: | v1 state object not found Jan 19 19:23:40 guest pluto[5180]: packet from :4500: Informational Exchange is for an unknown (expired?) SA with MSGID:0x5671576e Jan 19 19:23:40 guest pluto[5180]: | - unknown SA's md->hdr.isa_icookie: Jan 19 19:23:40 guest pluto[5180]: | 06 db b7 0f 44 9b f4 08 Jan 19 19:23:40 guest pluto[5180]: | - unknown SA's md->hdr.isa_rcookie: Jan 19 19:23:40 guest pluto[5180]: | e6 a4 24 98 57 08 2b b1 Jan 19 19:23:40 guest pluto[5180]: | * processed 0 messages from cryptographic helpers. Jan 19 19:23:40 guest pluto[5180]: | next event EVENT_NAT_T_KEEPALIVE in 2 seconds Jan 19 19:23:40 guest pluto[5180]: | next event EVENT_NAT_T_KEEPALIVE in 2 seconds