Alexey Lyahkov

> self-test-то где? Как и просили раньше он был отправлен месяц назад в support - тикет 634093. Из письма на help@

Как и ожидалось в 4.2.1 не исправлено. Все та же ерунда # ip route list table 10 default via 100.76.249.1 dev eth3 78.30.227.41 via 100.76.249.1 dev eth3 78.30.254.20 via 100.76.249.1 dev eth3 78.30.254.55 via 100.76.249.1 dev eth3 100.76.249.0/24 dev eth3 scope link 172.16.10.1 dev ppp1 scope link 172.16.10.45 dev ppp0 scope link 192.168.0.0/16 dev ipip0 scope link 192.168.2.1 dev ppp0 scope link 192.168.12.0/24 dev ppp1 scope link 192.168.12.1 dev ppp1 scope link 192.168.14.0/24 dev br0 scope link 198.18.0.2 via 100.76.249.1 dev eth3 198.18.1.12/30 dev ipip0 scope link

Хм... Весьма странный ответ. Из разряда сам дурак ? Быстрый просмотр changelog - говорит нету изменений которые могли быть связанными с этой проблемой.

После направления информации в Сапорт - не было предложено ничего лучше чем проверить isolate-private, и ip global у ipip интерфейса. Оба этих параметра стоят как нужно, и с тех пор уже неделю Сапорт молчит. Это исправится в релизе ?

Кинетик Ультра с 2мя таблицами роутинга. Части клиентов надо выходить в мир через ipip тунель поверх ipsec, часть напрямую. После обновления на 4.2 Beta3 - перестало работать. Если смотреть в вывод ip route list table 11 то дефолт вообще указывает не на ip-ip тунель, а на ppp который далеко не первый в списке. У таблицы 10 дефолт вообще указывает в ethernet - когда он запрещен для этой группы. # ip route list table 10 default via 100.76.249.1 dev eth3 78.30.227.41 via 100.76.249.1 dev eth3 78.30.254.20 via 100.76.249.1 dev eth3 78.30.254.55 via 100.76.249.1 dev eth3 100.76.249.0/24 dev eth3 scope link 172.16.10.1 dev ppp2 scope link 172.16.10.45 dev ppp0 scope link 192.168.0.0/16 dev ipip0 scope link 192.168.2.1 dev ppp0 scope link 192.168.12.0/24 dev ppp2 scope link 192.168.12.1 dev ppp2 scope link 192.168.14.0/24 dev br0 scope link 198.18.0.2 via 100.76.249.1 dev eth3 198.18.1.12/30 dev ipip0 scope link ~ # ip route list table 11 default dev ppp2 scope link 100.76.249.0/24 dev eth3 scope link 172.16.10.1 dev ppp2 scope link 172.16.10.45 dev ppp0 scope link 192.168.0.0/16 dev ipip0 scope link 192.168.2.1 dev ppp0 scope link 192.168.12.0/24 dev ppp2 scope link 192.168.12.1 dev ppp2 scope link 192.168.14.0/24 dev br0 scope link 198.18.1.12/30 dev ipip0 scope link

Кинетик Ультра с 2мя таблицами роутинга. Части клиентов надо выходить в мир через ipip тунель поверх ipsec, часть напрямую. После обновления на 4.2 Beta3 - перестало работать. Если смотреть в вывод ip route list table 11 то дефолт вообще указывает не на ip-ip тунель, а на ppp который далеко не первый в списке. У таблицы 10 дефолт вообще указывает в ethernet - когда он запрещен для этой группы. # ip route list table 10 default via 100.76.249.1 dev eth3 78.30.227.41 via 100.76.249.1 dev eth3 78.30.254.20 via 100.76.249.1 dev eth3 78.30.254.55 via 100.76.249.1 dev eth3 100.76.249.0/24 dev eth3 scope link 172.16.10.1 dev ppp2 scope link 172.16.10.45 dev ppp0 scope link 192.168.0.0/16 dev ipip0 scope link 192.168.2.1 dev ppp0 scope link 192.168.12.0/24 dev ppp2 scope link 192.168.12.1 dev ppp2 scope link 192.168.14.0/24 dev br0 scope link 198.18.0.2 via 100.76.249.1 dev eth3 198.18.1.12/30 dev ipip0 scope link ~ # ip route list table 11 default dev ppp2 scope link 100.76.249.0/24 dev eth3 scope link 172.16.10.1 dev ppp2 scope link 172.16.10.45 dev ppp0 scope link 192.168.0.0/16 dev ipip0 scope link 192.168.2.1 dev ppp0 scope link 192.168.12.0/24 dev ppp2 scope link 192.168.12.1 dev ppp2 scope link 192.168.14.0/24 dev br0 scope link 198.18.1.12/30 dev ipip0 scope link

есть не нулевое подозрение что отвалы ipsec связаны с dhcp lease time и renew 😕

Судя по всему обновление на 3.9.1 - не решает проблему с периодическими отвалами ipsec. Обновил одну из точек на 3.9.1 - стало стабильнее - но 8 часов лимита у l2tp+ipsec никуда не пропали.

Раздельно работает с любой частью на другой стороне (в моем случае это микротик или линукс) - а "вместе" - работает только между кинетиками. "Вместе" не поддерживает авторизацию по fqdn - когда с другой стороны динамический адрес, нужны статические адреса. Вот ipsec сам по себе дает статические адреса на обоих сторонах - а тунель позволяет не заморачиваться с кучей политик если у тебя на обоих сторонах более чем одна сеть (нужна политика только для сети (или двух адресов с /32) которая(ые) обслуживают ipsec трафик. Это основные причины. Есть еще куча дополнительных типа удобства в отладке - установки нужных мне алгоритмов шифрования и тп. Раздельно - позволяет достаточно легко менять транспорт для шифрования - будь то ipsec, буть то openvpn, будть то WireGuard, или openconnect server. Раздельно позволит на стороне сервера - использовать продвинутую авторизацию (да хоть тот же радиус) и тп. Вот такие причины делать все раздельно, а не пытаться использовать комбайн.

а почему не положить поверх WG обычный ip-ip / gre / eth over ip / ... etc тунель? пусть wg отвечает за шифрование точка - точка и вообще о сетях не знает?

>Правда работает ~7 часов и опять пропадает. Ровно 8 часов. Иногда идет ругань о том что такой же SA уже есть в ядре. По ощущениям ошибку притащили в 3.8.5 а пару релизов до этого - все работало как часы.

Есть более простое решение. Создаем ipsec в режиме точка-точка, внутрь этого ipsec добавляем ip-ip / gre тунели. Внимательно следим за src address для пакетов тунеля. Нужный адрес создаем как алиас на интересе Home. После чего задача упрощается - и в тунель можно заворачивать любые сети. как-то так access-list _WEBADMIN_IPSEC_sev permit ip 198.18.0.3 255.255.255.255 198.18.0.2 255.255.255.255 ... interface Bridge0 rename Home description "Home network" ip address 192.168.3.1 255.255.255.0 ip alias 198.18.0.3 255.255.255.255 interface IPIP0 security-level private ip address 198.18.1.6 255.255.255.252 ip mtu 1400 ip access-group _WEBADMIN_IPIP0 in ip global 41221 ip tcp adjust-mss pmtu tunnel source 198.18.0.3 tunnel destination 198.18.0.2 up у самого ipsec - настраиваем авторизацию по FQDN.

День добрый. Наблюдается подводный стук. В наличии несколько девайсов кинетика - Giga и что-то еще у коллеги (без usb порта). Каждый из них поднимает l2tp сессию с сервером на Alma9 - но каждые 8 часов происходит reconnect. Доступа к всем железкам нету, но к той что есть - в логе записи что ipsec peer down, что вполне возможно - если бы это не происходило у всех и ровно через 8 часов. # radlast | grep tagan | head -10 tagan1 004:localhos 192.0.0.117 Mon Dec 12 15:54 gone - no logout tagan1 004:localhos 192.0.1.133 Mon Dec 12 07:54 - 15:54 (08:00) tagan1 004:localhos 192.0.0.60 Sun Dec 11 23:52 - 07:53 (08:01) tagan1 004:localhos 192.0.0.232 Sun Dec 11 18:26 - 23:52 (05:25) tagan1 004:localhos 192.0.1.133 Sun Dec 11 10:25 - 18:26 (08:01) tagan1 004:localhos 192.0.0.117 Sun Dec 11 02:23 - 10:25 (08:01) tagan1 004:localhos 192.0.1.133 Sat Dec 10 18:22 - 02:23 (08:01) tagan1 004:localhos 192.0.0.117 Sat Dec 10 10:21 - 18:22 (08:01) tagan1 004:localhos 192.0.1.148 Sat Dec 10 07:02 - 10:16 (03:14) tagan1 004:localhos 192.0.1.25 Fri Dec 9 23:00 - 07:01 (08:01) При этом всем сессия которую поднимает микротик 4011 - держится несколько суток. Со стороны сервера стоит strongwan в простейшем конфиге. Что посмотреть в кинетике/подкрутить ?

Такс.. пардон - не уследил что остался в конфиге не смотря на "no ip ..." - почему-то удалило то что с Home. после правки - заработало. Спасибо большое!

Не помогло.