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 нету..

с 1.2 или 1.20 ?

без разницы. Не работает. Network::RoutingTable: renewed static route: 0.0.0.0/0 via 192.168.1.1 (Home). Окт 16 22:03:06 ndm Core::Ndss: [22013] no internet connection. Окт 16 22:03:27 ndm Core::Ndss: [22113] no internet connection. Окт 16 22:03:38 ndm Core::Ndss: [22147] no internet connection. Окт 16 22:03:50 ndm Core::Ndss: [22179] no internet connection.

~ # ifconfig br0 br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.2 netmask 255.255.255.0 broadcast 192.168.1.255 пробовал с 1.20 - без разницы.

не помогает.

эээ.. это же зернет а не p2p интерфейс - как его прописать? или вы имеете ввиду что надо дополнительно указать интерфейс? ~ # netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 br0 10.1.30.0 0.0.0.0 255.255.255.0 U 0 0 0 br1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 ~ # ip route l default via 192.168.1.1 dev br0 10.1.30.0/24 dev br1 proto kernel scope link src 10.1.30.1 192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.2 ~ # предупреждая вопрос - ничего особенного - в opkg не поставлено - только mc / tcpdump - только что бы анализировать трафик.

Так как официальный сапорт не смог решить эту проблему, попробуем решить ее тут. Есть Ultra - которая настроена в режиме только контролера wifi сети согласно https://help.keenetic.com/hc/ru/articles/360014436120-Возможно-ли-использовать-контроллер-Wi-Fi-системы-в-режиме-обычной-точки-доступа- - роутером выступает микротик 4011. На первый взгляд все работает config)> tools ping www.google.com sending ICMP ECHO request to www.google.com... PING www.google.com (142.250.74.132) 56 (84) bytes of data. 84 bytes from www.google.com (142.250.74.132): icmp_req=1, ttl=57, time=43.00 ms. 84 bytes from www.google.com (142.250.74.132): icmp_req=2, ttl=57, time=42.93 ms. 84 bytes from www.google.com (142.250.74.132): icmp_req=3, ttl=57, time=42.93 ms. --- www.google.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss, 0 duplicate(s), time 2243.89 ms. Round-trip min/avg/max = 42.93/42.95/43.00 ms. (config)> tools traceroute www.google.com starting traceroute to www.google.com... traceroute to www.google.com (142.250.74.132), 30 hops maximum, 60 byte packets. 1 192.168.1.1 (192.168.1.1) 0.413 ms 0.571 ms 0.290 ms 2 10.10.1.1 (10.10.1.1) 1.098 ms 47.861 ms 47.519 ms 3 gw.sevstar.net (109.110.64.10) 1.154 ms 1.008 ms 1.084 ms 4 ae19-535.svsl-30-ar1.miranda-media.net (185.64.47.165) 6.617 ms 2.131 ms 0.917 ms Но.. попытка получить обновления - уходит в цикл, keendns - говорит нет подключения, попытка добавить через мобильное приложение говорит "а давайте вы настроете сначала интернет". Хорошо - через web портал - устройство добавилось, видно в мобильном приложении - но остальных ошибок это не убрало. Из интересных сообщений в системном логе > Core::Ndss: [31930] no internet connection. и так в цикле. вопрос традиционный - что это такое - и как лечить? :)

Спасибо! arp флуд ушел. Но проблему с плавающим пингом это не полечило. При этом с железки подключений к Ultra по ethernet - пинг не плавает 😕 Но радует что теперь на viva - хорошо, и все что может быть это ultra которая отдает в воздух - при этом линк на 1170/1300 репортится (тут до полуметра к точке).

И так и так. все одно. вот примерно так это выглядит к привязке к ICMP.

готово. отправил.

192.168.10.x - это сегмент "home". в guest - тоже отключено. разборки начались когда стали появляться непонятные задержки по wifi - по времени совпадающие с появлением мультикста (по статистике на интерфейсе). ultra в 50см от ноута - 1300 линк и периодические всплески задержки до 300мс. Что в целом логично ибо все ждут ответа на arp who-was...