Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • RouterOS
  • Мобильные приложения MikroTik
  • Архив
Форум
Настройка
    info@mikrotik.moscow
    +7 495 320-55-52
    Заказать звонок
    Mikrotik.moscow
    Каталог
    • Акции
      Акции
    • Маршрутизаторы
      Маршрутизаторы
    • Коммутаторы
      Коммутаторы
    • Радиомосты и уличные точки доступа
      Радиомосты и уличные точки доступа
    • Wi-Fi для дома и офиса
      Wi-Fi для дома и офиса
    • LTE/5G
      LTE/5G
    • Powerline адаптеры
      Powerline адаптеры
    • IoT устройства
      IoT устройства
    • Оборудование 60 ГГц
      Оборудование 60 ГГц
    • Материнские платы RouterBOARD
      Материнские платы RouterBOARD
    • Корпуса
      Корпуса
    • Интерфейсы
      Интерфейсы
    • SFP/QSFP трансиверы
      SFP/QSFP трансиверы
    • Аксессуары
      Аксессуары
    • Антенны
      Антенны
    • Архив
      Архив
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Скачать WinBox Скачать Прошивки Форум > RouterOS Форум > SwOS Форум > Железо
    Mikrotik.moscow
    Каталог
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Mikrotik.moscow
    Телефоны
    +7 495 320-55-52
    Заказать звонок
    0
    0
    0
    Mikrotik.moscow
    • +7 495 320-55-52
      • Назад
      • Телефоны
      • +7 495 320-55-52
      • Заказать звонок
    • info@mikrotik.moscow
    • г. Москва, ул. Бакунинская, 84
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной


    • Кабинет
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Форум
    RouterOS
    Недоступный IPv6 пинг с локального хоста

    Недоступный IPv6 пинг с локального хоста

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Недоступный IPv6 пинг с локального хоста, RouterOS
     
    diasdm
    Guest
    #1
    0
    19.03.2024 02:34:00
    С моего HAP AX3, когда я пытаюсь пропинговать домен с поддержкой только IPv6, кажется, что роутер не может достучаться до цели. [@MikroTik] > ping [:resolve checkipv6.dedyn.io]
     SEQ HOST                                     SIZE TTL TIME       STATUS  
       0 2a01:4f8:10a:1044:deec:642:ac10:80                           тайм-аут  
       1 2a01:4f8:10a:1044:deec:642:ac10:80                           тайм-аут  
       2 2a01:4f8:10a:1044:deec:642:ac10:80                           тайм-аут  
       3 2804::pub:ipv6       104  64 89ms653us  адрес недоступен  

    Я думал, что дело в правилах файервола, но ICMP-пакеты принимаются. [@MikroTik] > ipv6/firewall/filter/print
    2    ;;; defconf: accept ICMPv6  
         chain=input action=accept protocol=icmpv6 log=no log-prefix=""  

    Клиенты спокойно пингуют IPv6-домен без проблем.  
    PS > ping checkipv6.dedyn.io  
    Ответ от 2a01:4f8:10a:1044:deec:642:ac10:80: время=238мс  
    Ответ от 2a01:4f8:10a:1044:deec:642:ac10:80: время=238мс  
    Ответ от 2a01:4f8:10a:1044:deec:642:ac10:80: время=238мс  
    Ответ от 2a01:4f8:10a:1044:deec:642:ac10:80: время=239мс  

    Не могу понять, в чём проблема. Есть идеи, почему с самого роутера IPv6 пинги не проходят?
     
     
     
    diasdm
    Guest
    #2
    0
    22.04.2024 23:45:00
    Получаю публичный IPv6.  
    [@MikroTik] > ipv6/dhcp-client/export
    /ipv6 dhcp-client  
    add add-default-route=yes interface=ether1_WAN pool-name=WAN_IPv6_Pool request=address use-peer-dns=no  
    [@MikroTik] > ipv6/dhcp-client/print
    # INTERFACE   STATUS  REQUEST  ADDRESS  
    0 ether1_WAN  bound   address  2804:X:X:X:X:X:X:X, 23h59m57s  

    Похоже, что маршрут по умолчанию настроен правильно.  
    [@MikroTik] > ipv6/route/print
       DST-ADDRESS               GATEWAY      DISTANCE  
    DAd ::/0                      ether1_WAN          1  
    DAc ::1/128                   lo                  0  
    DAc 2804:X:X:X:X:X:X:X/128    ether1_WAN          0  
    DAc fd08:192:168:8::/64       bridge_LAN          0  
    DAc fd09:192:168:9::/64       bridge_WiFi         0  
    DAc fe80::%ether1_WAN/64      ether1_WAN          0  
    DAc fe80::%bridge_LAN/64      bridge_LAN          0  
    DAc fe80::%bridge_WiFi/64     bridge_WiFi         0  

    Однако, когда пытаюсь пропинговать любой удалённый IPv6-адрес, он недостижим.  
    [@MikroTik] [ping]> ping 2800:3f0:4004:803::200e
     SEQ HOST                                     SIZE TTL TIME       STATUS  
       0 2800:3f0:4004:803::200e                                      timeout  
       1 2800:3f0:4004:803::200e                                      timeout  
       2 2800:3f0:4004:803::200e                                      timeout  
       3 2804:X:X:X:X:X:X:X                        104  64 80ms661us  address unreachable  
       4 2800:3f0:4004:803::200e                                      timeout  
       5 2800:3f0:4004:803::200e                                      timeout  
       sent=6 received=0 packet-loss=100%  

    Правил в фаерволе, которые могли бы блокировать IPv6-пакеты, не нашёл.  
    [@MikroTik] > ipv6/firewall/filter/export
    /ipv6 firewall filter  
    add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked  
    add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid  
    add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6  
    add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp  
    add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10  
    add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp  
    add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah  
    add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp  
    add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec  
    add action=drop chain=input comment="defconf: drop everything else not coming from LAN" in-interface-list=LAN  
    add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked  
    add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid  
    add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6  
    add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6  
    add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6  
    add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6  
    add action=accept chain=forward comment="defconf: accept HIP" protocol=139  
    add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp  
    add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah  
    add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp  
    add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec  
    add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN  

    Есть идеи, в чём тут дело?
     
     
     
    mkx
    Guest
    #3
    0
    23.04.2024 06:18:00
    Ты неправильно настраиваешь IPv6-адресацию. Твоему роутеру на WAN-порту вообще не нужен GUA (глобальный) адрес. Но зато нужен префикс, чтобы можно было включить IPv6 на LAN-сетях. Вместо того чтобы настраивать DHCPv6-клиента так, как у тебя, сделай примерно так:

    /ipv6/dhcp-client  
    add interface=ether1_WAN pool-name=WAN_IPv6_Pool request=prefix use-peer-dns=no pool-prefix-length=64 prefix-hint=::/56  

    /ipv6/address  
    add address=::1 from-pool=WAN_IPv6_Pool interface=bridge_LAN  
    add address=::1 from-pool=WAN_IPv6_Pool interface=bridge_WiFi  

    (заметка: конструкция «address= from-pool=» будет назначать разные адреса для разных интерфейсов, потому что пул выдаёт разные адреса при каждом запросе, несмотря на то, что выглядит, будто адрес будет одинаковый)

    Далее: информация о маршрутизации в IPv6 должна поступать из Router Advertisements (RA). Опция DHCPv6-клиента add-default-route=yes — это костыль в MikroTik, который пытается поставить дефолтный маршрут на адрес DHCPv6-сервера или, как в твоём случае, на интерфейс, что неправильно для точка-многоточка.

    Вместо этого настрой роутер так:

    /ipv6 settings  
    set accept-router-advertisements=yes  

    Это позволит роутеру получать RA от твоего провайдера…
     
     
     
    diasdm
    Guest
    #4
    0
    25.04.2024 01:32:00
    После некоторых тестов я понял, что маршрут по умолчанию для IPv6 был настроен неправильно. Шлюз по умолчанию должен задаваться динамически клиентом DHCP для WAN-интерфейса. Опция «add-default-route» установлена в «yes», но маршрут не добавлялся после перезагрузки. Простой повторный запуск DHCP-клиента автоматически устанавливал динамический шлюз по умолчанию — следующий переход провайдера с локальным линковым адресом.

    [@MikroTik] [rout]> ipv6/route/print
    DST-ADDRESS             GATEWAY                              DISTANCE  
    DAd ::/0                fe80::662:73ff:fee4:a419%ether1_WAN         1  

    Опция «accept-router-advertisements=yes» проблему не решила, поэтому я вернул её к значению по умолчанию. Затем я изменил параметр запроса для DHCP-клиента на «request=address,prefix», и, наконец, правильный маршрут по умолчанию был добавлен. Кажется, это решило проблему.  

    Но вопрос остаётся... Даже если «add-default-route» стоит в «yes», почему DHCP-клиент не добавляет корректный IPv6 маршрут по умолчанию, если он запрашивает только адрес, а не префикс?
     
     
     
    mkx
    Guest
    #5
    0
    25.04.2024 20:24:00
    Потому что протокол DHCPv6 не поддерживает передачу маршрутизирующей информации клиенту. И не важно, запрашивает ли клиент адрес или префикс. Так что всё, что ROS делает при включённой опции add-default-route, — это просто догадки, ведь то, что он придумывает, не настраивается провайдером. ROS может угадать правильно, а может и грубо промахнуться. Есть ещё один момент: маршрутизатор наверху должен знать, куда пересылать трафик для делегированного префикса. А эта информация есть только у DHCPv6-сервера. WAN IPv6-адрес клиента может быть ULA (собран из MAC-адреса интерфейса, а эту информацию DHCPv6-сервер знает, потому что она нужна для односторонней связи, которая используется на последующих этапах рукопожатия DHCPv6). WAN IPv6-адрес клиента может быть и GUA (технически для маршрутизации это не обязательно), и если DHCPv6-клиент запрашивает одновременно и адрес, и префикс в одном рукопожатии, то сервер DHCPv6 может выдать оба сразу и связать их с одним устройством. Учтите, что это нужно только для правильной маршрутизации пакетов с интернета в сторону LAN клиента. Чтобы маршрутизировать трафик в обратную сторону, шлюз клиента должен знать, какой должен быть следующий хоп. Как я уже писал, эта информация доступна из RA (но приём их должен быть включён). Можно также задать вышеупомянутую опцию DHCPv6-клиента, и тогда ROS установит шлюз по умолчанию на адрес DHCPv6-сервера. Похоже, что MT — не единственный производитель, который так делает, и многие провайдеры как-то терпят такое неправильное использование их DHCPv6-сервера. Если клиенты хотя бы принимают сообщения ICMPv6 Neighbor Redirect, то бедные DHCPv6-серверы не перегружаются из-за неправильно направленного трафика.
     
     
     
    diasdm
    Guest
    #6
    0
    25.04.2024 22:14:00
    Чтобы направлять трафик в обратную сторону, клиентский шлюз должен знать, какой будет следующий переход. Как я уже писал, эта информация доступна из RA (Router Advertisements), но их приём должен быть включён. Потому что протокол DHCPv6 не поддерживает передачу маршрутизирующей информации клиенту. И не важно, запрашивает клиент адрес или префикс. Так что всё, что делает ROS при включённой опции add-default-route — это просто догадки, потому что ISP не настраивает это явно. ROS может угадать правильно, а может и провалиться.

    Итак, вы говорите, что опция «add-default-route» не имеет значения. ROS берёт информацию из DHCPv6 и просто угадывает шлюз от DHCPv6-сервера. Информацию о следующем переходе даёт именно RA. Верно?

    Тем не менее, после перезагрузки правильный маршрут по умолчанию добавится только если в DHCPv6-запросе указана опция «prefix». Насколько я понимаю, IPv6-настройки стоят так, чтобы не принимать RA, потому что параметр «forward» установлен в «yes».

    [@MikroTik] > ipv6/settings/print
    disable-ipv6: no  
    forward: yes  
    accept-redirects: yes-if-forwarding-disabled  
    accept-router-advertisements: yes-if-forwarding-disabled  
    max-neighbor-entries: 14336  

    Однако если вернуться к моей изначальной конфигурации, где указано «request=address» и включено «accept-router-advertisements=yes», ROS после перезагрузки не добавляет правильный маршрут по умолчанию.  

    И если DHCPv6-клиент запрашивает и адрес, и префикс в одном запросе, то DHCPv6-сервер может выдать оба одновременно, и они будут связаны с одним и тем же устройством.  

    Да, думаю, в итоге я так и сделал — «request=address,prefix».
     
     
     
    diasdm
    Guest
    #7
    0
    25.04.2024 23:06:00
    После всех этих тестов я остановился на таких настройках: IPv6 DHCP клиент — «add-default-route=yes» и «request=address,prefix» IPv6 настройки — «accept-router-advertisements: yes»

    [@MikroTik] [prin]> ipv6/route/print
    Flags: D - Dинамический; A - Активный; c - Подключение; d - DHCP; g - SLAAC; + - ECMP  
        DST-ADDRESS               GATEWAY                              DISTANCE  
    DAd+ ::/0                      fe80::662:73ff:fee4:a419%ether1_WAN         1  
    DAg+ ::/0                      fe80::662:73ff:fee4:a419%ether1_WAN         1  
    DAc  ::1/128                   lo                                          0  
    DAc  2804:pub:prefix::/64      ether1_WAN                                  0  
    DAc  2804:pub:add/128          ether1_WAN                                  0  
    DAc  fd08:192:168:8::/64       bridge_LAN                                  0  
    DAc  fd09:192:168:9::/64       bridge_WiFi                                 0  
    DAc  fe80::%ether1_WAN/64      ether1_WAN                                  0  
    DAc  fe80::%bridge_LAN/64      bridge_LAN                                  0  
    DAc  fe80::%bridge_WiFi/64     bridge_WiFi                                 0  

    Так мы видим, что есть как маршрут SLAAC (g), так и DHCP (d), и они одинаковые. На самом деле маршрутизация начинает работать только тогда, когда маршрут DHCP настроен с указанием следующего узла.
     
     
     
    mkx
    Guest
    #8
    0
    26.04.2024 05:20:00
    На мой взгляд, когда есть два одинаковых маршрута, должен сработать любой из них (флаги тут не важны, они — метаданные, а не информация о маршрутизации). Приятно видеть, что «DHCPv6 client default route mock-up» в твоём случае приводит к правильной настройке. Так что, если использование этой опции DHCPv6 клиента у тебя работает, продолжай её применять.

    Ещё один момент, который стоит учитывать: RA (Router Advertisements) по сути рассылаются периодически и с интервалами в несколько минут. Устройство, при поднятии интерфейса, может запросить отправку RA вне обычного расписания, чтобы получить нужную информацию быстрее. Но если оно этого не делает (или если маршрутизатор игнорирует запрос), тогда может пройти некоторое время, прежде чем IPv6-соединение заработает. Так что при настройке IPv6 иногда придётся подождать, чтобы увидеть, влияют ли изменения на ситуацию или нет.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры