Deadlock
Forum Members-
Posts
23 -
Joined
-
Last visited
Equipment
-
Keenetic
Keenetic Giga (KN-1010)
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
Deadlock's Achievements
Member (2/5)
2
Reputation
-
А вот что пишут Strongswan'овцы, почему не работает чистый Андрюша ) Согласно проекту EAP-MSCHAPv2 , ключи выводятся согласно RFC 3079 (MPPE). В результате получается два 128-битных ключа: MasterSendKey и MasterReceiveKey (т.е. всего 32 октета). Однако согласно RFC 5247 MSK для методов EAP ДОЛЖЕН быть не менее 64 октетов , поэтому эти ключи необходимо каким-то образом дополнить. Первые бета-версии Windows 7 еще в 2009 году (именно это мы и тестировали, когда реализовывали EAP-MSCHAPv2) делали это следующим образом: MasterReceiveKey|16 zero bytes|MasterReceiveKey|16 zero bytes. Но в версии-кандидате Windows 7 это было изменено на: MasterReceiveKey|MasterReceiveKey|32 zero bytes, которое с тех пор используем мы и другие реализации. Поэтому, пока Google не исправит свой клиент соответствующим образом, вы не сможете подключиться.
-
IPsec Удаленные подсети
Deadlock replied to KapJleoHe KapJleoHe's question in Тестирование Dev-сборок
Заходи, я порешал)) -
Всех с наступающим! Итак, в 4.0 появилась долгожданная, по крайней мере для меня фича, позволяющая дополнительно добавлять локальные и удаленные подсети. Туннель поднят в паре с Kerio Control. Его IPsec реализован на базе Strongswan. Первые попытки не увенчались успехом. То есть связность была исключительно между подсетями, которые были первыми в списке, доп. сети доступны не были, child SA not established, как говорится. А когда меняешь местами любые подсети, то доступ всё равно был у первых в списке. Покопавшись по форумам, у многих парней та же проблема. Сегодня удалось победить в своей тестовой среде. Описываю, что сделал. 1. Отключил шифры по умолчанию в Control и выставил такие: Фаза1 - aes192-sha1-modp2048, Фаза2 - aes128-sha1. Затем в Кинетике соответственно. 2. Выставил в настройках обоих активный режим, то есть и Keenetic и Control стали инициаторами. Это произошло случайно, но туннель нормально поднялся. 3. Подключился к Кинетику в консоль и вуаля: (config)> show crypto map crypto_map, name = Control: config: remote_peer: 10.0.0.3 enabled: yes crypto_ipsec_profile_name: Control mode: tunnel status: primary_peer: true phase1: name: Control unique_id: 309 ike_state: ESTABLISHED establish_time: 1703655957 rekey_time: 1703666725 reauth_time: 0 local_addr: 10.0.0.5 remote_addr: 10.0.0.3 ike_version: 1 local_spi: 1451d08a1e0249f9 remote_spi: f685e81611168d23 local_init: yes ike_cypher: aes-cbc-192 ike_hmac: sha1 ike_dh_group: 14 phase2_sa_list: phase2_sa, index = 0: unique_id: 1 request_id: 1 sa_state: INSTALLED mode: TUNNEL protocol: ESP encapsulation: no local_spi: ccb5ab7e remote_spi: cccaff94 ipsec_cypher: esp-aes-128 ipsec_hmac: esp-sha1-hmac ipsec_dh_group: in_bytes: 166702 in_packets: 783 in_time: 1703658191 out_bytes: 169888 out_packets: 705 out_time: 1703658191 rekey_time: 1703659506 local_ts: 192.168.1.0/24 remote_ts: 10.100.88.0/24 phase2_sa, index = 1: unique_id: 2 request_id: 2 sa_state: INSTALLED mode: TUNNEL protocol: ESP encapsulation: no local_spi: c25aec11 remote_spi: c8b74fe0 ipsec_cypher: esp-aes-128 ipsec_hmac: esp-sha1-hmac ipsec_dh_group: in_bytes: 1200 in_packets: 20 in_time: 1703658080 out_bytes: 1200 out_packets: 20 out_time: 1703658080 rekey_time: 1703659505 local_ts: 192.168.1.0/24 remote_ts: 10.15.20.0/24 phase2_sa, index = 2: unique_id: 3 request_id: 3 sa_state: INSTALLED mode: TUNNEL protocol: ESP encapsulation: no local_spi: c75d44a2 remote_spi: c7cb5e43 ipsec_cypher: esp-aes-128 ipsec_hmac: esp-sha1-hmac ipsec_dh_group: in_bytes: 1200 in_packets: 20 in_time: 1703658087 out_bytes: 1200 out_packets: 20 out_time: 1703658087 rekey_time: 1703659525 local_ts: 192.168.1.0/24 remote_ts: 172.30.30.0/24 phase2_sa, index = 3: unique_id: 4 request_id: 4 sa_state: INSTALLED mode: TUNNEL protocol: ESP encapsulation: no local_spi: cef01974 remote_spi: c79a10eb ipsec_cypher: esp-aes-128 ipsec_hmac: esp-sha1-hmac ipsec_dh_group: in_bytes: 58740 in_packets: 979 in_time: 1703658100 out_bytes: 58740 out_packets: 979 out_time: 1703658101 rekey_time: 1703659503 local_ts: 192.168.1.0/24 remote_ts: 10.100.99.0/24 state: PHASE2_ESTABLISHED Все хосты всех подсетей пингуются в обе стороны, всё rulezzz!
-
IPsec Удаленные подсети
Deadlock replied to KapJleoHe KapJleoHe's question in Тестирование Dev-сборок
Наконец, мы рады представить вариант настройки Множественных подсетей для VPN-соединения IPsec типа "сеть–сеть" в параметрах Фаза 2. Эта функция позволит установить сетевое соединение между несколькими подсетями через VPN-туннель, повысив универсальность вашего интернет-центра." Поддерживаю вопрос, радости не прибавилось. Child SA established действительно как и раньше между подсетями в первой строчке, доп сети не доступны. Ответьте хотя бы, что в процессе.... -
3.9: перестало работать подключение к L2TP/IPsec-серверу
Deadlock replied to Serg54's question in Тестирование Dev-сборок
На прошивке 3.9.1 l2tp\ipsec клиент на Кинетике абсолютно перестал подключаться к Kerio Control. По предлагаем proposals нужный есть, хз, что ещё смотреть -
3.9: перестало работать подключение к L2TP/IPsec-серверу
Deadlock replied to Serg54's question in Тестирование Dev-сборок
На текущий момент соединение стабильно, 14 часов. Завтра отпишусь еще утром и хорэ -
3.9: перестало работать подключение к L2TP/IPsec-серверу
Deadlock replied to Serg54's question in Тестирование Dev-сборок
-
Туннель между keenetic и kerio control
Deadlock replied to brus13's topic in Обсуждение IPsec, OpenVPN и других туннелей
Я победил! Kerio c Кинетиком дружат уже 8 часов без реконнекта!!! -
3.9: перестало работать подключение к L2TP/IPsec-серверу
Deadlock replied to Serg54's question in Тестирование Dev-сборок
Работало замечательно на моей памяти с 3.5 и до 3.7 точно. потом надобность отпала. Вновь подключение настроил на последнем билде 3.8, часа три четыре поробит и в аут. С переходом на 3.9 пляски конкретные начались, то 30 минут, то 45, то 60. На L2TP интерфейсе менял в меньшую сторону lifetime обоих фаз и ставил одинаково по спецификации Kerio Control, не помогло никак. И не мог зацепиться, кто виновен. Выкл/вкл что на сервере, что на клиенте возвращал к жизни коннект. Получается, что есть взаимосвязь програмная и да, считаю... (пока считаю, сутки пусть пройдут хотя бы), что компонент IPv6 помог. Хотелось от гуру получить коммент по этому поводу, да и успокоится.