Alexey Lyahkov

а Микротик сделал ipv6 опциональным.. Может и вам так же ? Там по сути набор userspace софта который можно и не ставить 😕

Но роутинг странный. 198.18.0.2 via 31.x.x.x dev eth3 table 248 proto static src 198.18.0.1 mtu 1500 advmss 1460 адрес 31.x.x.x не является direct reachable для этого хоста - я честно удивлен что его дали добавить. Гораздо логичнее был адрес 100.x.x.1 который является шлюзом для этого кинетика для ISP интерфейса

попробую, но не гарантирую что это будет быстро. Кроме того отваливание интерфейса - меня волнует достаточно слабо. Как раз таки умирающий трафик был бы лучше - иначе пришлось быть делать отдельно blackhole для этих IP адресов. Ибо специфика доступа из Крыма к некоторым адресам на территории US. PS. только сейчас обратил внимание что destination ip печатается криво в ifconfig ipip0 PPS. нашел таки роутинг на пира в ipip0 в 248 таблице

Не будет работать в моем случае - по двум причинам. 1. На той стороне Mikrotik 4011 - к которому надо подбирать отдельные настройки. Возможно получится - возможно нет. 2. На стороне "клиента" - динамический "серый" адрес. В то время как ip tunnel ipip требует указания на обоих сторонах destination ip. PS. и все это что бы при создании ipsec peer не добавлять его адрес в роутинг.. собственно это больше для других кто наступит на эту же бяку.

в смысле автоматический? вы имеете ввиду ipsec в туннельном режиме? Тогда прикиньте сколько нужно политик прописать когда с обоих сторон туннеля по 5-7 сетей. Я молчу о том что с другой стороны Mikrotik 4011 - как vpn шлюз. У того проблемы с несколькими сетями в рамках фазы 2 есть проблемы. Или вы о l2tp ?

Хм.. вроде привел пример. Давайте еще раз. 1. По совету KorDen был сделан ip route add default ipip0 и через политику назначено 2м хостам в локалке. ip route default IPIP0 2. Через политику назначено некоторым хостам. ip policy vpn-gw description vpn-gw permit global IPIP0 permit global Wireguard0 permit global ISP ! 3. crypto map home2 set-peer xxxxx.keenetic.name .. ---- Таблица роутинга как ее видел кинетик - я показал выше. > show ip route ================================================================================ Destination Gateway Interface Metric ================================================================================ 0.0.0.0/0 100.68.91.1 ISP 0 5.8.48.16/32 100.68.91.1 ISP 0 10.1.30.0/24 0.0.0.0 Guest 0 100.68.91.0/24 0.0.0.0 ISP 0 Устраиваем reboot.. ОПА.. и ipsec не поднимается - говорит не могу достучаться до пира. I [Feb 15 10:00:58] ipsec: 12[IKE] retransmit 7 of request with message ID 0 I [Feb 15 10:01:14] ipsec: 10[IKE] retransmit 8 of request with message ID 0 I [Feb 15 10:01:31] ipsec: 10[IKE] giving up after 8 retransmits I [Feb 15 10:01:31] ndm: IpSec::Configurator: "home2": schedule reconnect for crypto map. I [Feb 15 10:01:31] ipsec: 10[IKE] establishing IKE_SA failed, peer not responding делаем ip route 31.28.251.xxx ISP IPSEC поднимается, и вся схема работает. Получается по какой-то причине ipsec демон не может найти роутинг до пира.

@Le ecureuil маленькое дополнение по глюкам. Воспользовавшись советом default в ipip0 наткнулся на баго/фичу. IPsec тунель не добавляет свой peer в роутинг на дефолтовый интерфейс. В результате ipsec тихо умирает и не может найти пира. Хотя show ip route видит default в нужный интерфейс 😕 Добавление руками адреса пира в роутинг решает проблему - но не кошерно система должна сама это делать. С туннельными адресами меня берет сомнение.. но выглядит как тоже надо бы добавить - во избежание глюков.

~ # opkg list | grep openconnect openconnect - 8.10-3 - A VPN client compatible with several SSL VPN implementations (ocserv, Cisco AnyConnect, Juniper, Palo Alto) OpenConnect is an SSL VPN client initially created to support Cisco's AnyConnect SSL VPN. It has since been extended to support the Pulse Connect Secure VPN (formerly known as Juniper Network Connect or Junos Pulse) and the Palo Alto Networks GlobalProtect SSL VPN. A corresponding OpenConnect VPN server implementation can be found in the ocserv package. только генерировать пароль от токенов прийдется на чем нить.

спасибо, за подсказки! заработало адекватно. хотелось еще PBR в виде - вот эти хосты ходят в интерфейс только если это не к этим адресам - но в тех местах где стоят кинетики - это наверно не нужно. А в тике это было реализовано одним правилом с 2мя IPSET списками.

(config)> ip route default IPIP0 auto Network::RoutingTable error[5046298]: automatic default routes are invalid. > show interface ipip0 id: IPIP0 index: 0 type: IPIP description: interface-name: IPIP0 link: up connected: yes state: up mtu: 65516 tx-queue: 1 address: 198.18.1.1 mask: 255.255.255.252 uptime: 12856 global: yes defaultgw: no priority: 350 security-level: private tunnel-local-source: 198.18.0.1 tunnel-remote-destination: 198.18.0.2 ipsec-enabled: no ipsec-ikev2-allowed: yes ipsec-ikev2-enabled: no

Простите - но дико не удобно. Когда у тебя больше пары интерфейсов - прийдется прописывать в конфиг MxN (m - гостевых, N - внешних) строк что бы описать что же и как натить. И молиться что бы не одну из конфигураций не забыть 😕 Тогда как перечисление только тех где натить - дало бы в разы меньше строк. Я подозревал что прийдется делать ip static ... но похоже более простое решение это N строчек в _NDM_MASQ_BYPASS - для исключения интерфейсов где натить не нужно.

@Le ecureuil К сожалению это не сверх паранойя. А требование вполне конкретных отделов. PS. разворачивать полный SA (как сделано у Микротиков - не стоит, кому это надо - будет специальный комп). А вот загрузка сертификатов - сделать и не долго и приятно людям.

После некоторой эксплуатации данной связки накопились проблемы. 1. Не возможность использовать policy routing в данной связке. ip policy принимает в конфиге и вебморде только "global" интерфейсы - ipip0 по какой-то причине этим не является. Фича или Бага? Выход из положения через Enterware и перебивание содержимого ip таблицы - мягко скажем не очень приятен. 2. Как не крути - Кинетик упорно делает NAT на ipip0 (no ip nat ipip0 естественно сделан). Найден вариант с #!/bin/sh [ "$table" != "nat" ] && exit 0 iptables -t nat -I _NDM_MASQ_BYPASS -o ipip0 -j ACCEPT Но как-то вот.. 3. В качестве пожелания - сделать PBR через ipset а не через стопку одинаковых правил. И вам проще - и файрволу напрягаться меньше.

спасибо!

А проще тем что есть how-to для Mikrotik сразу https://mikrotik.wiki/wiki/VPN:IPsec_(аутентификация_с_помощью_сертификата) https://system-administrators.info/?p=2094 Ну и не один из этих how-to не предусматривает скачивание откуда-то полного списка корневых сертификатов.

Генерация сертификатов полностью подконтрольна организации. Как SA так и конкретный сертификат для пира. Вполне документируемая и не допускает даже потенциальную утечку данных о сертификатах. Хотя я вижу вы полностью верите Let's crypt и что они совершенно никогда и никому (даже если прийдут правильные органы) не выпустят дубль сертификата. Напомню - что выпуск сертификатов дублей уже был в истории. Не Let's crypt другими SA - но был. Я вот не уверен что вы готовы поручиться что их не будет в будущем? линки илюстрируюие - https://www.securitylab.ru/analytics/365717.php - https://www.opennet.ru/opennews/art.shtml?num=36712 ну и там куча всяких других.

Судя по анонсам сделали ipsec с сертификатами Let's crypt, а почему бы не сделать загрузку сертификатов и тп - из собственного SA. (опционально еще генерацию этого самого SA). Тогда товарищам Microtic админам будет сильно легче - ибо в наличии будет how-to как для сервера, так и для клиента.

все таки определенные проблемы в логике у авторов микротика есть. Если нужно создавать несколько пиров у которых динамические адреса и которых надо разделять по FQDN, то надо создать 1 пира который слушает 0/0, и 2 комплекта policy / identifies - каждая из которых описывает пира. В остальном ... все работает.

А почему не сделать то как делали в старые времена? выделить фейковую сетку и поднять IPIP / GRE / anything - тунель в который маршрутизируй хоть черта в ступе. (если хочется совсем автоматом - поднимается ospf и больше в эту схему не заглядываем не разу)

Буквально на днях поднял IPSec между M 4011 и Viva. Микротик выступил ike v2 сервером (Изначально на месте M 4011 был Kenetik GIGA III.) - Viva клиентом. Особых сложностей не возникло. За основу взял https://www.anz.ru/2017/03/23/ipsec-between-mikrotik-and-keenetic-ultraii/ . У подключения M - статический белый адрес, у Viva - динамический белый. Схема была создана следующая. IPsec в туннельном режиме - авторизация по FQDN - адреса туннеля выбраны для них из алиасов созданных с /32 маской. Поверх этой фейковой сети - поднят IPIP тунель - в который тунелируется трафик - так как M - планируется центральным vpn сервером куда будут сходиться разные сети, и не хочется рисовать кучу ipsec политик. На стороне тика - очень помогло добавить в логирование *.debug - видны все ошибки от ipsec.

Замена GIGA III на Mikrotik 4011 - добавила еще 5-10мбит/с - ipsec трафик держится на скорости около 92-95мбит/с

Хм.. условия достаточно тепличные - но.. GiGA III + Viva - у обоих на порту зажато 100мбит (специфика провайдера) - через ipsec + ipip тунель тянется с NAS стоящий за giga на другой NAS стоящий за viva.. ssh трафик. в графике загрузки стоит 80-90 мбит/с. Было бы наверно и больше но на той стороне стоит слабенькая железка - где ssh уперся в CPU.

А такой вопрос - можно сделать что бы опция 249 по умолчанию совпадала с 121й опцией? а вот если уж админ захотел отдельно назначить 249 - то брать то что назначил.

спасибо.

собственно systemd - поступает ровно так же. https://github.com/systemd/systemd/issues/5695 оно понятно что можно задать 121 опцию через hex или ascii - но не хотелось бы...