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

Вопрос

  • Ответы 143
  • Создана
  • Последний ответ

Лучшие авторы в вопросе

Рекомендуемые сообщения

  • 0
Опубликовано (изменено)
1 час назад, mrGhotius сказал:

В правильном описании проблемы! В каком режиме Ultra работает? Почему вытягивать информацию всегда нужно?

Подозреваю, что подключили просто воткнув кабель в WAN и оставили работать как роутер? Тогда делегируйте префикс с Giga на Ultra.

да. сначала ультра был настроен как точка доступа, счас как роутер.

как делегировать префикс???

Изменено пользователем Denis Bormaleytus
  • 0
Опубликовано (изменено)

на ultra прилетает айпишник с главного роутера.

после прописывания делигивания - пропадает.

Цитата

ipv6 subnet Default
    bind Home
    mode slaac
    prefix length 63
    prefix delegate 64
    number 0

 

Изменено пользователем Denis Bormaleytus
  • 0
Опубликовано (изменено)
11 минут назад, Denis Bormaleytus сказал:

после прописывания делигивания - пропадает.

В этом случае не получится делегировать префикс (для делегирования получаемый от провайдера префикс должен быть меньше 64),  проще вам вернуть Ultra в режим точки доступа в MESH.

Изменено пользователем mrGhotius
  • 0
Опубликовано
40 минут назад, mrGhotius сказал:

В этом случае не получится делегировать префикс, проще вам вернуть Ultra в режим точки доступа в MESH

вернул ульру в ретранслятор.

заработало

  • 0
Опубликовано
On 8/10/2023 at 10:50 AM, Denys said:

Планируется ли добавить traceroute6?

Мне тоже было бы очень полезно иметь traceroute6. Надеюсь, эта функция появится в будущих обновлениях. Спасибо!

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

Столкнулся с проблемой, о которой известно уже 2 года. Файрволл роутера забывает постоянный IPv6-адрес установленного в сети DNS-сервера. Обращаются к нему по этому адресу не часто из из кэша DNS, который может пару дней запись хранить. Сам DNS-сервер в сеть выходит с временных адресов и соответственно анонсирует этот адрес только при подключении к сети. Я конечно понимаю, что память не бесконечная и нужно периодически чистить NDP-таблицу и правила файрволла от временных адресов, но стоит всё таки проверять, что устройство отказалась от адреса и больше для него на NDP-запросы не отвечает. Самый простой способ это перед удалением адреса из файрволла отправить ему ping, а затем независимо от результата проверить NDP-таблицу. Проблему конечно я решил одной строчкой в cron на DNS-сервере, но это костыль.

А теперь вопрос к администрации, если багу уже 2 года, то когда же его уже починят внеся пару строк в скрипт? Ладно DNS это редкий случай, но как насчёт удалённого доступа по ssh или SMB ? Или же принятие звонков через SIP ? Последнее как бы в бизнесе часто используется и пропущенный звонок из за мнимой безопасности может стоить дороже любого вашего роутера.

  • 0
Опубликовано
4 часа назад, None 7 сказал:

Столкнулся с проблемой, о которой известно уже 2 года. Файрволл роутера забывает постоянный IPv6-адрес установленного в сети DNS-сервера. Обращаются к нему по этому адресу не часто из из кэша DNS, который может пару дней запись хранить. Сам DNS-сервер в сеть выходит с временных адресов и соответственно анонсирует этот адрес только при подключении к сети. Я конечно понимаю, что память не бесконечная и нужно периодически чистить NDP-таблицу и правила файрволла от временных адресов, но стоит всё таки проверять, что устройство отказалась от адреса и больше для него на NDP-запросы не отвечает. Самый простой способ это перед удалением адреса из файрволла отправить ему ping, а затем независимо от результата проверить NDP-таблицу. Проблему конечно я решил одной строчкой в cron на DNS-сервере, но это костыль.

А теперь вопрос к администрации, если багу уже 2 года, то когда же его уже починят внеся пару строк в скрипт? Ладно DNS это редкий случай, но как насчёт удалённого доступа по ssh или SMB ? Или же принятие звонков через SIP ? Последнее как бы в бизнесе часто используется и пропущенный звонок из за мнимой безопасности может стоить дороже любого вашего роутера.

