Comments 11
ifconfig
Есть причины не использовать для этого iproute2?
Это на скриншоте из оригинальной статьи. Я никогда не работал с macOS. Вероятно, это её особенность, либо привычки автора оригинальной статьи.
Куда интереснее вопрос, есть ли причины отказываться от утилиты, которая уже пятый десяток лет прекрасно делает от неё требуемое в любом юниксе, в пользу сугубо линуксового новодела, у которого вообще не было причин появляться, кроме Лёшиной одержимости и положивших с прибором мэйнтейнеров net-tools?
Оказывается прямо перед публикацией этого материала вышла новая версия NetworkManager 1.52, которая теперь поддерживает RFC 8925 «IPv6-only preferred». Жду появления в дистрибутивах.
Собственно, проверил. Установил пакет в Archlinux из extra-testing. В качестве маршрутизатора взял официальную сборку под свой маршрутизатор без каких-либо модификаций. Всё необходимое он получал от головного маршрутизатора, где были настроены свои DNS64 и NAT64, как и было описано в статье, поэтому устроил и базовый набор компонентов.
Опция действительно работает, но она не включена по умолчанию, что разумно, т. к. NetworkManager не использует clat (уже есть патчи и обсуждение внедрения), поэтому возможны проблемы при работе некоторых программ. При включенной опции реально идёт запрос 108 опции в DHCPv4, на который отвечает OpenWrt и указывает время, на которое нужно выключить DHCPv4 клиента. Компьютер не получает IPv4 адреса и работает только через IPv6.
Удивительно, что я решил написать подобную статью прямо в тоже самое время, когда вышел NetworkManager с таким революционным изменением! Стоит доработать статью?
DNS64 не обязателен в случае iOS macOS. Скорее от него больше вреда, т.к. он перепишет все записи и даже вреден для ipv6 mostly. Достаточно NAT64, PREF64, DHCP option 108 и dns записей для ipv4only.arpa типа А и АААА.
DNS64 не обязателен в случае iOS macOS. Скорее от него больше вреда, т.к. он перепишет все записи и даже вреден для ipv6 mostly.
Это совершенно не так. DNS64 делает доступным большую часть сервисов IPv4. При этом никакой дополнительной нагрузки на клиента не создаётся. Он просто изначально отправляет все запросы на IPv6 адрес и ему без разницы что там дальше происходит, потому что ответ он получит, если NAT64 работает и сервис отвечает. Для устройства всё выглядит так, что он общается с IPv6 сервисом. CLAT же нужен именно для тех случаев, если программы напрямую обращаются к IPv4 адресам. В этом случае нужен виртуальный интерфейс с фейковым IPv4. Дальше это нужно дополнительно обрабатывать прямо на устройстве, чтобы пакет ушёл на NAT64.
Никакие записи DNS не переписываются. Записи типа AAAA добавляются к записям типа A, если для этих доменных имён нет AAAA. Ничего страшного в этом нет, кроме того, что это сломает DNSSEC для доменов, которые его используют, но не имеют AAAA записей. Например, так будет у банка ВТБ и Ростелекома... Впрочем, DNSSEC на rt.ru и так сломан без всяких DNS64... Интересно было бы узнать насколько часто вообще включают проверку DNSSEC компании.
Достаточно NAT64, PREF64, DHCP option 108 и dns записей для ipv4only.arpa типа А и АААА.
Тут вы всё в кучу смешали. ipv4only.apra и PREF64 - это два разных способа обнаружения NAT64 в данном конкретном сегменте сети и это два разных RFC. Обнаружение через DNS имеет потенциальные проблемы с безопасностью, а также не гарантирует того, что NAT64 будет обнаружен. Банально, если клиент прописал себе другой DNS. И может ложно сработать, если клиент прописал себе DNS64 от того же Cloudflare или Google. PREF64 в RA тоже не самая безопасная штука, но в RA приходит множество других критичных параметров, которым приходится доверять. Для ipv4only.arpa есть отдельный RFC, но я бы не стал его использовать как основной способ обнаружения, только как резервный вариант. А лучше бы вообще не использовал.
DHCP option 108 нужна только в том случае, если ваша сеть выдаёт IPv4 адреса, которых у вас ограниченное количество. При помощью этой опции вы можете экономить пул адресов за счёт того, что его не будут занимать те, кто может работать в режиме IPv6-only, а это все мобильные устройства на Android и iOs, а также MacOS. Понятное дело, что если вы используете внутри сети 192.168.1.0/24, то вам скорее всего фиолетово все 200 устройств получат себе IPv4 адрес или только 50 из 200. А вот если вы выдаёте белые IPv4, то экономия пула оправдана.
Вы все правильно пишите. Я описал свой практический опыт. В реализации CLAT от эппл AAAA записи синтезируются на клиенте, и это хороший и правильный способ не трогать DNS вообще. Запись ipv4only.arpa потребовалась только для старых айфонов (iOS 15), где PREF64 применяется, но как-то странно и без нее не работал ipv4 интернет. О причинах такого поведения можно догадываться, скорее всего это старая реализация их механизмов обнаружения.
Кстати чем может мешать наличие ipv4only.arpa?
Без DHCP option 108 у вас будет маршрутизируемый ipv4 адрес у клиента, или если отключить DHCPv4 полностью, то появятся адреса вида 169.254.х.х и попытки их согласовать. Экономии в пуле IPv4 точно не будет, т.к. большинство DHCP серверов адрес все же выделают, хоть и клиенты с поддержкой этой опции их не используют.
На счет безопастности, у меня нет квалифицированного комментария.
В реализации CLAT от эппл AAAA записи синтезируется на клиенте
Да. Хороший вариант заставить синтезировать записи локальный резольвер. Но тогда теряется смысл домена ipv4only.arpa, ведь чтобы синтезировать нужную запись устройство должно узнать адресацию NAT64. И тут единственным рабочим вариантом оказывается PREF64 в RA.
Запись ipv4only.arpa потребовалась для старых айфонов (iOS 15)
Это просто более ранний RFC, но многие его критикуют и призывают не использовать. Я присоединяюсь к ним.
На счет безопасности, у меня нет квалифицированного комментария.
Тут есть потенциальная опасность в том, что если вы каким-то образом начнёте использовать недоверенный DNS, который может весь ваш IPv4 трафик направить на подставной NAT64 шлюз, ведь диапазон NAT64 не является чем-то фиксированным и можно использовать любые адреса, в том числе и GUA для публичных NAT64. Такое может провернуть, например, какой-то вирус. Может и администратор сети, но он вообще может перехватывать весь ваш трафик и у него нет в таком способе особой нужды. Конечно, ваш трафик и так будет по большей части зашифрован, но его как минимум злоумышленник может записать для последующей расшифровки. Будет неприятно, если какая-то чувствительная информация будет защищена ненадёжными алгоритмами шифрования.
Это просто более ранний RFC, но многие его критикуют и призывают не использовать. Я присоединяюсь к ним.
Вы пишите так словно DNS arpa запись имеет приоритет выше чем PREF64. Нигде про это не видел, но положим это так.
На счет атаки что вы описываете, это возможно. Как метод борьбы: просто переводить в фаерволе все исходящие DNS на локальные и возможно этого достаточно? С таким же успехом можно подставить DNS c поддельным DNS64 который синтезирует "нужный" префикс и отправит трафик куда-то.
Однако будем считать что сеть настраиваем не в каком-то светлом будущем где все вендоры обсудили все граничные кейсы и все поправили, в том числе старые реализации, а сейчас.
Я пишу вам с компьютера где все настроено как я описывал выше и сломанных приложений я пока что не нашёл. Готовность всех этих технологий с точки зрения хотяб работоспособности, на мой взгляд, высокая.
Вы пишите так словно DNS arpa запись имеет приоритет выше чем PREF64.
Нет. Я такого не имел в виду. Просто RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) вышел аж в ноябре 2013 года, а RFC 8781 (Discovering PREF64 in Router Advertisements) только в апреле 2020), поэтому старые реализации обнаружения префикса могут опираться на старый RFC. По-хорошему, старый способ нужно отключать по умолчанию и включать только вручную, только тем, кому оно действительно нужно. Но это лично моё мнение.
Как метод борьбы: просто переводить в фаерволе все исходящие DNS на локальные и возможно этого достаточно?
А что делать с DNSoverTLS и DNSoverHTTPS? Я вполне могу прописать в качестве DNS 2606:4700:4700::64 и включить DNSoverTLS и этот трафик не перенаправит. При этом система на моей машине согласно RFC 7050 будет думать, что у меня есть NAT64 по стандартному адресу 64:ff9b::/96, а его там может и не быть. Да и вообще тут просто огромный простор для целевых атак, ведь весь интернет IPv4 можно вписать в сеть IPv6 стандартного размера и ещё куча адресов останется. При этом жертва даже ничего не заподозрит, ведь будут работать стандартные механизмы системы, а значит выявить атаку будет практически невозможно.
Да. Это больше потенциальная опасность, а не реальная. Но если есть другой, более надёжный способ, то зачем сохранять этот.
где все вендоры обсудили все граничные кейсы и все поправили, в том числе старые реализации
Ну, вообще-то в Android и iOs это уже поправили. В MacOS, вроде, тоже. А на Linux и Windows из коробки этого нет и сейчас. Я вообще не представляю можно ли Windows использовать в режиме IPv6-only через WiFi или Ethernet подключение.
Я пишу вам с компьютера где все настроено как я описывал выше и сломанных приложений я пока что не нашёл.
Я тоже баловался на Fedora. Только у меня не было автоматического обнаружения префикса NAT64. Просто был настроен clatd, а NAT64 был на маршрутизаторе. Да, всё прекрасно работает при полностью отключенном вручную IPv4, даже торренты качаются с пиров IPv4 и Steam работает. Кстати, тут недавно обнаружил, что починили возможность запуска Steam в режиме без clat. Так что можно запускать игры, но при попытке что-то скачать из магазина просто выдаётся, что интернет недоступен. Для этого нужен clat.
Развёртывание сетей доступа преимущественно на основе IPv6