Информация
Настройка
Новости
Контакты
Новинка
Распродажа
Оплата
Доставка
Загрузки
  • Прошивки
    • WinBox
    • RouterOS
    • Мобильные приложения MikroTik
    • Архив
  • Changelogs
  • 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
    Запрос на добавление функций: NAT64 + DNS64

    Запрос на добавление функций: NAT64 + DNS64

    Форумы: RouterOS, Аппаратное обеспечение, SwOS, Обратная связь, Объявления, Сторонние инструменты
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Запрос на добавление функций: NAT64 + DNS64, RouterOS
     
    jonburrows
    Guest
    #1
    0
    22.02.2015 06:51:00
    В основном NAT64. DNS64 — насколько это возможно.  
    *) NAT64: https://tools.ietf.org/html/rfc6146  
    *) DNS64: https://tools.ietf.org/html/rfc6147  

    Продолжайте в том же духе.
     
     
     
    omally01
    Guest
    #2
    0
    17.03.2015 14:25:00
    Да, эта функция будет очень полезна для нашей будущей версии v6.
     
     
     
    ZeroByte
    Guest
    #3
    0
    17.03.2015 14:45:00
    Я гораздо предпочёл бы развивать двойной стек, чем создавать изолированный островок IPv6 с обходными middlebox’ами, которые пытаются это сработать. Это никогда не будет работать так же хорошо, как полноценный нативный IPv6, и, скорее всего, сформирует неправильные привычки или даже создаст плохое первое впечатление от использования IPv6. Мы уже много лет используем сервис tunnelbroker от Hurricane Electric с BGP, который рекламирует наш нативный IPv6 /32, и всё работает безупречно.
     
     
     
    dmcken
    Guest
    #4
    0
    19.11.2015 16:20:00
    Просто проверяю, есть ли какие-то обновления по этому поводу? Поддерживается или нет? @ZeroByte: Двойной стек для некоторых из нас уже не вариант. ARIN отклонил нашу последнюю заявку и выделил только IPv6 для нового развертывания, у нас начинает катастрофически не хватать v4 для клиентов. Сейчас многие сервисы работают и по v6, и по v4, и я ожидаю, что использование NAT со временем снизится, когда больше людей перейдут на v6 и будут использовать нативное подключение вместо NAT. К счастью, легко убедить клиента, что проблема не в нем, ведь такие сервисы, как YouTube, Facebook, Netflix, работают нормально.
     
     
     
    shahbazian
    Guest
    #5
    0
    16.04.2017 01:36:00
    +1 NAT64 и DNS64 Отправлено с моего мобильного через Tapatalk
     
     
     
    ZeroByte
    Guest
    #6
    0
    04.05.2017 16:40:00
    Я по-другому теперь смотрю на NAT64 после моего предыдущего сообщения в этой ветке. Хорошо бы нам здесь, в компании, использовать 464XLAT, но, увы, Mikrotik должен хотя бы поддерживать stateless NAT64, чтобы мы смогли его развернуть. Планирую обсудить это с ребятами из Mikrotik на MUM USA в этом году.
     
     
     
    blackmesawireless
    Guest
    #7
    0
    20.06.2017 02:15:00
    Было бы здорово иметь это в ROS, но у нас сейчас в тестировании работает коробка с bind9, jool и quagga, и всё отлично. Планирую добавить ещё, используя anycast/ospf, чтобы оптимизировать производительность и обеспечить резервирование.
     
     
     
    idlemind
    Guest
    #8
    0
    20.06.2017 02:37:00
    Если вы планируете использовать stateful NAT64 с anycast, убедитесь, что они равномерно распределены или настроены по стоимости для всех ваших клиентов. Вам нужно, чтобы клиенты как можно чаще подключались к одному и тому же NAT64-серверу, чтобы избежать потери состояния из-за переключения между двумя серверами. В простой сети, например, с одним дата-центром и двумя башнями, размещайте каждое устройство на башнях, а не в дата-центре, или настройте стоимость каналов в дата-центре так, чтобы один сервер был предпочтительнее другого для ::/96.
     
     
     
    blackmesawireless
    Guest
    #9
    0
    20.06.2017 20:11:00
    Да, именно так планируем. У нас есть три крайних узла, и я думал поставить по одному на каждый, а также настроить стоимости OSPF, чтобы трафик не делился.
     
     
     
    ZeroByte
    Guest
    #10
    0
    20.06.2017 21:30:00
    Если Mikrotik не реализует stateless NAT64, то XLAT464 не будет жизнеспособным решением для тех из нас, у кого много роутеров Mikrotik CPE. Я разговаривал с Янисом Мегисом на MUM USA в этом году, и он принадлежит к лагерю «противников NAT». Раньше я тоже был в этом лагере, но теперь понял, что определённые виды NAT полезны и имеют смысл, не нарушая принцип сквозного соединения в IPv6. По его ответам на мои вопросы я понял, что не стоит надеяться на реализацию NAT64 в ближайшем будущем. Кстати, когда я в последний раз изучал этот вопрос в чисто Linux-среде, не нашёл решений на уровне ядра для NAT64. Приходилось использовать дополнительные инструменты, такие как TAIGA или JOOL, чтобы обеспечить NAT64, насколько я понял. Думаю, именно это повлияло на решение Mikrotik не вводить NAT64 в RouterOS. Ещё один вариант, который стоит рассмотреть — DS-Lite. Mikrotik может сделать всё необходимое на стороне CPE (B4). Вы можете настроить свои Linux-сервера как AFTR-устройства и получить функционал NAT64 таким образом. Это путь, который я сейчас исследую для внедрения IPv6 в своей компании.
     
     
     
    idlemind
    Guest
    #11
    0
    29.06.2017 12:52:00
    К сожалению, я всё ещё вижу это в корпоративной среде. Много людей, с кем я общаюсь, ждут, пока другие начнут использовать IPv6. Их позиция — «у меня работает, зачем менять?». По мере того, как мобильные технологии продолжают менять рынок и переходят на IPv6, я ожидаю, что это мнение либо изменится, либо люди просто будут ещё дальше прятать голову в песок, поскольку нативный IPv6 даёт более высокую производительность в сравнении с постоянно растущими слоями NAT.

    Это высказывание — скорее о растущем мировом использовании IPv6, но… Учитывая отзывы, которые вы получили, мне интересно, не разделяет ли и MikroTik такую точку зрения. Как бы там ни было, до мира, работающего только на IPv6, нам ещё далеко, и технологии перехода ещё долго будут нужны. Это значит, что рынок существует и он далеко не временный.

    Было бы печально, если бы из-за такого взгляда на IPv6 и технологии перехода MikroTik упустил возможность закрепиться или хотя бы сохранить лидерство в magic quadrant. В итоге всё сводится к продажам, а, по моему опыту, бизнесмены гораздо охотнее продают продукцию, чем выписывают зарплаты упрямым технарям. Надеюсь, до этого не дойдёт, но если дойдёт — MikroTik может потерять позиции в magic quadrant, а вернуть их очень сложно. Особенно с конкурентами по цене, как Ubiquiti. Тот, кто разработает нужные фичи, лучше выстроит работу с рынком по цене, чем Cisco и Juniper, у которых эти функции уже есть, но для ядра или для POP-установок.

    Я считаю, что NAT64 и DNS64 — это технологии перехода. Но я не ошибаюсь, думая, что они слишком мимолётны, чтобы их использовать. На самом деле, NAT для IPv4 довольно недавно стал повсеместным. MikroTik, выбирайте быть лидерами в технологиях, не ждите, пока придётся догонять рынок.

    Причина, по которой, как мне кажется, давление на переход к IPv6 будет расти — это доказанная работоспособность технологии: и Microsoft, и Cisco уже работают с сотнями пользователей на ней. Они приводят аргументы в пользу single stack — меньше сложности, проще контролировать безопасность, плюс есть возможности вроде глобально уникальных адресов, потому что адресное пространство RFC1918 заканчивается. Да, MS прямо так и сказала. В их корпоративной сети адресов RFC1918 стало не хватать. Невероятно.

    Ещё одна больная тема — пересечения адресного пространства при поглощениях компаний. Часто покупают конкурента, у которого тоже случайно выделены одни и те же блоки 10.0.0.0/8. Теперь приходится менять адреса сервисов — весело.

    Если IPv6 в single stack продолжит расти, повысится и использование NAT64. К счастью, это позволяет лучше централизовать нагрузку после CPE, сохраняя распределённые и отказоустойчивые возможности. При ограниченной поддержке это, возможно, будет модель развёртывания, к которой придётся прибегать людям вроде ZeroByte. Они либо будут поддерживать Linux-серверы с NAT64, либо несколько роутеров Cisco, способных на то же.

    Будь это Linux на Dell или Cisco, для MikroTik это всегда потерянные продажи. Отличный повод купить одну из этих красивых CCR… ой, подожди, там нет нужных мне функций...

    Проблема в том, что очень сложно найти роутеры, которые клиенты могут просто вставить у себя дома и чтобы они без проблем работали. Прошли те времена, когда можно было просто взять любой Netgear с полки. С этим, возможно, поможет борьба ISPs, которые хотят убрать все переходные технологии и перейти на single stack IPv6, но пока это наша насущная проблема.

    Как намекнул ZeroByte, DS-Lite помогает разгрузить NAT для IPv4 и IPv6, перекладывая задачи на ISP. По крайней мере, там есть адресное пространство.
     
     
     
    blackmesawireless
    Guest
    #12
    0
    10.07.2017 17:38:00
    Есть ли у вас советы, где почитать именно про эту настройку на RouterOS? Я знаю, что роутеры Linksys тоже из коробки поддерживают DS-lite, и, насколько я понимаю, именно это использует Comcast для внедрения IPv6. Но я не могу найти информацию, как настроить NAT с IPv4 на IPv6 на WAN-интерфейсе в RouterOS. В каком меню нужно быть или какую функцию использовать?

    Добавляю: посмотрев по ссылке ниже, заметил ещё одну проблему с RouterOS. Похоже, что рекомендуемый способ передать клиенту информацию AFTR — это опция (AFTR_NAME) для DHCPv6. Насколько я знаю, в RouterOS нет возможности это задать. Так ли это?

    https://www.isc.org/blogs/ds-lite-architecture-overview-and-automatic-configuration/
     
     
     
    ZeroByte
    Guest
    #13
    0
    10.07.2017 19:53:00
    Итак, поскольку я ещё не установил AFTR, чтобы поэкспериментировать, я пока не проверял необходимые настройки B4 на ROS, но, по сути, устройство B4 просто создаёт 4-в-6 туннель к какому-то удалённому IPv6 адресу (который может быть известен в вашей сети) — устройство B4 вообще не выполняет NAT. Оно просто пересылает IPv4 на маршрут с дефолтным шлюзом, доступный через туннель. Именно устройство AFTR отвечает за NAT, потому что, помимо типичного поведения NAT44, где в таблице трансляций используются «внутренний IP:порт + удалённый IP хоста:порт», DS-Lite добавляет ещё src-ipv6-адрес туннеля. Например: 2001:db8:ace:cafe::1 | 192.168.1.44:TCP:12345 | 172.217.11.142:TCP:443, где 2001:db8:ace:cafe::1 — это публичный IPv6 адрес B4, который он использует для создания туннеля к AFTR. (кстати, другие устройства в локалке могут просто использовать нативный IPv6 и напрямую выходить в интернет, без этого туннеля) 192.168.1.44 — это внутренний IPv4 адрес клиента, а IP справа — это IP-адрес www.youtube.com на момент написания примера. Так что B4 не занимается NAT, и поэтому AFTR нужен уникальный ключ для каждого клиента, чтобы разграничивать множество LAN, все использующие один и тот же внутренний диапазон 192.168.1.0/24. В общем, в качестве базового эксперимента уровня 101, я собирался просто построить туннель и заставить его работать. После этого можно переходить к следующему этапу — работе с AAA, безопасностью и так далее.
     
     
     
    blackmesawireless
    Guest
    #14
    0
    10.07.2017 21:08:00
    Какой именно туннель? В RouterOS есть возможность туннеля 6to4, но я никак не могу найти способ сделать 4to6.
     
     
     
    blackmesawireless
    Guest
    #15
    0
    15.07.2017 22:30:00
    Я могу вручную настроить туннель ipipv6 и пропускать через него ipv4, но сколько же это головной боли делать для каждого клиента с только IPv6.
     
     
     
    ZeroByte
    Guest
    #16
    0
    17.07.2017 15:09:00
    Mikrotik рекомендовал SSTP, когда я спрашивал об этом на MUM. Пока я с этим не игрался, но похоже, что это больше про профиль, чем просто обычный туннель IPIP6. Если вы используете Mikrotik как сервер SSTP, то это не сильно поможет, потому что он не сможет выполнять DS-Lite NAT64 (вообще никакого IPv6 NAT / NAT64, не говоря уже о NAT64 в стиле DS-Lite). Однако они предлагали использовать это как способ сделать транспорт только по v6 с централизованной доставкой IPv4 через SSTP. Это тоже сработает, и можно просто туннелировать маршрутизируемые V4-адреса или использовать CGNAT поверх туннелей с адресным пространством 100.64.0.0/10.
     
     
     
    barkas
    Guest
    #17
    0
    17.07.2017 19:32:00
    По моему опыту, sstp не обеспечивает самое стабильное соединение.
     
     
     
    idlemind
    Guest
    #18
    0
    17.07.2017 20:06:00
    Вот почему меня больше интересует одностековый IPv6 для клиента с NAT64 для работы с именованными (DNS) ресурсами IPv4. Ключевая задача — проверка CPE. Я уже знаю, что самые дешёвые устройства не подойдут, и вам понадобится либо Linux-серверы для NAT64 и DHCPv6 (назначение адресов, а не обязательно префиксов), либо, например, Cisco 1841 (~30 долларов на eBay), которые могут работать как NAT64-шлюзы, а в качестве сервиса DNS64 использовать Google. В какой-то момент мне нужно будет официально описать свой NAT64-лабораторию и выложить подробности по роутерам для домашних пользователей, которые я тестировал. Единственное, чего здесь нет, — это прямого доступа к IPv4-ресурсам (то есть к http://132.132.254.254 или что-то вроде того; решение — просто создать A-запись).
     
     
     
    ZeroByte
    Guest
    #19
    0
    17.07.2017 20:45:00
    Конечно, пока Mikrotik не реализует хотя бы stateless NAT64 в RouterOS, это всего лишь несбыточная мечта, но чтобы показать, почему это было бы круто, вот пример того, как 464XLAT делает жизнь проще. Если вы уже внедрили 464XLAT, то решить эту проблему можно с помощью stateless NAT64 прямо на CPE (за исключением IPv6-only хостов в LAN — см. в конце поста).

    Предположим, что у каждого CPE есть несколько /64 блоков (что и рекомендуется). Пусть, например, используется /60 — самый длинный префикс с границей ниббла, короче чем /64. Пусть CPE выделен префикс 2001:db8:cafe::/60. Можно легко назначить /96 для локального stateful nat для исходящего 4->6 трафика. Чтобы избежать конфликтов с LAN, обозначим целиком блок …F::/64. Итак: 2001:db8:cafe:f::/64 — это NAT64.

    Более конкретно, любые внутренние IPv4-адреса за роутером будут отображаться в: 2001:db8:cafe:f::aabb:ccdd (где a,b,c,d — это шестнадцатеричные значения 4 октетов IPv4-адреса).

    На стороне провайдера будет выделен аналогичный отдельный stateful NAT64 префикс. Можно использовать ULA-префикс или даже взять один из публичных блоков, если вы боитесь, что у клиентов могут блокироваться fd::/8 как префикс назначения. Например, на стороне провайдера 2001:db8:64::/96 можно назначить под «Интернет».

    На каждом CPE stateless NAT64 будет выглядеть так:
    DSTNAT64 a.b.c.d → 2001:db8:64::aabb:ccdd  
    SRCNAT64 a.b.c.d → 2001:cafe:f::aabb:ccdd

    Со стороны оператора вы направите трафик 2001:db8:64::/96 на CGNAT-устройства, которые будут делать stateful SRCNAT на какой-то публичный IPv4-адрес из пула для 64-битного транслятора. Ответы автоматически пойдут на тот CPE, который изначально открыл сокет — исходный src будет 2001:db8:cafe:f::aabb:ccdd — и CPE stateless'но преобразует это обратно в приватный IP.

    С такой схемой CPE позволит dual-stack устройствам в LAN обращаться к IPv4-адресам напрямую, без какого-либо DNS64 (даже для старых устройств без поддержки IPv6). В этом случае DNS64 нужен только для IPv6-only хостов в LAN, которым надо достучаться до IPv4-only адресов в Интернете — DNS64 будет переводить в тот же 2001:db8:64::/96.

    Очевидно, что 6-only хост не сможет обратиться напрямую к IPv4 literal (как вы и написали в своем посте), но при такой реализации 464XLAT нет причин не использовать dual-stack за роутером CPE.
     
     
     
    Страницы: 1
    Читают тему
    +7 495 320-55-52
    info@mikrotik.moscow
    Электрозаводская, Бауманская
    Москва, ул. Бакунинская, 84с21
    Конфиденциальность Оферта
    © 2025 «Mikrotik.Moscow»
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры