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.

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

Не помогло.

я бы сказал что даже сокета через который должно запрашиваться обновление не видно в системе. в одном окне браузера открыта вкладка "общие настройки" где идет проверка обновлений, при этом в консоли ~ # netstat -4np Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.1.2:80 192.168.1.64:59766 ESTABLISHED 1105/nginx: worker tcp 0 0 192.168.1.2:80 192.168.1.64:59732 ESTABLISHED 1105/nginx: worker tcp 0 0 192.168.1.2:80 192.168.1.64:59767 ESTABLISHED 1105/nginx: worker tcp 0 0 192.168.1.2:80 192.168.1.64:59769 ESTABLISHED 1105/nginx: worker tcp 0 180 192.168.1.2:222 192.168.1.64:58738 ESTABLISHED 15855/dropbear tcp 0 0 192.168.1.2:49508 192.168.1.3:3517 TIME_WAIT - tcp 0 0 192.168.1.2:80 192.168.1.64:59768 ESTABLISHED 1105/nginx: worker tcp 0 0 192.168.1.2:49510 192.168.1.3:3517 TIME_WAIT - в это же время ~ # tcpdump -s 0 -vv -n -i br0 port 53 and host 192.168.1.2 - показывает тишину - значит запросов на dns нету..