Перейти к содержанию

vasek00

Участники форума
 Профиль  Обзор контента

  • Постов

    4 749

  • Зарегистрирован

  • Посещение

  • Победитель дней

    79

 Тип контента 

Сообщения, опубликованные vasek00

    Хотелка - удаление маршрутов с помощью импорта файла

    в Развитие

    Опубликовано

    3 минуты назад, Кинетиковод сказал:

    Тут всё индивидуально. Кто-то может руками набивал изначально и батника исходника у него нет. Тогда надо добавить выгрузку маршрутов в батник, чего тут мелочиться то.

    Это да.

    Но когда роутер настроен и работает, то правильней сохранить конф файл тек.настроек -> он файл всегда под рукой.

    Хотелка - удаление маршрутов с помощью импорта файла

    в Развитие

    Опубликовано

    51 минуту назад, Кинетиковод сказал:

    Само собой. Тут имеется ввиду, что есть батник для добавления маршрутов. Переделать его для удаления недолго. Если конечно куча маршрутов набито вручную, то батник для удаления делать долго. Быстрее галки понатыкать.

    Быстрее удалить в конф файле нужный блок, где он можно посмотреть чуть выше. Да потом придется залить конф обратно.

    Хотелка - удаление маршрутов с помощью импорта файла

    в Развитие

    Опубликовано · Изменено пользователем vasek00

    22 минуты назад, VVS сказал:

    А зачем набивать вручную, если можно набить в батник?

    Быстрее получится в результате.

    А зачем НАБИВАТЬ в батник, если можно быстрее в конф файл 

    ip policy Policy3
route 142.250.0.0 255.254.0.0 Wireguard0 auto reject

или в основном 
ip route 142.250.0.0 255.254.0.0 Wireguard0 auto reject !yt1

    копируете данную строку n-раз (или "route <> Wireguard0 auto reject") и потом НАБИВАЕТЕ сами маршруты сразу в конф файл.

    Маршрутизация между сегментами

    в Обмен опытом

    Опубликовано

    40 минут назад, Andron_ сказал:

    Никаким спобом мне не удалось добиться связи из домашнего в дополнительный сегмент. security-level, no-isolation не помогают. Видимо, есть какое-то ключевое условие, которое я не делаю, а оно нигде не описывается.

    Подскажите, пжлст, как настроить доп. сегмент?

    Осмыслите еще раз порядок действий. Начните с сохранения selftest файла, поиска в нем ваших интерфейсов (относящихся к сегментам). B еще раз прочитать/посмотреть https://help.keenetic.com/hc/ru/articles/360001434079-Настройка-правил-межсетевого-экрана-из-командного-интерфейса но начните с

    Цитата

    На интерфейсах интернет-центра предусмотрены настройки уровня доступа (security-level), которые определяют уровень безопасности (логику работы сетевого экрана):

    — private (частный, локальный);
    — public (внешний, публичный);
    — protected (защищённый, локальный).

    По умолчанию Keenetic принимает сетевые подключения только с интерфейсов private. Интерфейсам типа private разрешено устанавливать соединения в интерфейсы public, и на само устройство для управления и доступа к сервисам, работающим на интернет-центре. Для интерфейса гостевой сети закрыт доступ для управления интернет-центром и к его сервисам.

    Между интерфейсами private и из private в protected устанавливать соединение запрещено по умолчанию, но при необходимости, доступ можно разрешить. Данная настройка зависит от установки параметра isolate-private. Если вам нужно разрешить соединения между интерфейсами типа private или между private и protected (т.е. не изолировать доступ), для этого выполните команду no isolate-private

    Из интерфейсов типа public запрещено устанавливать соединения на любые интерфейсы, в том числе на другие интерфейсы типа public, а также на само устройство.

    Интерфейсам типа protected разрешено устанавливать соединения только в интерфейсы public. По умолчанию доступ запрещён к устройствам интерфейсов private и других protected, а также к управлению устройством.

    С помощью команды security-level public|private|protected можно управлять уровнями доступа на интерфейсах интернет-центра.

    и картинка.

    security-level, no-isolation не помогают. Видимо, есть какое-то ключевое условие, которое я не делаю, а оно нигде не описывается.

    Cразу вопрос что в итоге имеете или обратитесь тогда в ТП с приложенном файлом selftest.

     

    локальный доступ по https

    в Веб-интерфейс

    Опубликовано · Изменено пользователем vasek00

    1 час назад, TheDmitry сказал:

    Ну не очень, прописал не только контроллеры из другой сети, но и ретрансляторы. И все ссылки работают. Понятно, что my.keenetic.net - только на "ближайший" keenetic перебрасывает. Нужно все ссылки в браузере запомнить в закладки, и затем закрыть 80 порт.

    static_a = my.keenetic.net 78.47.125.180
    static_a = ****************.keenetic.io 192.168.X.H1 <- контроллер в сети X
    static_aaaa = *****************.keenetic.io ::
    static_a = ****************.keenetic.io 192.168.Z.H1 <- контроллер в сети Z
    static_a = ****************.keenetic.io 192.168.W.H1 <- контроллер в сети W
    static_a = ****************.keenetic.io 192.168.W.H2 <- ретранслятор1 в сети W
    static_a = ****************.keenetic.io 192.168.W.H3 <- ретранслятор2 в сети W

    На локальном ПК ( в сети так же несколько) берем готовый html (можно и в закладки) 

    <!DOCTYPE html>
<html>
<head><meta charset="utf-8"><title>Keenetic</title></head>
<body>
	<a href="https://ffffffffffffffffffffffb.keenetic.io/login?backUrl=%2Fdashboard" title="Переход на Giga1">Место1<br></a>
        <a href="https://dfffffffffffffffffffff9.keenetic.io/login?backUrl=%2Fdashboard" title="Переход на Giga2">Место2<br></a>
	<a href="https://7ffffffffffffffffffffff6.keenetic.io/login?backUrl=%2Fdashboard" title="Переход на Giga3">Место3<br></a>

