Comments 93
У нас хостеры за копейки выдают эти адреса. Мой домашний провайдер по запросу вообще бесплатно его подключает.
Так они их себе покупают навсегда, а вам выдают на время. Если ваш тариф $5 в месяц, за полгода адрес отобьётся (при условии, что его купили за $30, а если в старые времена по старым ценам, то дешевле, а когда-то и бесплатно).
Даже если открывается новый крупный провайдер и хочет например сеть /16, то затраты $2 млн. на адреса не такие уж и большие на фоне стоимости всего бизнеса.
У нас хостеры за копейки выдают эти адреса.
Квартиру тоже можно снять за гораздо меньшие деньги, чем стоимость самой квартиры.
Про отобрать у американской военщины часть из принадлжащих им двенадцати блоков /8 речь опять не идёт.
А что или кто мешает перейти на ipv6? И прекратить эту дележку чужого.
Никто не мешал российскому руководству вместо хранения цифрового мусора яровой принудить наших операторов запустить ipv6 и даже дать немного денег - ибо оборудование у всех давно позволяет это сделать.
IPv6 значительно сложнее, с ним до сих пор накоплено меньше опыта, он по умолчанию даёт доступ из инета внутрь локалки, он не заменяет IPv4 и требует дополнительных усилий для поддержки обоих протоколов.
Как следствие всего этого добавление поддержки IPv6 сильно увеличивает риск некорректной (разные правила для IPv4 и IPv6) и/или небезопасной (IPv6 добавляет новые векторы атак) конфигурации сети.
Иными словами, пока нет ценных для пользователей ресурсов, которые доступны исключительно по IPv6, или законодательных требований поддерживать IPv6 - бизнесу этот ваш IPv6 только лишние проблемы создаёт, не давая взамен ничего ценного. Для пользователей аналогично, за исключением того факта, что они просто не осознают, что выдача им IPv6 провайдером по умолчанию может создать дополнительные дыры в безопасности их домашней локалки.
IPv6 значительно сложнее
ARP, DHCP, NATPT, пересечение адрессных пространств, CIDR не выровненный по точкам, это всё конечно же не сложно?
он по умолчанию даёт доступ из инета внутрь локалки
Некоторые ещё наверное помнят времена, когда IPv4 был таким же. И наверное некоторые американские корпорации до сих пор так живут, взяв в своё время сеть класса A. Проблема решается персональными фаерволлами и IPSec.
он не заменяет IPv4
В каких задачах? Он не заменяет IPv4 только если пытаться скопировать конфигурацию существующий IPv4-сети один к одному, что делать не следует по многим причинам.
В когечном итоге провайдерам станет не выгодно поддерживать именно IPv4, так как BGP таблица разжирела слишком сильно, а NAT операторского класса стоит абсурдно дорого. Не новоря уже о том, что давно обсуждается необходимость взымать в пользу RIR плату за каждый IPv4-адресс. Следовательно они будут просить больше денег за предоставление IPv4. Американский Comcast уже перешёл на IPv6-only архитектуру и очевидно слелали они это по экономическим причинам. С увеличением числа IPv6-only сетей, маршрутизация IPv4 определённо осложнится. Средняя задержка до Google в США по IPv4 уже на 10 мс выше, чем пр IPv6. Строить новые сети стоит только на IPv6 с NAT64. А вот старым надо думать, ведь в принципе можно просто прокси поднять с двойным стеком, не меняя в своей сети ничего и это даже будет работать автоматически для многих приложений.
это всё конечно же не сложно?
Сложно. Проблема в том, что IPv6 ещё сложнее IPv4, причём - значительно.
Некоторые ещё наверное помнят времена, когда IPv4 был таким же.
Это было слишком давно. Я с IPv4 работаю с ~1994, и тогда уже этого не было. А когда это было актуально - сеть была другой, там практически не было вредоносного софта и сетевых атак (червь Морриса появился в 1988, но даже после него эта тема ещё долго не была популярной и реальных проблем особо не создавала).
И наверное некоторые американские корпорации до сих пор так живут, взяв в своё время сеть класса A.
Точно не знаю, но во-первых сильно в этом сомневаюсь, а во-вторых особенности нескольких компаний совершенно не имеют значения при обсуждении того, что коснётся абсолютно всех.
Проблема решается персональными фаерволлами и IPSec.
Решается. Но проблема внедрения IPv6 не в том, что его невозможно внедрить корректно, а в том, что это требует дополнительных усилий во-первых, и во-вторых большинство об этом даже не догадывается (из-за чего в результате внедрения IPv6 они создадут дополнительные уязвимости для своих локальных сетей).
В каких задачах?
Во всех. Я про то, что мы не заменяем IPv4 на IPv6, а добавляем второй протокол к первому. Т.е. внедрение IPv6 не только не избавляет нас от необходимости поддерживать параллельную конфигурацию для IPv4, но и добавляет дополнительное требование синхронизировать часть изменений (актуальную для обоих) этих двух конфигураций между собой.
В когечном итоге провайдерам станет не выгодно поддерживать именно IPv4
Возможно. Но глядя на то, сколько лет уже идёт процесс внедрения IPv6 и его текущий прогресс - при нашей жизни мы отказ провайдеров от IPv4 можем и не застать.
Я про то, что мы не заменяем IPv4 на IPv6, а добавляем второй протокол к первому.
IPv6 способен полностью заменить IPv4. Можно построить домашнюю сеть только на IPv6 и всё будет прекрасно работать с помощью DNS64+NAT64. Да, для некоторых вещей понадобится костыль на клиентах (clat), например, чтобы видеть пиры IPv4 в торрент клиенте или использовать магазин Steam. Да, это всё, что у меня потребовало clat!!! Я реально ставил эксперимент и на своей машинке пользовался исключительно IPv6 протоколом. И при этом не испытывал никаких трудностей. Другое дело, что делать так особого смысла нет в условиях массовости IPv4 ресурсов.
А если убрать необходимость использовать ресурсы на IPv4 адресах, то и костыли можно просто выкинуть за ненадобностью. Они нужны только во время перехода, пока сервис не предоставляется через IPv6.
Проблема в том, что IPv6 ещё сложнее IPv4, причём - значительно.
А вы можете эту сложность выразить в каких-нибудь измеримых значениях?
Возможно. Но глядя на то, сколько лет уже идёт процесс внедрения IPv6 и его текущий прогресс - при нашей жизни мы отказ провайдеров от IPv4 можем и не застать.
У некоторых крупнейших операторов связи сети IPv6-only: T-Mobile US, Orange Poland, Telstra, SK-Telecom.
Выход в IPv4 осуществляется через псевдо-туннель 464XLAT, требующий поддержки со стороны ОС (встроено в смартфоны и десктопные ОС).
это требует дополнительных усилий во-первых, и во-вторых большинство об этом даже не догадывается (из-за чего в результате внедрения IPv6 они создадут дополнительные уязвимости для своих локальных сетей).
Это так. Это одна из причин, почему провайдеры России не включают его по умолчанию, и кажется, что внедрение IPv6 не слишком широкое. Попробуйте обратиться к вашему провайдеру — есть немалая вероятность, что он может вам просто включить поддержку этого протокола.
В 94м году далеко не все сидели на ipv4, это был только выход наружу. Внутри у организациц был ipx, netware и дюжина других. Сейчас все оборудование и протоколы стандартизированы, Ос поддерживают ip4и ipv6 , половина провайдеров тоже на 6м.. А вот государственники и РКН - на 4м.
А нельзя просто с ipv6 NAT включить?
Это Вы про прокси? Если да, то никакой NAT не позволит IPv4-only клиентам в старой сети получить доступ к IPv6 серверам. А вот прокси может. И http и socks5 позволяют подключаться по доменному имени и клиент не обязан знать какой метод доставки TCP или UDP пакетов к серверу предпочтёт прокси, хоть IPv15. Соединить IPv6-only клиента с IPv4-сервером можно и через NAT64.
Нет, я хочу с ipv6 роутером сидеть за NAT чтобы никто порты не сниффал у устройств в сети
Такое поведение достигается настройками firewall на роутере. Если роутер на linux, это делается стандартными настройками. Разрешаются пакеты только от соединений, который установлены по инициативе устройства из внутренней сети. По защищённости тот же NAT, за тем исключением, что у устройств во внутренней сети не "серые" IP-адреса, а глобально маршрутизируемые.
IPv6 значительно сложнее, с ним до сих пор накоплено меньше опыта, он по умолчанию даёт доступ из инета внутрь локалки, он не заменяет IPv4 и требует дополнительных усилий для поддержки обоих протоколов.
Если не лезть в дебри, то IPv6 даже проще, чем IPv4. Там, где в IPv4 требуется настройка, в IPv6 всё начинает работать само при наличии маршрутизатора. Он просто другой. Разобраться в нём не сложно, особенно если вам нужен просто доступ в интернет и локалка.
В каком месте у вас доступ внутри локалки? У меня обычная конфигурация на OpenWRT. Провайдер даёт мне /56 сеть. И у меня ничего в сети по умолчанию недоступно. Файервол на маршрутизаторе настроен на блокировку соединений. Если нужно что-то открыть для интернета, нужно вписать соответствующее правило. И это легче, чем в IPv4, т.к. ты просто указываешь куда дать доступ и не нужно заморачиваться пробросом портов.
От IPv4 в локалке вообще можно отказаться. Для доступа к IPv4 ресурсом можно использовать NAT64. По сути NAT44 (или просто NAT) заменяется на NAT64.
Я думаю, проблемой будут legacy-приложения.
Сейчас ok.ru, vk.com не поддерживают IPv6, но на них хотя бы можно будет заходить через прокси.
А что делать с играми, какие-нибудь "танки", которые просто создают v4 сокеты и работают через них.
всё будет прекрасно работать с помощью DNS64+NAT64. Да, для некоторых вещей понадобится костыль на клиентах (clat), например, чтобы видеть пиры IPv4 в торрент клиенте
Я не очень понимаю, как это технически работает. Во многих сложных сетевых приложениях внутри протокола указываются адреса/порты. Простейший пример - протокол FTP, активный режим. Там приложение говорит: мой адрес такой-то, подключайся. Более свежий пример - DC++ с его $ConnectToMe RemoteNick IP:PORT, или тот же торрент с адресами пиров внутри траффика. DNS64+NAT64 не могут же влезать внутрь траффика и подправлять там адреса?
Хорошо, если приложение развивается, и там появляется нативная поддержка v6. А если есть только бинарник, и авторы не считают нужным работать по v6, а протокол сложный, то что делать?
А я ещё застал времена, когда vk.com был доступен по IPv6.
Простейший пример - протокол FTP, активный режим. Там приложение говорит: мой адрес такой-то, подключайся.
Так FTP в активном режиме сквозь NAT не заработает и в IPv4, так что приходится городить костыли с вмешательством в контрольное соединение или принудительно всех заставлять работать в пассивном режиме.
Хотя, вообще, FTP в 2024 году это уже позор позорный, при наличии всяческих SFTP, rsync и прочего.
Я думаю, проблемой будут legacy-приложения.
В любой современной системе запрос соединения обслуживается системой. И этой системе плевать какой IP используется. Если идёт разрешение доменного имени и существует AAAA запись для него, то система будет использовать IPv6. Это происходит прозрачно. И на этом работает NAT64 с DNS64. Там просто добавляется отсутствующая AAAA запись и соединение направляется по сети IPv6 на шлюз с NAT64.
Проблема есть только с приложениями, где жёстко вбит IPv4 адрес. Но и на этот случай есть решения, пусть и костыльные, но рабочие.
запрос соединения обслуживается системой. И этой системе плевать какой IP используется
На уровне API ОС, например при создании сокета в C/C++ нужно явно указывать формат адреса.
Может, какой-нибудь python принимает URI и в библиотеке requests (не в системе, заметьте!) принимается решение, какой создавать сокет.
Но и на этот случай есть решения, пусть и костыльные, но рабочие
Вот мне и любопытно, какие костыли могут решить проблему протокола. Когда пиры обмениваются своими ip-адресами непрозрачно для ОС.
Проблемой будут не приложения, а устройства.
Есть 100500 всякого железа, которое уже не умеет новомодной почтой и браузерами пользоваться, а никаких ipv6 там нет вообще, как нет компаний это железо изготовивших. Но оно работает, и менять его никто не стремится.
Ну т.е. если есть очень много денег, то поменяют, но это как-то не очень разумным видится.
в IPv6 всё начинает работать само
Если для Вас кто-то (разработчики OpenWRT, например) это уже настроил, то да. Работать - начинает само. А вот насколько оно безопасно настроено - тут уже всё совсем не так очевидно. Для IPv4 все очень давно научились его настраивать безопасно, включая разработчиков всех прошивок роутеров и всех "домашних" админов. А для IPv6 это пока не так.
Ну и там нюансов хватает даже для того, чтобы всё просто работало корректно. Например если попытаться пойти по пути IPv4 и на роутере тупо включить NAT для IPv6, то это может сломать кучу приложений в локалке, просто потому, что если для IPv4 они к поддержке NAT морально готовы, то в IPv6 это крайне нетипичный кейс и они его могут не поддерживать. А самое смешное то, что вариантов NAT для IPv6 существует минимум два (NAT66 и NPTv6), работают они по-разному (причём у одного из них могут быть проблемы с тем же IPSec и т.д.), разные вендоры реализуют что хотят и как хотят, а принятого стандарта для IPv6 NAT всё ещё нет (есть RFC в статусе Experimental).
При этом куча "пуристов IPv6" годами сопротивляются поддержке NAT для IPv6, пытаясь донести до всех что в IPv6 NAT не нужен, что проблем это создаст больше, чем решит, что все проблемы для решения которых хочется использовать NAT в IPv6 можно и нужно решать другими способами, и что в принципе NAT (даже в IPv4) не предназначен решать проблему безопасной изоляции локалки от инета и по факту в этом качестве он используется не по назначению (так что тем более не надо переносить эти плохие практики в IPv6).
В конечном итоге всё это ведёт только к одному: сложность корректной и безопасной настройки IPv6 параллельно и эквивалентно текущей настройке IPv4 - довольно большая, не смотря на то, что внедрение IPv6 тянется уже столько лет. А польза от него, на сегодня, всё ещё незначительная. Вывод: не сегодня!
сложность корректной и безопасной настройки IPv6 параллельно и эквивалентно текущей настройке IPv4 - довольно большая,
Не сложность, а лень админов. Ничего принципиально сложного в v6 нет.
что внедрение IPv6 тянется уже столько лет. А польза от него, на сегодня, всё ещё незначительная. Вывод: не сегодня!
Вот так и про UTF говорили. Мол значительно сложнее считать длину, зачем это нужно, всё ж и так работает...
Не нужен NAT в IPv6. Без него всё работает и на безопасность он никак не влияет. Только настройку усложняет. Вот в IPv4 без него невозможно, потому что там катастрофически не хватает адресов и уже двухуровневые NAT становятся нормой. IPv6 эту проблему прекрасно решает!
Мне предложили один вариант, где без NAT не обойтись. Да и то оказался по той причине, что сеть была неправильно настроена и NAT был тем костылём, который маскирует проблему.
Прямо сейчас использую NAT в IPv6, а именно NAT66.
Причина - у меня MultiWAN. Несколько провайдеров выдают каждый свою подсеть, и нужно организовать балансировку трафика и/или фейловер и/или маршрутизацию трафика на разные ресурсы через разных провайдеров. Если один из провайдеров "падает", должно осуществляться автоматическое переключение на рабочего провайдера с даунтаймом не более нескольких секунд.
Минус - все устройства выходят в интернет через один единственный IP адрес, который как правило выглядит как :1 или :2. Смотрела в сторону NPTv6, но к сожалению он не реализован в OpenWRT.
У меня пока не было возможности использовать двух провайдеров с IPv6. Одного то еле нашёл. Но теоретически можно раздать адреса GUA от обоих провайдеров, просто один из адресов будет неактивен, благо такое в IPv6 возможно.
Если соединение основное падает, то происходит рассылка RA, что первый шлюз прекращает работу, а второй наоборот должен объявить, что он теперь шлюз по умолчанию. Схему с двумя маршрутизаторами кто-то делал. Возможно это были микротики.
Нужно искать тех, кто подобным уже занимался. Самому интересно, но нет второго провайдера с IPv6. Вообще из доступных никто не предоставляет.
Слышала про такой вариант, но непонятно как его реализовать.
Если просто в лоб подключить двух провайдеров, то конечные устройства получают по адресу от каждого провайдера и используют какого-то одного из них. Даже если он падает, продолжают ломиться через упавшее соединение.
Кроме того, описанный вами вариант предполагает фейловер, но не предполагает балансировку (суммирование) каналов и маршрутизацию трафика на разные ресурсы через разных провайдеров.
С NAT и OpenWRT все просто. Одной настройкой включается NAT66, ставится пакет mwan3, далее можно как угодно рулить хоть 10-ю каналами в интернет.
Для IPv4 все очень давно научились его настраивать безопасно, включая разработчиков всех прошивок роутеров и всех "домашних" админов.
А я не сомневаюсь, что на типичных линукс-боксах типичный системный администратор настроит IPv4 уязвимым образом, с недостаточной фильтрацией.
Вот первые попавшиеся 11 инструкций из поисковика:
Hidden text
https://www.howtoforge.com/nat_iptables
https://howtoforge.com/internet-connection-sharing-masquerading-on-linux
https://www.linuxjournal.com/content/linux-networking-configuring-network-address-translation-nat
https://kifarunix.com/configure-ubuntu-20-04-as-linux-router/
https://www.cyberciti.biz/faq/howto-configure-network-address-translation-or-nat/
https://ixnfo.com/en/ubuntu-ip-masquerading.html
https://www.server-world.info/en/note?os=Ubuntu_22.04&p=ufw&f=2
https://medium.com/@lfoster49203/setting-up-ubuntu-as-a-router-with-advanced-routing-features-4511abc5e1eb
https://www.linode.com/docs/guides/linux-router-and-ip-forwarding/
https://blog.oshim.net/2013/01/configure-ip-masquerading-for-ubuntu/
https://help.ubuntu.com/community/Router
Только в одной, официальной от Ubuntu, инструкции приводится скрипт для корректной настройки маршрутизации. В остальных 10 инструкциях сеть настраивается так, что позволяет и маршрутизировать трафик и через саму машину (она начинает выступать NAT-шлюзом для всех устройств на WAN-порту без ограничений или с ограничением по диапазону IP-адресов, но не интерфейсов), и в другие интерфейсы на машине.
Иными словами, при настройке по подобной инструкции машина из WAN может получить прямой доступ к вашим машинам из LAN. Потому что NAT не защищает от такого, а защищает межсетевой экран. Он работает одинаково что для IPv4, что для IPv6.
У меня установка роутера начинается с отключения IPV6. При чем, последнее время это не всегда тривиальная задача.
Мне как-то спокойнее если маршрутизатор роутит мою локалку моим соседям по провайдеру (хотя лично в моём случае - нет), чем через IPV6 потенциально всей сети.
Как я понимаю, фильтрация на линукс софтроутерах (которые сейчас чуть менее чем все) работает методом наложения фильтра на прозрачный интерфейс. Если я на роутере с IPV6 делаю условно /etc/init.d/ip(6)tables stop, то вся локалка резко выставляется в сеть. Т.е. если iptables не поднимется (а такое случается порой), то локалка будет светить в сеть и хуже всего то, что я этого не увижу. Еще по дефолту может быть временной лаг между поднятием интерфейса и фильтра. Это решается, но это надо решать. С натом такой проблемы нет, там наоборот - нет ната нет связи.
Еще момент - провайдер тупо по адресам может считать мои домашние устройства. А я этого не хочу. Я понимаю, что это можно делать и с натом, но гораздо сложнее, особенно если я предпринимаю дополнительные меры. Это конечно специфичная для российского опыта параноя, но тем не менее.
Т.е. если обобщить, то глобально с IPV6 по умолчанию локалка открыта и закрывается костылями, а IPV4+NAT закрыта и открывается костылями.
По этому очевидно, что в первом случае открыть сеть по ошибке куда проще.
Т.е. если iptables не поднимется (а такое случается порой), то локалка будет светить в сеть и хуже всего то, что я этого не увижу.
Справедливо, это действительно так.
С натом такой проблемы нет, там наоборот - нет ната нет связи.
Это не совсем правда, но принимается.
Еще момент - провайдер тупо по адресам может считать мои домашние устройства.
IPv6 Privacy Extensions включены, полагаю, везде, или почти везде. У каждой машины могут быть десятки адресов, меняющиеся через определённые интервалы.
По этому очевидно, что в первом случае открыть сеть по ошибке куда проще.
Настраивайте конечные устройства так, чтобы их можно было подключить к любой сети, не опасаясь за их безопасность.
Настраивайте конечные устройства так, чтобы их можно было подключить к любой сети, не опасаясь за их безопасность.
Это бесмысленная рекомендация из серии "делай хорошо - будет хорошо".
Если мы говорим про устройства из категории IoT, то там прошивки с уязвимостями - совершенно обычное дело, и у владельца тупо нет технической возможности выполнить Вашу рекомендацию. Если мы говорим про обычные компы/ноуты в домашней локалке, то обычно в такой локалке просто нет никого с необходимой для их безопасной настройки квалификацией (частично потому, что на сегодняшний день все такие пользователи привыкли, что безопасность локалки обеспечивает домашний роутер, и им самим на конечных устройствах для этого ничего делать не требуется).
В результате при переходе на IPv6 на текущем уровне сохранится безопасность только тех домашних локалок, в которых есть достаточно квалифицированный специалист, который сможет настроить (и поддерживать) безопасность всех конечных устройств... мда.
Вы про отсутствие политики DROP по умолчанию для FORWARD? Формально Вы правы, но размер этой дыры всё-таки по-меньше, чем в IPv6: чтобы воспользоваться этой дырой в IPv4 необходимо как-то обеспечить роутинг своего пакета предназначенного адресу локалки до WAN интерфейса. По сути это ограничивает возможность её эксплуатации ближайшими соседями по подъезду/дому, максимум - клиентами своего провайдера (если провайдер криво настроил своё оборудование, что маловероятно но не исключено). Из инета такой пакет точно не дойдёт.
чтобы воспользоваться этой дырой в IPv4 необходимо как-то обеспечить роутинг своего пакета предназначенного адресу локалки до WAN интерфейса
А чтобы воспользоваться ей в IPv6, злоумышленнику сперва нужно каким-то образом узнать адрес. Почти все устройства используют Privacy Extensions с периодически меняющимися адресами, а если не используют, то всё равно генерируют себе из RA самостоятельно.
По сути это ограничивает возможность её эксплуатации ближайшими соседями по подъезду/дому, максимум - клиентами своего провайдера
Вы узко мыслите — подумайте об этом в рамках датацентра.
злоумышленнику сперва нужно каким-то образом узнать адрес
Честно говоря, я не готов сравнивать вероятности обсуждаемых кейсов - на поверхностный взгляд у нас нет очевидных оснований заявить, что какая-то вероятность значительно больше другой.
Адрес - информация не секретная. Он виден на каждом ресурсе, к которому обратился (включая всякие служебные - DNS, NTP, CA revocation list, сервера обновлений разного софта, сервера куда указывают разные механизмы слежки вроде прозрачных пикселей и прочих кук и т.п.), плюс на куче промежуточных серверов по дороге к этим ресурсам плюс нередко в рамках локалки (которая может включать соседей по дому если провайдер не очень хорошо настроил роутер) и при использовании WiFi.
Тип атак из-за этого может сместиться с брутфорса адресов на получение их из вышеупомянутых источников, но вот как это скажется на количестве/доступности атак - я не готов оценивать.
подумайте об этом в рамках датацентра
На мой взгляд в рамках ДЦ эта проблема не настолько критична. В ДЦ локалку с NAT обычно делают либо штатным механизмом ДЦ (VPC сотоварищи), либо этим занимается админ компании-клиента ДЦ который понимает, что делает - в отличие от пользователей домашних локалок.
Адрес - информация не секретная. Он виден на каждом ресурсе, к которому обратился
В IPv6 -- секретная.
Интерфейс, кроме основного адреса может нахватать сколько угодно дополнительных-временных, с которых и будет ходить на все нужные ресурсы и не принимать коннекты на них. А принимать только на основном, который не светится нигде, кроме явно указанных мест.
IPv4 так не сумеет, если только вы не купите по паре белых айпи каждой рабочей станции :)
Это всё прекрасно, честно! Лично я только "за". Но есть одна небольшая проблема: когда несколько месяцев назад на хабре было аналогичное обсуждение я не поленился изучить поддержку в ядре линуха всех таких фич IPv6. И знаете что выяснилось? Все эти "для безопасности/приватности" фичи реализованы, но по умолчанию все они выключены. Как думаете, какой процент устройств в домашних локалках будет их использовать в реальном мире и скажется ли это хоть как-то на общей ситуации с безопасностью? (Вопрос риторический.)
Все эти "для безопасности/приватности" фичи реализованы, но по умолчанию все они выключены.
Вы в этом видите большую проблему? Добавить\поменять один небольшой скриптик в установщике дистра?
Как думаете, какой процент устройств в домашних локалках будет их использовать
А вы как думаете, какой процент устройств в домашних локалках будет линуксом? :)
Потому как я лично видел RFC 8981 на виндах включённый и работающий под SLAAC по умолчанию ёщё, емнип, на Windows 7.
и скажется ли это хоть как-то на общей ситуации с безопасностью? (Вопрос риторический.)
Никак. Проникновения, для которых требуется находить конкретную жертву по ёё IP, выловленному на скомпрометированном ресурсе, занимают доли процента на фоне всяких фишингов. С тех пор, как нетбиос перестал торчать в инет, я даже не припомню ни одной атаки такого класса.
Вы в этом видите большую проблему? Добавить\поменять один небольшой скриптик в установщике дистра?
Проблема не в том, что это сложно включить по умолчанию. Проблема в том, что это пока не включено, и неизвестно когда будет и будет ли вообще включено. Потому что пользователи сами это массово включать точно не станут - они даже знать про существование этих фич не будут. Так что пока оно по умолчанию выключено - правильнее считать что этого функционала вообще не существует (с точки зрения безопасности по миру в среднем, а не отдельных hardened систем).
А вы как думаете, какой процент устройств в домашних локалках будет линуксом? :)
Явно намного больший, чем виндой. Почти весь IoT и прочие стиральные машины с пылесосами и холодильниками обычно на линухе, большая часть телефонов и планшетов на андроиде (да и эппловские тоже не на винде работают, но как там с умолчаниями для IPv6 я не знаю), все роутеры, "свистки" для телевизоров… ну и заметный процент десктопов тоже.
Проникновения, для которых требуется находить конкретную жертву по ёё IP, выловленному на скомпрометированном ресурсе, занимают доли процента на фоне всяких фишингов.
Можете дать ссылки на исследования по этому вопросу, или это ваше личное ощущение?
С тех пор, как нетбиос перестал торчать в инет, я даже не припомню ни одной атаки такого класса.
Вот как бы не оказалось, что IPv6 - это новый нетбиос в этом плане, и такие атаки снова вернутся. Атакуют то, что проще/дешевле. Лезть внутрь локалки IPv4 прикрытой NAT-ом было явно не проще и не дешевле. Но в IPv6 это может изменится.
Проблема в том, что это пока не включено, и неизвестно когда будет и будет ли вообще включено
Будет. Как только IPv6 реально пойдёт в массы и станет востребован среди целевой аудитории, дистро-строители озаботятся более-менее безопасными дефолтами.
Почти весь IoT и прочие стиральные машины с пылесосами и холодильниками обычно на линухе,
Очень оптимистичная оценка. Современный линух не так-то просто впихнуть в рамки типичного же современного IoT устройства. Малинообразные устройства так и не стали индустриальным стандартом, как для IoT так и вообще, так что там либо какая-нибудь экзотика типа VxWorks, либо винегрет из embedded OS, у которых стек tcp/ip не из линуха.
все роутеры, "свистки" для телевизоров… ну и заметный процент десктопов тоже.
не все роутеры (есть роутеры на том же VxWorks), а процент десктопов незаметный.
Можете дать ссылки на исследования по этому вопросу, или это ваше личное ощущение?
Это мой личный опыт, скажем так, шапки, которая в годы молодости не всегда была белой.
Целевые атаки (именно на пен, а не тупой ддос) чрезвычайно редки. Целевые атаки на пен на клиентскую сторону -- чрезвычайно редки в квадрате. Все последние легендарные успехи на этом поприще -- фишинг, трояны в почте и социалка. Вы поинтересуйтесь, как спецслужбы вкорячивали Stuxnet иранцам — через виндовый autorun, ага.
И домножьте это на долю юзеров, которые ходят в инет с белых адресов сейчас и вам тоже это станет очевидно.
Лезть внутрь локалки IPv4 прикрытой NAT-ом было явно не проще и не дешевле. Но в IPv6 это может изменится.
А может и не измениться. Вы этого не знаете заранее, а я вижу, что разработчики IPv6 на эту тему думали и предлагали решения, тот же RFC 8981.
дистро-строители озаботятся более-менее безопасными дефолтами
Точно нет. Безопасность - никогда не была приоритетом. Она обычно вредит удобству и/или функционалу, приоритет которых для абсолютного большинства пользователей считается более высоким. Так что пока у разработчиков дистрибутивов не будет уверенности, что этот функционал ничего никому не сломает - его не включат по умолчанию. А пока он у абсолютного большинства выключен - нет и не будет уверенности, что он ничего не сломает. Тут типичная проблема курицы и яйца. Другое дело, если какая-то уязвимость будет использоваться настолько массово, что это начнёт заметно вредить значительному числу обычных пользователей и поднимется вой в СМИ - тогда да, защитную фичу вполне могут включить даже с риском кому-то что-то сломать. Но во-первых это несколько поздновато (как на мой взгляд), и во-вторых включат только эту фичу, а все остальные (а там их немало) останутся выключенными. Так всё происходило минимум последние лет 25, и я не вижу оснований надеяться, что с этими фичами будет как-то иначе.
Остальные пункты комментировать нет смысла, мы свои позиции и аргументы озвучили, а есть ли реальные основания для большего или меньшего оптимизма по упомянутым вопросам мы всё-равно тут не выясним, будем считать это личными предпочтениями.
так а не проще тогда когда провайдер выдает глобальный айпив6 на роутер, а роутер внутри квартиры раздает уже локальные айпив6.
)))👍🏻
IPv6 значительно сложнее
В целом - они примерно одинаково сложны для человека, не знающего глубоко о проблемах каждого из них. Просто немного разные проблемы.
с ним до сих пор накоплено меньше опыта
Очень давно в эксплуатации ipv6 only сети с DNS64+NAT64, литературы навалом.
он по умолчанию даёт доступ из инета внутрь локалки
У нем нет такой функции, как и в ipv4. Это домашний роутер может быть настроен по разному, firewall нужен в любом случае.
он не заменяет IPv4 и требует дополнительных усилий для поддержки обоих протоколов.
И операторские и корпоративные ipv6 only сети уже есть. Поддержка - только на бордере, ну так раньше там стоял NAT.
бизнесу этот ваш IPv6 только лишние проблемы создаёт, не давая взамен ничего ценного
Огромные CGNAT боксы - это зло, а дырки в безопасности - из-за домашнего ipv6 не подтверждаются на практике в сетях, где ipv6 получают все клиенты - таких в мире уже немало.
дырки в безопасности - из-за домашнего ipv6 не подтверждаются на практике в сетях
Как можно подтвердить отсутствие чего-то? Тут обычные взломы крупные корпорации умудряются не замечать годами, пока хакеры резвятся на их серверах и воруют данные терабайтами, а Вы ждёте что обычные юзеры отследят взлом домашней локалки и напишут об этом в СМИ?
Вот наличие чего-то подтвердить можно. Например поиск "IPv6" по базе CVE выдаёт порядка 50 уязвимостей только за последний год, а всего их 554. Например, вот, пару месяцев назад опубликовали: "D-Link R15 before v1.08.02 was discovered to contain no firewall restrictions for IPv6 traffic. This allows attackers to arbitrarily access any services running on the device that may be inadvertently listening via IPv6.".
Ну и плюс очевидное: добавление IPv6 по определению увеличивает поверхность атаки. И если делать это не вникая, надеясь что безопасность обеспечит роутер (вроде вышеупомянутого, ага) - в локалке совершенно точно добавится уязвимостей.
IPv6 по определению увеличивает поверхность атаки
Нет, не увеличивает. Вы не сможете, как с IPv4, просканировать /64 за вменяемое время, если там сидит RFC 4941, а оно там сидит везде по дефолту уже давно.
Почитайте определение понятия "поверхность атаки". Оно включает много чего, в т.ч. дополнительный код, в котором могут быть уязвимости (стек IPv6 в ядре ОС, например).
С чего вы взяли, что код, реализующий IPv6 как то более уязвим, чем код, реализующий IPv4 ?
Ой, вэй! Таки почитайте уже что Вас попросили почитать, чисто чтобы не писать ещё больше глупостей.
Он может быть не более уязвим, он может быть даже менее уязвим, но пока он не заменяет старый код а добавляется к нему - добавляются и его уязвимости. Если раньше можно было атаковать только код в стеке IPv4, то теперь можно атаковать и его, и код в стеке IPv6 - следовательно поверхность атаки увеличилась.
Но по факту - он таки более уязвим (хоть в данном контексте это и не важно). Просто потому, что он более новый и он менее активно используется - а в таких условиях в коде всегда больше ошибок, если сравнивать с аналогичным но более старым и проверенным. И в этом легко убедиться: поиск "linux ipv4" по CVE выдаёт 4 результата за 2023 год, а аналогичный для ipv6 выдаёт 11.
но пока он не заменяет старый код а добавляется к нему - добавляются и его уязвимости. Если раньше можно было атаковать только код в стеке IPv4, то теперь можно атаковать и его, и код в стеке IPv6 - следовательно поверхность атаки увеличилась.
Это какая-то очень эзотерическая логика. Чем меньше кода, тем больше его защищённость, серьёзно? Ну ок, давайте повыкидываем обработку эксепшнов, канареек из стэка выбросим, санитайзеры всякие, zerofill-аллокации, сборщики мусора, вот это всё. Сразу защищённее станет, ага.
Но по факту - он таки более уязвим (хоть в данном контексте это и не важно). Просто потому, что он более новый и он менее активно используется - а в таких условиях в коде всегда больше ошибок, если сравнивать с аналогичным но более старым и проверенным. И в этом легко убедиться: поиск "linux ipv4" по CVE выдаёт 4 результата за 2023 год, а аналогичный для ipv6 выдаёт 11.
А почему только за 2023 год? Я вот сделал поиск по всей базе, и для "linux ipv4" нашлось 84 результата, а для "linux ipv6" -- 88 результатов. Огромная разница, ага. Причём подавляющее большинство их вообще никак не относилось к разнице между реализациями протокола IP этих версий.
Кстати, по "linux netware" за всё время нашлось аж 5 уязвимостей. По вашей логике, его код, получается, в 16 раз более защищён, чем IP.
Очень странную вы метрику выбрали.
Это какая-то очень эзотерическая логика.
Да нет, логика вполне обычная. Это просто Вы никак не изучите общепринятое определение обсуждаемого термина.
Чем меньше кода, тем больше его защищённость, серьёзно?
Абсолютно. Многократно подтверждённый факт. Есть даже метрики по среднему количеству багов на 1000 строк кода.
Ну ок, давайте повыкидываем обработку эксепшнов, канареек из стэка выбросим, санитайзеры всякие, zerofill-аллокации, сборщики мусора, вот это всё. Сразу защищённее станет, ага.
Не станет. Но половина кода написанного в таком стиле будет содержать в 2 раза меньше багов чем весь такой код - так что принцип продолжает работать.
А почему только за 2023 год?
Потому что меня интересует ситуация на текущий момент. Желающие могут построить график как это изменялось по годам. Плюс ещё внимательно вчитаться в описание каждого CVE - вполне вероятно, что часть из них не имеет отношения к этому вопросу. Плюс ещё можно учесть критичность CVE. Лично у меня нет ни времени ни желания этим заниматься, но если это кто-то проделает - это будет очень круто.
Это просто Вы никак не изучите общепринятое определение обсуждаемого термина.
Теорию я знаю, но не могу избавиться от ощущения что вы как-то уж слишком буквально ставите телегу формальных метрик впереди кодовой лошади. Впрочем, дело вкуса.
Но половина кода написанного в таком стиле будет содержать в 2 раза меньше багов чем весь такой код - так что принцип продолжает работать.
Но и писать такой код никто не будет, потому что это дольше, дороже, и бизнесу непонятно зачем нужно.
Как можно подтвердить отсутствие чего-то?
Можно посмотреть на трафик, который генерируют зараженные компьютеры в таких сетях и сравнить его с трафик в ipv4 only. Так что вполне возможно.
Например поиск "IPv6" по базе CVE выдаёт порядка 50 уязвимостей только за последний год
В обычных ipv4 сетях точно так же хватает проблем, а уж дырявых роутеров - и подавно много. У этого девайса это не одна и не первая проблема.
Ну и плюс очевидное: добавление IPv6 по определению увеличивает поверхность атаки
Такой роутер найти надо. Все ipv4 адреса в интернет я лично могу за пару часов просканировать, с ipv6 такой трюк не пройдет.
Можно посмотреть на трафик, который генерируют зараженные компьютеры в таких сетях и сравнить его с трафик в ipv4 only. Так что вполне возможно.
Ну у нас нет сетей чисто IPv6, просто потому что из них недоступен контент, который есть только в IPv4 и его сейчас, к сожалению, большинство. Большая часть сетей IPv6 работает в паре с IPv4 (дуалстэк). Очень малое число работает только в IPv6 с доступом к IPv4 через специальные шлюзы с NAT64. И вот как в таких условиях считать количество заражённых машин в разных типах сетей? Даже если машина оказалась заражённой по IPv4, то она вполне может проявлять активность через IPv6. Напомню, ОС без разницы какой IP будет использоваться. Она разрешила доменное имя, получила A и AAAA записи, а дальше по своим правилам стучится на узлы IPv6 и IPv4. Да и вообще, как отделить машины, которые были заражены через уязвимость сетевого стэка операционной системы от тех, кто были заражены через другой софт?
Ну у нас нет сетей чисто IPv6
Как это нет? Есть! У клиента используются только ipv6 адреса - T-Mobile на такую схему перешли еще в 2014 году.
И вот как в таких условиях считать количество заражённых машин в разных типах сетей
Очень просто - достаточно сравнить процент зараженных в сравнении с ipv4 only.
Да и вообще, как отделить машины, которые были заражены через уязвимость
сетевого стэка операционной системы от тех, кто были заражены через
другой софт?
А это не важно - если в ipv6 сетях количество зараженных компьютеров в процентном соотношении не выше, чем в ipv4 only, то ipv6 значимого влияния на безопасность не оказывает.
Как это нет? Есть! У клиента используются только 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.
Опять таки, сам процент заражённых получить сложно. Плюс как вы будете отделять заражённые машины по тому через что они были заражены, если на подавляющем большинстве есть два стека и они могут обращаться к любым типам адресов? Да основная часть заражений происходит от действий пользователя или от его бездействия (не ставит обновления безопасности для своей ОС).
Лично я не представляю как даже просто собрать данные о заражениях и как их потом отсортировать корректно.
Опять таки, сам процент заражённых получить сложно.
На DPI можно прикинуть, примерные паттерны зараженных машин понятны.
Плюс как вы будете отделять заражённые машины по тому через что они были заражены
А зачем их отделять? Тут работает обычная статистика - если в сети, где есть ipv6, процент зараженных не отличается от сети ipv4 only - то все в порядке.
А зачем их отделять? Тут работает обычная статистика - если в сети, где есть ipv6, процент зараженных не отличается от сети ipv4 only - то все в порядке.
Я бы посмотрел на такую статистику... только кто бы её предоставил :-D
Я не могу - NDA не позволяет :) Понимаю, что это не повышает доверия к моим словам, но можете принять их просто за идею, которую можно предложить кому-то, кто не отягощен подобными ограничениями.
У меня есть два варианта что должно быть в реальной статистике:
процент заражений примерно одинаков, потому что заражения именно через сетевой стэк имеет небольшой процент от всех заражений (кроме разве что IoT, где производители забивают на обновление).
процент заражений выше для IPv6, просто потому, что производители маршрутизаторов забивают на протокол IPv6 и делают его для галочки, например, могут забыть о файерволе.
Во втором случае проблема не в протоколе, а в его уровне поддержки. Если сравнить с IPv4, то было время когда всякие ADSL модемы по умолчанию имели стандартные пароли для управления, а их веб-интерфейсы светились в интернете. Но по мере увеличения потребности в услуге, это стали решать. Также будет и с IPv6.
Кстати, я до сих пор не знаю работает ли он на оборудовании Ростелеком для GPON. Там можно в настройках включить IPv6 и он будет ограниченно работать. Можно получить адрес IPv6 и пользоваться услугами. Однако раньше они блокировали все входящие в мою сторону пакеты, кроме ответных по TCP. UDP полностью не работал. Потом я сменил маршрутизатор на тот, который полноценно поддерживает IPv6. Спустя какое-то время проблема с UDP у меня решилась, а также стало возможным открывать порты для нужных мне устройств для доступа из интернет. А вот как в такой ситуации вёл бы провайдерский CPE я не знаю. IPv6 там практически не имеет настроек ни в веб-интерфейсе, ни в командной строке (у меня был доступ уровня superadmin). Либо подсказки не содержат информацию по командам для IPv6.
IPv6 значительно сложнее, с ним до сих пор накоплено меньше опыта, он по умолчанию даёт доступ из инета внутрь локалки, он не заменяет IPv4 и требует дополнительных усилий для поддержки обоих протоколов.
Предлагаю перестать бояться IPv6 познакомившись с моим материалом
https://habr.com/ru/articles/773708/
Там вы узнаете как на практике начать использовать IPv6.
Спасибо, почитаю. Первая фраза уже порадовала:
В 2023 году люди боятся многих новых для них вещей, например, systemd, SELinux, IPv6 и др.
Как Вы узнали, Вы за мной следите? :-) Нет, я всего этого не "боюсь", а вполне осознанно избегаю из-за переусложнённости этих технологий. Вместо systemd у меня runit и udevd. Вместо SELinux был GrSecurity (пока его не сделали закрытым), сейчас ничего (собираюсь попробовать Apparmor но пока руки не дошли). Простое всегда лучше сложного (пока функционала простого достаточно).
Что нам даёт IPv6
Лично мне - исключительно экономию денег на оплату белого IPv4. Но создаваемые внедрением IPv6 сложности лично для меня пока намного значительнее чем экономия этих копеек.
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 Ссылка на оригинал приведена во вступлении.
я слишком переусложнил код приложения в угоду запуска его через старые системы инициализации
Ну да, ну да. А "не переусложнённое" приложение будет работать без systemd? Вот в этом и проблема systemd - он слишком много функционала в себя затянул, и продолжает затягивать (включая вот такой "требующий systemd" совершенно посторонний софт). При этом качество всего этого функционала в systemd не настолько хорошее, чтобы отказ от всех альтернатив и vendor-lock на единственном монстрообразном решении были действительно оправданы. Но продолжать эту тему тут явно не стоит, про это уже всё давно и много раз сказано. Остановимся на общеизвестной идее, не про systemd: монополия - плохо, возможность выбора альтернативных решений - хорошо.
SELinux не могу рекомендовать, но если она есть (а я пользуюсь Fedora на своём домашнем ноутбуке), то отключать её большого смысла нет. При обычном использовании все необходимые правила прописаны в дистрибутиве.
Это правда. Проблема только в том, что из-за общей сложности для обычного пользователя и даже абсолютного большинства админов управление SELinux сводится к единственному большому тумблеру: вкл/выкл. А качественно (т.е. с учётом её специфики) защитить свою систему одной кнопкой нереально, к сожалению, мир слишком сложен чтобы это работало. Так что спасибо SELinux что он даёт какую-то защиту "из коробки", но это не тот инструмент который нужен желающим адаптировать защиту под свои нужды.
Ну, а IPv6 меня просто заинтересовал.
Было бы интересно почитать серьёзный гайд на тему безопасной настройки IPv6 и сопровождения dual stack конфигурации. С описанием всего, что нужно изменить в настройке ядра Linux для повышения безопасности/конфиденциальности IPv6, какие дополнительные приложения/сервисы рекомендуется установить и как их безопасно настроить, что нужно настроить в файрволе IPv6 специфичного для IPv6 и как в нём учитывать специфику IPv6 при настройке аналога типовых задач файрвола IPv4, какие инструменты/процессы использовать чтобы исключить случайное расхождение настроек файрвола/маршрутизации/etc. между IPv4 и IPv6, … Мне вот такие пока не попадались, а Вам?
А "не переусложнённое" приложение будет работать без systemd? Вот в этом и проблема systemd - он слишком много функционала в себя затянул, и продолжает затягивать (включая вот такой "требующий systemd" совершенно посторонний софт).
А почему я должен тянуть функционал системы инициализации в каждое своё приложение? В чём проблема создать подобный функционал в других системах инициализации? Я просто пишу приложение, которая запускается и дальше в цикле работает. Я не хочу форкать процессы и прочее. Я вообще не хочу в этом разбираться. Я просто хочу чтобы мой исполняемый файл запускался при старте системы и работал. А если вдруг упал (мало ли какие-то данные пришли, которые вызвали ошибку в обработке и процесс упал), чтобы его система перезапустила.
Было бы интересно почитать серьёзный гайд на тему безопасной настройки IPv6 и сопровождения dual stack конфигурации.
Да мне даже гайды по безопасности IPv4 не особо попадались. Это такая обширная тема, что гайд написать по ней очень сложно. Скорее даже невозможно. Этому люди годами учатся.
С другой стороны у нас есть устройства, которые предоставляются пользователям. Производители устройств должны сделать так, чтобы было максимально безопасно. Тут я уже писал комментарий про пароли на админку ADSL модемов. Вы просто не представляете сколько спама летело из Америки с адресов в 2000х, которые у провайдера были прописаны как adsl клиенты. В это же время у меня за 30 дней в ящике гугла в папке спам было больше 6000 писем. По спаму можно было проверять работает ящик или письма не приходят.
В чём проблема создать подобный функционал в других системах инициализации?
Очевидно в том, что они не хотят превратиться в монстрообразный комбайн а-ля systemd.
Будем откровенны: функционала всех остальных систем инициализации вполне хватает для запуска любых сервисов.
А то, что systemd решил предоставить дополнительные уникальные фичи, которые до этого момента не считались нужными для систем инициализации - не делает эти фичи обязательными для всех (иначе, следуя этой логике, все остальные системы инициализации должны реализовывать вообще все фичи, которые решит реализовать systemd).
И решение автора приложения реализовать обязательную зависимость конкретно от уникального функционала systemd - это его личный выбор добровольного вендор-лока и отказ от поддержки в своём приложении тех пользователей, которые не используют systemd. Право сделать такой выбор у автора есть, а вот оснований удивляться, что кому-то может не понравится такой вендор-лок - нет.
И решение автора приложения реализовать обязательную зависимость конкретно от уникального функционала systemd - это его личный выбор добровольного вендор-лока и отказ от поддержки в своём приложении тех пользователей, которые не используют systemd.
Так а в чём проблема просто запускать исполняемый файл через другие системы инициализации? Там уж пусть мэйнтейнеры пакета заботятся о том, чтобы через скрипы демонизировать процесс, сохранить его PID, на случай необходимости остановки, контролируют, что этот файл не завершил работу и завершил, перезапускать. Нет мэйнтейнеров - пользователь другой системы инициализации может написать или попросить кого-то.
российскому руководству
выгодна нехватка адресов.
В пределе, если все абоненты будут сидеть за NAT, они не смогут связываться друг с другом напрямую, а будут общаться только через вконтактики/одноклассники/телеграмчики, а это проще контролировать.
Люблю адекватные теории заговоров, но эта к ним не относится. Если сейчас всем юзерам в РФ выдать белые IPv4, то единственное отличие будет в том, что торренты станут качаться немного быстрее. А пользоваться всеми упомянутыми сервисами никто меньше не станет, равно как не начнётся повальный переход на P2P соц.сети и прочие Mesh сети.
Так кроме прямых ip адресов, ещё и роутер нужно перенастроить или вовсе выкинуть...
Не забываем тот факт, что в IPv4 нет ресурсов даже не на то, чтобы выдать адреса всем нужным устройствам пользователя, но и вообще выдать всем пользователям. На том же Ростелекоме если не заказать статический IPv4, то всё время попадаешь на CGNAT и очень редко тебе выделяют нормальный белый адрес. А вот IPv6 изначально проектировался так, чтобы каждому устройству можно было присвоить отдельный адрес. И торренты, как ни странно, прекрасно качаются с пиров IPv6. Можно даже на клиенте заглушить IPv4 и пользоваться только IPv6.
Не думаю - при наличие отдельного ipv6 адреса на каждом устройстве - сильно упрощается СОРМ.
Я тут перешёл на IPv6... Это адово сложный и запутанный протокол. Попробуйте несчастный IPv6-шлюз (ведь раздавать подсети это так легко и здорово!) на Linux поднять. 99% инструкций просто не правильные! А, уже, как оно в ядре криво сделано... Попробуйте понять, что делает опция net.ipv6.conf.eth0.forwarding ! Там даже в ядре максимально прекрасное объяснение!
Короче, масса боли, проблем и детских болезней.
А чего у них надо отбирать? Военные США изобрели интернет если что ;) Это ихнее детище, изобретение, как хотят так и распоряжаются! Создайте своё что-то и решайте кому давать, у кого отбирать... И назовите это "коллективизация"... В духе СССР)))
Военные США изобрели интернет если что ;)
Это слишком громко сказано -- "военные изобрели".
Максимум -- профинансировали разработку технологии, на развитии которой он потом был построен (не ими).
Вот так в Англии рассуждали. В итоге в один город идёт три параллельных ветки ж/д, и рядом стоят три станции. А в более крупный город в том же регионе - ни одной, и не планируется. В итоге для спасения экономики страны пришлось всё национализировать в 1948, и бардак до сих пор разгребают.
DoD собирались перевести 80% систем на IPv6 к концу 2025 года, правда не ясно насколько им удаётся выполнение графика и простые смертные этих сетей всё равно не увидят - всё скупят гиперскейлеры на аукционах.
Домашний Мегафон, где ipv6?
По словам Уилсона, в 2008 году именно сложности с поддержкой побудили экспертов отказаться от идеи разблокировки 240/4. Тогда специалисты посчитали, что процесс может занять десятилетия. Обновление прошивки потребовалось бы в том числе миллионам маршрутизаторов. Но с тех пор ситуация стала заметно лучше. Специалисты планируют и дальше изучать способы добавить в устройства поддержку нового блока.
Обновить ПО на всём железе, чтобы расширить диапазон IPv4... Или сделать тоже самое, чтобы внедрить IPv6... Мне кажется тут вывод очевиден. Лучше внедрить новый протокол, который избавлен от недостатков предыдущего, ведь всё равно ПО нужно обновлять.
По Вашей же логике, раз уж всё-равно обновлять, почему бы заодно и 240/4 не разблокировать? :-)
А зачем, если старый протокол будет зря использовать ресурсы устройства? Наоборот, от него лучше избавиться как можно скорее. Новый протокол проще при обработке на аппаратном уровне. Его таблицы маршрутизации не так раздуты, как у IPv4 с его мелкими сетями. Да и на будущее есть запас, чтобы эта таблица не росла. А новый диапазон ещё больше сделает таблицу для IPv4, ведь его придётся порезать и раскидать по всему миру.
Основная проблема IPv6 в локалке это человеко нечитаемые ip-адреса, которые к тому же будут привязаны к оператору (поменяли оператора - поменялись все адреса в локалке). Если для IPv4 пользователь может вручную раскидать адреса 192.168.1.x по своим устойствам и использовать все это в локалке без DNS (например wifi 192.168.1.1, принтер - 192.168.1.2 и тд), то с IPv6 так не получится. Придется поднимать DNS. Да, есть локальные адреса, которые из MAC-адреса генеруруются, но они к конкретному устройству привязаны и при смене принтера нужно будет на всех компьютерах его адрес менять.
Попробуйте представить, что нужно сделать SOHO админу, что бы перевести все на IPv6 - там гемороя будет столько, что большинство до последнего будет сидеть на IPv4 + NAT, так как в этом случае любая смена провайдера не потребует вас полностью перенастраивать всю локальную сеть.
человеко нечитаемые ip-адреса
В IPv6 просто гораздо меньше сценариев, которые требуют человеко-читать IP адрес.
которые к тому же будут привязаны к оператору (поменяли оператора - поменялись все адреса в локалке)
RFC 6275 вам в помощь.
, то с IPv6 так не получится.
Это почему вдруг? Прекрасно раздаётся статика хоть по slaac хоть по dhcp6.
Попробуйте представить, что нужно сделать SOHO админу, что бы перевести все на IPv6
Переводил всё на IPv6, вернее на дуалстэк в одной конторе. Ничего более сложного чем поднятие пары демонов на пограничном роутере и некоторых локальных заморочек с pac-скриптом.
Основная проблема IPv6 в локалке это человеко нечитаемые ip-адреса
Скорее наоборот. Те, кто глубоко занимается сетями скорее оценят шестнадцатиричную систему счисления. IPv6 прямо видны в дампах. Ну и кто занимается настройкой сети скорее всего знаком с компьютерами глубже, чем обычные пользователя и для него эта систем счисления не является проблемой. Обычные пользователи и IPv4 адреса всегда вводили с трудом. Я просто какое-то время консультировал людей как исправить неработающий интернет. И там нужно было руками вводить IPv4 адреса. Если там был маршрутизатор с IPv6, то они бы просто получили адрес по SLAAC и ничего вводить не надо было, если их сеть нормально функционировала. А если нет, то там без специалиста не обойтись.
Мой прогноз, что через какое-то время магистрали (и провайдеры) перейдут целиком на IPv6, но внутри локалок еще очень долго останется IPv4 + прокси (IPv4 -> IPv6) на маршрутизаторе.
Пример тому имперская система мер (а так же 110В 60Гц) в США. Весь мир (а так же промышленность) давно на СИ, но человеческая инерция (и капитальные затраты) очень большая для полного перехода на общий стандарт в быту
Это уже происходит. Уже крупные провайдеры имеют сети только с IPv6, а IPv4 предоставляется через 464LAT.
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464XLAT
Пик цен на IP-адреса, государственное регулирование и попытка разблокировать блок 240/4 — что там с переходом на IPv6