Чаще всего мне встречался вариант, когда дают доступ через пользователя root. Т.е. подключаться нужно ssh root@host. Далее после входа на сервер:
Создаёте пользователя и добавляете его в группу sudo. Также полезно сразу указать пользователю оболочку /bin/bash
Задаёте пароль для пользователя
Загружаете свой ключ под вашим пользователем.
Проверяете, что можете войти без пароля и можете переключиться на root через sudo.
Ели всё нормально, запрещаете доступ к ssh от пользователя root и с использованием парольной аутентификации.
В случае проблем с доступом, можно воспользоваться панелью правления и доступом к консоли сервера (VNC и др.). Она же спасёт, если накосячите что-то с настройкой сети.
Встречался также вариант, что есть какой-то предустановленный пользователь.
Также был вариант, когда можно в панели управления сразу загрузить свой ключ. В этом случае можно получить доступ без пароля к root или другому пользователю.
Да, действительно. Надо подробнее изучить вопрос. Однако указанный вами ключ в Ubuntu 22.04 LTS и Fedora 39 имеет значение no. В Ubuntu это задано прямо в sshd_config, а в Fedora в sshd_config.d (правда там используется старое имя параметра).
Это уже конкретно издевательство. Из-за такого распределения я бы вынужден был использовать NAT для IPv6, потому что не могу выделить себе сеть для своих нужд. Нужно пинать провайдера.
Всё проще. Математический аппарат подсказывает нам, что нет смысла прослушивать записи с частотами дискретизации выше 40+ кГц. Перейдите на спектр ИКМ сигнала и вы увидите, что кроме полезного сигнала в нём есть составляющие, аналогичные амплитудно-модулированному сигналу на частотах кратных частоте дискретизации. Т.е. если мы фильтром обрежем всё что выше нашего уровня восприятия, то мы получим исходный сигнал без каких либо искажений. Искажения будет давать только шаг квантования.
Зачем же на студии повышать частоту дискретизации и количество уровней квантования? Потому что мы сможем вместо сложных аналоговых фильтров (а нужно обрезать резко после 20 кГц и при этом не искажать то, что до этих 20 кГц есть) можем применить цифровую обработку и более качестве обрезать лишнее. АЧХ среза будет куда более идеальна, чем то, что нам могут дать аналоговые фильтры. Дополнительные уровни квантования позволят нам без заметных искажений подтянуть уровень сигнала до нужного нам уровня. Ведь если нам нужно усилить сигнал в 2 раза, то мы половину уровней квантования в результирующем материале потеряем (конечно, вряд ли кто-то так сильно усиливает сигнал в студийных условиях, проще переписать нормально, но это хорошо отражает суть, зачем нам лишние уровни). Итого, мы за счёт избыточности вытягиваем нужный нам сигнал и уже в идеальном виде кодируем со стандартными параметрами для потребителей. В результате у нас есть отличный
и они выяснили, что есть уникумы, которые слышат вплоть до 22 кГц
Это скорее не из-за уникумов, а из-за неидеальности фильтров. Нужно обрезать очень хорошо до той частоты, которая ниже в 2 раза частоты оцифровка материала. Если этого не сделать, то мы можем получить лишние шумы. В спектре ИКМ сигнала от частоты дискретизации вверх и вниз идёт спектр нашего полезного сигнала, примерно как при АМ модуляции. И вот эта нижняя часть может залезть на наш полезный сигнал и добавить лишних звуков. Идеальных фильтров не бывает, вот и взяли запас в 2кГц на неидеальность фильтров, чтобы точно до частоты в половину частоты дискретизации ничего не добралось.
На Ростелекоме открылся. Но если проверить через curl, то работает только по IPv6. По IPv4: curl: (35) Recv failure: Соединение разорвано другой стороной
У меня пока не было возможности использовать двух провайдеров с IPv6. Одного то еле нашёл. Но теоретически можно раздать адреса GUA от обоих провайдеров, просто один из адресов будет неактивен, благо такое в IPv6 возможно.
Если соединение основное падает, то происходит рассылка RA, что первый шлюз прекращает работу, а второй наоборот должен объявить, что он теперь шлюз по умолчанию. Схему с двумя маршрутизаторами кто-то делал. Возможно это были микротики.
Нужно искать тех, кто подобным уже занимался. Самому интересно, но нет второго провайдера с IPv6. Вообще из доступных никто не предоставляет.
И решение автора приложения реализовать обязательную зависимость конкретно от уникального функционала systemd - это его личный выбор добровольного вендор-лока и отказ от поддержки в своём приложении тех пользователей, которые не используют systemd.
Так а в чём проблема просто запускать исполняемый файл через другие системы инициализации? Там уж пусть мэйнтейнеры пакета заботятся о том, чтобы через скрипы демонизировать процесс, сохранить его PID, на случай необходимости остановки, контролируют, что этот файл не завершил работу и завершил, перезапускать. Нет мэйнтейнеров - пользователь другой системы инициализации может написать или попросить кого-то.
А "не переусложнённое" приложение будет работать без systemd? Вот в этом и проблема systemd - он слишком много функционала в себя затянул, и продолжает затягивать (включая вот такой "требующий systemd" совершенно посторонний софт).
А почему я должен тянуть функционал системы инициализации в каждое своё приложение? В чём проблема создать подобный функционал в других системах инициализации? Я просто пишу приложение, которая запускается и дальше в цикле работает. Я не хочу форкать процессы и прочее. Я вообще не хочу в этом разбираться. Я просто хочу чтобы мой исполняемый файл запускался при старте системы и работал. А если вдруг упал (мало ли какие-то данные пришли, которые вызвали ошибку в обработке и процесс упал), чтобы его система перезапустила.
Было бы интересно почитать серьёзный гайд на тему безопасной настройки IPv6 и сопровождения dual stack конфигурации.
Да мне даже гайды по безопасности IPv4 не особо попадались. Это такая обширная тема, что гайд написать по ней очень сложно. Скорее даже невозможно. Этому люди годами учатся.
С другой стороны у нас есть устройства, которые предоставляются пользователям. Производители устройств должны сделать так, чтобы было максимально безопасно. Тут я уже писал комментарий про пароли на админку ADSL модемов. Вы просто не представляете сколько спама летело из Америки с адресов в 2000х, которые у провайдера были прописаны как adsl клиенты. В это же время у меня за 30 дней в ящике гугла в папке спам было больше 6000 писем. По спаму можно было проверять работает ящик или письма не приходят.
У меня есть два варианта что должно быть в реальной статистике:
процент заражений примерно одинаков, потому что заражения именно через сетевой стэк имеет небольшой процент от всех заражений (кроме разве что IoT, где производители забивают на обновление).
процент заражений выше для IPv6, просто потому, что производители маршрутизаторов забивают на протокол IPv6 и делают его для галочки, например, могут забыть о файерволе.
Во втором случае проблема не в протоколе, а в его уровне поддержки. Если сравнить с IPv4, то было время когда всякие ADSL модемы по умолчанию имели стандартные пароли для управления, а их веб-интерфейсы светились в интернете. Но по мере увеличения потребности в услуге, это стали решать. Также будет и с IPv6.
Кстати, я до сих пор не знаю работает ли он на оборудовании Ростелеком для GPON. Там можно в настройках включить IPv6 и он будет ограниченно работать. Можно получить адрес IPv6 и пользоваться услугами. Однако раньше они блокировали все входящие в мою сторону пакеты, кроме ответных по TCP. UDP полностью не работал. Потом я сменил маршрутизатор на тот, который полноценно поддерживает IPv6. Спустя какое-то время проблема с UDP у меня решилась, а также стало возможным открывать порты для нужных мне устройств для доступа из интернет. А вот как в такой ситуации вёл бы провайдерский CPE я не знаю. IPv6 там практически не имеет настроек ни в веб-интерфейсе, ни в командной строке (у меня был доступ уровня superadmin). Либо подсказки не содержат информацию по командам для IPv6.
А зачем их отделять? Тут работает обычная статистика - если в сети, где есть ipv6, процент зараженных не отличается от сети ipv4 only - то все в порядке.
Я бы посмотрел на такую статистику... только кто бы её предоставил :-D
systemd очень рекомендую. Под него легко писать юниты свои и легко обеспечить запуск любых своих процессов с полным контролем их выполнения. Когда написал свой первый юнит под демон, который из сети принимает определённые пакеты и перенаправляет их декодированными на веб-сервер локальный, понял, что я слишком переусложнил код приложения в угоду запуска его через старые системы инициализации. Оказалось можно просто сделать обычный процесс, который можно и просто так запустить. А потом написать для него юнит и systemd полностью будет контролировать, что процесс запустился, что он работает, а в случае краха, перезапускать твой сервис. И это делается элементарно. Даже PID процессов никому не нужны в этой схеме.
Да и вообще с systemd гораздо проще управлять linux не зависимо от системы, в которой ты находишься.
SELinux не могу рекомендовать, но если она есть (а я пользуюсь Fedora на своём домашнем ноутбуке), то отключать её большого смысла нет. При обычном использовании все необходимые правила прописаны в дистрибутиве. А если сам что-то пишешь и иногда возникают проблемы с SELinux, то вполне можно разобраться и написать своё правило. Плюс она может защитить от некоторых эксплойтов, потому что просто не даст запустить то, что лежит не там, где положено и не имеет соответствующих прав.
Ну, а IPv6 меня просто заинтересовал. Ведь его внедряют многие крупные компании. Он позволяет сделать то, что сделать с IPv4 невозможно. Его возможности впечатлили. И единственное, о чём сейчас жалею, что не могу сделать простой костыль и забыть о том, что IPv4 есть. Мне приходится настраивать оба адреса на серверах. Костыли для IPv4 можно придумать и забыть о нём вообще, банально, если использовать проксирование Cloudflare, то можно IPv4 вообще не иметь на сервере и не настраивать его. Но там есть свои ограничения. Если бы я что-то делал с нуля, то я строил исключительно на IPv6, а проблемы с доступом к сети IPv4 решал бы через отдельные шлюзы NAT46, NAT64. Тем более подходов там масса. По этой теме я даже переводил документацию Jool, который у меня сейчас работает на домашнем маршрутизаторе и обеспечивает доступ в IPv4 сеть машинам, которые не имеют IPv4 адреса (можно просто руками отключить, что я и сделал на одном из ПК, который подключен к телевизору, чисто ради эксперимента). Спустя время я не помню большинство из них, но я могу перечитать свой перевод. Если интересно, то мой перевод тут: https://tavda.net/siit_nat64 Ссылка на оригинал приведена во вступлении.
Как это нет? Есть! У клиента используются только ipv6 адреса - T-Mobile на такую схему перешли еще в 2014 году.
На сколько я знаю там сетевая инфраструктура провайдера вся на IPv6. Используют технологию MAP-T. Я бы тоже такого провайдера хотел, но... у нас в РФ строят сети с CGNAT.
По сути вы всё также под защитой CPE провайдера и у вас всё также есть IPv4 в локальной сети в привычном для вас понимании. Но вместо того, чтобы делать NAT44, как это происходит у большинства, они на CPE делают NAT46. При этом весь диапазон портов IPv4 адреса разбит на несколько частей и каждая из частей привязана к одному CPE. Дальше по сети пакет IPv6 с CPE направляется на провайдерский шлюз, где уже происходит обратное преобразование в IPv4.
С точки зрения клиента вообще ничего не поменялось. У него также есть дома серая сеть IPv4 и полноценная сеть IPv6. С точки зрения провайдера, вся их сеть построена исключительно на IPv6 и имеется только ограниченный стык через NAT64, который, к тому же не требует хранить состояние соединений, поскольку порты жёстко привязаны к конкретной CPE и пакеты можно транслировать без разбора, ведь защита сети абонента лежит именно на маршрутизаторе у клиента.
Очень просто - достаточно сравнить процент зараженных в сравнении с ipv4 only.
Опять таки, сам процент заражённых получить сложно. Плюс как вы будете отделять заражённые машины по тому через что они были заражены, если на подавляющем большинстве есть два стека и они могут обращаться к любым типам адресов? Да основная часть заражений происходит от действий пользователя или от его бездействия (не ставит обновления безопасности для своей ОС).
Лично я не представляю как даже просто собрать данные о заражениях и как их потом отсортировать корректно.
IPv6 значительно сложнее, с ним до сих пор накоплено меньше опыта, он по умолчанию даёт доступ из инета внутрь локалки, он не заменяет IPv4 и требует дополнительных усилий для поддержки обоих протоколов.
Предлагаю перестать бояться IPv6 познакомившись с моим материалом
Основная проблема IPv6 в локалке это человеко нечитаемые ip-адреса
Скорее наоборот. Те, кто глубоко занимается сетями скорее оценят шестнадцатиричную систему счисления. IPv6 прямо видны в дампах. Ну и кто занимается настройкой сети скорее всего знаком с компьютерами глубже, чем обычные пользователя и для него эта систем счисления не является проблемой. Обычные пользователи и IPv4 адреса всегда вводили с трудом. Я просто какое-то время консультировал людей как исправить неработающий интернет. И там нужно было руками вводить IPv4 адреса. Если там был маршрутизатор с IPv6, то они бы просто получили адрес по SLAAC и ничего вводить не надо было, если их сеть нормально функционировала. А если нет, то там без специалиста не обойтись.
Не забываем тот факт, что в IPv4 нет ресурсов даже не на то, чтобы выдать адреса всем нужным устройствам пользователя, но и вообще выдать всем пользователям. На том же Ростелекоме если не заказать статический IPv4, то всё время попадаешь на CGNAT и очень редко тебе выделяют нормальный белый адрес. А вот IPv6 изначально проектировался так, чтобы каждому устройству можно было присвоить отдельный адрес. И торренты, как ни странно, прекрасно качаются с пиров IPv6. Можно даже на клиенте заглушить IPv4 и пользоваться только IPv6.
Можно посмотреть на трафик, который генерируют зараженные компьютеры в таких сетях и сравнить его с трафик в ipv4 only. Так что вполне возможно.
Ну у нас нет сетей чисто IPv6, просто потому что из них недоступен контент, который есть только в IPv4 и его сейчас, к сожалению, большинство. Большая часть сетей IPv6 работает в паре с IPv4 (дуалстэк). Очень малое число работает только в IPv6 с доступом к IPv4 через специальные шлюзы с NAT64. И вот как в таких условиях считать количество заражённых машин в разных типах сетей? Даже если машина оказалась заражённой по IPv4, то она вполне может проявлять активность через IPv6. Напомню, ОС без разницы какой IP будет использоваться. Она разрешила доменное имя, получила A и AAAA записи, а дальше по своим правилам стучится на узлы IPv6 и IPv4. Да и вообще, как отделить машины, которые были заражены через уязвимость сетевого стэка операционной системы от тех, кто были заражены через другой софт?
Добавил замечание в текст. Спасибо за подсказку.
Чаще всего мне встречался вариант, когда дают доступ через пользователя root. Т.е. подключаться нужно ssh root@host. Далее после входа на сервер:
Создаёте пользователя и добавляете его в группу sudo. Также полезно сразу указать пользователю оболочку /bin/bash
Задаёте пароль для пользователя
Загружаете свой ключ под вашим пользователем.
Проверяете, что можете войти без пароля и можете переключиться на root через sudo.
Ели всё нормально, запрещаете доступ к ssh от пользователя root и с использованием парольной аутентификации.
В случае проблем с доступом, можно воспользоваться панелью правления и доступом к консоли сервера (VNC и др.). Она же спасёт, если накосячите что-то с настройкой сети.
Встречался также вариант, что есть какой-то предустановленный пользователь.
Также был вариант, когда можно в панели управления сразу загрузить свой ключ. В этом случае можно получить доступ без пароля к root или другому пользователю.
Исправил.
Да, действительно. Надо подробнее изучить вопрос. Однако указанный вами ключ в Ubuntu 22.04 LTS и Fedora 39 имеет значение no. В Ubuntu это задано прямо в sshd_config, а в Fedora в sshd_config.d (правда там используется старое имя параметра).
Если вы используете NAT в IPv6, то либо вы что-то неправильно делаете, либо с вашей сетью что-то не так.
Это уже конкретно издевательство. Из-за такого распределения я бы вынужден был использовать NAT для IPv6, потому что не могу выделить себе сеть для своих нужд. Нужно пинать провайдера.
Всё проще. Математический аппарат подсказывает нам, что нет смысла прослушивать записи с частотами дискретизации выше 40+ кГц. Перейдите на спектр ИКМ сигнала и вы увидите, что кроме полезного сигнала в нём есть составляющие, аналогичные амплитудно-модулированному сигналу на частотах кратных частоте дискретизации. Т.е. если мы фильтром обрежем всё что выше нашего уровня восприятия, то мы получим исходный сигнал без каких либо искажений. Искажения будет давать только шаг квантования.
Зачем же на студии повышать частоту дискретизации и количество уровней квантования? Потому что мы сможем вместо сложных аналоговых фильтров (а нужно обрезать резко после 20 кГц и при этом не искажать то, что до этих 20 кГц есть) можем применить цифровую обработку и более качестве обрезать лишнее. АЧХ среза будет куда более идеальна, чем то, что нам могут дать аналоговые фильтры. Дополнительные уровни квантования позволят нам без заметных искажений подтянуть уровень сигнала до нужного нам уровня. Ведь если нам нужно усилить сигнал в 2 раза, то мы половину уровней квантования в результирующем материале потеряем (конечно, вряд ли кто-то так сильно усиливает сигнал в студийных условиях, проще переписать нормально, но это хорошо отражает суть, зачем нам лишние уровни). Итого, мы за счёт избыточности вытягиваем нужный нам сигнал и уже в идеальном виде кодируем со стандартными параметрами для потребителей. В результате у нас есть отличный
Это скорее не из-за уникумов, а из-за неидеальности фильтров. Нужно обрезать очень хорошо до той частоты, которая ниже в 2 раза частоты оцифровка материала. Если этого не сделать, то мы можем получить лишние шумы. В спектре ИКМ сигнала от частоты дискретизации вверх и вниз идёт спектр нашего полезного сигнала, примерно как при АМ модуляции. И вот эта нижняя часть может залезть на наш полезный сигнал и добавить лишних звуков. Идеальных фильтров не бывает, вот и взяли запас в 2кГц на неидеальность фильтров, чтобы точно до частоты в половину частоты дискретизации ничего не добралось.
На Ростелекоме открылся. Но если проверить через curl, то работает только по IPv6. По IPv4: curl: (35) Recv failure: Соединение разорвано другой стороной
У меня пока не было возможности использовать двух провайдеров с IPv6. Одного то еле нашёл. Но теоретически можно раздать адреса GUA от обоих провайдеров, просто один из адресов будет неактивен, благо такое в IPv6 возможно.
Если соединение основное падает, то происходит рассылка RA, что первый шлюз прекращает работу, а второй наоборот должен объявить, что он теперь шлюз по умолчанию. Схему с двумя маршрутизаторами кто-то делал. Возможно это были микротики.
Нужно искать тех, кто подобным уже занимался. Самому интересно, но нет второго провайдера с IPv6. Вообще из доступных никто не предоставляет.
Так а в чём проблема просто запускать исполняемый файл через другие системы инициализации? Там уж пусть мэйнтейнеры пакета заботятся о том, чтобы через скрипы демонизировать процесс, сохранить его PID, на случай необходимости остановки, контролируют, что этот файл не завершил работу и завершил, перезапускать. Нет мэйнтейнеров - пользователь другой системы инициализации может написать или попросить кого-то.
А почему я должен тянуть функционал системы инициализации в каждое своё приложение? В чём проблема создать подобный функционал в других системах инициализации? Я просто пишу приложение, которая запускается и дальше в цикле работает. Я не хочу форкать процессы и прочее. Я вообще не хочу в этом разбираться. Я просто хочу чтобы мой исполняемый файл запускался при старте системы и работал. А если вдруг упал (мало ли какие-то данные пришли, которые вызвали ошибку в обработке и процесс упал), чтобы его система перезапустила.
Да мне даже гайды по безопасности IPv4 не особо попадались. Это такая обширная тема, что гайд написать по ней очень сложно. Скорее даже невозможно. Этому люди годами учатся.
С другой стороны у нас есть устройства, которые предоставляются пользователям. Производители устройств должны сделать так, чтобы было максимально безопасно. Тут я уже писал комментарий про пароли на админку ADSL модемов. Вы просто не представляете сколько спама летело из Америки с адресов в 2000х, которые у провайдера были прописаны как adsl клиенты. В это же время у меня за 30 дней в ящике гугла в папке спам было больше 6000 писем. По спаму можно было проверять работает ящик или письма не приходят.
У меня есть два варианта что должно быть в реальной статистике:
процент заражений примерно одинаков, потому что заражения именно через сетевой стэк имеет небольшой процент от всех заражений (кроме разве что IoT, где производители забивают на обновление).
процент заражений выше для IPv6, просто потому, что производители маршрутизаторов забивают на протокол IPv6 и делают его для галочки, например, могут забыть о файерволе.
Во втором случае проблема не в протоколе, а в его уровне поддержки. Если сравнить с IPv4, то было время когда всякие ADSL модемы по умолчанию имели стандартные пароли для управления, а их веб-интерфейсы светились в интернете. Но по мере увеличения потребности в услуге, это стали решать. Также будет и с IPv6.
Кстати, я до сих пор не знаю работает ли он на оборудовании Ростелеком для GPON. Там можно в настройках включить IPv6 и он будет ограниченно работать. Можно получить адрес IPv6 и пользоваться услугами. Однако раньше они блокировали все входящие в мою сторону пакеты, кроме ответных по TCP. UDP полностью не работал. Потом я сменил маршрутизатор на тот, который полноценно поддерживает IPv6. Спустя какое-то время проблема с UDP у меня решилась, а также стало возможным открывать порты для нужных мне устройств для доступа из интернет. А вот как в такой ситуации вёл бы провайдерский CPE я не знаю. IPv6 там практически не имеет настроек ни в веб-интерфейсе, ни в командной строке (у меня был доступ уровня superadmin). Либо подсказки не содержат информацию по командам для IPv6.
Я бы посмотрел на такую статистику... только кто бы её предоставил :-D
systemd очень рекомендую. Под него легко писать юниты свои и легко обеспечить запуск любых своих процессов с полным контролем их выполнения. Когда написал свой первый юнит под демон, который из сети принимает определённые пакеты и перенаправляет их декодированными на веб-сервер локальный, понял, что я слишком переусложнил код приложения в угоду запуска его через старые системы инициализации. Оказалось можно просто сделать обычный процесс, который можно и просто так запустить. А потом написать для него юнит и systemd полностью будет контролировать, что процесс запустился, что он работает, а в случае краха, перезапускать твой сервис. И это делается элементарно. Даже PID процессов никому не нужны в этой схеме.
Да и вообще с systemd гораздо проще управлять linux не зависимо от системы, в которой ты находишься.
SELinux не могу рекомендовать, но если она есть (а я пользуюсь Fedora на своём домашнем ноутбуке), то отключать её большого смысла нет. При обычном использовании все необходимые правила прописаны в дистрибутиве. А если сам что-то пишешь и иногда возникают проблемы с SELinux, то вполне можно разобраться и написать своё правило. Плюс она может защитить от некоторых эксплойтов, потому что просто не даст запустить то, что лежит не там, где положено и не имеет соответствующих прав.
Ну, а IPv6 меня просто заинтересовал. Ведь его внедряют многие крупные компании. Он позволяет сделать то, что сделать с IPv4 невозможно. Его возможности впечатлили. И единственное, о чём сейчас жалею, что не могу сделать простой костыль и забыть о том, что IPv4 есть. Мне приходится настраивать оба адреса на серверах. Костыли для IPv4 можно придумать и забыть о нём вообще, банально, если использовать проксирование Cloudflare, то можно IPv4 вообще не иметь на сервере и не настраивать его. Но там есть свои ограничения.
Если бы я что-то делал с нуля, то я строил исключительно на IPv6, а проблемы с доступом к сети IPv4 решал бы через отдельные шлюзы NAT46, NAT64. Тем более подходов там масса. По этой теме я даже переводил документацию Jool, который у меня сейчас работает на домашнем маршрутизаторе и обеспечивает доступ в IPv4 сеть машинам, которые не имеют IPv4 адреса (можно просто руками отключить, что я и сделал на одном из ПК, который подключен к телевизору, чисто ради эксперимента). Спустя время я не помню большинство из них, но я могу перечитать свой перевод. Если интересно, то мой перевод тут: https://tavda.net/siit_nat64 Ссылка на оригинал приведена во вступлении.
На сколько я знаю там сетевая инфраструктура провайдера вся на IPv6. Используют технологию MAP-T. Я бы тоже такого провайдера хотел, но... у нас в РФ строят сети с CGNAT.
По сути вы всё также под защитой CPE провайдера и у вас всё также есть IPv4 в локальной сети в привычном для вас понимании. Но вместо того, чтобы делать NAT44, как это происходит у большинства, они на CPE делают NAT46. При этом весь диапазон портов IPv4 адреса разбит на несколько частей и каждая из частей привязана к одному CPE. Дальше по сети пакет IPv6 с CPE направляется на провайдерский шлюз, где уже происходит обратное преобразование в IPv4.
С точки зрения клиента вообще ничего не поменялось. У него также есть дома серая сеть IPv4 и полноценная сеть IPv6. С точки зрения провайдера, вся их сеть построена исключительно на IPv6 и имеется только ограниченный стык через NAT64, который, к тому же не требует хранить состояние соединений, поскольку порты жёстко привязаны к конкретной CPE и пакеты можно транслировать без разбора, ведь защита сети абонента лежит именно на маршрутизаторе у клиента.
Опять таки, сам процент заражённых получить сложно. Плюс как вы будете отделять заражённые машины по тому через что они были заражены, если на подавляющем большинстве есть два стека и они могут обращаться к любым типам адресов? Да основная часть заражений происходит от действий пользователя или от его бездействия (не ставит обновления безопасности для своей ОС).
Лично я не представляю как даже просто собрать данные о заражениях и как их потом отсортировать корректно.
Предлагаю перестать бояться IPv6 познакомившись с моим материалом
https://habr.com/ru/articles/773708/
Там вы узнаете как на практике начать использовать IPv6.
Скорее наоборот. Те, кто глубоко занимается сетями скорее оценят шестнадцатиричную систему счисления. IPv6 прямо видны в дампах. Ну и кто занимается настройкой сети скорее всего знаком с компьютерами глубже, чем обычные пользователя и для него эта систем счисления не является проблемой. Обычные пользователи и IPv4 адреса всегда вводили с трудом. Я просто какое-то время консультировал людей как исправить неработающий интернет. И там нужно было руками вводить IPv4 адреса. Если там был маршрутизатор с IPv6, то они бы просто получили адрес по SLAAC и ничего вводить не надо было, если их сеть нормально функционировала. А если нет, то там без специалиста не обойтись.
Не забываем тот факт, что в IPv4 нет ресурсов даже не на то, чтобы выдать адреса всем нужным устройствам пользователя, но и вообще выдать всем пользователям. На том же Ростелекоме если не заказать статический IPv4, то всё время попадаешь на CGNAT и очень редко тебе выделяют нормальный белый адрес. А вот IPv6 изначально проектировался так, чтобы каждому устройству можно было присвоить отдельный адрес. И торренты, как ни странно, прекрасно качаются с пиров IPv6. Можно даже на клиенте заглушить IPv4 и пользоваться только IPv6.
Ну у нас нет сетей чисто IPv6, просто потому что из них недоступен контент, который есть только в IPv4 и его сейчас, к сожалению, большинство. Большая часть сетей IPv6 работает в паре с IPv4 (дуалстэк). Очень малое число работает только в IPv6 с доступом к IPv4 через специальные шлюзы с NAT64. И вот как в таких условиях считать количество заражённых машин в разных типах сетей? Даже если машина оказалась заражённой по IPv4, то она вполне может проявлять активность через IPv6. Напомню, ОС без разницы какой IP будет использоваться. Она разрешила доменное имя, получила A и AAAA записи, а дальше по своим правилам стучится на узлы IPv6 и IPv4. Да и вообще, как отделить машины, которые были заражены через уязвимость сетевого стэка операционной системы от тех, кто были заражены через другой софт?