</body>
</html>

    и без разницы где он хоть локально, хоть не локально.

    локальный доступ по https

    в Веб-интерфейс

    Опубликовано

    2 часа назад, TheDmitry сказал:

    А если это дача, с плохим 4G (без усиления) и гостей под 30 человек, из них более 10 дети со смартфонами? Стоит промышленный модем и узконаправленная антенна для получения нормального канала в интернет. Звонки по сотовой не всегда проходят, а вот телеграмм - работает.

    Ну я так и подозревал.

    Еще вопрос, а если вообще нет интернета то гости не придут?

    локальный доступ по https

    в Веб-интерфейс

    Опубликовано

    1 час назад, TheDmitry сказал:

    Спасибо! Помогло, похоже keenetic не жёстко маппит *.io на 78.47.125.180, можно переопределить.

    Как раз жестко

    Спойлер 
    static_a = my.keenetic.net 78.47.125.180
static_aaaa = my.keenetic.net fd78:4712:5180:feed:feee:ed78:4712:5180
static_aaaa = xxxxxxx.keenetic.pro fd78:4712:5180:feed:feee:ed78:4712:5180
static_a = xxxxxx.keenetic.pro 78.47.125.180
static_a = fxxxxxxxxxxxxxxxxxxxxxxxb.keenetic.io 78.47.125.180
static_aaaa = fxxxxxxxxxxxxxxxxxxxxxxxxxxxb.keenetic.io fd78:4712:5180:feed:feee:ed78:4712:5180

     

     

    локальный доступ по https

    в Веб-интерфейс

    Опубликовано

    19 часов назад, TheDmitry сказал:

    Так же, никто не отменял наличие вирусов на устройствах гостей, которые могут осуществить атаку сразу. А устраивать для гостей "досмотр" их техники - не очень гостеприимное мероприятие, к тому же домашний пользователь - не профессионал в данном вопросе.

    А не проще гостей не пускать в сеть. Есть же у них свой 4G/5G или я неверное не догоняю сегодня эта фишка такая "приходят гости и с 4G/5G обязательно должны  переключится на гостевой Wifi" они же в гости пришли, а не в интернете тусоваться.

    локальный доступ по https

    в Веб-интерфейс

    Опубликовано

    12 часов назад, TheDmitry сказал:

    к п.1 - есть проблема с несколькими устройствами keenetic, объединёнными в одну сеть через, например, WireGuard VPN. Например, у меня 4 таких устройства. И мне нужно уметь подключаться к каждому из них по HTTPS по локальной сети.

    Потенциально, можно вычислить их имена, но через Web интерфейс я не нашёл как их получить. При этом контроллер имеет не локальный IP адрес. Т.е. сканом по сети его не получить. И ещё вопрос, смогу ли я попасть на контроллер с непонятным IP через туннель WireGuard.

    Как и написано выше, можно по .io (достаточно посмотреть в selftest файл роутера), если смотреть не хочется то https://rmm.netcraze.ru/sites регистрация устройств (хоть в mesh хоть не в mesh, хоть ТД) - выбор устройства и в правом углу надпись "Веб интерфейс" если навести мышку то в левом низу будет видна ссылка, если на жать то попадаете на нужный/выбранный роутер - где в браузере будет так же ссылка ( https://7........6.keenetic.io )

    Спойлер

    -2.jpg.0f3ce16ad49ba213d2399ff99bd5ba34.jpg

     

    Связать несколько удалённых подсетей по Wireguard

    в Обсуждение IPsec, OpenVPN и других туннелей

    Опубликовано

    3 часа назад, Danich сказал:

    По итогу видно что к серваку пиры подключаются обмениваются пакетами, но пингануть пиры между собой не удается, так же пинга нет до локальной сети. 

    При настройке WG вы делали правила firewall для данного интерфейса - либо ip или TCP+UDP, не пробовали добавить icmp.

    Как отключить NAT между private-интерфейсами

    в Обмен опытом

    Опубликовано

    https://help.keenetic.com/hc/ru/articles/360001434079-Настройка-правил-межсетевого-экрана-из-командного-интерфейса

    Цитата

    По умолчанию Keenetic принимает сетевые подключения только с интерфейсов private. Интерфейсам типа private разрешено устанавливать соединения в интерфейсы public, и на само устройство для управления и доступа к сервисам, работающим на интернет-центре. Для интерфейса гостевой сети закрыт доступ для управления интернет-центром и к его сервисам.

    Между интерфейсами private и из private в protected устанавливать соединение запрещено по умолчанию, но при необходимости, доступ можно разрешить. Данная настройка зависит от установки параметра isolate-private. Если вам нужно разрешить соединения между интерфейсами типа private или между private и protected (т.е. не изолировать доступ), для этого выполните команду no isolate-private

    Из интерфейсов типа public запрещено устанавливать соединения на любые интерфейсы, в том числе на другие интерфейсы типа public, а также на само устройство.

    Интерфейсам типа protected разрешено устанавливать соединения только в интерфейсы public. По умолчанию доступ запрещён к устройствам интерфейсов private и других protected, а также к управлению устройством.

     

     

    Создание политики обслуживания клиента.

    в Развитие

    Опубликовано · Изменено пользователем vasek00

    Подправил под 4.3.

    Вариант когда клиент в своем профиле. Получим первое упоминание для блока его правил по MAC и прибавим +1 

    iptables -t mangle -L --line-numbers | awk '/E8:_MAC_CLIENTA_:74/ {print $1; exit}'

получил номер первого упоминнаия -> +1 = 58
 
iptables -t mangle -I _NDM_HOTSPOT_PRERT 58 -m mac --mac-source E8:_MAC_CLIENTA_:74 -m dscp --dscp 0x3f -j MARK --set-xmark 0xffffaab/0xffffffff

    В итоге, нужное правило dcp = 63 или 0x3f (профиль для него 0хffffaab), чтоб оно было после основного правила для профиля (0хffffaaa). Данный раздел ниже это весь блок для данного клиента, что у него и куда. 

    57   MARK       all  --  anywhere             anywhere             MAC E8:_MAC_CLIENTA_:74 MARK set 0xffffaaa
58   MARK       all  --  anywhere             anywhere             MAC E8:_MAC_CLIENTA_:74 DSCP match 0x3f MARK set 0xffffaab
59   CONNMARK   all  --  anywhere             anywhere             MAC E8:_MAC_CLIENTA_:74 CONNMARK save
60   RETURN     all  --  anywhere             anywhere             MAC E8:_MAC_CLIENTA_:74

    Фишка так и осталась, но уже только при передаче по основному профилю и в момент приема на другом проф. Это уже на LAN клиенте.

    Спойлер

    -2.thumb.jpg.fe56ae074aa27d3fa3d585af2a23a9a2.jpg

     

    Создание политики обслуживания клиента.

    в Развитие

    Опубликовано

    Проверил на 4.3 (чуток изменения) и вот такую картину получил 

    #!/bin/sh

[ "$table" != "mangle" ] && exit 0

if [ -z "$(iptables-save | grep 'dscp')" ]; then
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -j RETURN
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -m dscp --dscp 0x3f -j MARK --set-xmark 0xffffaab/0xffffffff
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -m mac --mac-source e0:клиент_ПК:e0 -j MARK --set-xmark 0xffffaaa/0xffffffff
fi
exit 0

    Для dscp 0х3f сервиса клиента выбран канал Inet-2, сервис для проверки torrent на клиенте ПК по wifi и проф. aab.

    Все остальное с данного клиента в aaa (на данном профиле поднят только WG который на канале РТ).

    Итог все работает, но есть маленькая фишка, падение скорости на канале Inet-2 во время работы по другому.

    Спойлер

    -2.thumb.jpg.da9799ec28732c17b69cc36e7054028b.jpg

     

    Создание политики обслуживания клиента.

    в Развитие

    Опубликовано · Изменено пользователем vasek00

    На пороге 2025год и на сегодня в прошивки все есть для реализации - "Создание политики обслуживания клиента" или можно назвать по другому. В моем случае есть два канала хотелось бы завернуть приложение клиента на Windows через канал отличный от default канала клиента.

    На Windows клиенте ставим метку на нужный сервис/приложение, а роутер по этой метке отправляет пакетики в нужный нам канал

    Ранее делал так 

    [ "$table" != "mangle" ] && exit 0

if [ -z "$(iptables-save | grep 'dscp')" ]; then
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -j RETURN
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -j CONNMARK --save-mark 
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -j MARK --set-mark 0xffffaaa
 iptables -t mangle -I _NDM_HOTSPOT_PRERT -i br0 -s 192.168.1.2/32 -m dscp --dscp 63 -j MARK --set-mark 0xffffaab
fi

    т.е. политика1 "--set-mark 0xffffaaa" (будет основная) и политика2 для приложения на клиенте "--set-mark 0xffffaab" (будет вторая). Именно в такой последовательности, так как правила iptables будут сначала для "0xffffaab", а потом для "0xffffaaa". Сам клиент должен находится в основном профиле.

    Сейчас в 4.3 опять хотелось бы вернуться  к этой "плюшке", но нужен USB порт и Entware.

    Не плохо бы иметь возможность реализации хотя бы через cli то было бы хорошо.

    Спойлер

    -3.thumb.jpg.253e76496acbb7847f23c1f3345eed11.jpg

     

    • Спасибо 1

    NDSS cannot connect to the server

    в Обмен опытом

    Опубликовано

    2 минуты назад, Danchess сказал:

    Роутер основной. У Ethernet высший приоритет, WISP - резервное соединение.

    Опытным путем выяснил, что IP "зависает" от другого соединения.

    Вывод show ndss, когда подключаюсь к WISP (основное соединение отключаю):

    Вывод show ndss, когда отключаю WISP и включаю Ethernet:

    Вывод show ndss, после удаления WISP-соединения:

    Роутер перезагружаю после каждого действия.

    Опытным путем выяснил, что IP "зависает" от другого соединения.

    При наличие нескольких каналов/интерфейсов то это перестройка маршрута, т.е. смена одного default (выход в интернет) на другой. На пальцах пров.1 (основной/интерфейс ppp0) и пров2 (резервный/интерфейс eth2.9).

    Вариант 1 когда на основном то имеем default на ppp0 (пров1) 

    ~ # ip ro
default dev ppp0  scope link
10.IP_пров2.0/24 dev eth2.9  proto kernel  scope link  src IP_от_Интерфейс_eth2.9
xxx.xxx.xxx.1 dev ppp0  proto kernel  scope link  src IP_от_Интерфейс_ppp0
...

    Вариант 2 когда на другом провайдере то имеем смену default (тут просто смена в основной политики каналов/местами, второй выше первого) 

    ~ # ip ro
default via 10.IP_пров2.1 dev eth2.9
10.IP_пров2.0/24 dev eth2.9  proto kernel  scope link  src IP_от_Интерфейс_eth2.9
xxx.xxx.xxx.1 dev ppp0  proto kernel  scope link  src IP_от_Интерфейс_ppp0
...

    Вариант 3 - настройка выбора интерфейса через параметр "ip global _ПРИОРИТЕТ_", т.е. чем цифра выше -> имеем приоритет на данном интерфейсе (в WEB чем выше позиция, ниже пров1 приоритетней) 

    interface PPPoE0
    ip global 65387 ***************** 65387


interface GigabitEthernet0/Vlan9
    ip global 65382 ***************** 65382

    Вы описываете свои действия так 

    когда подключаюсь к WISP (основное соединение отключаю)
когда отключаю WISP и включаю Ethernet
после удаления WISP-соединения

    При таком действие - это тоже самое -> смена default с одного на другой интерфейс, вопрос только "баг" это или нет.

    Сделал подключение через телефон (WISP) в итоге 

    ~ # ip ro
default via 192.168.226.12 dev apcli0 ********************************************* def через телефон
10.IP_пров2.0/24 dev eth2.9  proto kernel  scope link  src IP_от_Интерфейс_eth2.9
xxx.xxx.xxx.1 dev ppp0  proto kernel  scope link  src IP_от_Интерфейс_ppp0
....
192.168.226.0/24 dev apcli0  proto kernel  scope link  src 192.168.226.161 ********* телефон/сеть


	"host": "ndss.keenetic.ru",
	
		"wan-ip": "192.168.226.161",
		"sent-wan-ip": "192.168.226.161",

    Выключаю WISP (WEB роутера) и как итог переход на пров1 

    ~ # ip ro
default dev ppp0  scope link
10.IP_пров2.0/24 dev eth2.9  proto kernel  scope link  src IP_от_Интерфейс_eth2.9
xxx.xxx.xxx.1 dev ppp0  proto kernel  scope link  src IP_от_Интерфейс_ppp0
...


	"host": "ndss.keenetic.ru",
	
		"wan-ip": "IP_от_Интерфейс_ppp0",
		"sent-wan-ip": "IP_от_Интерфейс_ppp0",

    Все сработало как и надо. Маленькая ремарка - на ppp0 произошла смена IP это говорит о переподключение для данного канала, но во время второго теста проблем на возникло (переподключения не было). 

    interface WifiMaster0/WifiStation0
    description Aa73
    dyndns nobind
    security-level public
    authentication wpa-psk ns3 ***
    encryption enable
    encryption wpa2
    ip address dhcp
    ip dhcp client dns-routes
    ip global 65515 ********************************** приоритет по умолчанию встал такой
    ip name-servers
    ssid Aa73
    standby no enable
    standby timeout 600
    up

    От себя сейчас в 4.3 (draft канала) по настройкам данного подключения куча настроек

     

    Спойлер

    -2.thumb.jpg.07dbb55d5b4d908e133e4bbe8b39f0c0.jpg

    -6.thumb.jpg.e58fe0eb8ad669289630ccf17d0bc3f4.jpg

     

     

    NDSS cannot connect to the server

    в Обмен опытом

    Опубликовано

    7 часов назад, Danchess сказал:

    Почему может отправляться внутренний ip?

    Роутер в основном режиме но подключен как ТД по LAN к другому/основному

    Спойлер 
    {
	"host": "ndss.keenetic.ru",
	"registrator": {
		"reasons": [
			"periodic"
		],
		"state": "PERIODIC",
		"delay": 12353,
		"wan-ip": "192.168.1.100",
		"wan-ip6": "::",
		"sent-wan-ip": "192.168.1.100",
		"sent-wan-ip6": "::",
		"last-nr-reason": "periodic",
		"last-error": "00000000",
		"since-last-call": 74046,
		"since-last-nr": 74046,
		"failure-count": 0,
		"fallback": false
	},
	"prompt": "(config)"
}

     

    На основном

    Спойлер 
    {
	"host": "ndss.keenetic.ru",
	"registrator": {
		"reasons": [
			"periodic"
		],
		"state": "PERIODIC",
		"delay": 29881,
		"wan-ip": "ххх.ххх.ххх.211",
		"wan-ip6": "2a00:ххххххххххххххххххххххххххххх:29c4",
		"sent-wan-ip": "ххх.ххх.ххх.211",
		"sent-wan-ip6": "2a00:хххххххххххххххххххххххх:29c4",
		"last-nr-reason": "periodic",
		"last-error": "00000000",
		"since-last-call": 56519,
		"since-last-nr": 56519,
		"failure-count": 0,
		"fallback": false
	},
	"prompt": "(config)"
}

     

    Покажите ваши маршруты "show ip route", потом в конфиг файле посмотреть разделы "interface" (согласно вывода пред.команды) и поле найти "ip global _ПРИОРИТЕТ_" (где приоритет это набор цифр и чем он выше по отношению к другому интерфейсу он и главный, ip global - выход в интернет, если их много то смотрим приоритет).

    Почему может отправляться внутренний ip?

    Без понимания что и как у вас подключается к интернету тут можно только гадать, почему не вернулся на канал провайдера после пропажи или что-то переключили/настроили, может надо было перегрузить роутер и т.д.

    NDSS cannot connect to the server

    в Обмен опытом

    Опубликовано

    10 часов назад, KorDen сказал:

    Он уже сказал выше, что просил перевести свой роутер в EU, т.е. речь про другой домен

    Про его я понял

    Устройство действительно EU - через тех поддержку специально переводил в регион EU, чтобы пользоваться одним приложением Keenetic, т.к. имею устройство еще в Европе.

    В посте ответ был другому пользователю.

    NDSS cannot connect to the server

    в Обмен опытом

    Опубликовано

    1 час назад, Илья Картавенко сказал:

    потом возьмите его ip проведите traceroute и ping

     

    Спойлер 
    Обновления

A? ndss.keenetic.ru. (34)
3/0/0 A 91.142.81.244, A 31.200.254.34, A 85.198.119.89 (82)

91.142.81.244
AS41722: miran.ru - St.-Petersburg

31.200.254.34
AS61400: netrack.ru - Москва

85.198.119.89
AS29182: firstdedic.ru - Химки

    Выше канал РТ. Если же через Нидерланды канал, то конечная точка входа для обновлений ndss.keenetic.ru -> 31.200.254.34

     

     

    NDSS cannot connect to the server

    в Обмен опытом

    Опубликовано

    30 минут назад, Илья Картавенко сказал:

    У вас например рутрекер открывается без технологии из трех букв?

    Проверьте. 

    потом возьмите его ip проведите traceroute и ping

    Не отклоняйтесь от темы данного поста.

    Ровно 2 недели назад впервые возникла проблема. Перестал работать KeenDNS и пропала связь с сервером обновлений. При этом интернет работает и на подключенных устройствах, и на Keenetic-е. Сервера NDSS пингуются. В тот раз решилось подключением через WISP к телефону. Сервера Keenetic увидел, я обновил его до последней версии и в течение 2 недель всё работало.

    Сегодня снова та же проблема. Подключаю через WISP к телефону - KeenDNS работает, обновления видно. Переключаю обратно на Ethernet - всё пропадает.

    4.3 Beta 2. Buddy6 перестал подключаться к Mesh-системе.

    в Тестирование Dev-сборок

    Опубликовано

    2 часа назад, GeodE сказал:

    Не совсем понял, что имеется в виду, почему 192.168.1.3 резервный и где про это почитать?

    У меня вручную назначены IP - 192.168.1.2 и 192.168.1.3 у обеих ТД, на Beta2 вторая точка становится не видна в mesh, хотя по факту в UI зайти можно. Любые манипуляции с IP ничего не дают - по новым IP также доступна веб-морда, но в mesh точку не видно. Откат на Beta1 решает проблему, всё работает

    Почитать наверное где в базе знаний есть, а так я же показ конф файл ТД 

    interface Bridge0
    rename Home
    description HomeLan
    inherit GigabitEthernet0/Vlan1
    include AccessPoint
    include AccessPoint_5G
....
    ip address 192.168.1.3 255.255.255.0
    ip address dhcp
    ip dhcp client fallback static
    ip dhcp client dns-routes
    ip dhcp client name-servers
    interface Bridge0 - ip address 192.168.1.3 255.255.255.0 если проблема при "ip address dhcp/ip dhcp client fallback static"
    • Спасибо 1
    • Лайк 1

    Wireguard asc 4.3 beta 2

    в Тестирование Dev-сборок

    Опубликовано

    В 28.02.2025 в 13:56, Le ecureuil сказал:

    Спасибо за репорты, разбираемся.

    Вопрос, на 43B2 перестал подключаться WG на второго провайдера при перезагрузки роутера.

    Инет1-провайдер РТ и WG0 - все ОК

    Инет2-провайдер провод и WG1 - проблемка, требуется передергивания соединения. На некоторых весриях ПО все нормально, например на 43B1 теперь на 43B2 опять проблема.

     

    Спойлер 
    [I] Mar  2 15:37:05 ndm: Wireguard::Interface: "Wireguard0": resolved peer "b.................................o=" endpoint to "188.хх.хх.хх". 
[I] Mar  2 15:37:05 ndm: Network::Interface::EndpointTracker: "Wireguard0": "b.................................o=": remote endpoint is "188.хх.хх.хх". 
[I] Mar  2 15:37:05 ndm: Network::Interface::EndpointTracker: "Wireguard0": "b.................................o=": connecting via "PPPoE0" (PPPoE0). 
[I] Mar  2 15:37:05 ndm: Network::Interface::EndpointTracker: "Wireguard0": "b.................................o=": local endpoint is "IP_от_PPP0". 
[I] Mar  2 15:37:05 kernel: wireguard: Wireguard0: peer "b.................................................o=" (7) created
[I] Mar  2 15:37:05 ndm: Wireguard::Interface: "Wireguard1": resolved peer "Hp....................................RA=" endpoint to "185.хх.хх.хх". 
[I] Mar  2 15:37:05 ndm: Wireguard::Interface: "Wireguard1": "Hp.............................................RA=": via interface is not ready, standby. 
[I] Mar  2 15:37:05 ntced: now running as nobody:nobody. 
[I] Mar  2 15:37:05 ntced: ready for processing. 
[I] Mar  2 15:37:05 ndm: Core::System::DriverManager: loading /lib/modules/4.9-ndm-5/hw_nat.ko. 
[I] Mar  2 15:37:06 kernel: hw_nat: MediaTek HW NAT module v5.0.7.0-10 loaded, FoE size: 16384, AG pairs: 31
[I] Mar  2 15:37:06 ndnproxy: NDM DNS Proxy, v1.4.12. 
...
[I] Mar  2 15:37:10 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". 
[I] Mar  2 15:37:10 ndm: Network::Interface::Ip: "Wireguard0": interface "Wireguard0" is global, priority 65359. 
[I] Mar  2 15:37:10 ndm: Network::Interface::Ip: "Wireguard0": adding default route via Wireguard0. 
[I] Mar  2 15:37:10 ndm: Network::Interface::Ip6: "Wireguard0": interface "Wireguard0" is global, priority 65359. 
[I] Mar  2 15:37:10 ndm: Network::Interface::Ip6: "Wireguard0": adding default route via Wireguard0. 

[I] Mar  2 15:38:47 ndm: Core::System::Clock: system time has been changed. 
[I] Mar  2 15:38:47 ndm: Ntp::Client: time synchronized with "192.36.143.130". 

[I] Mar  2 15:38:47 ndm: Wireguard::Interface: "Wireguard0": triggering peers to reinitiate handshakes. 
[I] Mar  2 15:38:47 kernel: wireguard: Wireguard0: peer "b.........................................o=" (7) (188.хх.хх.хх:хххх) destroyed
[I] Mar  2 15:38:47 kernel: wireguard: Wireguard0: peer "b.........................................o=" (8) created
...
[I] Mar  2 15:38:47 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "running" to "pending". 
[I] Mar  2 15:38:47 ndm: Network::Interface::Ip: "Wireguard0": removing default route via Wireguard0. 
[I] Mar  2 15:38:47 ndm: Network::Interface::Ip6: "Wireguard0": removing default route via Wireguard0. 
[I] Mar  2 15:38:47 ndm: Wireguard::Interface: "Wireguard1": triggering peers to reinitiate handshakes. 
[I] Mar  2 15:38:47 pppd[880]: System time change detected. 
...
[I] Mar  2 15:38:49 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". 
[I] Mar  2 15:38:49 ndm: Network::Interface::Ip: "Wireguard0": interface "Wireguard0" is global, priority 65359. 
[I] Mar  2 15:38:49 ndm: Network::Interface::Ip: "Wireguard0": adding default route via Wireguard0. 
[I] Mar  2 15:38:49 ndm: Network::Interface::Ip6: "Wireguard0": interface "Wireguard0" is global, priority 65359. 
[I] Mar  2 15:38:49 ndm: Network::Interface::Ip6: "Wireguard0": adding default route via Wireguard0. 
[I] Mar  2 15:38:49 ndm: Netfilter::Util::Conntrack: flushed 209 IPv4 connections. 

[I] Mar  2 15:41:27 kernel: wireguard: Wireguard0: retrying handshake with peer "b..................................o=" (8) (188.хх.хх.хх:хххх) because we stopped hearing back after 15 seconds

     

    Передергивание и итог WG2 на втором провайдере

    Спойлер

    [I] Mar  2 16:00:54 ndm: Network::Interface::Base: "Wireguard1": "base" changed "conf" layer state "running" to "disabled". 
    [I] Mar  2 16:00:54 ndm: Network::Interface::Base: "Wireguard1": interface is down. 
    [I] Mar  2 16:00:54 ndm: Core::System::StartupConfig: saving (http/rci). 
    [I] Mar  2 16:00:56 ndm: Network::Interface::Base: "Wireguard1": "base" changed "conf" layer state "disabled" to "running". 
    [I] Mar  2 16:00:56 ndm: Network::Interface::Base: "Wireguard1": interface is up. 
    [I] Mar  2 16:00:56 ndm: Core::System::StartupConfig: saving (http/rci). 
    [I] Mar  2 16:00:58 ndm: Wireguard::Interface: "Wireguard1": resolved peer "H.........................................................................RA=" endpoint to "185.хх.хх.хх". 
    [I] Mar  2 16:00:58 ndm: Network::Interface::EndpointTracker: "Wireguard1": "H.........................................................................RA=": remote endpoint is "185.хх.хх.хх". 
    [I] Mar  2 16:00:58 ndm: Network::Interface::EndpointTracker: "Wireguard1": "H.........................................................................RA=": connecting via "GigabitEthernet0/Vlan9" (GigabitEthernet0/Vlan9). 
    [I] Mar  2 16:00:58 ndm: Network::Interface::EndpointTracker: "Wireguard1": "H.........................................................................RA=": local endpoint is "10._Инет_2.12". 
    [I] Mar  2 16:00:58 ndm: Network::RpForwarder: "Wireguard1": copy IPv4 route 10._Инет-2.0/24 gw 0.0.0.0 dev eth2.9 to table 19. 
    [I] Mar  2 16:00:58 ndm: Network::RpForwarder: "Wireguard1": install IPv4 route to 0.0.0.0/0 to table 19 via gw 10._Инет-2.1 dev GigabitEthernet0/Vlan9. 
    [I] Mar  2 16:00:58 kernel: wireguard: Wireguard1: peer "H.........................................................................RA=" (9) created
    [I] Mar  2 16:00:58 kernel: wireguard: Wireguard1: flushing endpoint cache for peer "H.........................................................................RA="
    [I] Mar  2 16:00:58 kernel: wireguard: Wireguard1: sending keepalive packet to peer "H.........................................................................RA=" (9) (185.хх.хх.хх:5ххх)
    [I] Mar  2 16:00:58 kernel: wireguard: Wireguard1: sending handshake initiation to peer "H.........................................................................RA=" (9) (185.хх.хх.хх:5ххх)
    [I] Mar  2 16:00:58 ndm: Core::System::StartupConfig: configuration saved. 
    [I] Mar  2 16:01:03 kernel: wireguard: Wireguard1: handshake for peer "H.........................................................................RA=" (9) (185.хх.хх.хх:5ххх) did not complete after 5 seconds, retrying (try 2)
    [I] Mar  2 16:01:03 kernel: wireguard: Wireguard1: sending handshake initiation to peer "H.........................................................................RA=" (9) (185.хх.хх.хх:5ххх)
    [I] Mar  2 16:01:03 kernel: wireguard: Wireguard1: receiving handshake response from peer "H.................................................................RA=" (9) (185.хх.хх.хх:5ххх)
    [I] Mar  2 16:01:03 kernel: wireguard: Wireguard1: keypair 17 created for peer 9
    [I] Mar  2 16:01:04 ndm: Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "pending" to "running". 
    [I] Mar  2 16:01:04 ndm: Network::Interface::Ip: "Wireguard1": interface "Wireguard1" is global, priority 65377. 
    [I] Mar  2 16:01:04 ndm: Network::Interface::Ip: "Wireguard1": adding default route via Wireguard1. 
    [I] Mar  2 16:01:04 ndm: Network::Interface::Ip6: "Wireguard1": interface "Wireguard1" is global, priority 65377. 
    [I] Mar  2 16:01:04 ndm: Network::Interface::Ip6: "Wireguard1": adding default route via Wireguard1. 

    *************************

    interface Wireguard1
        description Pr
    ....

        wireguard asc 1 ....
        wireguard peer Hp......................................................................RA= !WG-Pr
            endpoint 185.хх.хх.хх:5ххх
            keepalive-interval 120
        ...
            connect via GigabitEthernet0/Vlan9
        !
        up
     

    interface GigabitEthernet0/0
        rename 1
        role inet for GigabitEthernet0/Vlan9
        switchport mode access
        switchport access vlan 9
        up
    !

    interface GigabitEthernet0/Vlan9
        description Inet-2
    ....
        ip global 65382
        ip no name-servers
        ipv6 name-servers auto
        up
    !
    *************************

    interface PPPoE0
        description RosTelecom
        role inet
    ...

        ip global 65387

        connect via ISP
        up
    interface Wireguard0
        description Cl

    ...
        wireguard listen-port 65103
        wireguard asc 1 ........
        wireguard peer b........................................................o= !Cl
            endpoint 188.хх.хх.хх:хххх
            keepalive-interval 60
    ...
            connect
        !
        up
     

    nwg1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
              inet addr:10.11.130.96  P-t-P:10.11.130.96  Mask:255.255.255.255
              UP POINTOPOINT RUNNING NOARP  MTU:1324  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0 frame:0
              TX packets:1 errors:0 dropped:1 overruns:0 carrier:0
              collisions:0 txqueuelen:50
              RX bytes:0 (0.0 B)  TX bytes:148 (148.0 B)
    *****************************

    Ранее на 43B1

    Спойлер 
    [I] Feb  1 14:57:47 ndm: Wireguard::Interface: "Wireguard0": triggering peers to reinitiate handshakes. 
[I] Feb  1 14:57:47 kernel: wireguard: Wireguard0: peer "b..................o=" (7) (188.xx.xx.xx:5xx) destroyed
[I] Feb  1 14:57:47 kernel: wireguard: Wireguard0: peer "b..................o=" (9) created
[I] Feb  1 14:57:47 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "running" to "pending". 
[I] Feb  1 14:57:47 ndm: Network::Interface::Ip: "Wireguard0": removing default route via Wireguard0. 
[I] Feb  1 14:57:47 ndm: Network::Interface::Ip6: "Wireguard0": removing default route via Wireguard0. 
[I] Feb  1 14:57:47 ndm: Wireguard::Interface: "Wireguard1": triggering peers to reinitiate handshakes. 
[I] Feb  1 14:57:47 kernel: wireguard: Wireguard1: peer "H....................RA=" (8) (185.yy.yy.yy:5yyy) destroyed
[I] Feb  1 14:57:47 kernel: wireguard: Wireguard1: peer "Hp...................RA=" (10) created
...
[I] Feb  1 14:57:50 ndm: Network::Interface::Base: "Wireguard0": "wireguard" changed "link" layer state "pending" to "running". 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip: "Wireguard0": interface "Wireguard0" is global, priority 65359. 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip: "Wireguard0": adding default route via Wireguard0. 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip6: "Wireguard0": interface "Wireguard0" is global, priority 65359. 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip6: "Wireguard0": adding default route via Wireguard0. 
[I] Feb  1 14:57:50 ndm: Network::Interface::Base: "Wireguard1": "wireguard" changed "link" layer state "pending" to "running". 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip: "Wireguard1": interface "Wireguard1" is global, priority 65377. 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip: "Wireguard1": adding default route via Wireguard1. 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip6: "Wireguard1": interface "Wireguard1" is global, priority 65377. 
[I] Feb  1 14:57:50 ndm: Network::Interface::Ip6: "Wireguard1": adding default route via Wireguard1.

     

    При переводе WG1 на РТ канал, проблем не возникает (основной РТ и default на него, Inet-2 резерв).

     

     

    Без имени-3.jpg

    • Спасибо 1

    4.3 Beta 2. Buddy6 перестал подключаться к Mesh-системе.

    в Тестирование Dev-сборок

    Опубликовано · Изменено пользователем vasek00

    8 часов назад, GeodE сказал:

    По факту, роутер доступен по своему адресу (вручную назначен 192.168.1.3). В логе нашёл, что у третьего роутера "same ipv4", как у второго, что, по факту, не так. Любые попытки поиграть с ip (поменять, сделать автоназначение , не решают проблему)

    192.168.1.3 данный адрес используется при проблеме на DHCP сервере или его отсутствие, т.е. точка не получила IP и был назначен по умолчанию. 

    interface Bridge0
    rename Home
    description HomeLan
    inherit GigabitEthernet0/Vlan1
    include AccessPoint
    include AccessPoint_5G
....
    ip address 192.168.1.3 255.255.255.0
    ip address dhcp
    ip dhcp client fallback static
    ip dhcp client dns-routes
    ip dhcp client name-servers

    Смотрим лог

    Спойлер 
    [I] Oct  2 21:00:12 ndm: Network::Interface::Ip: "Bridge0": IP address is 192.168.1.3/24. 
