KorDen

У Keenetic есть отличная техподдержка - https://help.keenetic.com/hc/ru - не стесняйтесь задавать вопросы туда, вам там обязательно помогут. Это форум пользователей - тут тоже могут помочь, но - это форум "Поиск - самая неиспользуемая часть форума © Лурк". Поиск тут в лучших традициях search.php ничего нормального типа поиска форм слов не умеет

Vlan tag не для этого. Нужно настраивать межсетевой экран или сделать "no isolate-private" в CLI

Похоже не надо специально отключать, при включении DoT/DoH он сам отрубает все остальные прописанные и полученные обычные name-server

Хотелось бы понять логику работы DoT/DoH и взаимодействие с name-server. Пробуем прописать, при включенном opkg dns-override и полном отсутствии ydns/adguard/...: (config)> dns-proxy tls upstream 1.1.1.1 sni cloudflare-dns.com Dns::Secure::ManagerDot: DNS-over-TLS name server "1.1.1.1" is disregarded while Internet Filter is active. Т.е. как я понимаю, для резолва запросов самим роутером (RPC) DoT/DoH использовать нельзя, они будут ходить напрямую? (использовать name-server только для необходимых резолвов для DoH, и затем переходить полностью на DoH/DoT) Как можно диагностировать работу DoT/DoH?

Точно так же как набор vdsl profile для Plus DSL например. Отсутствие списка - дефолтные параметры, при наличии хоть одной команды типа "interface WifiMaster1 channel allowed 36 width 20" - автовыбор работает только в пределах указанных каналов. Ну и подробное описание стандартной логики автовыбора и используемых по умолчанию каналов на KB не помешает.

@enpa, 😕 Чегось?

Wut? Это точно-точно SFP ONU? Ничего не путаете? Да и самим операторам весело - SFP ONU по закупке чаще всего стоят этак чуть меньше ONU "3в1" (скажем, сейчас актуальное у вендоров условно Econet+MT7615), в 2-4 раза выше стоимости "бриджового" однопортового ONU

Название опции говорит само за себя. При обычном прохождении NAT исходящий порт 500 заменяется на произвольный, а дальше возможно оператором еще раз меняется. При включенной опции кинетик сохраняет исходящий порт 500, CG-NAT провайдера скорее всего тоже сохраняет его, и тогда всё ок. У вас в центре случаем никакого фаервола нет? Вот старый топик по очень похожей ситуации, но там были проблемы другого рода - https://forum.keenetic.net/topic/2811-ipsec-туннель-через-keenetic/?tab=comments

С точностью наоборот же?

4x4 в ноутах вроде бы нет, 3x3 раз-два и обчелся, а вот 2x2 BW160 можно поискать например в распоследних интеловских чипах (9560) которые CNVi.

Большинство мобильников 1x1, топовые 2x2. 3x3 - удел топовых ноутбуков/моноблоков и топовых адаптеров для ПК, а 4x4 адаптеров раз-два и обчелся.

UDP/500 - т.е. установка соединения вообще не начинается? Или всё-таки что-то начинается, но потом тухнет (где-то забыли включить NAT-T?) ip nat udp-port-preserve проблему решает, или нет/не везде/частично? Компонент IPsec на кинетике установлен или нет? IPsec довольно капризная штука. И да, некоторые провайдерские CG-NAT его умудряются ломать так или иначе. Можно еще вспомнить МТС с поломаной фрагментацией пакетов (хотя может уже починили). Увы, с учетом нынешнего состояния тех.блока опсосов решать подобные технические проблемы очень затруднительно.

https://help.keenetic.com/hc/ru/articles/115000045689-Синтаксис-и-описание-команды-ip-static-для-настройки-трансляции-сетевых-адресов-NAT Раздел 3, пример 2

А можно запилить "грозозащиту", соединив RB260GS и Ultra оптикой (получив 5 проводных линков на ISP), при прилетании грозы шанс что выгорит что-то кроме 260 понижается до вероятности пробоя через БП. Еще у меня был забавный факт - при пинге с кинетика девайс за WAN напрямую пинг на десятки микросекунд больше, чем при пинге через 260 в качестве "медиаконвертера" (giga-260 по оптике) нет

