У меня пока не было возможности использовать двух провайдеров с 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. Да и вообще, как отделить машины, которые были заражены через уязвимость сетевого стэка операционной системы от тех, кто были заражены через другой софт?
А зачем, если старый протокол будет зря использовать ресурсы устройства? Наоборот, от него лучше избавиться как можно скорее. Новый протокол проще при обработке на аппаратном уровне. Его таблицы маршрутизации не так раздуты, как у IPv4 с его мелкими сетями. Да и на будущее есть запас, чтобы эта таблица не росла. А новый диапазон ещё больше сделает таблицу для IPv4, ведь его придётся порезать и раскидать по всему миру.
По словам Уилсона, в 2008 году именно сложности с поддержкой побудили экспертов отказаться от идеи разблокировки 240/4. Тогда специалисты посчитали, что процесс может занять десятилетия. Обновление прошивки потребовалось бы в том числе миллионам маршрутизаторов. Но с тех пор ситуация стала заметно лучше. Специалисты планируют и дальше изучать способы добавить в устройства поддержку нового блока.
Обновить ПО на всём железе, чтобы расширить диапазон IPv4... Или сделать тоже самое, чтобы внедрить IPv6... Мне кажется тут вывод очевиден. Лучше внедрить новый протокол, который избавлен от недостатков предыдущего, ведь всё равно ПО нужно обновлять.
В любой современной системе запрос соединения обслуживается системой. И этой системе плевать какой IP используется. Если идёт разрешение доменного имени и существует AAAA запись для него, то система будет использовать IPv6. Это происходит прозрачно. И на этом работает NAT64 с DNS64. Там просто добавляется отсутствующая AAAA запись и соединение направляется по сети IPv6 на шлюз с NAT64.
Проблема есть только с приложениями, где жёстко вбит IPv4 адрес. Но и на этот случай есть решения, пусть и костыльные, но рабочие.
Не нужен NAT в IPv6. Без него всё работает и на безопасность он никак не влияет. Только настройку усложняет. Вот в IPv4 без него невозможно, потому что там катастрофически не хватает адресов и уже двухуровневые NAT становятся нормой. IPv6 эту проблему прекрасно решает!
Мне предложили один вариант, где без NAT не обойтись. Да и то оказался по той причине, что сеть была неправильно настроена и NAT был тем костылём, который маскирует проблему.
Я про то, что мы не заменяем IPv4 на IPv6, а добавляем второй протокол к первому.
IPv6 способен полностью заменить IPv4. Можно построить домашнюю сеть только на IPv6 и всё будет прекрасно работать с помощью DNS64+NAT64. Да, для некоторых вещей понадобится костыль на клиентах (clat), например, чтобы видеть пиры IPv4 в торрент клиенте или использовать магазин Steam. Да, это всё, что у меня потребовало clat!!! Я реально ставил эксперимент и на своей машинке пользовался исключительно IPv6 протоколом. И при этом не испытывал никаких трудностей. Другое дело, что делать так особого смысла нет в условиях массовости IPv4 ресурсов. А если убрать необходимость использовать ресурсы на IPv4 адресах, то и костыли можно просто выкинуть за ненадобностью. Они нужны только во время перехода, пока сервис не предоставляется через IPv6.
IPv6 значительно сложнее, с ним до сих пор накоплено меньше опыта, он по умолчанию даёт доступ из инета внутрь локалки, он не заменяет IPv4 и требует дополнительных усилий для поддержки обоих протоколов.
Если не лезть в дебри, то IPv6 даже проще, чем IPv4. Там, где в IPv4 требуется настройка, в IPv6 всё начинает работать само при наличии маршрутизатора. Он просто другой. Разобраться в нём не сложно, особенно если вам нужен просто доступ в интернет и локалка.
В каком месте у вас доступ внутри локалки? У меня обычная конфигурация на OpenWRT. Провайдер даёт мне /56 сеть. И у меня ничего в сети по умолчанию недоступно. Файервол на маршрутизаторе настроен на блокировку соединений. Если нужно что-то открыть для интернета, нужно вписать соответствующее правило. И это легче, чем в IPv4, т.к. ты просто указываешь куда дать доступ и не нужно заморачиваться пробросом портов.
От IPv4 в локалке вообще можно отказаться. Для доступа к IPv4 ресурсом можно использовать NAT64. По сути NAT44 (или просто NAT) заменяется на NAT64.
Заполнять честно, чревато. А то ведь прочитают и найдут и премии лишат или уволят. Или заставят придумывать то, как повысить свою удовлетворённость без финансовых вложений. Так что да, заполнять нужно так, как ожидает руководство, чтобы не было проблем.
Отчитаться точно помогают о том, что предприняты меры по обеспечению безопасности.
Вспоминаю себя в школьное время. Если бы у нас такое было в 90-е, то я бы отлично пользовался тем, что «забыл» карточку. Например, у тебя урок немецкого языка. Ты приходишь, а карты нет... ну что делать, не пускают. Пускают? А в чём тогда смысл всего этого мероприятия?
Когда учился в колледже, то у нас на вахте иногда в обед устраивали цирк с конями. Мол те, кто не носит с собой пропуск, не проходят в общежитие, даже если тебя вахтёр в лицо знает и ты тут точно живёшь. Вот только попасть в общагу в обед - очень важно лично для тебя, ведь голодным останешься. Школьникам, часто то, что не пустили в школу - повод прогулять. А если карточку можно не носить, то зачем её носить? Тут такой же цирк, как со входом в общежитие не пройдёт, ребёнок развернётся и уйдёт, а вахтёр ещё останется крайним, что ребёнка не пустил и тот прогулял.
У меня пока не было возможности использовать двух провайдеров с 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. Да и вообще, как отделить машины, которые были заражены через уязвимость сетевого стэка операционной системы от тех, кто были заражены через другой софт?
А зачем, если старый протокол будет зря использовать ресурсы устройства? Наоборот, от него лучше избавиться как можно скорее. Новый протокол проще при обработке на аппаратном уровне. Его таблицы маршрутизации не так раздуты, как у IPv4 с его мелкими сетями. Да и на будущее есть запас, чтобы эта таблица не росла. А новый диапазон ещё больше сделает таблицу для IPv4, ведь его придётся порезать и раскидать по всему миру.
Обновить ПО на всём железе, чтобы расширить диапазон IPv4... Или сделать тоже самое, чтобы внедрить IPv6... Мне кажется тут вывод очевиден. Лучше внедрить новый протокол, который избавлен от недостатков предыдущего, ведь всё равно ПО нужно обновлять.
В любой современной системе запрос соединения обслуживается системой. И этой системе плевать какой IP используется. Если идёт разрешение доменного имени и существует AAAA запись для него, то система будет использовать IPv6. Это происходит прозрачно. И на этом работает NAT64 с DNS64. Там просто добавляется отсутствующая AAAA запись и соединение направляется по сети IPv6 на шлюз с NAT64.
Проблема есть только с приложениями, где жёстко вбит IPv4 адрес. Но и на этот случай есть решения, пусть и костыльные, но рабочие.
Не нужен NAT в IPv6. Без него всё работает и на безопасность он никак не влияет. Только настройку усложняет. Вот в IPv4 без него невозможно, потому что там катастрофически не хватает адресов и уже двухуровневые NAT становятся нормой. IPv6 эту проблему прекрасно решает!
Мне предложили один вариант, где без NAT не обойтись. Да и то оказался по той причине, что сеть была неправильно настроена и NAT был тем костылём, который маскирует проблему.
IPv6 способен полностью заменить IPv4. Можно построить домашнюю сеть только на IPv6 и всё будет прекрасно работать с помощью DNS64+NAT64. Да, для некоторых вещей понадобится костыль на клиентах (clat), например, чтобы видеть пиры IPv4 в торрент клиенте или использовать магазин Steam. Да, это всё, что у меня потребовало clat!!! Я реально ставил эксперимент и на своей машинке пользовался исключительно IPv6 протоколом. И при этом не испытывал никаких трудностей. Другое дело, что делать так особого смысла нет в условиях массовости IPv4 ресурсов.
А если убрать необходимость использовать ресурсы на IPv4 адресах, то и костыли можно просто выкинуть за ненадобностью. Они нужны только во время перехода, пока сервис не предоставляется через IPv6.
Если не лезть в дебри, то IPv6 даже проще, чем IPv4. Там, где в IPv4 требуется настройка, в IPv6 всё начинает работать само при наличии маршрутизатора. Он просто другой. Разобраться в нём не сложно, особенно если вам нужен просто доступ в интернет и локалка.
В каком месте у вас доступ внутри локалки? У меня обычная конфигурация на OpenWRT. Провайдер даёт мне /56 сеть. И у меня ничего в сети по умолчанию недоступно. Файервол на маршрутизаторе настроен на блокировку соединений. Если нужно что-то открыть для интернета, нужно вписать соответствующее правило. И это легче, чем в IPv4, т.к. ты просто указываешь куда дать доступ и не нужно заморачиваться пробросом портов.
От IPv4 в локалке вообще можно отказаться. Для доступа к IPv4 ресурсом можно использовать NAT64. По сути NAT44 (или просто NAT) заменяется на NAT64.
Заполнять честно, чревато. А то ведь прочитают и найдут и премии лишат или уволят. Или заставят придумывать то, как повысить свою удовлетворённость без финансовых вложений. Так что да, заполнять нужно так, как ожидает руководство, чтобы не было проблем.
Отчитаться точно помогают о том, что предприняты меры по обеспечению безопасности.
Вспоминаю себя в школьное время. Если бы у нас такое было в 90-е, то я бы отлично пользовался тем, что «забыл» карточку. Например, у тебя урок немецкого языка. Ты приходишь, а карты нет... ну что делать, не пускают. Пускают? А в чём тогда смысл всего этого мероприятия?
Когда учился в колледже, то у нас на вахте иногда в обед устраивали цирк с конями. Мол те, кто не носит с собой пропуск, не проходят в общежитие, даже если тебя вахтёр в лицо знает и ты тут точно живёшь. Вот только попасть в общагу в обед - очень важно лично для тебя, ведь голодным останешься. Школьникам, часто то, что не пустили в школу - повод прогулять. А если карточку можно не носить, то зачем её носить? Тут такой же цирк, как со входом в общежитие не пройдёт, ребёнок развернётся и уйдёт, а вахтёр ещё останется крайним, что ребёнка не пустил и тот прогулял.
Это они ещё не знают, что вы мегабайты данных, возможно даже персональных, на сторону гоняли.