Для всех адресов попавших в NDP запускается периодический трекинг. Если адрес перестает отвечать на прямой запрос NDP трекеру, то медицина бессильна - это его проблема, этот хост невозможно отличить от "насовсем отключенного". Также если хост из-за privacy extensions меняет адрес, но не анонсирует его через DAD - он сами виноват, как это вообще можно узнать?

Единственное решение в таком случае - дополнительный статический адрес, который всегда доступен.

  • 0
Опубликовано
6 часов назад, Le ecureuil сказал:

Для всех адресов попавших в NDP запускается периодический трекинг. Если адрес перестает отвечать на прямой запрос NDP трекеру, то медицина бессильна - это его проблема, этот хост невозможно отличить от "насовсем отключенного". Также если хост из-за privacy extensions меняет адрес, но не анонсирует его через DAD - он сами виноват, как это вообще можно узнать?

Единственное решение в таком случае - дополнительный статический адрес, который всегда доступен.

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

  • 0
Опубликовано (изменено)

Есть ли возможность добавить команду ipv6 nat, по аналогии с ip nat?

PS: Провайдер выдаёт /128 😡

Изменено пользователем Oleg Nekrylov
  • 0
Опубликовано
В 07.02.2026 в 12:27, Oleg Nekrylov сказал:

Есть ли возможность добавить команду ipv6 nat, по аналогии с ip nat?

PS: Провайдер выдаёт /128 😡

Провайдер на роутер может /128 выдавать. Но должен еще выдавать префикс для делегирования в домашнюю сеть.

  • 0
Опубликовано (изменено)
В 09.03.2026 в 00:54, Heggi сказал:

Провайдер на роутер может /128 выдавать. Но должен еще выдавать префикс для делегирования в домашнюю сеть.

Не должен и не выдаёт: Deutsche Telecom. Хочешь префикс, плати ещё 50€

Когда подключали деревню (лет 10 назад), провайдер воткнул провод напрямую в корпоративный ноутбук (Fritz!Box тогда ещё не ставили).

И вот в один прекрасный момент, мой товарищ (на ПМЖ в Германии) увидел, что по его экрану мышь сама ползает, открывает каталоги, смотрит корпоративные файлы. По старой памяти, позвонил мне: что делать?

Я посоветовал поставить роутер и проверить ноутбук, роутер он купил в Калининграде (KN-2311, чтобы заодно был мобильный интернет в командировках), корпоративные it ноут проверили.

Вот и возник вопрос: подключается проводом напрямую или через взятый у соседа на время Fritz!Box - есть доступ к корпоративному серверу (только ipv6), подключается через Keenetic - нет доступа.

Fritz!Box получает публичный /128, а в сеть транслирует по DHCPv6 приватные адреса: fxxxx

Как сделать такое на Keenetic без Entware?
 

Изменено пользователем Oleg Nekrylov
  • 0
Опубликовано
1 час назад, Oleg Nekrylov сказал:

Не должен и не выдаёт: Deutsche Telecom. Хочешь префикс, плати ещё 50€

Когда подключали деревню (лет 10 назад), провайдер воткнул провод напрямую в корпоративный ноутбук (Fritz!Box тогда ещё не ставили).

И вот в один прекрасный момент, мой товарищ (на ПМЖ в Германии) увидел, что по его экрану мышь сама ползает, открывает каталоги, смотрит корпоративные файлы. По старой памяти, позвонил мне: что делать?

Я посоветовал поставить роутер и проверить ноутбук, роутер он купил в Калининграде (KN-2311, чтобы заодно был мобильный интернет в командировках), корпоративные it ноут проверили.

Вот и возник вопрос: подключается проводом напрямую или через взятый у соседа на время Fritz!Box - есть доступ к корпоративному серверу (только ipv6), подключается через Keenetic - нет доступа.

Fritz!Box получает публичный /128, а в сеть транслирует по DHCPv6 приватные адреса: fxxxx

Как сделать такое на Keenetic без Entware?
 

ipv6 local-prefix fd00:0:0::/48

ipv6 subnet Default number 1
  • 0
Опубликовано

Локальный префикс не будет форвардиться в интернет. Нужен nat66, что это работало, как сейчас работает ipv4.

Скорее всего тут поможет ipv6 pass-throught.

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

NPTv6 как раз есть, иначе multihoming не работал бы. Просто пользователем не управляется 

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

Да, вы правы. Но работает он у меня настолько отвратительно, что можно сказать не работает.
Включение второго провайдера с ipv6 у меня ломает ipv6 вообще :(

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

Добавлю свежий практический пример по IPv6 на KN-1811 / KeeneticOS 5.1b4 (preview 5.01.B.4.0-1).

Это именно проблема с текущей реализацией при нескольких выходах в сеть, маршрутизации по DNS и нежелании раздавать домашним устройствам публичный IPv6-префикс провайдера.

Схема такая:

  • провайдер выдаёт IPv6 и делегированный префикс;
  • на роутере используется штатная IPv6-маршрутизация KeeneticOS;
  • используется маршрутизация доменов через dns-proxy route ... Wireguard<N> auto reject;
  • хочется, чтобы устройства в Home получали только ULA, маршрут по умолчанию на роутер и DNS тоже через роутер;
  • публичный адрес из префикса провайдера на устройства раздавать наоборот — не хочется.

Причина простая: если клиент получает публичный 2a02:..., меняется вся модель безопасности и приватности. Устройство уже не просто “внутри домашней сети за роутером”, а имеет публичный IPv6-адрес. Да, входящий трафик можно фильтровать, но сама модель становится другой.

Штатная настройка выглядит логично:

Цитата

 

interface ISP
    ipv6 address auto
    ipv6 prefix auto

interface Home
    ipv6 prefix auto
    no ipv6 name-servers auto

ipv6 local-prefix default

ipv6 subnet Default
    bind Home
    mode slaac
    prefix length 64
    number 0

 

Но при включении mode slaac штатный radvd раздаёт в домашнюю сеть сразу оба префикса:

- ULA fdf4:.../64;
- публичный префикс провайдера 2a02:.../64.

В итоге Windows-клиент получает и fdf4:..., и 2a02:..., плюс маршрут по умолчанию и DNS через RA/RDNSS.

Отдельной настройки вида “SLAAC только для ULA” или “не раздавать публичный префикс провайдера в LAN” я в CLI не нашёл.

Пробовал:

Цитата

ipv6 subnet Default
    no prefix delegate

В моём случае это не убрало публичный префикс из RA.

Если же сделать:

Цитата

ipv6 subnet Default
    no mode

то штатная раздача RA выключается полностью. Префиксы на роутере остаются, маршрутизация есть, но клиенты не получают ни SLAAC-адреса, ни маршрут по умолчанию, ни DNS — вообще ipv6 отсутствует дальше кинетика.

То есть сейчас выбор такой:

  1. mode slaac — клиентам раздаются и ULA, и публичный IPv6 провайдера.
  2. no mode — клиентам не раздаётся вообще ничего.

Рабочий обходной вариант оказался таким: оставить всю штатную маршрутизацию KeeneticOS, но заменить только источник RA.

Штатно остаётся:

  • получение IPv6 на ISP;
  • получение делегированного префикса;
  • ipv6 local-prefix default;
  • маршрутизация;
  • dns-proxy;
  • firewall;
  • работа через Wireguard-интерфейсы.

А штатный RA выключается:

Цитата

ipv6 subnet Default
    no mode

Вместо него запускается обычный radvd через entware на br0, который раздаёт только ULA:

Цитата

 

interface br0 {
    AdvSendAdvert on;
    AdvManagedFlag off;
    AdvOtherConfigFlag on;
    AdvDefaultLifetime 1800;

    prefix fdf4:...::/64 {
        AdvOnLink on;
        AdvAutonomous on;
        AdvPreferredLifetime infinity;
        AdvValidLifetime infinity;
    };

    RDNSS fe80::<link-local-адрес-роутера> {
    };
};

 

После этого Windows-клиент получает:

  • только fdf4:...;
  • без 2a02:... на клиенте;
  • маршрут по умолчанию через link-local адрес роутера;
  • DNS тоже через link-local адрес роутера.

При этом внешний IPv6 продолжает работать. Проверка с исходным адресом fdf4:... проходит, снаружи соединение видно как адрес из провайдерского 2a02:... префикса. То есть штатная маршрутизация/трансляция префикса на роутере продолжает работать, просто публичный префикс больше не раздаётся клиентам напрямую.

Сравнение получается такое

Штатный Keenetic mode slaac:

  • включается одной командой;
  • но раздаёт клиентам и ULA, и публичный префикс провайдера;
  • нет понятной настройки “раздавать только local-prefix”;
  • no mode выключает весь RA целиком.

Пользовательский radvd:

  • вся маршрутизация остаётся штатной;
  • клиентам можно раздавать только ULA;
  • DNS можно оставить строго через роутер;
  • маршрутизация доменов через dns-proxy route продолжает работать;
  • но это уже ручной обход, потому что приходится забирать у KeeneticOS управление RA.

Отдельная связанная проблема — DNS в IPv6.

Сейчас есть несколько разных мест, которые влияют на DNS6:

  • interface ipv6 name-servers auto / no ipv6 name-servers auto;
  • ipv6 name-server;
  • ipv6 subnet dns-server;
  • RDNSS в RA;
  • dns-proxy route ... <interface> auto reject.

Сам dns-proxy route очень полезен. На нём можно строить нормальную маршрутизацию доменов через разные выходы: ISP, Wireguard0, Wireguard1 и т.д.

Но в IPv6 не хватает единой понятной политики:

  • принимать или не принимать DNS6 от провайдера;
  • что именно отдавать клиентам через RDNSS/DHCPv6;
  • как гарантировать, что клиенты используют роутер как DNS;
  • как не допустить утечки запросов в DNS6 провайдера;
  • как связать это с dns-proxy route, чтобы IPv4 и IPv6 имена маршрутизировались одинаково.

Что хотелось бы видеть в KeeneticOS:

1. Управление RA по префиксам в подсети.

Например:

  • раздавать только ULA;
  • раздавать только публичный префикс;
  • раздавать оба;
  • не раздавать конкретный делегированный префикс;
  • отдельно управлять RDNSS/DNSSL.

2. Явное управление трансляцией IPv6-префиксов.

Сейчас видно, что внутри оно есть и работает, иначе ULA-клиент не выходил бы наружу через адрес провайдера. Но пользователю это почти никак не управляется и плохо диагностируется.

Нужны команды, которые показывают:

  • какие префиксы транслируются;
  • через какой выход;
  • что будет при нескольких провайдерах;
  • почему выбран именно этот внешний префикс.

3. Нормальная работа с несколькими IPv6-выходами.

Например:

  • ISP;
  • Wireguard0;
  • Wireguard1;
  • второй провайдер с IPv6.

Нужны понятные правила выбора выхода, исходного префикса, firewall-правил и DNS-маршрутов. Сейчас при добавлении второго IPv6-выхода слишком легко получить непредсказуемое поведение.

4. Единая политика DNS6.

Хочется иметь возможность явно сказать:

  • DNS6 от провайдера не принимать;
  • клиентам отдавать только роутер;
  • все DNS-запросы клиентов пропускать через dns-proxy;
  • маршруты dns-proxy route применять и к A, и к AAAA;
  • не обходить DoT/DoH или настроенные DNS-маршруты через провайдерские DNS6.

5. Диагностика.

Тут тоже — очень не хватает команд вида:

  • показать, какие RA сейчас реально отправляются в Home;
  • показать, какие префиксы раздаются клиентам;
  • показать RDNSS для каждой подсети;
  • показать состояние трансляции IPv6-префиксов;
  • показать, почему конкретный клиент получил или не получил конкретный IPv6-адрес.

Видел в мане ipv6 subnet debug, но описания нет у этого добра.

Итог.

Низкоуровнево в KeeneticOS уже есть почти всё нужное: ULA, делегирование префикса, subnet, маршрутизация, firewall, dns-proxy route, внутренняя трансляция префиксов.

Не хватает управляемой связки поверх этого.

Из-за отсутствия одной настройки “SLAAC только для ULA, публичный префикс в LAN не раздавать” приходится выключать штатный mode slaac и запускать свой radvd. При этом вся остальная штатная часть KeeneticOS работает правильно и предсказуемо.

  • 0
Опубликовано (изменено)

Есть еще проблема IPv6: RogueRA ( router advertisement)  // это у одного прова в СПБ , писать название пока не                                                                                                             //  буду...
                                                                                                  // просто выключаю IPv6 у всех у кого данный пров...

 

https://datatracker.ietf.org/doc/html/rfc6104

Изменено пользователем krass
  • 0
Опубликовано (изменено)
В 30.05.2026 в 20:38, nos1609 сказал:

Причина простая: если клиент получает публичный 2a02:..., меняется вся модель безопасности и приватности. Устройство уже не просто “внутри домашней сети за роутером”, а имеет публичный IPv6-адрес. Да, входящий трафик можно фильтровать, но сама модель становится другой.

В IPv6 адрес источника и адрес назначения имеет значительный вес и в выборе адреса, с которого подключаться (их легко может быть 10 на интерфейсе), и в приоритете адреса, к которому подключаться.
ULA source address имеет приоритет ниже, чем IPv4 source.

Если вы открываете обычный сайт, у которого A (IPv4) и AAAA (IPv6) записи на домене (IPv6 глобальный, разумеется), подключение будет устанавливаться через IPv4. IPv6 будет использоваться только для IPv6-only сайтов (даже у ULA-ULA приоритет ниже, чем IPv4-IPv4). Потому что с точки зрения спецификации ULA-адреса считаются предназначенными для локальной сети, и нет резона их использовать при подключении к GUA-адресам.

Приоритеты заложены во все операционные системы и меняются только на стороне клиента, а не роутера/сервера.

https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/

https://www.infoblox.com/blog/ipv6-coe/ula-is-broken-in-dual-stack-networks/

Изменено пользователем ValdikSS
  • 0
Опубликовано (изменено)
В 03.11.2026 в 17:51, sermart1234 сказал:

Очень не хватает IPv6 endpoint на WG и тд

Это поддержу! Сделал запрос в поддержку, там ответили, что работа над этим ведется в рамках NDM-4300, но каких-либо сроков дать не могут. Но это обязательно будет "в коробке".

Сейчас для себя эту проблему решил при помощи AWG Manager - работает отлично! На стороне сервера вижу, что клиент (Кинетик) пришел к нему именно IPv6 адресом.

Еще хотел было поднять проблему с DNS маршрутизацией и IPv6 в KeeneticOS, по которой делал запрос в техподдержку и которая мне помочь не смогла, но уже нашел решение в виде Hydra Route Neo.

Суть - у меня провайдер выдает IPv6 префикс /48. Так же у меня настроена DNS маршрутизация "в коробке" через несколько поднятых AWG туннелей. Так вот, если не выдавать устройствам сети IPv6 адреса, то все шикарно работает. Стоит только включить галочку выдачи IPv6 адресов на странице Сегменты, как часть ресурсов из списков DNS маршрутизации начинают отдавать ошибку и в ней пишут мой IPv6 адрес. Это те ресурсы, которые по той или иной причине блокируют пользователей из РФ. Так вот, поддержка меня уверила, что так и должно быть и это by design и роутер тут помочь не может. 

Сегодня отключил маршруты в коробочном DNS Маршрутизация и поставил Hydra Route Neo - там просто повторил все то, что у меня было в коробке. Но теперь, о чудо! Я включил выдачу устройствам IPv6 адресов, они их получили. А те ресурсы, что ранее меня не впускали и показывали ошибку с моим публичным IPv6 адресом, теперь прекрасно продолжают открываться! То есть все было возможно и роутер еще как мог помочь! 

Мое предположение, что в данном случае сработала фича Hydra Route Neo "L7-перехват" //обновлено - проверил, эта фича у меня в состоянии по-умолчанию, то есть выключена. Значит сработало без нее.//

Но мнение уважаемого @Le ecureuil я бы по этой теме выслушал с удовольствием.

Изменено пользователем ankar84
  • 0
Опубликовано (изменено)
2 часа назад, ankar84 сказал:

Но мнение уважаемого @Le ecureuil я бы по этой теме выслушал с удовольствием.

Жаль, но мы не услышим "начальника транспортного цеха" ((( Форум очень многое потерял после его аннигиляции.

Изменено пользователем cool

Присоединяйтесь к обсуждению

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

Гость
Ответить на вопрос...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

  • Последние посетители   1 пользователь онлайн

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

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

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