и смена
[I] Oct  2 21:00:52 ndhcpc: Bridge0: received OFFER for 192.168.1.4 from 192.168.1.1. 
[I] Oct  2 21:00:52 ndhcpc: Bridge0: received ACK for 192.168.1.4 from 192.168.1.1 lease 36600 sec. 
[I] Oct  2 21:00:52 ndm: Dhcp::Client: configuring interface Home. 
[I] Oct  2 21:00:52 ndm: Network::Interface::Ip: "Bridge0": IP address is 192.168.1.4/24. 
[I] Oct  2 21:00:52 ndm: Dhcp::Client: obtained IP address 192.168.1.4/24. 
[I] Oct  2 21:00:52 ndm: Dhcp::Client: interface "Home" is global, priority 1. 
[I] Oct  2 21:00:52 ndm: Dhcp::Client: adding a default route via 192.168.1.1. 
[I] Oct  2 21:00:52 ndm: Dhcp::Client: adding name server 192.168.1.1. 
[I] Oct  2 21:00:52 ndm: Dns::Manager: name server 192.168.1.1 added, domain (default). 
[I] Oct  2 21:00:52 mtkiappd: stopped. 
[I] Oct  2 21:00:53 ndm: Http::Nginx: loaded SSL certificate for "ххххх4.keenetic.pro". 
[I] Oct  2 21:00:53 ndm: Http::Nginx: loaded SSL certificate for MWS.

    192.168.1.4 IP данной ТД, назначенный на контроллере.

    Возможно лог прояснит ситуацию по данному вопросу.

    Создание резервного канала в роутере Keenetic, через модем другого роутера Keentic, без потери функциональности этого роутера.

    в Обмен опытом

    Опубликовано · Изменено пользователем vasek00

    5 часов назад, Borgoss сказал:

    через Entware можно сделать практически всё, но штатными средствами всегда приятнее чем погружаться в эти дебри маршрутов и какая же утилита из набора OpenWRT тебе поможет, а что сломает, потому что заменяет собой функционал.

    Можно и штатными -> тогда ручками менять def мвршрут в WEB или как описывали на форуме через vlan.

    О каких дебрях идет речь ????? На втором роутере def на основной 

    ~ # ip ro
default via 192.168.1.100 dev br0  proto static

    После подключения модема к нему, def на модем 

    ~ # ip ro
default via 192.168.8.1 dev cdc_br0

    Смена def c модема на основной 

    ~ # ip ro del default
~ # ip route add default via 192.168.1.100 dev br0
~ # ip ro
default via 192.168.1.100 dev br0

    Смена обратно на модем 

    ~ # ip ro del default
~ # ip route add default via 192.168.8.1 dev cdc_br0
~ # ip ro
default via 192.168.8.1 dev cdc_br0

    Проконтролировать модемный интерфейс 

    ~ # ifconfig | awk '/cdc_br0/ {print $1}'
cdc_br0
~ #

~ # ip route | awk '/default/ {print $3}'
192.168.8.1
~ #

~ # ping -c2 -I cdc_br0 8.8.8.8 | awk '/packets received/ {print 4}'
4
~ #

    а что сломает, потому что заменяет собой функционал

    Т.е. если вы прописываете свой стат маршрут заворачивая его на нужный интерфейс то вы что-то ломаете в функционале?

     

    описанное выше 

    Инет1----Keenetiс/ТД---------Основной/Keenetic----Инет2

     

    • Спасибо 1
    • Лайк 1

    Wireguard asc 4.3 beta 2

    в Тестирование Dev-сборок

    Опубликовано

    2 часа назад, FLK сказал:

    В любом случае - поведение странное на мой взгляд, тем более оно не только у меня, а еще у как минимум нескольких человек

    Как я понял эта проблема возникает при количестве WG asc > 1

    Такое поведение было много раз и видел на 42 и т.д.

    Так как в стандартном WG никаких "левых/мусорных" пакетов быть не может, то поведение сервера который ориентирован на "стандартный" WG не предсказуемо.

    Спойлер

    Писал же ранее

    Спойлер

    Перед началом сессии клиент отправляет несколько пакетов со случайными данными (количество таких пакетов Jc и их минимальный и максимальный размер в байтах Jmin, Jmax задается в конфиге).

    Изменен заголовок пакета рукопожатия (Initiator to Responder), и ответного пакета (Responder to Initiator), эти значения также выставляются в конфиге (H1 и H2).


    Инит-пакеты рукопожатия дополнительно имеют мусор в начале данных, размеры определяются значениями S1 и S2. (по умолчанию инициирующий пакет рукопожатия имеет фиксированный размер (148 байт), после добавления мусора его размер будет равен 148 + длина случайных байтов).

    Изменен заголовок пакетов с данными и специальных пакетов “Under Load” - H4 и H3 соответственно.

    Ещё раз подробно о настраиваемых полях:

    ....

        S1         (Init packet junk size) - размер случайных данных, которые будут добавлены к init пакету, размер которого изначально фиксированный
        S2         (Response packet junk size) - размер случайных данных, которые будут добавлены к ответу, размер которого изначально фиксированный
        H1         (Init packet magic header) - заголовок первого байта рукопожатия
        H2         (Response packet magic header) - заголовок первого байта ответа на рукопожатие
        H4         (Transport packet magic header) - заголовок пакета передаваемых данных
        H3         (Underload packet magic header) - заголовок пакета UnderLoad

    Если выставить Jc, S1 и S2 в нули, то и мусора не будет.

    Так “init и response пакеты” рукопожатия дополнительно имеют “мусор” в начале данных, размер которого определяются значениями S1 и S2.
    По умолчанию инициирующий пакет рукопожатия имеет фиксированный размер (148 байт), а после добавления мусора, его размер будет равен 148 байтам +S1.
     

    Для WARP например как раз принципиально.

    Так же в самом начале появления asc пробовал разные значения - при 5 работало, при 3 нет.

    Так же для примера который был выше при

    Ремарка при настройках параметра "keepalive-interval 120" на специфиц. WG была проблема с handshake ... try (т.е. держался чуть менее суток или менее 12часов, но поднимался каждый раз сам) при установки "keepalive-interval 60" проблема ушла (держится несколько дней). Никаких ping-check

     

     

×
×
  • Создать...

Важная информация

На этом сайте используются файлы cookie. Нажимая "Я принимаю" или продолжая просмотр сайта, вы разрешаете их использование: Политика конфиденциальности.

  Я принимаю