Mikrotik.moscow [тема: Недоступный IPv6 пинг с локального хоста]

Mikrotik.moscow [тема: Недоступный IPv6 пинг с локального хоста] http://mikrotik.moscow Новое в теме Недоступный IPv6 пинг с локального хоста форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Fri, 31 Jul 2026 19:57:49 -0400 Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
На мой взгляд, когда есть два одинаковых маршрута, должен сработать любой из них (флаги тут не важны, они — метаданные, а не информация о маршрутизации). Приятно видеть, что «DHCPv6 client default route mock-up» в твоём случае приводит к правильной настройке. Так что, если использование этой опции DHCPv6 клиента у тебя работает, продолжай её применять.

Ещё один момент, который стоит учитывать: RA (Router Advertisements) по сути рассылаются периодически и с интервалами в несколько минут. Устройство, при поднятии интерфейса, может запросить отправку RA вне обычного расписания, чтобы получить нужную информацию быстрее. Но если оно этого не делает (или если маршрутизатор игнорирует запрос), тогда может пройти некоторое время, прежде чем IPv6-соединение заработает. Так что при настройке IPv6 иногда придётся подождать, чтобы увидеть, влияют ли изменения на ситуацию или нет.
26.04.2024 05:20:00, mkx.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393080 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393080 Fri, 26 Apr 2024 05:20:00 -0400 RouterOS Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
После всех этих тестов я остановился на таких настройках: 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 настроен с указанием следующего узла.
25.04.2024 23:06:00, diasdm.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393079 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393079 Thu, 25 Apr 2024 23:06:00 -0400 RouterOS Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
Чтобы направлять трафик в обратную сторону, клиентский шлюз должен знать, какой будет следующий переход. Как я уже писал, эта информация доступна из 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».
25.04.2024 22:14:00, diasdm.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393078 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393078 Thu, 25 Apr 2024 22:14:00 -0400 RouterOS Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
Потому что протокол 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-серверы не перегружаются из-за неправильно направленного трафика.
25.04.2024 20:24:00, mkx.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393077 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393077 Thu, 25 Apr 2024 20:24:00 -0400 RouterOS Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
После некоторых тестов я понял, что маршрут по умолчанию для 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 маршрут по умолчанию, если он запрашивает только адрес, а не префикс?
25.04.2024 01:32:00, diasdm.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393076 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393076 Thu, 25 Apr 2024 01:32:00 -0400 RouterOS Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
Ты неправильно настраиваешь 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 от твоего провайдера…
23.04.2024 06:18:00, mkx.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393075 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393075 Tue, 23 Apr 2024 06:18:00 -0400 RouterOS Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
Получаю публичный 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

Есть идеи, в чём тут дело?
22.04.2024 23:45:00, diasdm.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393074 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393074 Mon, 22 Apr 2024 23:45:00 -0400 RouterOS Недоступный IPv6 пинг с локального хоста Недоступный IPv6 пинг с локального хоста RouterOS в форуме RouterOS.
С моего 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 пинги не проходят?
19.03.2024 02:34:00, diasdm.]]> http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393073 http://mikrotik.moscow/forum/forum57/85090-nedostupnyy-ipv6-ping-s-lokalnogo-khosta/message393073 Tue, 19 Mar 2024 02:34:00 -0400 RouterOS