Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Новинка
Распродажа
Новости
Доставка
Оплата
Загрузки
  • Прошивки
    • 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
     
    vasco
    Guest
    #1
    0
    29.11.2020 13:31:00
    Привет! Я настраиваю новую домашнюю сеть с RB2011 в роли основного роутера. Это небольшая сеть, до 10 устройств (Linux-десктопы, Android-телефоны и т.п.). Провайдер — местный VDSL, RB2011 подключен к VDSL-модему через eth1, интернет работает через pppoe-client. Когда всё настроил, включил IPv6-пакет на RB2011 и добавил такую конфигурацию:

    /interface pppoe-client  
    add add-default-route=yes disabled=no interface=ether1 max-mru=1480 max-mtu=1480 name=pppoe-vdsl password=adsl service-name=internet user=adsl

    /ipv6 address  
    add address=::1 from-pool=IP6-pool interface=bridge

    /ipv6 dhcp-client  
    add add-default-route=yes interface=pppoe-vdsl pool-name=IP6-pool request=prefix

    /ipv6 nd  
    set [ find default=yes ] interface=bridge

    Теперь главный роутер и все устройства в LAN имеют IPv6-адреса и могут подключаться к любым IPv6-серверам. Но есть одна большая проблема: некоторые сайты недоступны по IPv6 при использовании HTTPS. Например, https://mikrotik.com — один из таких:

    $ curl -v https://mikrotik.com  
    * Rebuilt URL to: https://mikrotik.com/  
    *   Trying 2a02:610:7501:1000::2...  
    * Connected to mikrotik.com (2a02:610:7501:1000::2) port 443 (#0)  
    * Operation timed out after 0 milliseconds with 0 out of 0 bytes received  
    * Closing connection 0  
    curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received

    Если же заходить на этот сайт по IPv4 — никаких проблем:

    $ curl -v https://mikrotik.com  
    * Rebuilt URL to: https://mikrotik.com/  
    *   Trying 159.148.147.196...  
    * Connected to mikrotik.com (159.148.147.196) port 443 (#0)  
    * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  
    * Server certificate: mikrotik.com  
    * Server certificate: DigiCert SHA2 Extended Validation Server CA  
    * Server certificate: DigiCert High Assurance EV Root CA  
    > GET / HTTP/1.1  
    > Host: mikrotik.com  
    > User-Agent: curl/7.43.0  
    > Accept: */*  
    >  
    < HTTP/1.1 200 OK  
    .....

    У меня нет проблем с https://mikrotik.com по IPv6 при обычном HTTP, да и пинг до mikrotik.com по IPv6 тоже проходит. Mikrotik.com — не единственный сайт, который не открывается по IPv6. Ещё один с такой же проблемой — https://ipv6.test-ipv6.com/.

    Такая же ситуация на Macbook, подключённом к моей сети по Wi-Fi, и на Ubuntu-десктопе, подключённом напрямую к eth2 на RB2011. Даже Android-телефоны испытывают ту же проблему с https://mikrotik.com — поэтому думаю, что проблема в основном роутере.  

    Что здесь происходит? Почему одни HTTPS-сайты по IPv6 работают, а другие — нет? Есть ли идеи, что не так с настройкой RouterOS или что можно изменить? Спасибо за любые идеи и комментарии. Уже несколько часов занимаюсь этим вопросом без успеха и прогресса.

    Кстати, вот мои базовые IPv6 правила фаервола:

    /ipv6 firewall address-list  
    add address=::/128 comment="defconf: unspecified address" list=bad_ipv6  
    add address=::1/128 comment="defconf: lo" list=bad_ipv6  
    add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6  
    add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6  
    add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6  
    add address=100::/64 comment="defconf: discard only " list=bad_ipv6  
    add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6  
    add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6  
    add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6  
    add address=::224.0.0.0/100 comment="defconf: other" list=bad_ipv6  
    add address=::127.0.0.0/104 comment="defconf: other" list=bad_ipv6  
    add address=::/104 comment="defconf: other" list=bad_ipv6  
    add address=::255.0.0.0/104 comment="defconf: other" list=bad_ipv6

    /ipv6 firewall filter  
    add action=drop chain=input comment="defconf: rfc4890 drop ll if hop-limit!=255" dst-address=fe80::/10 hop-limit=not-equal:255 protocol=icmpv6  
    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::/16  
    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=drop chain=forward comment="defconf: drop everything else not coming from LAN" in-interface-list=!LAN
     
     
     
    DarkNate
    Guest
    #2
    0
    07.01.2021 09:11:00
    ICMPv6 нужен для автоматического согласования MTU. То, что предложено выше — плохое решение и повлияет на пропускную способность канала. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/xe-3se/5700/ip6-mtu-path-disc.html#GUID-DC81F457-F213-426C-92B1-C1C7C0DCDA29
     
     
     
    Znevna
    Guest
    #3
    0
    07.01.2021 09:59:00
    Опять же, даже здесь он не использовал 1280. Читайте: http://forum.mikrotik.com/t/some-websites-unavailable-on-ipv6/145044/1 Отмеченное «решение», которое вызывает отвращение, так и не было применено.
     
     
     
    DarkNate
    Guest
    #4
    0
    07.01.2021 10:24:00
    В этом полный провал, и это здорово. Ненавижу этих бездарных пропагандистов MTU. Мой основной провайдер всё ещё ограничивает MTU до 1460 на своей так называемой «следующем поколении» оптоволоконной инфраструктуре. Некоторые люди так и не освоили базовые 1500 MTU в Ethernet.
     
     
     
    pe1chl
    Guest
    #5
    0
    07.01.2021 12:03:00
    Главная проблема в том, что Path MTU Discovery работает ужасно. Во-первых, потому что ICMP-сообщения часто удаляют неопытные администраторы фаерволов, а во-вторых, потому что такой механизм всегда имеет срок жизни, после которого снова пытается отправлять пакеты размером 1500 байт и вынужден снижать размер заново. Часто этот срок жизни очень короткий. Поэтому на практике он работает корректно только когда можно использовать MTU в 1500 байт — совершенно произвольное значение, которое стало «стандартом».
     
     
     
    StubArea51
    Guest
    #6
    0
    07.01.2021 16:28:00
    Первый день в интернете с MTU? Его эффективный MTU был на 20 байт меньше 1500 от провайдера, а PMTUD работала некорректно. Нужно настроить и протестировать MTU, когда он не работает по умолчанию, чтобы понять проблему. Спроектировав и построив сотни провайдерских и MPLS-сетей, где требуется сложная математика MTU, я сохраняю своё мнение. Регулировка MSS — это не идеальное решение и всегда считается «пластырем» в сети провайдера. Когда MTU не может достичь 1500 из-за транспортной инкапсуляции, например PPPoE, установка IP-подсети на максимальное значение всегда остается самым эффективным решением для роутера и производительности. Если есть лучший способ с учётом уменьшенного MTU и сломанного PMTUD — я открыт для предложений.
     
     
     
    DarkNate
    Guest
    #7
    0
    07.01.2021 17:25:00
    Именно, PMTUD ненадёжен, потому что тупые админы его блокируют, а MSS не исправляет UDP-трафик, разве нет? Решение (два в одном — одно для сломанного MTU, другое для провайдеров, соответствующих RFC4638): Netflix и IPv6 — #11 от DarkNate. Для развлечения другой участник попытался выяснить, куда делись эти 12 байт, ведь это эксклюзивно для MikroTik, он отправил баг-репорт в MikroTik: Netflix и IPv6 — #11 от DarkNate.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2026 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры