Alexey Lyahkov
-
Posts
54 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by Alexey Lyahkov
-
-
Судя по всему обновление на 3.9.1 - не решает проблему с периодическими отвалами ipsec. Обновил одну из точек на 3.9.1 - стало стабильнее - но 8 часов лимита у l2tp+ipsec никуда не пропали.
-
Раздельно работает с любой частью на другой стороне (в моем случае это микротик или линукс) - а "вместе" - работает только между кинетиками.
"Вместе" не поддерживает авторизацию по fqdn - когда с другой стороны динамический адрес, нужны статические адреса. Вот ipsec сам по себе дает статические адреса на обоих сторонах - а тунель позволяет не заморачиваться с кучей политик если у тебя на обоих сторонах более чем одна сеть (нужна политика только для сети (или двух адресов с /32) которая(ые) обслуживают ipsec трафик.
Это основные причины. Есть еще куча дополнительных типа удобства в отладке - установки нужных мне алгоритмов шифрования и тп.Раздельно - позволяет достаточно легко менять транспорт для шифрования - будь то ipsec, буть то openvpn, будть то WireGuard, или openconnect server. Раздельно позволит на стороне сервера - использовать продвинутую авторизацию (да хоть тот же радиус) и тп.
Вот такие причины делать все раздельно, а не пытаться использовать комбайн.
-
1
-
-
а почему не положить поверх 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 в простейшем конфиге.
Что посмотреть в кинетике/подкрутить ?
-
Такс.. пардон - не уследил что
Цитатаip route default 192.168.1.1остался в конфиге не смотря на "no ip ..." - почему-то удалило то что с Home.
после правки - заработало.
Спасибо большое!
-
6 минут назад, sergeyk сказал:
ip route default 192.168.1.1 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 минуту назад, sergeyk сказал:
Прикрепите self-test в скрытом сообщении.
с 1.2 или 1.20 ?
-
2 минуты назад, vasek00 сказал:
ip route default 192.168.130.97 Homeбез разницы. Не работает.
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. -
20 минут назад, sergeyk сказал:
Какой у вас адрес на br0?
~ # 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 - без разницы. -
не помогает.
ЦитатаNetwork::RoutingTable: added static route: 0.0.0.0/0 via Home.Окт 16 21:36:22ndmCore::Ndss: [16060] no internet connection.Окт 16 21:36:30ndmCore::Ndss: [16088] no internet connection.Окт 16 21:36:41ndmCore::Ndss: [16107] no internet connection.Окт 16 21:36:53ndmCore::Ndss: [16166] no internet connection.Окт 16 21:36:54ndmCore::Ndss: [16179] no internet connection.Окт 16 21:37:04ndmCore::Ndss: [16227] no internet connection. -
Только что, sergeyk сказал:
Пропишите маршрут по умолчанию с Ultra через интерфейс, а не через подсеть.
эээ.. это же зернет а не 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.comsending ICMP ECHO request to www.google.com...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.comstarting traceroute to www.google.com...1 192.168.1.1 (192.168.1.1) 0.413 ms 0.571 ms 0.290 ms2 10.10.1.1 (10.10.1.1) 1.098 ms 47.861 ms 47.519 ms3 gw.sevstar.net (109.110.64.10) 1.154 ms 1.008 ms 1.084 ms4 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.
и так в цикле.
вопрос традиционный - что это такое - и как лечить? :) -
12 часа назад, werldmgn сказал:
ip hotspot auto-scan no interface Guest
Спасибо! arp флуд ушел.
Но проблему с плавающим пингом это не полечило. При этом с железки подключений к Ultra по ethernet - пинг не плавает 😕
Но радует что теперь на viva - хорошо, и все что может быть это ultra которая отдает в воздух - при этом линк на 1170/1300 репортится (тут до полуметра к точке).
-
7 минут назад, Илья Картавенко сказал:
После отключения igmp роутер перезагрузили?
И так и так. все одно.
вот примерно так это выглядит к привязке к ICMP.ЦитатаAlexeys-MacBook-Pro:log root# tcpdump -n -i en0 | grep -e ICMP -e who-has
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:50:23.325202 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 23, length 64
19:50:23.327985 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 23, length 64
19:50:23.725815 ARP, Request who-has 192.168.10.116 tell 192.168.10.1, length 46
19:50:23.725821 ARP, Request who-has 192.168.10.117 tell 192.168.10.1, length 46
19:50:23.725871 ARP, Request who-has 192.168.10.118 tell 192.168.10.1, length 46
19:50:24.326791 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 24, length 64
19:50:24.329214 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 24, length 64
19:50:24.647409 ARP, Request who-has 192.168.10.119 tell 192.168.10.1, length 46
19:50:24.647414 ARP, Request who-has 192.168.10.120 tell 192.168.10.1, length 46
19:50:24.647466 ARP, Request who-has 192.168.10.121 tell 192.168.10.1, length 46
19:50:25.331070 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 25, length 64
19:50:25.333050 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 25, length 64
19:50:25.671347 ARP, Request who-has 192.168.10.122 tell 192.168.10.1, length 46
19:50:25.671353 ARP, Request who-has 192.168.10.123 tell 192.168.10.1, length 46
19:50:25.671405 ARP, Request who-has 192.168.10.124 tell 192.168.10.1, length 46
19:50:26.183220 IP6 fe80::52ff:20ff:fe53:ea62 > ff02::2: ICMP6, router solicitation, length 8
19:50:26.183294 IP6 fe80::52ff:20ff:fe1e:7d76 > ff02::1: ICMP6, router advertisement, length 24
19:50:26.331556 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 26, length 64
19:50:26.334298 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 26, length 64
19:50:26.695479 ARP, Request who-has 192.168.10.125 tell 192.168.10.1, length 46
19:50:26.695484 ARP, Request who-has 192.168.10.126 tell 192.168.10.1, length 46
19:50:26.695535 ARP, Request who-has 192.168.10.127 tell 192.168.10.1, length 46
19:50:27.336752 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 27, length 64
19:50:27.339589 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 27, length 64
19:50:27.719481 ARP, Request who-has 192.168.10.128 tell 192.168.10.1, length 46
19:50:27.719487 ARP, Request who-has 192.168.10.129 tell 192.168.10.1, length 46
19:50:27.719537 ARP, Request who-has 192.168.10.130 tell 192.168.10.1, length 46
19:50:28.338390 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 28, length 64
19:50:28.341115 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 28, length 64
19:50:28.641120 ARP, Request who-has 192.168.10.131 tell 192.168.10.1, length 46
19:50:28.641126 ARP, Request who-has 192.168.10.132 tell 192.168.10.1, length 46
19:50:28.641175 ARP, Request who-has 192.168.10.133 tell 192.168.10.1, length 46
19:50:29.152981 IP6 fe80::52ff:20ff:fe1e:7d76 > ff02::1: ICMP6, router advertisement, length 24
19:50:29.339095 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 29, length 64
19:50:29.341868 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 29, length 64
19:50:30.340641 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 30, length 64
19:50:30.509818 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 30, length 64
19:50:31.345837 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 31, length 64
19:50:31.537960 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 31, length 64
19:50:32.351016 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 32, length 64
19:50:32.985938 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 32, length 64
19:50:33.355067 IP 192.168.10.10 > 192.168.10.1: ICMP echo request, id 23607, seq 33, length 64
19:50:33.357414 IP 192.168.10.1 > 192.168.10.10: ICMP echo reply, id 23607, seq 33, length 64Цитата64 bytes from 192.168.10.1: icmp_seq=103 ttl=64 time=2.087 ms
64 bytes from 192.168.10.1: icmp_seq=104 ttl=64 time=2.028 ms
64 bytes from 192.168.10.1: icmp_seq=105 ttl=64 time=1.758 ms
64 bytes from 192.168.10.1: icmp_seq=106 ttl=64 time=2.909 ms
64 bytes from 192.168.10.1: icmp_seq=107 ttl=64 time=2.846 ms
64 bytes from 192.168.10.1: icmp_seq=108 ttl=64 time=64.757 ms
64 bytes from 192.168.10.1: icmp_seq=109 ttl=64 time=88.380 ms
64 bytes from 192.168.10.1: icmp_seq=110 ttl=64 time=532.558 ms
64 bytes from 192.168.10.1: icmp_seq=111 ttl=64 time=2.796 ms
64 bytes from 192.168.10.1: icmp_seq=112 ttl=64 time=2.036 ms
64 bytes from 192.168.10.1: icmp_seq=113 ttl=64 time=2.141 ms
64 bytes from 192.168.10.1: icmp_seq=114 ttl=64 time=2.803 ms
64 bytes from 192.168.10.1: icmp_seq=115 ttl=64 time=2.743 ms
64 bytes from 192.168.10.1: icmp_seq=116 ttl=64 time=2.105 ms
64 bytes from 192.168.10.1: icmp_seq=117 ttl=64 time=2.814 ms
64 bytes from 192.168.10.1: icmp_seq=118 ttl=64 time=2.812 ms
64 bytes from 192.168.10.1: icmp_seq=119 ttl=64 time=2.806 ms
64 bytes from 192.168.10.1: icmp_seq=120 ttl=64 time=2.620 ms
64 bytes from 192.168.10.1: icmp_seq=121 ttl=64 time=2.577 ms
64 bytes from 192.168.10.1: icmp_seq=122 ttl=64 time=3.520 ms
64 bytes from 192.168.10.1: icmp_seq=123 ttl=64 time=51.830 ms
64 bytes from 192.168.10.1: icmp_seq=124 ttl=64 time=64.764 ms
64 bytes from 192.168.10.1: icmp_seq=125 ttl=64 time=297.448 ms
64 bytes from 192.168.10.1: icmp_seq=126 ttl=64 time=16.862 ms
64 bytes from 192.168.10.1: icmp_seq=127 ttl=64 time=5.048 ms
64 bytes from 192.168.10.1: icmp_seq=128 ttl=64 time=3.018 ms
64 bytes from 192.168.10.1: icmp_seq=129 ttl=64 time=2.730 ms -
готово. отправил.
-
192.168.10.x - это сегмент "home". в guest - тоже отключено.
разборки начались когда стали появляться непонятные задержки по wifi - по времени совпадающие с появлением мультикста (по статистике на интерфейсе).
ultra в 50см от ноута - 1300 линк и периодические всплески задержки до 300мс. Что в целом логично ибо все ждут ответа на arp who-was... -
IGMP proxy было включено. Отключил - поведение не изменилось.
-
Собрана wifi система из Viva (master) + Ultra.. Версии - последний stable.
В какой-то момент заинтересовался странным количеством мультикаста, и tcpdump выдал следующее.
как будто viva решила просканировать сеть.
Цитатаtcpdump -s0 -n -i eno2 not port ssh | grep tell
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno2, link-type EN10MB (Ethernet), capture size 262144 bytes
15:44:38.846987 ARP, Request who-has 192.168.10.84 tell 192.168.10.1, length 46
15:44:38.847041 ARP, Request who-has 192.168.10.85 tell 192.168.10.1, length 46
15:44:38.847144 ARP, Request who-has 192.168.10.86 tell 192.168.10.1, length 46
15:44:39.846188 ARP, Request who-has 192.168.10.87 tell 192.168.10.1, length 46
15:44:39.846188 ARP, Request who-has 192.168.10.88 tell 192.168.10.1, length 46
15:44:39.846374 ARP, Request who-has 192.168.10.89 tell 192.168.10.1, length 46
15:44:40.845841 ARP, Request who-has 192.168.10.90 tell 192.168.10.1, length 46
15:44:40.845882 ARP, Request who-has 192.168.10.91 tell 192.168.10.1, length 46
15:44:40.846013 ARP, Request who-has 192.168.10.92 tell 192.168.10.1, length 46
15:44:41.845313 ARP, Request who-has 192.168.10.93 tell 192.168.10.1, length 46
15:44:41.845411 ARP, Request who-has 192.168.10.94 tell 192.168.10.1, length 46
15:44:41.845464 ARP, Request who-has 192.168.10.95 tell 192.168.10.1, length 46
15:44:42.843681 ARP, Request who-has 192.168.10.96 tell 192.168.10.1, length 46
15:44:42.843722 ARP, Request who-has 192.168.10.97 tell 192.168.10.1, length 46
15:44:42.843830 ARP, Request who-has 192.168.10.98 tell 192.168.10.1, length 46
15:44:43.843510 ARP, Request who-has 192.168.10.99 tell 192.168.10.1, length 46при этом локальной arp таблице
~ # arp -an | grep incom
? (192.168.10.6) at <incomplete> on br0
? (192.168.10.36) at <incomplete> on br0
? (192.168.10.12) at <incomplete> on br0
? (192.168.10.23) at <incomplete> on br0+ каждую секунду спамит STP пакетами.
Вопрос обычный. С чем может быть связано такое поведение и как его отключить ?
-
вопрос снят. после обновления в конфиге появилось isolate-private. вынес - заработало.
-
День добрый.
После обновления одного из кинетиков (giga) на 3.6.3 начались чудеса.
дано ipip0 security private , отключен nat на ipip0 (no ip nat Home, ip static nat Home ISP), в ipip0 завернут роутинг для сети 192.168.1.0/24, локальная сеть 192.168.3.0/24. Судя по захвату пакетов пакеты в ipip0 не ходят 😕 при этом с самого роутера сеть 192.168.1.0/24 отлично пингуется.
Подскажите что проверить стоит.
-
On 2/16/2021 at 8:58 PM, Le ecureuil said:
Ну вот смотрите - есть к примеру web-сервер. Его нужно собирать два раза - с ipv6 и без? И тестировать два раза? А кто за это заплатит (условно)? И вот так с каждой мелочью в ipv6.
Потому следующий шаг после текущего - полная интеграция.
Пример web сервера не очень удачный - хотя.. смотря как посмотреть. Если мой склероз не изменяет (ну или можно спросить у авторов) nginx поддерживает откат на использование ipv4 если ipv6 не доступен. В крайнем случае можно собрать ядро с поддержкой ipv6 - но при этом userspace делать опциональной компонентой. у и всякие forward / iptables - они отдельными sysctl и пакетами.
И того - у вас ровно одно тестирование nginx (listen [::]:80) - ну или можно озадачить Сысоева и сотоварищей - думаю даже после перехода в F5 они возьмут на сапорт ваш nginx.
Перестал подключаться к VPN-серверу IKEv2 StrongSwan
in Обсуждение IPsec, OpenVPN и других туннелей
Posted
есть не нулевое подозрение что отвалы ipsec связаны с dhcp lease time и renew 😕