Простейший свич с VLANами (например RB260GS - и даже не смотрите в сторону глюкодрома DGS1100*), настройка через CLI. Можно и другой кинетик заюзать при наличии, вопрос только в необходимой скорости портов... Например первого провайдера отправляете так, второго как vlan10. Для простоты со стороны роутера вначале через морду настраиваете провайдера который с тегом, а затем через консоль навешиваете на ISP конфиг для первого (который прозрачно). Главное потом ничего не менять через веб, а то поломается.

ACK идут каждые ~25 минут. rx_errors вроде единичные (на момент дерганья кабеля) Смотрим время: [I] May 1 15:23:18 ndhcpc: FastEthernet0/Vlan2: received ACK for ... from 10.177.0.1. [I] May 1 15:37:07 ndm: Network::InternetChecker: Internet access lost. [I] May 1 15:37:42 ndm: Network::InternetChecker: Internet access detected. [I] May 1 15:38:16 ndm: Network::InternetChecker: Internet access lost. [W] May 1 16:53:19 ndm: Dhcp::Client: DHCP server is not responding. [I] May 1 16:53:19 ndm: Network::Interface::IP: "FastEthernet0/Vlan2": IP address cleared. [I] May 1 17:14:55 ndm: Network::Interface::Switch: "FastEthernet0/0": switch link down at port 0. [I] May 1 17:16:03 ndm: Network::Interface::Switch: "FastEthernet0/0": switch link up at port 0. [I] May 1 17:16:15 ndhcpc: FastEthernet0/Vlan2: received ACK for ... from 10.177.0.1. В 15:37 инет отвалился (по internet-checker), дальше по идее в районе 15:50 должен был быть ACK - его не было, и до 17:14 DHCP-сервер провайдера не отвечал. Больше похоже действительно на совпадение и проблемы у провайдера. Хотя еще, фантазируя, можно объяснить каким-то странным залипанием мака, и втыкание компа чего-нибудь сбросило...

(пароли бы из конфига убрали...)

security-level private вкупе с no isolate-private отрубает, но там вроде были какие-то нюансы натирования между private-интерфейсами, или ip global туда нельзя навесить...

Попробуйте в межсетевом экране для L2TP0 добавить разрешающее правило для udp/67 (можно еще "шоб наверняка" udp/68). Ну и таки в захвате пакетов, запросы теперь ходят?

Ну, это "вариант-максимум", на всякий случай - а то такие вот 10.10.10.. любят занимать некоторые 4G-модемы Это "доснести" DHCP-сервер, если вдруг еще остался... Ой, я там ошибся, не "ip dhcp server", а "ip dhcp relay server" конечно же.. Впрочем, думаю вы догадались поправить. Похоже действительно в поддержку.... Ну или еще можно подебажить, включив захват пакетов на L2TP0 и проверив, а уходят ли вообще DHCP Discover в него. Тут еще подумалось - L2TP0 у вас с каким security-level, public? А не отбивает ли фаервол (смотреть дамп L2TP0)... Может надо разрешить входящий UDP/67 (и UDP/68) на L2TP0..

А не получилась ли каша в результате... Давайте для уверенности no ip dhcp relay lan no ip dhcp relay wan no ip dhcp relay server ip route 10.10.10.11 L2TP0 auto ip dhcp relay lan Home ip dhcp server 10.10.10.11 ip dhcp pool _WEBADMIN no bind Home system configuration save И ребут https://help.keenetic.com/hc/ru/articles/115000990005-Таблица-актуальных-версий-KeeneticOS

Нет. DHCP-сервер (пул) роутера и DHCP-релей это две разные сущности. Если включено и то и то - запрос прилетает на прошивочный И релеется. Как и при обычном наличии двух DHCP-серверов в сети, клиент ловит первый ответ, а быстрее конечно же отвечает прошивочный. Выключите его, тогда будет только релей работать

Вам не нужно включать DHCP-сервер в сегменте. DHCP relay работает отдельно от DHCP-сервера

А не работает как - IP вообще не приходит, или приходит от DHCP-сервера роутера? Вы не забыли выключить DHCP-сервер в настройках сегмента? Навскидку быстренько соорудил на 3.00 - в IPIP-туннель discover в таком виде нормально уходит.