На Хакере лучше статья начинается. Там сразу пишут, что
> Связанная с Китаем APT-группировка TheWizards использует сетевую функциональность IPv6 для проведения атак типа man-in-the-middle, которые перехватывают обновления ПО для установки Windows-малвари.
Т. е. в первую очередь это MitM-атака.
Кстати, если бы сеть была построена только на IPv6, то такой проблемы не возникло. И я сейчас не шучу. Только Windows не умеет полноценно в таких сетях работать. Если у вас MacOS, Linux или любая современная мобильная операционная система, то они могут работать в сети только IPv6 и не испытывать каких-либо проблем. Всё, что нужно - NAT64 шлюз и особым образом настроенный DNS64 (хотя это больше для того, чтобы на клиентах трафик обрабатывался более эффективно, без этого тоже работать будет).
Да, такая проблемы есть. Но неужели обновление системы вообще не проверяет легитимность скачанных пакетов с помощью подписей? Даже если ты перехватишь трафик, то большая часть его будет зашифрована. Т.е. нужно ещё MiM-атаку проводить... А ещё обеспечить корректность цифровых подписей.
Что-то подробности атаки совсем не раскрыты. Да, через RA можно перенаправить трафик. Очень плохо, если кто-то из провайдеров это разрешает. Если речь идёт о локальных сетях, значит злоумышленник уже имеет доступ в локальную сеть.
Даже если трафик был перенаправлен с помощью RA, остаётся открытым вопрос, ка они вклиниваются в защищённое (https) соединение? Подменяют сертификаты? Если да, то у меня плохие новости, они уже имеют доступ на машины, где производят подмену корневых сертификатов. Или у них есть какой-то свой корневой сертификат (как в своё время пытались сделать в Казахстане), чтобы выпускать сертификаты для любых доменов.
Да, RA позволяет перенаравить трафик клиентов на другие узлы, поэтому к нему необходимо проявлять столько же внимания, сколько проявляется для защиты от фиктивных DHCP серверов. Но просто перенаравить трафик - мало.
В смысле становится адом? Там изначально тот ад, что раньше был в виде атрибутов тегов. По мне так Tailwind максимум для прототипирования. Потом нужно всё это переводить в нормальные стили, которые будут описывать элементы интерфейса. Вроде там в новой версии сделали такое, что можно собирать из этих классов какие-то свои.
TailwindСSS вообще какое-то чудо чудесное. Столько времени старались отделить текст от оформления, а в Tailwind взяли и реализовали свои атрибуты HTML тегов через классы...
Столько пафоса, что это революция... прорыв. Неужели они смогли? Не совсем... Java версия в пролёте, а значит под Linux нормально поиграть не получится. Впрочем, поиграть с шейдерами можно было уже лет 12 назад наверно, разной степени качества.
Для денег специальные типы придуманы в компьютерах, чтобы эта погрешность не копилась. Ведение бухгалтерии - это отдельное искусство. Если работаете с деньгами, лучше заранее изучить.
А системы, которые используют числа с плавающей точкой для финансов мне встречались. Одно время провайдер использовал такую и людей массово отключали за неуплату, потому что к началу месяца у них на счёте числился долг в 0,01 копейки. Просто абонентская плата списывалась каждый день. И в один прекрасный момент вылезает погрешность из-за того, что сумма делится на число дней. Лечилось там просто установкой порога отключения в 1 рубль (с запасом). А потом, благо, эту систему сменили.
Мне понравилось высказывание одного из руководителей разработки этого самого IP:
I'm serious, the decision to put a 32-bit address space on there was the result of a year's battle among a bunch of engineers who couldn't make up their minds about 32, 128 or variable length. And after a year of fighting I said - I'm now at ARPA, I'm running the program, I'm paying for this stuff and using American tax dollars - and I wanted some progress because we didn't know if this is going to work. So I said - 32 bits, it is enough for an experiment, it is 4.3 billion terminations - even the defense department doesn't need 4.3 billion of anything and it couldn't afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing a experiment to prove the technology and that if it worked we'd have an opportunity to do a production version of it. Well - it just escaped! - it got out and people started to use it and then it became a commercial thing. So, this [IPv6] is the production attempt at making the network scalable. Only 30 years later.
Цитату приводят в таком виде в вики на английском на странице «IPv4 address exhaustion». Также есть ссылка на ролик на ютубе от 2008 года, откуда эту цитату и взяли.
Суть всего этого. IPv4 задумывался как протокол, который должен был работать в условиях «лаборатории». Даже размер адресного пространства выбрали исходя из того, что больше не понадобится, ибо никто, даже министерство обороны США в те года не могли себе позволить такое количество оконечных устройств, чтобы понадобилось больше адресов. А потом этот протокол просто утёк за пределы лаборатории и стал применяться для коммерческих целей. Естественно, спустя какое-то время столкнулись с ограничениями протокола. А если взглянуть на сам заголовок пакета IPv4, то можно увидеть кучу «лишних» полей, которые добавляли, чтобы проверить концепции, а не для реального использования. Как результат, в IPv6 всё лишнее выкинули и сделали реально удобный протокол.
Ну а NAT - это просто костыль, которые приходится применять в IPv4 хочешь ты того или нет. В IPv6 он тоже есть, но если твоя сеть грамотно спроектирована, то он не нужен.
Создатель «Честного Реестра» Александр Литвинов считает, что в отрасли сложилась ситуация, при которой записи о продукции в реестре аннулируются, но заказчики, получившие оборудование, не соответствующее заявленным требованиям, остаются без компенсации.
Не совсем согласен с такой формулировкой. Как раз заказчики получили то, что было нужно. Наличие в реестре - требование от государства. Оно не сказывается на потребительских свойствах продукции.
В данном случае нанесён ущерб другим производителям электроники, которые имеют своё производство и производят технику с отечественными компонентами. Это, скорее всего, обходится дороже. Но из-за подлога, они не могли конкурировать с более дешёвыми импортными аналогами, поэтому проиграли тендер и недополучили прибыль на дальнейшее развитие.
Также ущерб был нанесён государству, т. к. подобные подлоги срывают программу импортозамещения. Другим игрокам просто не выгодно вкладываться в отечественные разработки, ведь их затраты не позволяют снизить цену ниже той, что предоставляют те же Китайские производители.
Люди думают, что очень сложно делать всякие кавычки «ёлочки» и прочее. Но если у вас, например, KDE Plasma на компьютере, то можно сделать себе 3 раскладку клавиатуры. Я вешаю её обычно на правый ALT. Там я могу и €, и ₽, и § добавить, и даже ударе́ние поставить. А уж разделять минус, дефис и тире привык ещё в те времена, когда ещё читал Ководство от Лебедева в 2000-х. Так что есть люди, которые всё это используют. А есть и те, кто даже вместо буквы «ё» ставят букву «е», ровно также, как делает deepl при переводе текстов на русский.
А если вы берёте и сохраняете у себя эти авторские материалы и не своим мозгом пользуетесь, а просто копируете то, что в этим материалах написано, немного видоизменяя и передавая ту же самую суть? Человеческий мозг сложнее устроен. Могут быть какие-то отклонения, какие-то новые догадки. Так вы можете выдать какую-то уникальную идею базируясь на своём опыте, который вы не помните дословно, как было в материале. ИИ же по большей части в том или ином виде хранит то, на чём обучался и используется именно в том виде.
Не знаю как менялись, но после ухода Google Adsense мой еле приносящий что-то сайт с РСЯ стал зарабатывать ещё меньше. Если раньше можно было надеяться хотя бы иногда окупать хостинг и домен, то сейчас дохода от РСЯ хватает максимум на оплату более дешёвого чем раньше хостинга. А на домен вообще не хватает. Но и это ещё не чистое сравнение, потому что в последнее время у меня начал приносить что-то мой блог. Он сейчас обгоняет тот сайт. Т. е. теперь доход идёт от двух сайтов, а он меньше, чем был от одного в Google Adsense. Если бы это были коммерческие проекты, я бы давно их закрыл. А раз хобби, поэтому тянут деньги из кармана, а РСЯ покрывает эти расходы лишь частично, меньше трети.
Если вы ещё не заметили, сейчас большинство продуктов так и делается. Это просто ужас какой-то, когда заходишь на сайт, а он грузится оооочень долго, браузер съедает оперативку. Если глянуть код, то диву даёшься что там наворочено. А внешне там выглядит всё довольно просто. Бизнес не хочет хороших решений, бизнесу нужны быстрые решения, которые приносят деньги. А там как-нибудь допилят (нет).
ИИ в целом позволяет экономить время на рутиных задачах. Может быть даже качество кода подрастёт, потому что у разработчиков будет больше времени подумать над общим улучшением программы. Думаю, что программисты не станут ненужными, просто специфика работы сменится. И количество вакансий уменьшится. Кто знает. Время покажет.
Вы пишите так словно 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.
В реализации CLAT от эппл AAAA записи синтезируется на клиенте
Да. Хороший вариант заставить синтезировать записи локальный резольвер. Но тогда теряется смысл домена ipv4only.arpa, ведь чтобы синтезировать нужную запись устройство должно узнать адресацию NAT64. И тут единственным рабочим вариантом оказывается PREF64 в RA.
Запись ipv4only.arpa потребовалась для старых айфонов (iOS 15)
Это просто более ранний RFC, но многие его критикуют и призывают не использовать. Я присоединяюсь к ним.
На счет безопасности, у меня нет квалифицированного комментария.
Тут есть потенциальная опасность в том, что если вы каким-то образом начнёте использовать недоверенный DNS, который может весь ваш IPv4 трафик направить на подставной NAT64 шлюз, ведь диапазон NAT64 не является чем-то фиксированным и можно использовать любые адреса, в том числе и GUA для публичных NAT64. Такое может провернуть, например, какой-то вирус. Может и администратор сети, но он вообще может перехватывать весь ваш трафик и у него нет в таком способе особой нужды. Конечно, ваш трафик и так будет по большей части зашифрован, но его как минимум злоумышленник может записать для последующей расшифровки. Будет неприятно, если какая-то чувствительная информация будет защищена ненадёжными алгоритмами шифрования.
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, то экономия пула оправдана.
Ещё интересно, что сейчас в стоимость VPS закладывают аренду IPv4, которая немного-немало у многих провайдеров составляет 150 рублей. Такое есть даже у бесплатных серверов в РФ. Сам сервер бесплатны, но он без платного IPv4 недоступен.
В Европе стоимость IPv4 местами сильно ниже, примерно 60 евроцентов. При чём от IPv4 можно отказаться. А чтобы ваш сайт оставался доступен для всех, просто подключаете тот же Cloudflare.
Вот чего мне не хватает в обзоре - это имеется ли возможность на хостинге получить IPv6. Очень часто на серверах в РФ его просто нет. Кто-то барыжит IPv6 по рублю за штуку или пытается брать дополнительную оплату за префикс. И очень редко кто-то даёт больше, чем /64. Практически ни у кого не видел, чтобы выделяли префикс на аккаунт и можно было маршрутизировать трафик на нужную машину. Разве что в облаках крупных, вроде Oracle (сам пользовался пока не отобрали «бесплатные всегда» серверы).
На Хакере лучше статья начинается. Там сразу пишут, что
> Связанная с Китаем APT-группировка TheWizards использует сетевую функциональность IPv6 для проведения атак типа man-in-the-middle, которые перехватывают обновления ПО для установки Windows-малвари.
Т. е. в первую очередь это MitM-атака.
Кстати, если бы сеть была построена только на IPv6, то такой проблемы не возникло. И я сейчас не шучу. Только Windows не умеет полноценно в таких сетях работать. Если у вас MacOS, Linux или любая современная мобильная операционная система, то они могут работать в сети только IPv6 и не испытывать каких-либо проблем. Всё, что нужно - NAT64 шлюз и особым образом настроенный DNS64 (хотя это больше для того, чтобы на клиентах трафик обрабатывался более эффективно, без этого тоже работать будет).
По поводу этой заметки уже шутят, что «чтобы защититься от ARP спуфинга специалисты рекомендуют отключить IPv4».
Да, такая проблемы есть. Но неужели обновление системы вообще не проверяет легитимность скачанных пакетов с помощью подписей? Даже если ты перехватишь трафик, то большая часть его будет зашифрована. Т.е. нужно ещё MiM-атаку проводить... А ещё обеспечить корректность цифровых подписей.
Что-то подробности атаки совсем не раскрыты. Да, через RA можно перенаправить трафик. Очень плохо, если кто-то из провайдеров это разрешает. Если речь идёт о локальных сетях, значит злоумышленник уже имеет доступ в локальную сеть.
Даже если трафик был перенаправлен с помощью RA, остаётся открытым вопрос, ка они вклиниваются в защищённое (https) соединение? Подменяют сертификаты? Если да, то у меня плохие новости, они уже имеют доступ на машины, где производят подмену корневых сертификатов. Или у них есть какой-то свой корневой сертификат (как в своё время пытались сделать в Казахстане), чтобы выпускать сертификаты для любых доменов.
Да, RA позволяет перенаравить трафик клиентов на другие узлы, поэтому к нему необходимо проявлять столько же внимания, сколько проявляется для защиты от фиктивных DHCP серверов. Но просто перенаравить трафик - мало.
В смысле становится адом? Там изначально тот ад, что раньше был в виде атрибутов тегов. По мне так Tailwind максимум для прототипирования. Потом нужно всё это переводить в нормальные стили, которые будут описывать элементы интерфейса. Вроде там в новой версии сделали такое, что можно собирать из этих классов какие-то свои.
TailwindСSS вообще какое-то чудо чудесное. Столько времени старались отделить текст от оформления, а в Tailwind взяли и реализовали свои атрибуты HTML тегов через классы...
Столько пафоса, что это революция... прорыв. Неужели они смогли? Не совсем... Java версия в пролёте, а значит под Linux нормально поиграть не получится. Впрочем, поиграть с шейдерами можно было уже лет 12 назад наверно, разной степени качества.
Для денег специальные типы придуманы в компьютерах, чтобы эта погрешность не копилась. Ведение бухгалтерии - это отдельное искусство. Если работаете с деньгами, лучше заранее изучить.
А системы, которые используют числа с плавающей точкой для финансов мне встречались. Одно время провайдер использовал такую и людей массово отключали за неуплату, потому что к началу месяца у них на счёте числился долг в 0,01 копейки. Просто абонентская плата списывалась каждый день. И в один прекрасный момент вылезает погрешность из-за того, что сумма делится на число дней. Лечилось там просто установкой порога отключения в 1 рубль (с запасом). А потом, благо, эту систему сменили.
P.S. Систему звали Bill-Master.
Мне понравилось высказывание одного из руководителей разработки этого самого IP:
Цитату приводят в таком виде в вики на английском на странице «IPv4 address exhaustion». Также есть ссылка на ролик на ютубе от 2008 года, откуда эту цитату и взяли.
Суть всего этого. IPv4 задумывался как протокол, который должен был работать в условиях «лаборатории». Даже размер адресного пространства выбрали исходя из того, что больше не понадобится, ибо никто, даже министерство обороны США в те года не могли себе позволить такое количество оконечных устройств, чтобы понадобилось больше адресов. А потом этот протокол просто утёк за пределы лаборатории и стал применяться для коммерческих целей. Естественно, спустя какое-то время столкнулись с ограничениями протокола. А если взглянуть на сам заголовок пакета IPv4, то можно увидеть кучу «лишних» полей, которые добавляли, чтобы проверить концепции, а не для реального использования. Как результат, в IPv6 всё лишнее выкинули и сделали реально удобный протокол.
Ну а NAT - это просто костыль, которые приходится применять в IPv4 хочешь ты того или нет. В IPv6 он тоже есть, но если твоя сеть грамотно спроектирована, то он не нужен.
Не совсем согласен с такой формулировкой. Как раз заказчики получили то, что было нужно. Наличие в реестре - требование от государства. Оно не сказывается на потребительских свойствах продукции.
В данном случае нанесён ущерб другим производителям электроники, которые имеют своё производство и производят технику с отечественными компонентами. Это, скорее всего, обходится дороже. Но из-за подлога, они не могли конкурировать с более дешёвыми импортными аналогами, поэтому проиграли тендер и недополучили прибыль на дальнейшее развитие.
Также ущерб был нанесён государству, т. к. подобные подлоги срывают программу импортозамещения. Другим игрокам просто не выгодно вкладываться в отечественные разработки, ведь их затраты не позволяют снизить цену ниже той, что предоставляют те же Китайские производители.
В этом плане стандартные раскладки - топ. В KDE Plasma разве что надо это руками включить. А дальше просто привыкаешь к тому как настроено.
Я совсем не против, просто рассказал о том, чем пользуюсь я. Рад, что и для Windows есть такие утилиты.
Люди думают, что очень сложно делать всякие кавычки «ёлочки» и прочее. Но если у вас, например, KDE Plasma на компьютере, то можно сделать себе 3 раскладку клавиатуры. Я вешаю её обычно на правый ALT. Там я могу и €, и ₽, и § добавить, и даже ударе́ние поставить. А уж разделять минус, дефис и тире привык ещё в те времена, когда ещё читал Ководство от Лебедева в 2000-х. Так что есть люди, которые всё это используют. А есть и те, кто даже вместо буквы «ё» ставят букву «е», ровно также, как делает deepl при переводе текстов на русский.
А если вы берёте и сохраняете у себя эти авторские материалы и не своим мозгом пользуетесь, а просто копируете то, что в этим материалах написано, немного видоизменяя и передавая ту же самую суть? Человеческий мозг сложнее устроен. Могут быть какие-то отклонения, какие-то новые догадки. Так вы можете выдать какую-то уникальную идею базируясь на своём опыте, который вы не помните дословно, как было в материале. ИИ же по большей части в том или ином виде хранит то, на чём обучался и используется именно в том виде.
Не знаю как менялись, но после ухода Google Adsense мой еле приносящий что-то сайт с РСЯ стал зарабатывать ещё меньше. Если раньше можно было надеяться хотя бы иногда окупать хостинг и домен, то сейчас дохода от РСЯ хватает максимум на оплату более дешёвого чем раньше хостинга. А на домен вообще не хватает. Но и это ещё не чистое сравнение, потому что в последнее время у меня начал приносить что-то мой блог. Он сейчас обгоняет тот сайт. Т. е. теперь доход идёт от двух сайтов, а он меньше, чем был от одного в Google Adsense. Если бы это были коммерческие проекты, я бы давно их закрыл. А раз хобби, поэтому тянут деньги из кармана, а РСЯ покрывает эти расходы лишь частично, меньше трети.
Если вы ещё не заметили, сейчас большинство продуктов так и делается. Это просто ужас какой-то, когда заходишь на сайт, а он грузится оооочень долго, браузер съедает оперативку. Если глянуть код, то диву даёшься что там наворочено. А внешне там выглядит всё довольно просто. Бизнес не хочет хороших решений, бизнесу нужны быстрые решения, которые приносят деньги. А там как-нибудь допилят (нет).
ИИ в целом позволяет экономить время на рутиных задачах. Может быть даже качество кода подрастёт, потому что у разработчиков будет больше времени подумать над общим улучшением программы. Думаю, что программисты не станут ненужными, просто специфика работы сменится. И количество вакансий уменьшится. Кто знает. Время покажет.
Нет. Я такого не имел в виду. Просто RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) вышел аж в ноябре 2013 года, а RFC 8781 (Discovering PREF64 in Router Advertisements) только в апреле 2020), поэтому старые реализации обнаружения префикса могут опираться на старый RFC. По-хорошему, старый способ нужно отключать по умолчанию и включать только вручную, только тем, кому оно действительно нужно. Но это лично моё мнение.
А что делать с 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.
Да. Хороший вариант заставить синтезировать записи локальный резольвер. Но тогда теряется смысл домена ipv4only.arpa, ведь чтобы синтезировать нужную запись устройство должно узнать адресацию NAT64. И тут единственным рабочим вариантом оказывается PREF64 в RA.
Это просто более ранний RFC, но многие его критикуют и призывают не использовать. Я присоединяюсь к ним.
Тут есть потенциальная опасность в том, что если вы каким-то образом начнёте использовать недоверенный DNS, который может весь ваш IPv4 трафик направить на подставной NAT64 шлюз, ведь диапазон NAT64 не является чем-то фиксированным и можно использовать любые адреса, в том числе и GUA для публичных NAT64. Такое может провернуть, например, какой-то вирус. Может и администратор сети, но он вообще может перехватывать весь ваш трафик и у него нет в таком способе особой нужды. Конечно, ваш трафик и так будет по большей части зашифрован, но его как минимум злоумышленник может записать для последующей расшифровки. Будет неприятно, если какая-то чувствительная информация будет защищена ненадёжными алгоритмами шифрования.
Это совершенно не так. DNS64 делает доступным большую часть сервисов IPv4. При этом никакой дополнительной нагрузки на клиента не создаётся. Он просто изначально отправляет все запросы на IPv6 адрес и ему без разницы что там дальше происходит, потому что ответ он получит, если NAT64 работает и сервис отвечает. Для устройства всё выглядит так, что он общается с IPv6 сервисом. CLAT же нужен именно для тех случаев, если программы напрямую обращаются к IPv4 адресам. В этом случае нужен виртуальный интерфейс с фейковым IPv4. Дальше это нужно дополнительно обрабатывать прямо на устройстве, чтобы пакет ушёл на NAT64.
Никакие записи DNS не переписываются. Записи типа AAAA добавляются к записям типа A, если для этих доменных имён нет AAAA. Ничего страшного в этом нет, кроме того, что это сломает DNSSEC для доменов, которые его используют, но не имеют AAAA записей. Например, так будет у банка ВТБ и Ростелекома... Впрочем, DNSSEC на rt.ru и так сломан без всяких DNS64... Интересно было бы узнать насколько часто вообще включают проверку DNSSEC компании.
Тут вы всё в кучу смешали. 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, то экономия пула оправдана.
Ещё интересно, что сейчас в стоимость VPS закладывают аренду IPv4, которая немного-немало у многих провайдеров составляет 150 рублей. Такое есть даже у бесплатных серверов в РФ. Сам сервер бесплатны, но он без платного IPv4 недоступен.
В Европе стоимость IPv4 местами сильно ниже, примерно 60 евроцентов. При чём от IPv4 можно отказаться. А чтобы ваш сайт оставался доступен для всех, просто подключаете тот же Cloudflare.
Вот чего мне не хватает в обзоре - это имеется ли возможность на хостинге получить IPv6. Очень часто на серверах в РФ его просто нет. Кто-то барыжит IPv6 по рублю за штуку или пытается брать дополнительную оплату за префикс. И очень редко кто-то даёт больше, чем /64. Практически ни у кого не видел, чтобы выделяли префикс на аккаунт и можно было маршрутизировать трафик на нужную машину. Разве что в облаках крупных, вроде Oracle (сам пользовался пока не отобрали «бесплатные всегда» серверы).