Настройка IPsec для NDMS

[r13]

9 минут назад, Кинетиковод сказал:

На младших моделях AES работает значительно быстрее DES. Как на Гигах точно не скажу. Проверьте производительность по факту.

а на гигах надо ставить aes, как более безопасный. на скорость на них вид шифрования не влияет. то биш выбирать aes/sha а не des/md5

Изменено 21 сентября, 2018 пользователем r13

[Rezdbic]

А какой именно aes и sha? Чем больше цифирь, тем "круче" шифрование?

[Кинетиковод]

Только что, Rezdbic сказал:

А какой именно aes и sha? Чем больше цифирь, тем "круче" шифрование?

Типа того. Но реально AES-128 SHA1 будет достаточно. Но если на вас ведут охоту агенты АНБ, то можете усилить шифрование.

[Alexander Eerie]

В 20.09.2018 в 16:40, Le ecureuil сказал:

Никак. Топология звезда нормально не поддерживается XFRM.

да не, надо просто пару костылей воткнуть...) займусь потом может

[Alexander Eerie]

В 21.09.2018 в 09:37, gaaronk сказал:

Натяните везде GRE туннели и их шифруйте IPSec'ом. А там внутрь туннеля по маршрутизации что хотите то и отправляйте. У меня внутри туннелей бегает ospf на базе bird.

был бы пакетик с квагой в комплекте и белые адреса....

[r13]

7 минут назад, Alexander Eerie сказал:

был бы пакетик с квагой в комплекте и белые адреса....

Ну если usb есть то quagga в opkg доступен  

[gaaronk]

3 hours ago, Alexander Eerie said:

был бы пакетик с квагой в комплекте и белые адреса....

bird лучше

Белый адрес нужен только для центра звезды.

[Alexander Eerie]

В 25.09.2018 в 11:26, r13 сказал:

Ну если usb есть то quagga в opkg доступен  

а если нет усб?) да наверное надо свой мод прошивки делать...

 

 

22 часа назад, gaaronk сказал:

bird лучше

Белый адрес нужен только для центра звезды.

квага привычней.. ну можно и бёрд.)
насчёт белых.. для gre нужен удаленный адрес на обоих концах знать для transport mode, а туннель внутри тунеля - опять вручную прописывать айпишники на сервере и на клиенте. В этом случае проще l2tp гонять - там все настройки в одном месте
 

Изменено 26 сентября, 2018 пользователем Alexander Eerie

[gaaronk]

11 hours ago, Alexander Eerie said:

а если нет усб?) да наверное надо свой мод прошивки делать...

 

 

квага привычней.. ну можно и бёрд.)
насчёт белых.. для gre нужен удаленный адрес на обоих концах знать для transport mode, а туннель внутри тунеля - опять вручную прописывать айпишники на сервере и на клиенте. В этом случае проще l2tp гонять - там все настройки в одном месте
 

Нет не надо.

В центре для удаленных точек которые за NAT можно не указывать адрес удаленной точки. 

tunnel source <WAN> или tunnel source auto

а tunnel destination вообще не выставляем.

Именно так все и работает, адрес автоматически выставляется на основе политики, полученной от IPsec.

Можно даже автотуннели настроить, главное что бы имена интерфейсов на разных концах туннеля совпадали. 

То есть  центре создаете интерфейсы Gre1 и Gre2.

На первой удаленной точке делаете Gre1 интерфейс, на второй соотвественно Gre2

Все работает. Все описано. Каждая точка стучится в центр, при смене адреса у нее туннель переподнимается автоматом. 

[Chervonenko_CA]

Всем привет!

Не уверен, надо ли новую тему стартовать, в общем...

Имеется два Кинетика: в Крыму стоит Keenetic Giga, в Московской области - Omni II. Крымский получает у местного провайдера динамический IP из "белого" диапазона (185.119.56.0 - 185.119.59.255 Ukraine (UA)!!!!, Sevastopol ?  ), подмосковный - серый адрес (192.168.0.xxx) у своего.

По заветам https://help.keenetic.com/hc/ru/articles/214471405-Организация-туннеля-IPSec-VPN-между-двумя-интернет-центрами-Keenetic-Ultra-II-и-Giga-III проложил между ними туннель.. Гига на белом адресе ждет подключения, Омни с серого к ней подключается. Замечательно! Ping-ги ходят, usb-диски, подоткнутые к роутерам, перекрестно доступны.

Проходит месяц.. и туннель разваливается ?. В чем дело?? Проверяем.. "белый" Крымский адрес из МО более не пингуется, хотя по DNS (no-ip) разрешается. Предполагаю - провайдер зарезал "украинский" ip. С этим можно как-то бороться?

Полагаю, keenDNS справился-бы, но грузить ваши сервера моим мусорным трафиком - не комильфо...

Изменено 17 октября, 2018 пользователем Chervonenko_CA
дополнение

[r13]

@Chervonenko_CA попинайте провайдера на предмет доступности крымской подсети. 

[Chervonenko_CA]

9 минут назад, r13 сказал:

@Chervonenko_CA попинайте провайдера на предмет доступности крымской подсети. 

Уууу.. А може он с VPN-нами воюет?

Коллеги, ткните в адресок-другой из помянутого диапазона, може там какая глобальная беда, а не местного провайдера (провайдер получал адреса ещё при Украине, не удивлюсь, если и канал у него - через Украину)

Изменено 17 октября, 2018 пользователем Chervonenko_CA

[Le ecureuil]

В 17.10.2018 в 18:11, Chervonenko_CA сказал:

Всем привет!

Не уверен, надо ли новую тему стартовать, в общем...

Имеется два Кинетика: в Крыму стоит Keenetic Giga, в Московской области - Omni II. Крымский получает у местного провайдера динамический IP из "белого" диапазона (185.119.56.0 - 185.119.59.255 Ukraine (UA)!!!!, Sevastopol ?  ), подмосковный - серый адрес (192.168.0.xxx) у своего.

По заветам https://help.keenetic.com/hc/ru/articles/214471405-Организация-туннеля-IPSec-VPN-между-двумя-интернет-центрами-Keenetic-Ultra-II-и-Giga-III проложил между ними туннель.. Гига на белом адресе ждет подключения, Омни с серого к ней подключается. Замечательно! Ping-ги ходят, usb-диски, подоткнутые к роутерам, перекрестно доступны.

Проходит месяц.. и туннель разваливается ?. В чем дело?? Проверяем.. "белый" Крымский адрес из МО более не пингуется, хотя по DNS (no-ip) разрешается. Предполагаю - провайдер зарезал "украинский" ip. С этим можно как-то бороться?

Полагаю, keenDNS справился-бы, но грузить ваши сервера моим мусорным трафиком - не комильфо...

Попробуйте SSTP через KeenDNS. Учитывая, что с то стороны стоит Omni II, то скорость у вас в любом типе VPN будет невысокая, и с серверами все будет ок.

[Chervonenko_CA]

В 23.10.2018 в 17:21, Le ecureuil сказал:

Попробуйте SSTP через KeenDNS. Учитывая, что с то стороны стоит Omni II...

Да, про SSTP я тоже подумал.

НО для Omni II последняя версия прошивки - 2.08. Для неё STTP-клиент есть?

[AndreBA]

4 минуты назад, Chervonenko_CA сказал:

НО для Omni II последняя версия прошивки - 2.08

Версия 2.12 (журнал изменений), 2.13 (журнал изменений) — неофициальная:

Keenetic Lite II

Keenetic Lite III

Keenetic Omni

Keenetic Omni II

Keenetic II

Keenetic Giga II

Keenetic Ultra

Смотреть здесь

Изменено 4 ноября, 2018 пользователем AndreBA

[Chervonenko_CA]

В 04.11.2018 в 21:08, AndreBA сказал:

Версия 2.12 (журнал изменений), 2.13 (журнал изменений) — неофициальная:

А... Неофициальная, с Дельта-канала. Пробовал (по другому поводу). На Омни2 она не живет: слишком мало памяти. В Transmission есть утечка, после запуска роутер "вешается" через несколько минут. А с 2.08 работает несколько часов

[Chervonenko_CA]

Всё оказалось гораздо прозаичнее: на GIGA-е оказался закрыт ICMP, без которого тоннель не устанавливается 😮

Как так? Я-ж не закрывал!

Не закрывал.. А прошивку - обновил: с 2.11 до 2.13. В 2.13 icmp по умолчанию закрыт

[Le ecureuil]

15 часов назад, Chervonenko_CA сказал:

Всё оказалось гораздо прозаичнее: на GIGA-е оказался закрыт ICMP, без которого тоннель не устанавливается 😮

Как так? Я-ж не закрывал!

Не закрывал.. А прошивку - обновил: с 2.11 до 2.13. В 2.13 icmp по умолчанию закрыт

Он и в 2.11 должен быть закрыт на вход с WAN, по крайней мере если специально не открывался.

Но вот как связан IPsec с ICMP - я не понимаю.

[Chervonenko_CA]

В 20.11.2018 в 14:44, Le ecureuil сказал:

Он и в 2.11 должен быть закрыт на вход с WAN, по крайней мере если специально не открывался.

Но вот как связан IPsec с ICMP - я не понимаю.

Новая GIGA "из коробки" шла с 2.11 вроде? В соотв. со статьёй из базы знаний настроил тоннель между ней и Omni II (c 2.08) и "прозвонил" его в обе стороны с помощью ping -  всё работало, т.е. icmp был.

Потом обновил прошивку на GIGA и чуток позже обнаружил, что тоннель "лежит", а log  Omni II забит руганью (что-то о недоступности хоста); ping не идёт,  traceroute затыкается где-то на подходах к Крымскому провайдеру.

Грешил на провайдера, писал письма. Ответили, что всё у них открыто, а traceroute затыкается уже у меня на роутере.

Открыл icmp на ГИГе (правило добавил) - сразу пошли как traceroute, так и ping! Поднял тоннель - он тоже живой!!

Совпадение? Или провайдер хитрит?

ЗЫ: "в обе стороны" я прозванивал внутренние адреса точно, а вот внешний - не помню...

ЗЗЫ: повторю эксперимент, выключу правило, доложу...

[Le ecureuil]

В 21.11.2018 в 15:11, Chervonenko_CA сказал:

Новая GIGA "из коробки" шла с 2.11 вроде? В соотв. со статьёй из базы знаний настроил тоннель между ней и Omni II (c 2.08) и "прозвонил" его в обе стороны с помощью ping -  всё работало, т.е. icmp был.

 Потом обновил прошивку на GIGA и чуток позже обнаружил, что тоннель "лежит", а log  Omni II забит руганью (что-то о недоступности хоста); ping не идёт,  traceroute затыкается где-то на подходах к Крымскому провайдеру.

 Грешил на провайдера, писал письма. Ответили, что всё у них открыто, а traceroute затыкается уже у меня на роутере.

Открыл icmp на ГИГе (правило добавил) - сразу пошли как traceroute, так и ping! Поднял тоннель - он тоже живой!!

Совпадение? Или провайдер хитрит?

ЗЫ: "в обе стороны" я прозванивал внутренние адреса точно, а вот внешний - не помню...

ЗЗЫ: повторю эксперимент, выключу правило, доложу...

А, вы проверяли адреса _внутри_ туннеля? Тогда это должно было работать конечно.

[Chervonenko_CA]

В 22.11.2018 в 17:35, Le ecureuil сказал:

А, вы проверяли адреса _внутри_ туннеля? Тогда это должно было работать конечно.

ВНУТРИ - разумеется проверял (перекрёстно, обе сетки). Но у GIGAи - динамический адрес, его тоже должен был "прозвонить" (по имени, что-б проверить ddns). НО - не помню.. Вдруг пропустил? давно было...

[dexter]

Что-то я уже всю голову сломал. Может так нельзя, но.

Есть у меня 2 кинетика и между ними 2 туннеля. IPIP c IPsec и внутри него EoIP.

Сегодня настроил IPSec между данными кинетика из вэб в режиме туннель и заменил в EoIP "tunnel destination" адреса с IPIP туннеля на адреса которые у IPSec. Но туннель по все видимости не поднимается, т.к. с кинетиков не пингуются удаленные бридж интерфейсы, в который входит данный туннель.

Постом ниже будут 2 селф-теста для понимания картины.

[p.povolotsky]

Столкнулся с интересным моментом при настройке IPSec через xauth, имеется клиент на линуксе подключающийся через pluto, который в процессе ловит следующую ошибку
Keenetic ULTRA ll 2.14.C.0.0-4

Цитата

фев 08 13:29:35 universe pluto[8881]: "786c8918-272f-4401-a31e-31383103cca0" #1: we require IKEv1 peer to have ID 'x.x.x.x', but peer declares '@mykeenetic.net'
фев 08 13:29:35 universe pluto[8881]: "786c8918-272f-4401-a31e-31383103cca0" #1: sending encrypted notification INVALID_ID_INFORMATION to x.x.x.x:4500

Так как роутер не имеет доменного имени, подключение задается через ip адрес.

[Le ecureuil]

1 час назад, p.povolotsky сказал:

Столкнулся с интересным моментом при настройке IPSec через xauth, имеется клиент на линуксе подключающийся через pluto, который в процессе ловит следующую ошибку
Keenetic ULTRA ll 2.14.C.0.0-4

Так как роутер не имеет доменного имени, подключение задается через ip адрес.

У вас что-то из libre/openswan? Поставьте им в rightid = @mykeenetic.net. Все равно rightid в данном случае бесполезен - у роутера может быть несколько интерфейсов, и через все на него можно прийти - какой IP выставлять?

[Леха из Питера]

Добрый день.

Имею следующую схему:

два роутера Zyxel Keenetic со своими ланами успешно соединяются по IPSec туннелю (по схеме net-to-net). Клиенты обеих ланов видят друг друга.

На сервере дополнительно запущен VPN IPSec для клиентов из интернета. Клиент на андроиде успешно соединяется с сервером, видит клиентов лана сервера, но не видит клиентов лана второго роутера.

Подозреваю, что не хватает маршрута из сети VPN в сеть второго роутера.

Прошу помощи.

[Constantin]

В 22.02.2018 в 16:07, Le ecureuil сказал:

IPsec XAuth PSK в роли клиента у нас не поддерживается.

Добрый день!

В Entware есть пакет, который может работать клиентом IPsec XAuth PSK?

[r13]

1 час назад, Constantin сказал:

Добрый день!

В Entware есть пакет, который может работать клиентом IPsec XAuth PSK?

В entware есть  strongswan, но от прошивочного ipsec функционала тогда придется отказаться. Использовать какой-то  один

[Constantin]

13 часа назад, r13 сказал:

В entware есть  strongswan, но от прошивочного ipsec функционала тогда придется отказаться. Использовать какой-то  один

Спасибо. В Entware есть пакет vpnc. Под линух он успешно используется как раз для подключения к Cisco VPN шлюзу. У нас будет работать? Смогу я завернуть трафик до нужных подсетей в подключение сделанное через этот клиент?

[r13]

15 минут назад, Constantin сказал:

Спасибо. В Entware есть пакет vpnc. Под линух он успешно используется как раз для подключения к Cisco VPN шлюзу. У нас будет работать? Смогу я завернуть трафик до нужных подсетей в подключение сделанное через этот клиент?

Попробуйте, потом нам расскажете 😉

[Constantin]

В 08.12.2019 в 14:51, r13 сказал:

Попробуйте, потом нам расскажете 😉

Ну что, рассказываю. Ставятся два пакета. Vpc и vpnc-scripts. Соединение с роутера до Cisco gateway поднимается на ура и работает.

С консоли роутра я пингую ресурсы за шлюзом. Маршруты прописываются автоматом полученные от Cisco.

А вот дальше, комрады, нужна ваша помощь. Надо чтоб маршруты прописались для устройств в локалке. А этого не происходит.

Прикладываю файл скрипта, кторый это все прописывает. Помогите, что надо там подправить, чтоб маршруты прописались не только для самого роутера, но и для всех подключенных к нему устройств.

vpnc-script