Комментарии 244
Если коротко пересказать статью - то что IPv6 представляли как "серебряную пулю" получилось, пока что, как пуля совсем из другого мягкого материала... А еще миллионы (если не миллиарды) сетевых железяк, которые никак IPv6 не поддерживают, и никто их обновлять не будет, за дурные деньги и так далее... В идеале, если с нуля делать, то конечно оно супер будет. Но долго еще сисадмины будут седеть в поисках стабильных решений скрещивания того что есть с IPv6. А так идея, разумеется великолепная... Я про саму концепцию IPv6.
то что IPv6 представляли как "серебряную пулю"
Кто представлял?
А еще миллионы (если не миллиарды) сетевых железяк, которые никак IPv6 не поддерживают
Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6.
Но долго еще сисадмины будут седеть в поисках стабильных решений скрещивания того что есть с IPv6.
Дуалстэк прекрасно работает годами. Отказываться от него пока рано.
"Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6."
как человек с более чем 20-летним опытом и присутствовавший на семинарах RIPE в 2002 и 2003г., где тогда активно обсуждался и продвигался "новый классный протокол", могу сказать : массовой поддержки V6 20 лет назад не было, и в последующие годы тоже не было, тогда она была фрагментарной.
Даже в серьёзном сетевом железе полная (те. не "ой, смотрите, вот у нас что-то запустилось и пакетиуи бегают!") поддержка появилась позднее.
Ну и массовая поддержка V6 в огромном кол-ве сетевых сервисов и софте - это уже 2010е гг., где-то в районе 2015го, +- пара лет.
Причём 100% поддержки нет по сей день.
Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6.
IPv6 NAT у Mikrotik появился в RouterOS7 только (речь про NPTv6 конечно же). Зачем нужен NAT в IPv6? А потому что какой еще нормальный вариант с мультихомингом если нет возможности BGP поднимать с провайдерами?
Про /48 на сайт — ну вы это провайдерам объясните. Которых в рекомендации RIPE тыкаешь что хотя бы /56 надо но им пофиг, хватит клиенту и /64?
Это если IPv6 вообще — есть.
С DNS — если у провайдера есть возможность задавать rDNS для IPv4-адресов, совсем не факт что будет аналогичная возможность для IPv6 хоть в каком то виде.
Вот и получается что проще — туннель до he.net но тут скорость падает.
Все маршрутизаторы уровня чуть выше домашних уже лет как 15-20 умеют в ipv6.
Сетевые железяки - это не только маршрутизаторы. Одна только промышленная автоматика не даст умереть IPv4 при нашей жизни :)
Промышленность и сейчас тащит дремучее легаси, одни 8" диски и установка читающая программу с перфоленты (2019 год!!!) чего стоили. Правда 4 года прошло, может быть их нет в живых уже
Промышленность и сейчас тащит дремучее легаси
Промышленное оборудование работает десятки лет, до последнего вздоха. Автоматика уходит на покой вместе с объектом управления :)) Иногда, конечно, делают миграцию на что-то более свежее. Каждый год-два никто не переписывает на новый стек. Работает - не трогай!
У меня дежа-вю :) В позапрошлый IPv6-срач этой зимой в дискуссии со мной уже кто-то пытался именно в такую подмену тезиса, когда речь зашла об активном сетевом оборудовании с поддержкой IPv6. Мол, такая-то железка не умеет и никогда не научится. Беглое гугление номенклатуры железки показало, что это промышленный контроллер чего-то там.
Я, к сожалению, не могу на этот момент дать ссылку, потому что Хабр опять сломался и лента комментариев в профиле не доступна.
Но суть такова, что никакая промавтоматика не должна торчать голой жопой в Интернет в принципе, ни в 6-й, ни в 4-й. А в корпоративной интрасети вы можете любое легаси поддерживать, хоть IPX/SPX, и там всё равно, какая версия снаружи.
нам не хватает адресов - давайте придумаем протокол в котором выбросим по /64 на каждое устройство, всё равно никто не придумал что с ними делать...
nat навязан устаревшим старым протоколом - давайте вообще избавимся от закрытых сетей, ну а кому надо пусть сам придумывает, что будет фильтровать на границе.
Отличный и продуманный дизайн - впрочем все уже оценили по внедрению.
По поводу первого - категорически несогласен. Как показывает практика, у современных инженеров очень сильно плохо всё с масштабами мышления. Идиотизмы, типа "тысяча адресов на человека будет достаточно" или "640 килобайт хватит всем" или "8 мегов рама - более чем", даже тот же самый UnixTime это полный бред из этой же категории.
Пусть будет /64 уж если что, будем по блоку на планету выдавать в будущем.
По поводу второго - возражений нет.
/64 вполне обосновывается тем, что имея 64 бита можно вписать в адрес любой существующий MAC адрес и гарантированно получить уникальный адрес ни с кем не пересекающийся. В контексте серверов, это позволит сократить размер адреса благодаря тому что вторая часть будет состоять из нулей. А если ещё учесть сеть /48, которую вы можете легко получить, то можно получить очень короткий адрес.
NAT - это костыль, который был придуман для того, чтобы в сеть могли выйти те узлы, которые его не имели. В IPv6 тоже есть NAT и если вы желаете, то можете его использовать. К тому же NAT64 практически делает незаметным отсутствие IPv4 на машине, но за редким исключением, когда IPv4 адреса жёстко вшиты в программу. Но и для этого найдётся свой костыль в виде NAT46, который нужно установить на само устройство или ваш маршрутизатор (который, кстати говоря, уже занимается NAT44). И научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для этой задачи предназначен.
Основная проблема внедрения IPv6 - это нежелание людей разбираться в новом протоколе. Даже если провайдер вам его предоставляет, можно столкнуться с ситуацией, когда IPv6 перестаёт работать. Домашние провайдеры (например, Ростелеком) отказываются чинить баги ссылаясь на то, что они этот протокол не поддерживают, но по факту предоставляют, т.к. это позволяет снизить нагрузку на перегруженный провайдерский NAT. Все эти проблемы не вина протокола, но при этом, конечно, отпугивает новичков.
Уже сейчас можно перевести сеть на IPv6 и спокойно жить. А чтобы получить доступ к ресурсам IPv4 использовать уже знакомый костыль -NAT. Только в отличие от провайдерского NAT для IPv4, нагрузка на этот NAT будет падать по мере внедрения IPv6 и, в теории, вообще необходимость в нём отпадёт.
И научитесь уже использовать файервол для защиты, а не NAT. Файервол как раз для этой задачи предназначен.
Вы это хотите сказать всем пользователям интернета?
Это хочется сказать тем кто с пеной у рта доказывает что без NATа нет защиты...
А пользователям интернета пофигу чеге какой протокол отобразится их любимый вконтактик, хоть голубями пакеты пересылайте ))))))
Вы знаете, я не встречал тех, кто что-то доказывает про NAT. Но встречал тех, кто с пеной у рта доказывает (точнее высказывает), что NAT - это не фаервол. На деле, все домашние пользователи защищаются с помощью NAT.
На деле, все домашние пользователи защищаются с помощью NAT
Очень часто NAT является частью фаерволла (или наоборот??), и как правило во всей домашней и soho мелочи - фаерволл активен по умолчанию. И, домашние пользователи, мало того что ограничили связность через NAT, так ещё и закрыты кроме фаерволла на роутере, часто и фаерволлом isp
Фаервол - это инструмент, который применяет правила. Поэтому нужно смотреть не на фаервол, а на правила.
Например, NAT можно считать фаерволом со следующим функционалом:
закрыть все порты внутри сети;
при наличии исходящего соединения, открыть порт источника только для IP из соединения;
Что, в общем-то, уже очень неплохо защищает пользователей внутри сети. Включая NAT, человек гарантировано получает неплохую защиту.
Если человек полезет настраивать фаервол сам, такой гарантии уже нет. Тем более, что на разных железках правила и интерфейс фаервола может быть разным.
Можно сказать "Не смог настроить фаервол - ССЗБ". Но это очень странная логика. Сначала мы говорим человеку использовать фаервол, а потом потешаемся над ним, если он не смог его настроить.
Домашние пользователи защищаются тем, что им вендор в прошивку роутера впихнул. И всех этих страшных слов как фаерволл и нат они не знают вообще, так что не надо выдавать это за осознанный выбор.
Никто и не выдает это за осознанный выбор. Наверное, стоило написать не "защищаются", а "защищены", чтобы было точнее. Вы же понимаете, что большинство домашних пользователей не будет настраивать фаервол. Так что хорошо, что у них есть NAT.
Да.
Потому что, если вы вдруг забыли, само слово "Интернет" обозначает связность каждый сети с каждой. И эту связность NAT ломает.
"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось невостребованным и сейчас скорее представляет угрозу безопасности, чем то, к чему нужно стремиться. Нет смысла об этом даже вспоминать в мире, в котором интернет обозначает, что ты с телефона можешь заказать пиццу.
Это очень полезное свойство. Хотя бы тем, что дает возможность убрать CGNAT который ресурсы сейчас жрет у многих провайдеров.
Ну и — мессенджерам и им подобным как бы совсем не хорошо через сервер ретранслироватся (что еще и сервер грузит) ну или надо не всегда рабочие схемы обхода NAT'а
"Связность каждый сети с каждой" - это бесполезное свойство,
Да ладно?
Если вы интернетом пользуетесь только для заказа пиццы, то не надо судить о других по себе.
Раз в пол-года на Хабре появляется очередная статья с нытьём о том как у IPv6 всё плохо и как он никому не нужен. Под каждой такой статьёй каждый раз разгорается один и тот же срач с одними и теми же аргументами.
Вот чтобы не повторяться, по поводу невостребованности
https://habr.com/ru/articles/711444/comments/#comment_25130512
"Связность каждый сети с каждой" - это бесполезное свойство, которое оказалось невостребованным
Ага-ага, скажите это всем разработчикам, которым приходится изобретать NAT hole punching на свой лад, как только понадобится сделать что-то peer-to-peer.
Дело в том, что эти приложения довольно нишевые и их проблемы особо никому не интересны, особенно учитывая то, что эти проблемы решаемые. Облегчение работы несущественного числа разработчиков - точно не драйвер перехода на IPv6.
Здравствуйте! Извините, что здесь спрашиваю...
Делал настройку по вашей статьте "Shadowsocks-2022 & XRay (XTLS) сервер с простой настройкой и приятным интерфейсом"
Всё завелось! Есть проблема с доступом к панели: попробовал сделать доступ с "виртуального" IP, вместо возни с сертификатами, как в 3 варианте ( раньше заходил так - http://IPсервака:порт/URL/).
Добавил в /etc/network/interfaces следующую запись:
iface lo:1 inet static
address 192.88.99.1
network 192.88.99.0
netmask 255.255.255.0
В настройках панели указал IP 192.88.99.1. Панель из вне - стала не доступно, как и ожидалось... .
Подключаюсь к сети через Shadowsocks (в NekoBox только его пока настроил) - инет есть, всё работает. IP сервера через whoer светится.
Вбиваю строку в браузере - http://192.88.99.1:порт/URL/ - Вообщем, в панель попасть теперь не могу. Что не так?
Спасибо за подсказку и сорри за глупые вопросы (только вникаю, в связи с известными событиями)!
Система Debian12 у меня.
Так это Интернет. Домашний роутер с публичным IP адресом - вполне себе часть этого интернета. А в квартире у человека Интранет. Там полная связность только внутри квартиры. А с Интернетом связность избирательная.
Вы путаете причину и следствие.
Border gateway как концепция одинаково хорошо работет и на основе NAT и на основе файрволла, первый вариант больше распространён исключительно и только из-за истощения адресов, у него никакого технологического преимущества нет, скорее даже наоборот.
У него есть преимущество в том, что он дает хорошую защиту из коробки. А фаервол еще надо настроить. Нет гарантии, что во всех домашних роутерах он хорошо настроен из коробки.
У него есть преимущество в том, что он дает хорошую защиту из коробки. А фаервол еще надо настроить.
Не понял, почему файрвол не может давать хорошую защиту из коробки? Какой такой волшебник настраивает NAT хорошо, но не может настроить файрволл так же хорошо?
Нет гарантии, что во всех домашних роутерах он хорошо настроен из коробки.
А есть гарантия, что во всех домашних роутерах NAT хорошо настроен из коробки?
С этим все просто. По счастливой случайности, NAT by design обладает свойствами хорошего фаервола:
Закрыть все компьютеры внутри сети от атакующих снаружи;
При наличии исходящего соединения, сделать динамическое разрешающее правило только для IP из этого соединения;
Получается система, которую не нужно настраивать. Нет настроек - нет проблем :-)
Фаервол можно настроить так же. Но нет гарантии, что фаервол в каждой железке и на каждом компьютере настроен таким образом. На деле всплывает проблема человеческого фактора. Во первых, фаервол из коробки где-то может и не иметь таких правил. Во вторых, его могут неправильно настроить. В итоге фаервол как бы есть, но не защищает.
На самом деле я не против фаерволов. И я не говорю, что все фаерволы нужно заменить с помощью NAT. Просто исторически получилось так, что NAT, кроме своей функции, еще и не дает атакующим добраться до компьютеров внутри. Для многих людей этого оказалось вполне достаточно в плане безопасности.
Вы занимаетесь абсолютно произвольными допущениями, не основанными ни на чём, кроме ваших же предпочтений и привычек.
На каждое ваше «нет гарантии, что...» я могу заявить, что а) нет и гарантии обратного, и б) нет гарантии, что предлагаемое вами решение не страдает теми же недостатками.
В целом же, мне представляется более логичным использовать инструментарий по назначению.
не основанными ни на чём, кроме ваших же предпочтений и привычек.
А вот это уже ваше допущение) Я основываюсь на своем опыте. И сейчас я поделюсь им с вами.
Возьмем роутеры от разных компаний и посмотрим на функционал их фаерволов.
Вот документация к роутеру D-Link DIR-X1860: link.
Со страницы 230 начинается описание веб интерфейса для управления фаерволом. Там много настроек, но все они позволяют создавать только статические правила. То есть, нет динамических правил, которые реализованы в NAT.
Вот документация к роутеру D-Link DIR-842: link.
Со страницы 200 идет схожее описание управления фаерволом. Опять таки, они статические правила.
Вот ссылка на страничку FAQ компании Asus, с описанием их фаервола: link.
Там много разных настроек, но они скорее про то, чтобы закрыть пользователю доступ куда-то снаружи.
Справедливости ради, можно посмотреть на фаерволл в OpenWRT: link.
И вот там-то динамические правила можно настроить. Но просто потому, что тот фаервол - некая обертка над iptables, где все это есть.
Поэтому, когда мне говорят про фаерволы в роутерах, мне это видится, как очень урезанная штука, сделанная для галочки.
А еще есть роутеры "от провайдера", которые провайдер ставит клиентам. И очень часто клиенты даже не имеют там доступа в веб интерфейс. Поэтому они даже имеющийся фаервол не могут использовать.
Поэтому, говоря "нет гарантии, что есть фаервол", я немного лукавлю. Скорее можно утверждать, что в большинстве случаев у людей нет нормального фаервола. Зато есть NAT. Поэтому, имеем то, что имеем)
Прекратите распространять FUD. В том же самом роутере уже есть фаервол.
Конечно же, NAT - это не средство безопасности. Но если из сотни серверов мне нужно сделать доступными из Интернета штук 5, я вовсе не хочу, чтобы любой мой внутренний IP (IPv6) маршрутизировался и был доступен извне, и условная MongoDB стала публично доступной из-за малюсенькой ошибки в правиле на фаерволе.
Даже имея сеть класса C мне в голову не придет каждому из сотни серверов выдать по публичному IP. Я либо кусочек сети с публичными адресами замаршрутизирую в DMZ, либо даже DMZ серверы сделаю доступными извне через NAT. И уж точно серверы, которые не должны быть доступными из Интернета, буду выходить в Инет через NAT, но ни в коем случае не быть на публичных маршрутизируемых адресах. А-ля NAT66 (хотя мне казалось,что он в очень незрелом состоянии).
Для меня идеально иметь внутри сети IPv6 и не думать об адресах, а "снаружи" - IPv4. И пусть фаервол имеет не только политику с правилами доступа, в которой можно случайно открыть огромную сеть, но и делает Static NAT из IPv4 в IPv6 только для "избранных".
Клиенты мобильных операторов (и ряд других кейсов), разумеется, отдельная песня.
Если у вас во внутреннем контуре IPv6, то какой? И почему не site-local?
Я отвечал на "NAT - это костыль", пытаясь показать, что даже при использовании IPv6 всем серверам и устройствам выдавать публично маршрутизируемые адреса - не лучшая идея. NAT все равно не повредит, с ним безопаснее будет.
Если же использовать site-local - тем более без NAT не обойтись. И точно так же можно столкнуться с тем, что "купили компанию, надо объединять сети, а там совпадает адресное пространство".
Нет уж. Я бы регистрировал свой IPv6 блок, но использовал его внутри, в Интеренет не маршрутизировал, а наружу выпускал бы через NAT.
Нужно только помнить, что NAT - это не firewall. И он в любом случае нужен.
Высшее достижение NAT-строения - Carrier grade NAT у сотовиков. Врагу такого не пожелаешь.
Безусловно. Я вообще за эшелонированную защиту.
Интернет-фаервол - DMZ - Другой фаервол - бэкбон - ЦОД фаервол - серверные сегменты
Причем на Интернет фаерволе даже маршрутов в сторону "корпоративной сети" нет. Он только про DMZ сети знает.
Где бы и кто бы ни ошибся - внутренний сервер из ЦОД не окажется внезапно exposed.
А что не так с cgnat?
A что не так с cgnat?
Я сам не сисадмин, но вроде как все файерволлы из коробки блокируют все, что не разрешено? Тот же ufw.
Если вы зачем-то разрешили in на порт mongodb, то это ССЗБ.
Не поставили файерволл — ну, в общем-то, тоже.
А у домохозяек он как бы из коробки. Если только знакомый-вредитель им не поставил говносборочку с вырезанным "ненужным" брандмауэром windows...
ufw - локальный на сервере. Там порт монги открыть придётся, иначе к ней никто из локалки не сможет подключиться. Вопрос в том, чтобы теперь на этот открытый порт никто из инета не пришёл - а это уже должно делаться не в ufw сервера монги, а на роутере. И настройка файрвола этого роутера с введением IPv6 заметно усложняется, т.е. растёт и вероятность ошибок. В результате в среднем защита в сетях IPv6 получается ниже. Не потому, что её невозможно сделать (почти) идентичной, а потому, что людям свойственно совершать ошибки и чем больше возможностей для ошибок система предоставляет тем больше ошибок будет совершаться - а IPv6 возможностей для ошибок предоставляет заметно больше.
а это уже должно делаться не в ufw сервера монгиНо почему? Просто даете allow in со всех локальных адресов (можно подсетью) и дело с концом. Я так и сделал.
Вообще для всех 192.168/172.16/10.0 разрешили? Ну чтобы не заморачиваться, когда новый филиал открывается. Не будете же вы при такого рода изменении в сети по десяткам серверов бегать и правила ufw менять.
Если то, что при таком подходе партнерские организации, контракторы всякие имеют к нему свободный доступ, не смущает, можно и ufw ограничиться.
Очевидно же почему: потому что не стоит прошивать инфу "какие адреса в нашей локалке" на каждом отдельном сервере, иначе при изменении архитектуры сети замучаемся это на каждом сервере исправлять. И уж тем более не стоит прошивать на сервере инфу "а кто имеет доступ к этому сервису" в виде списка конкретных адресов, по аналогичной причине.
Доступ можно контролировать либо на уровне подсетей (все сервера в подсети имеют доступ ко всем сервисам в этой подсети) либо на уровне логики авторизации конкретного сервиса либо на уровне файрвола между подсетями на роутере (для доступа между подсетями). Всё остальное создаёт слишком много сложностей в поддержке.
"Просто поверьте, у нас не всё так однозначно" (С) мем
Мой опыт и то с чем столкнулся. Провайдер выдает IPv6 - все ок. Микротом пробросилось, все счастливо работает. Местами даже блокировки обходятся.
Проблема 1 - статичный IPv6. С IPv4 понятно, вот мой DHCP-сервер, вот создал запись, вот я знаю что 88.10 - это телевизор. IPv6 - SLAAC. Т.е. мне надо вкорячить DHCPv6 между мной и провом. И тут надо погружаться и становиться админом чтобы эт все настроить. Не погружался, но кажется микрот до сих пор так не умеет (если умеет нужна ссыль).
Проблема 1.5 - вы же в курсе что win10 (на других не проверял) для того чтобы "обезопасить" и "анонимизировать", каждый раз запрашивает temporary IPv6 адреса? Звучит как костыль, выглядит как костыль, ведет себя как костыль, значит перед нами костыль. (да, отключаемый, но збс - надеяться что ты выключишь ПК быстрее чем кто-нибудь сумеет воспользоваться какой-нибудь уязвимостью)
Проблема 2 - решение которой лично я не нашел. Windows firewall по дефолту блокирует не все. По этому если представить ситуацию что FW на роутере по умолчанию разрешает какие-то входящие, то можно получить сканером портов. А теперь думаете домохозяйки и прочие геймеры будут запариваться с FW на маршрутизаторе, FW на ПК? Сидеть и думать че-куда там пробросить надо? Да все жмакнут Allow, лишь бы запустилось и все.
Проблема 2.1 - Если проблему 1 маршрутизатор решить не может, то и публиковать внутренние ресурсы наружу становится невозможно. Т.к. надо будет или открывать доступ ко всем или после ребута можно получить смену IPv6 и тыкву вместо сервиса.
Проблема 3 (надуманная) - правила FW IPv4 я могу протестировать хоть с мобилки. А вот IPv6 нифига, кроме моего провайдера никто не дает. Как итог - настроил, работает, а вот чего открыто, как FW работает, не протестить. Надо идти в AWS (ну или любое другое облако) и брать инстанс с IPv6. Так каждый раз. =\
по дефолту блокирует не все.ЕМНИП, все что откровенно не нужно из коробки, там запрещено.
то можно получить сканером портов.Сканером портов ты в любом случае получишь, если есть разрешение на входящие подключения. Сам по себе он безвреден.
Ну вот открыт у меня (ныне пустующий) 27015, и что вы с ним сделаете?
Сидеть и думать че-куда там пробросить надо? Да все жмакнут Allow, лишь бы запустилось и все.Разве Windows Firewall делает запросы на входящие подключения? Вроде только при первом запуске, причем там по умолчанию стоит запрет для «общественных сетей», которыми по умолчанию являются все.
Сам по себе он безвреден. Ну вот открыт у меня (ныне пустующий) 27015, и что вы с ним сделаете?
Ну вот веду я разработку чего-нибудь и в своем домашнем, ламповом окружении. Да еще и с каким-нибудь старым легаси софтом из 2008 года к которому патчи безопасности выпускались примерно никогда. За NAT'ом можно открыть все. C IPv6 вы не можете спокойно работать с БД и паролем pa$$word. Т.е. вместо быстрого прототипирования у вас появляется задача даже дома, даже для тестового стенда настрой нормальную безопасность (FW как минимум). Это не проблема если вы администратор, а если инженер-проектировщик? Да в таком случае вы даже про security-patch можете ничего не знать.
Разве Windows Firewall делает запросы на входящие подключения?
В нем есть пучек стандартных правил, во-вторых когда приложение просит дать доступ, оно как бы не пишет чего-кому-куда. Считается что дома оно вам не поможет т.к. вы пользователь, а в организации у вас есть политики и админы.
Бонусом, иногда проще отключить FW, чем потратить полдня на выяснение а что же софту надо ради 10 минутной работы.
Проблема 1 - статичный IPv6. С IPv4 понятно, вот мой DHCP-сервер, вот создал запись, вот я знаю что 88.10 - это телевизор. IPv6 - SLAAC. Т.е. мне надо вкорячить DHCPv6 между мной и провом.
У телевизора внутри сети есть link local address, который всегда одинаковый.
Проблема 1.5 - вы же в курсе что win10 (на других не проверял) для того чтобы "обезопасить" и "анонимизировать", каждый раз запрашивает temporary IPv6 адреса?
Не запрашивает, а генерирует случайным образом.
Permanent address всегда остается, и используется для входящих подключений.
Это не проблема, а фича, чтобы не раскрывать permanent address.
Проблема 2 - решение которой лично я не нашел. Windows firewall по дефолту блокирует не все. По этому если представить ситуацию что FW на роутере по умолчанию разрешает какие-то входящие, то можно получить сканером портов.
Чтобы получить сканером портов, нужно, чтобы злоумышленник знал ваш permanent address. Это не так чтобы невозможно, но хотя бы тупым сканом всего адресного пространства уже не обойтись.
Проблема 2.1
Она в том, что провайдер выдает каждый раз новый префикс? Конечно, чтобы открывать сервисы наружу, нужно заказать статический префикс. В IPv4 ведь также?
Проблема 3 (надуманная)
Это не проблема протокола :)
Это не проблема, а фича, чтобы не раскрывать permanent address.
...
Чтобы получить сканером портов, нужно, чтобы злоумышленник знал ваш permanent address.
Я не говорил что это проблема, я говорил о том что это выглядит как костыль =) причем весьма сомнительный, т.к. это поможет от снифферов, но если пользователь зайдет на сомнительный сайт, то как бы вот IP - скань\используй уязвимости\DDoS'ь. Да, до ребута. Но и этого может хватить.
Еще раз, не силен в IPv6, но где гарантия что в FW для temporary address что-нибудь не будет открыто? Ну т.е. in microsoft we trust?
У телевизора внутри сети есть link local address, который всегда одинаковый.
Тут вопрос скорее был про публикацию (разрешение на FW) одного ресурса из локальной сети - скажем SSH'а или http(s). Или наоборот полный запрет на выход в интернет устройству.
Она в том, что провайдер выдает каждый раз новый префикс?
Не, префикс выдается один и тот же. Но у меня каждый раз устройства получают новые IPv6, т.е. я не могу прописать allow IPv6:80
Это не проблема протокола :)
Не проблема протокола, но проблема отладки, что не добавляет привлекательности
Еще раз, не силен в IPv6, но где гарантия что в FW для temporary address что-нибудь не будет открыто? Ну т.е. in microsoft we trust?
Я согласен, что на windows firewall не стоит полагаться, но в норме у вас на роутере стоит запрет на forward из WAN в LAN, кроме отдельных явным образом открытых портов.
Насчет микротиков не помню, там возможно по умолчанию нет вообще никаких правил файрвола для IPv6. Но микротик все-таки предполагает, что пользователь немного админ :)
Тут вопрос скорее был про публикацию (разрешение на FW) одного ресурса из локальной сети - скажем SSH'а или http(s). Или наоборот полный запрет на выход в интернет устройству.
Если у вас префикс выдается один и тот же, то и перманентные IP-адреса устройства получают по SLAAC одни и те же, вычисленные по их MAC-адресам. Они не должны каждый раз получать новые IP.
Они не должны каждый раз получать новые IP.
Да, но по факту нет =)
Windows
Пример с Win10, мак - C8-5B-76-E6-B1-9C
Ну и в целом смотрите картинку, там по МАКу выдан только 1 IPv6
Ethernet adapter vEthernet (LAN):
Connection-specific DNS Suffix . : *owl.ru
Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter #3
Physical Address. . . . . . . . . : C8-5B-76-E6-B1-9C
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : ****:****:****:****:8b21:b090:bed4:b6b2(Preferred)
Temporary IPv6 Address. . . . . . : ****:****:****:****:c82:8706:1b6f:cf2b(Preferred)
Link-local IPv6 Address . . . . . : fe80::b64c:ad:bf05:b58a%23(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.88.112(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : 14 августа 2023 г. 22:47:56
Lease Expires . . . . . . . . . . : 16 августа 2023 г. 22:57:56
Default Gateway . . . . . . . . . : fe80::66d1:54ff:fe68:53ee%23
192.168.88.1
DHCP Server . . . . . . . . . . . : 192.168.88.1
DHCPv6 IAID . . . . . . . . . . . : 1254644598
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-2A-D4-0A-CB-C8-5B-76-E6-B1-9C
DNS Servers . . . . . . . . . . . : 192.168.88.1
Primary WINS Server . . . . . . . : 192.168.88.1
NetBIOS over Tcpip. . . . . . . . : Enabled
Вы говорите в категориях DHCP, где адреса "выдают". При использовании SLAAC их не выдают, а устройство, зная префикс /64, само их генерирует на свое усмотрение в любом количестве.
Один из адресов всегда генерируется детерминированными образом, и остается одинаковый. По нему вы открываете файрвол для входящих соединений.
Остальные случайные, используются для исходящих содинений.
Есть два способа генерации детерминированного адреса:
EUI64, по мак-адресу (RFC 4291). Телевизор, скорее всего, воспользуется этим способом. В linux-системах этот метод обычно стоит по умолчанию, и он удобнее, если у вас в сети сервер, который вы хотите вывести наружу.
Stable privacy (RFC 7217) — как хэш от стабильных параметров системы. Вот этот адрес, :8b21:b090:bed4:b6b2, он должен быть детерминированным, но поменяется при переустановке системы, а также зависит от префикса сети и используемого сетевого интерфейса. В винде и MacOS по умолчанию такой метод. Не исключаю, что в hyper-v он работает не совсем так, как надо. Если нужно больше предсказуемости, то это можно отключить (google: windows disable stable privacy.
P.S. Создание временных адресов тоже можно отключить, если не нравятся.
IPv6 - SLAAC. Т.е. мне надо вкорячить DHCPv6 между мной и провом. И тут надо погружаться и становиться админом чтобы эт все настроить. Не погружался, но кажется микрот до сих пор так не умеет (если умеет нужна ссыль).
Не надо ничего вкорячивать. Грамотные реализации slaac такие как radvd, умеют выдавать статические адреса, если настроить.
Проблема 1.5 - вы же в курсе что win10 (на других не проверял) для того чтобы "обезопасить" и "анонимизировать", каждый раз запрашивает temporary IPv6 адреса? Звучит как костыль, выглядит как костыль, ведет себя как костыль, значит перед нами костыль.
Это не костыль, это фича.
Причём фича, предписанная стандартом — RFC 4941
Предназначена она да, для приватности — чтобы не палить кому не попадя основной адрес, исходящие коннекты делаются с временного.
Проблема 2.1 - Если проблему 1 маршрутизатор решить не может, то и публиковать внутренние ресурсы наружу становится невозможно. Т.к. надо будет или открывать доступ ко всем или после ребута можно получить смену IPv6 и тыкву вместо сервиса.
Может. Но если бы и не мог, то в v4 всё то же самое.
Грамотные реализации slaac такие как radvd, умеют выдавать статические адреса, если настроить.
И как это вкорячивать в IoT, windows и synology (для примера)?
Это вкорячивается со стороны роутера, а не клиентов.
https://wiki.mikrotik.com/wiki/Manual:IPv6/ND
Windows и Synology умеют в Ipv6 из коробки.
И уж точно серверы, которые не должны быть доступными из Интернета, буду
выходить в Инет через NAT, но ни в коем случае не быть на публичных
маршрутизируемых адресах.
Почему? В чём преимущество использования NAT для этого сценария, по сравнению с обычным firewall с блокировкой входящих соединений?
В человеческом факторе.
Что нужно, чтобы открыть доступ к серверу на публичном адресе? Чуток поменять правила. Они же не статичные. Не тот хост добавил в разрешенные.. Хотел дать доступ только из ЛВС, а сдуру открыл из Интернета... Не то drop правило удалил или просто перетащил выше этого блокирующего... Сетку с разрешениями указал /28 вместо /29... Когда в политике сотни правил такое легко может случиться. Я уж молчу про "случайную ошибку маршрутизации в обход фаервола", особенно при наличии всяких резервных каналов.
А вот если действительно хочешь опубликовать ресурс с приватного адреса в Инете, надо дополнительно к фаервольским правилам еще явным образом Static NAT сделать. Причем выбрать не задействованный под другие серверы. Это уже напрячься надо, не просто "рука дрогнула".
Повторюсь, NAT сам по себе - не средство безопасности. Как и маршруты, VLAN и многое другое. Можно обойтись и без него. Но он дополнительно уменьшает риски в случае человеческой ошибки. С ним нужно больше ошибок совершить для бадабумса (хотя это отнюдь не значит, что с NAT вы в полной безопасности).
Случайно залезли в роутер и случайно открыли доступ снаружи к внутреннему девайсу? Не несите бред.
Давайте быть последовательными. Степень распространения IPv6 определяется отнюдь не домашними пользователями, действующими по принципу "включил и забыл", а компаниями. Поэтому я рассматриваю кейсы применения IPv6 именно в организациях.
"Настрою-ка я у себя дома IPv6, чтобы сделать холодильник доступным из Интертнета" - с такими кейсами не ко мне.
Какой смысл вообще в локальной сети иметь ipv6?
Мой кейс: туннель с Микротика IPv6 через IPv4 в Hurricane Electric. Т.е. точка выхода "там".
IPv6 в локалке (в т.ч. на мобилке). Dual Stack.
Фейсбуки с Линкединами имеют адреса IPv6. К ним по умолчанию и иду по IPv6. Никакого VPN не требуется.
Всякие РБК/Госуслуги адреса IPv6 не имеют, к ним доступ с Российского IP. Никаких постоянных приседаний "туда пойти включи VPN, сюда пойти выключи VPN".
Один раз настроил такое извращение, и забыл. Понятно, что кейс не станадртный, и не для того IPv6 придумывали :)
А если серьезно - сплошь и рядом при объединении компаний с "приватными адресами в ЛВС" происходят пересечения адресных пространств и нужда в NAT даже в локалке. Причем это не обязательно слияние больших компаний (дело относительно редкое). Но и условное поглощение нефтяной компанией какой-нибудь местечковой сети заправок...
Купив свой блок IPv6 можно быть уверенным, что ни с кем потом не пересечешься.
Да, пересечение сеток это резонный аргумент. Буквально на прошлой неделе решал этот же вопрос. Учитывая, что люди умудряются занять и зарезервировать себе адреса c /8 и /16 - этот кейс весьма вероятен. Но я бы честно побоялся переводить, хз как тот или иной софт будет с этим работать и какие подводные камни, нет компетенции в работе с ipv6.
По поводу блокировок кто как не извращается. Я вот сейчас пытаюсь на заблокированные адреса делать реверс прокси стримом из впс, с подменой адресов на днс сервере на реверс прокси. Чтобы со стороны пользователя было прозрачно.
Фейсбуки с Линкединами имеют адреса IPv6. К ним по умолчанию и иду по IPv6. Никакого VPN не требуется.
Не знаю что за у вас провайдер, но туннелированный траффик тоже уже давно фильтруется. Ну, может быть провайдеры без IPv6 этим не заморачиваются.
Вот у меня есть конкретный пример, когда нужен NAT для ipv6.
Имею 2 4to6 туннеля, один в рф, другой не в рф. Хочу, чтобы сайты из рф ходили через туннель в рф, остальные через второй.
Без NAT имею, что каждый девайс в сети имеет по два IPv6 адреса и с какого source IP пойдет запрос - вообще не угадать. И через какой туннель уйдет запрос - тоже не угадать (а туннели вредные, если пакет идет не с их source IP, то пакет дропается).
С NAT это решилось бы легко и просто маршрутами на роутере. Как решить это без NAT - идей никаких.
upd: для конторы со своей AS все решается с помощью BGP. Для дома BGP не вариант.
"и с какого source IP пойдет запрос - вообще не угадать", но это вы просто не умеете его готовить. В системе тоже есть маршрутизация для source interface. В Linux через route tables.
Но настраивать маршрутизацию на каждом телефоне-телевизоре тоже не дело. Такое должно на роутере настраиваться.
Есть. Но вот только как быть в ситуациях когда устройство есть. Даже может быть с Linux. Но вот консоли нет (кроме разве что отладочного UART внутри корпуса). Подразумевается автонастройка приложением умного дома. Не опенсорсным конечно же.
Вот у меня есть конкретный пример, когда нужен NAT для ipv6.
Да кто ж вам NAT запрещает то? Я бы, пожалуй, вашу задачу тоже бы с ходу решил через NAT. На устройствах пользователей основной IPv6 от провайдера. А на шлюзе маршрутизация нужных адресов в нужный туннель, на конце которого NAT с его собственной адресацией. При чём транслировать можно адреса 1:1, а значит даже состояние не нужно запоминать для соединений.
NAT плох там, где его рассматривают как средство обеспечения защиты сети, хотя он им не является. К тому же, повсеместное применение его приводит к неявному отказу от главного принципа Internet: сквозной прозрачности на сетевом уровне [RFC 2775], когда любой хост А может послать пакет IP любому хосту Б (где А может быть равно Б). В вашем варианте, кстати, сквозная прозрачность нарушена, так что почему бы в этом случае не использовать NAT как средство обхода проблемы.
Имею 2 4to6 туннеля, один в рф, другой не в рф. Хочу, чтобы сайты из рф ходили через туннель в рф, остальные через второй.
В случае IPv6, ваша проблема легко решается через nftables. Выдавать 2 IPv6 нет смысла, выдавайте один любой IPv6 (даже локальный) и просто меняйте у него префикс сети.
Оба ваших туннеля должны поддерживать маршутизацию всей /64 подсети.
Определите список подсетей из РФ (2001:640::/64, 2001:6d0::/64, ... ) и настройте маршрутизацию этих адресов через интерфейс туннеля при помощи команды:
ip -6 route add 2001:640::/64 dev TUNNEL_RUSВ файле конфигурации nftables определите переменную, которая будет содержать набор подсетей из РФ:
define rus6 = {2001:640::/64, 2001:6d0::/64, ...};Создайте правило подмены префикса адреса отправителя:
chain post_rus {
type nat hook postrouting priority 0;
ip6 daddr $rus6 snat ip6 prefix to <prefix-of-rus-tunnel>::/64;
}PROFIT!
Для реализации задумки, достаточно любого роутера под управлением OpenWRT
Вы в самом деле думаете, что все MAC-адреса уникальны?
У меня как-то был в локалке компьютер, у которого MAC-адрес совпадал с MAC-адресом сетевого принтера. Было весело.
Как-то поставили нам несколько терминалов для бесконтактных пропусков. У двух из них были одинаковые MAC-адреса. Убил 5 часов на поиск плавающей нестабильности их функционирования. Думал, что я сошел с ума. Они как бы работали, но не всегда.
Как админ локалхоста могу сказать , что "нежелание людей разбираться" вполне объяснимо.
Разрыв сложности между привычным ipv4, который просто как два пальца и его понимают даже не специалисты и ipv6 - просто огромен. Новые концепции, куча режимов, магия. Сколько раз пытался осилить ipv6, так и не смог.
На сколько помнится, по стандарту /64 дается на подсеть. А там уже либо DHCPv6 с выдачей рандомных/последовательных адресов как в DHCPv4, либо SLAAC.
IPv6 это отличная замена, и уже почти полностью рабочая. Однажды я что-то тестировал на компьютере, отключил IPv4 и забыл про это, а потом несколько дней сидел не замечая. Только после того как заметил что некоторые редкие сайты перестали открываться вспомнил.
некоторые редкие сайты перестали открываться
Ну не такие уж и редкие. В России большинство сайтов не имеет IPv6. Да что там, далеко ходить, даже Хабр не имеет IPv6 адреса! Но если у вас был доступен DNS64+NAT64, то вы вполне могли не заметить отсутствие IPv4 на вашей машине. Знаю только одно приложение, которое не умеет в IPv6 сеть - это Steam. Видимо у него внутри вшиты IP адреса серверов. Но и это лечится путём запуска NAT46 непосредственно на вашей машине.
А вообще слышал, что Европейские провайдеры уже строят свои сети только на основе IPv6. Но ведь клиенты будут недовольны, что у них доступа нет? А вот и нет. Используется технология MAP-T. При этом сеть провайдера полностью построена на IPv6. Весь пул адресов они выделяют для NAT64. Один IPv4 адрес они делят между несколькими абонентами. Каждому выделяется определённое количество портов. При чём связь используется статичная, т.е. не нужно сохранять даже состояния соединений. На клиентской же стороне маршрутизатор по классике даёт какую-то серую сеть, типа 192.168.1.0/24 или аналогичную. А все соединения с серверами IPv4 направляются не на обычный NAT, а NAT46, который использует только строго выделенный диапазон портов, который согласован с набором на NAT64 у провайдера. Т.е. схема получается почти аналогичная тому, что есть сейчас с IPv4, только трафик между маршрутизатором клиента и NAT провайдера теперь идёт по IPv6. К тому же теперь провайдерскому NAT не нужно следить за состоянием соединений, т.е. он становится менее требователен к железу. Нагрузка на этот NAT будет постепенно снижаться ввиду того, что больше ресурсов будет доступно по IPv6 напрямую.
Про провайдеров верно, туннель на IPv6.
Мне интересно, что творится, когда размер IPv4 пакета проходит около MTU сети? IPv4 MTU искусственно занижен или пакеты фрагментируются на стороне провайдера?
Да что там, далеко ходить, даже Хабр не имеет IPv6 адреса!
У hsto.org есть.
Но это, судя по всему, какой-то побочный эффект а не сознательное внедрение.
Проблема открытости/закрытости внутренней сети высосана из пальца. Какая разница будет ли на пограничном устройстве nat или `ip deny any any` на вход?
давайте вообще избавимся от закрытых сетей, ну а кому надо пусть сам придумывает, что будет фильтровать на границе.
Вот каждый раз меня это тригеррит. NAT -- это не замена фаерволу.
а с чего столько людей стриггерилось на нат если речь про четко описанный в статье посыл "я не утверждаю что закрытые сети не нужны совсем, но это навязанный дизайн и на самом деле они вам не нужны" ?
при этом нат это конечно не фильтр, но средство изоляции сетей, что не однократно тут же в комментариях подтверждается
при этом нат это конечно не фильтр, но средство изоляции сетей
Потому что NAT это не средство изоляции сетей. Для изоляции как раз и придуман фаервол, и нормальный дизайн сети как раз предусматривает настроенный нормально закрытый фаерволл, а NAT, как следует из его названия, это механизм трансляции адресов.
можно сколько угодно триггериться от того что кто-то забивает шурупы молотком, но это не изменит существующей реальности
точно так же как и те кто признают, что нат мешает связности и придумывают средства пробивки нат почему-то думают, что фаерволы у юзер роутеров в дефолтных конфигах разрешат подключаться их в6<->-в6 приложухам без проблем
судя по темпам внедрения многие из нас этого всё равно не застанут :D
ждем дальше. когда все провайдеры переползут тогда и нам можно будет
Ну, на самом деле не всё так плохо. Внутренние сети поднимать на ipv6 - одно удовольствие. Получить адрес в ARIN? Занимает один день. У вас свой блок на пару ***-ардов адресов. Пожалуйста, по ссылке. https://www.arin.net/resources/guide/ipv6/first_request/
Сделаться провайдером? Не проблема.
Майкрософт не шелохнулись, чтобы ввести IPv6 на своих сетях? Оханьки и ухоньки. Естественно. И фиг с ними.
Обновления дебиана? Отлично обновлялся.
Настройки оборудования и маршрутов - одно удоволсьвие. Там, конечно не без приколов, но работает.
Я разрабатывал сеть для VDS провайдера. Для клиентов в конце концов на внутренних хостах поставили нат наружу для их же обратной совместимости. Но это тем, кому надо было. Сама система - вся на IPv6.
Ничего, переживём.
Протокол IPv6 не поддерживается ни моим домашним провайдером, ни рабочим.
Это, надо полагать, типичная ситуация вообще в мире, а не только локально у автора. Почему провайдеры не поддерживают IPv6? Потому что это не нужно клиентам - единичные энтузиасты не в счет, а поддержка стоит не только человекочасов, но и может потребовать аппаратного апгрейда. И ради чего, если у всех и так все работает? Дефицит белых адресов? Да неважно, будет больше слоев NAT.
К слову о NAT. Даже бытовой роутер является довольно эффективным экраном между этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего существования исключая значительное количество векторов атаки. Сказать по правде, я не уверен, что бытовой роутер с еще одним NAT это хуже, чем если все эти умные (умные, серьезно?) чайники и умные утюги будут смотреть наружу напрямую - с их-то пресловутой склонностью вступать в ряды ботнетов или по мере своих скромных вычислительных возможностей что-то там майнить, ведь пусть один чайник много не намайнит, но миллионы впараллель это же уже вполне себе сила.
Дефицит адресов объективен. Все остальное оказалось никому не нужно. Пора пилить IPv7, который будет полностью повторять известный IPv4 с единственным расширением - с еще одним, двумя, или сколько там решат достаточным октетами для описания пространства адресов и полной, насколько это возможно, совместимостью с IPv4, чтобы имеющееся оборудование продолжило работать без изменений ближайшие хотя бы лет двадцать, а новое просто имело больше возможностей. Чтобы у кого есть поддержка могли использовать новые диапазоны адресов вместе со старыми напрямую, а у кого нет - работали только со старым диапазоном, а новые - только через NAT.
Это зависит от страны. Equinix поддерживает IPv6 во всех своих зонах. Кстати, погуглите кто это такой.
А в Лос-Анджелесе местные провайдеры уже давно прокидывают IPv6 с настроеным сверху натом для IPv4 трансляций.
Даже бытовой роутер является довольно эффективным экраном между этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего существования исключая значительное количество векторов атаки
В этом же самом бытовом роутере есть бытовой фаерволл, который включением одной галочки (причём включенной по умолчанию) прекрасно защищает все ваши чайники и утюги.
Полностью согласен на счет необходимости переходить на IPv7/IPv8, а IPv6 следует похоронить как можно скорее.
IPv6 - это явный пример overengineering-а - вместо того, что бы банально увеличить битность адреса, создатели IPv6 попытались впиндюрить в протокол кучу всякого бесполезного г@вна и полностью изменили идеологию использования адресного пространства. Фактически создатели IPv6 предлагают нам совершенно новый Интернет. Я абсолютно уерен, что все эти потуги тщетны и IPv6 не взлетит никогда!
И еще. 128 бит на адрес это оверкилл, такие адреса совершенно невозможно запоминать и администрировать. 64 бита для IP адреса более чем достаточно на ближайшую тысячу лет.
Имхо ipv6 вышел довольно стройным, и да, это совершенно новый интернет, но оно выглядит лучше чем добавление «октетов» в ipv4.
P.S. А нафига запоминать 128 бит адреса? Тебе нужно оперировать префиксами. Да и раздавая /64 на оконечное устройство - ты уже получишь упомянутое тобой 64 бита адреса. Кстати, вручную сконфигурированный адрес - может быть и легко запоминаемым, для примера - :face:b00c, ::8888. это куски без префикса
Про запоминание слышать странно. Как правило, у вас единственный префикс на всю организацию (который достаточно быстро запоминается), вместо нескольких сетей IPv4 с разными масками. Мне стало даже легче ориентироваться. SLAAC вам точно запоминать не придется, а шлюзы, DNS и пр. имеют простые адреса. Некоторые админы даже придумывают некоторые осмысленные имена, которые можно запихнуть в IPv6 типа face, dead beef и.т.д.
Основной недостаток IPv4 в том, что в своё время слишком много адресов было бездумно выделено абы кому (бывший class E сюда же). И вместо того, чтобы придумать механизм отжима IPv4 у всех, кто не может показать целесообразность владения огромными пулами IPv4, был придуман сверхизбыточный IPv6. Который тоже может резко закончиться, если выдавать его также бездумно, как и IPv4.
чайники и умные утюги будут смотреть наружу напрямую
А зачем им смотреть наружу? Им можно раздать только Link-local...
Пора пилить IPv7
Вы явно недооцениваете инженеров, которые проектировали IPv6.
Цитата из книги «IPv6 для знатоков IPv4», Ярослав Тихий, 31 декабря 2013 г.:
Попробуем для начала консервативный подход. Можно ли расширить адрес IP, не отказываясь от протокола IPv4 и, в частности, от его формата заголовка? Например, мы могли бы поместить новые, расширенные адреса в специальные опции IPv4. ARP справился бы с новыми адресами, так как длина адреса в нем явно указывается. С ICMP ситуация сложнее, так как некоторые типы сообщений ICMP включают в себя адреса IPv4. Наконец, фиксированное смещение адресов от начала заголовка облегчает быструю аппаратную маршрутизацию пакетов, тогда как размещение адресов в опциях значительно усложнило бы ее. Ну, и вообще говоря, опции потому так и называются, что они должны быть факультативными, то есть необязательными для исполнения. Это окончательный аргумент против того, чтобы новые адреса находились в опциях IPv4. В то же время, основной заголовок IPv4 рассчитан только на 32‑битные адреса. Вывод такой, что текущим форматом заголовка IPv4 нам все-таки придется пожертвовать, поскольку в нем нет места для новых адресов.
Теперь, когда мы готовы распрощаться с заголовком IPv4, у нас возникает противоположное искушение: не просто расширить адреса, а радикально переделать протокол IP, чтобы исправить в нем существующие недостатки и добавить новые возможности.
Там есть ответы на большинство вопросов, которые тут задают в комментариях. И почему именно 128 бит, и почему 64 бита на сеть, и почему IPv6 не совместим с протоколом IPv4, и даже почему именно так щедро в настоящее время распределяются адреса IPv6.
Не стоит недооценивать протокол IPv6. Кроме того, что его достаточно хорошо проработали и сделали таким каким он сейчас, учитывайте, что практически всё современное железо так или иначе может работать с этим протоколом. Да, потребности массовой пока нет, поэтому возможности железа ограничены. Но как только критическая масса наберётся и производители софта для железа увидят потребность, они наклепают вам всех необходимых возможностей, которые вам нужны и не нужны. С IPv4 также было. Софт в старых маршрутизаторах тоже был ограничен. Но когда маршрутизаторы стали требоваться почти всем, они обросли разухабистыми веб интерфейсами, где можно настроить кучу всего.
Сам протокол IPv6 по своей природе меньше грузит промежуточные узлы. Маршрутизаторам проще обрабатывать эти пакеты. Если вам нужно фильтровать пакеты, то нужно опять таки запоминать состояние. Но этого требует и NAT. Но при этом нам не нужно переписывать заголовки пакетов, а значит наш маршрутизатор будет меньше загружен при тех же самых возможностях, что есть в IPv4.
К слову о NAT. Даже бытовой роутер является довольно эффективным экраном между этими вашими интернетами и уютненькой локальной сетью, одним лишь только фактом своего существования исключая значительное количество векторов атаки.
Сравниваем. Включаем в брандмауэре вашего маршрутизатора запрет на приём пакетов, кроме тех, что нужны для получения ответов. Получается та же схема, что и при работе NAT, только без NAT. Снаружи до вас не достучаться, но если вы откроете путь для себя изнутри, то пакеты до вас будут ходить. Вашему маршрутизатору не нужно хранить таблицу NAT (но при этом нужно всё так же хранить какие порты у вас активны) и модифицировать каждый пакет, который через него проходит. А уровень защиты получается на том же уровне.
Сравниваем. Включаем в брандмауэре вашего маршрутизатора запрет на приём пакетов, кроме тех, что нужны для получения ответов.
Увы, ipv6 требует для работы разрешения ICMP пакетов входящих на узлы в вашей сети. Так что полной изоляции всё равно не получится. И никто не гарантирует, что в IoT устройстве не найдут уязвимость в обработке ICMP. Более того — когда-то такая точно найдётся. И защититься от неё вы уже не сможете.
Воспользуюсь вашим методом. А вы знаете, что в IPv4 используется ARP? Если ваше устройство не отвечает на ARP запросы, то оно не сможет работать, т.е. полной изоляции не получится. И никто не гарантирует, что в IoT устройстве не найдут уязвимость в обработке ARP. Так что срочно нужно отказаться от IPv4!
А если серьёзно, то никто не заставляет вас все ICMP направлять напрямую без какой-либо фильтрации на вашем брандмауэре. И есть вполне конкретные решения для защиты сети. Они другие, не такие как в IPv4. Но и протокол у нас другой, который учитывает ошибки в старом протоколе.
И давно требуется отвечать на arp запросы от кого попало наружу из внутреннего периметра?
Все — никто не требует. Но конкретные виды ICMP сообщений направлять напрямую необходимо для работы протокола согласно https://www.rfc-editor.org/rfc/rfc4890. И что-то я пока не вижу IPS/IDS в распространённых домашних роутерах, чтобы пытаться блокировать запросы к известным уязвимостям.
Справедливости ради, ICMPv4 тоже не рекомендуется закрывать полностью.
Справедливости ради, ICMPv4 в локалку не требуется открывать из внешнего инета. Так что этот аргумент мимо.
Факт в том, что IPv6 требует более сложных настроек файрвола (которые мало кто умеет делать пока и которые вряд ли адекватно "из коробки" сделаны на всех домашних роутерах) и требует больше пропускать из инета в локалку - т.е. уровень защищённости локалки при использовании IPv6 падает.
Факт в том, что IPv6 требует более сложных настроек файрвола
Одна галочка в роутере (которая и так прожата по дефолту - "не пущать коннекты снаружи". Абсолютно столько же телодвижений, как и при IPv4 NAT.
Телодвижений-то столько же, а вот качество результата несколько отличается, и не в сторону большей безопасности.
В каких попугаях вы измеряете «качество результата» ?
В количестве открытых векторов атак (пропускаемых пакетов, в данном случае). И в размере вероятности, что галочка настроит не настолько правильно, как можно/нужно было (в связи с увеличением сложности настройки, меньшим накопленным опытом как настраивать правильно, меньшим объёмом тестирования/обратной связи от взломов).
А как вы посчитали количество открытых векторов атак, размер вероятности и сложность настройки? Были какие-то эксперименты, контрольные группы, экспертные оценки или просто с потолка, "потому что мне так кажется" ?
А Вы в теоретические знания не верите, всё нужно проверять на практике? Документации про IPv6 более чем достаточно, и если её почитать, даже поверхностно, становится очевидно, что IPv6 больше и заметно сложнее и что он требует пропускать из инета в локалку часть трафика, который в IPv4 пропускать не требовалось (часть ICMP). Из этого вполне однозначно следует и то, что количество векторов атак увеличивается, и то, что корректно настроить файрвол для IPv6 будет сложнее (а, значит, в его настройке тоже будет совершаться больше ошибок). Ну и там других, менее очевидных, новых угроз хватает - напр. если использовать MAC для младших 64 бит адреса то это может создать новый способ утечки приватности, когда перемещение вашего устройства (ноута, например) между разными сетями IPv6 (дом/работа, например) смогут отслеживать даже вебсайты в интернете.
Главным образом я не верю в оценочные суждения, исходящие от предвзятых неосиляторов-теоретиков, которые вбили себе в голову, что «IPv6 это сложнаааа» и наворачивают вокруг этого тезиса целую мифологию о тысячах виртуальных уязвимостей в ICMPv6.
смогут отслеживать даже вебсайты в интернете
Не смогут, RFC 4941 вам в помощь.
Не смогут, RFC 4941 вам в помощь.
В помощь оно только тем, кто позаботится ручками явно включить его на конкретном интерфейсе. Потому что по умолчанию в линухе оно выключено (networking/ip-sysctl.rst):
use_tempaddr - INTEGER
Preference for Privacy Extensions (RFC3041).
* <= 0 : disable Privacy Extensions
* == 1 : enable Privacy Extensions, but prefer public
addresses over temporary addresses.
* > 1 : enable Privacy Extensions and prefer temporary
addresses over public addresses.
Default:
* 0 (for most devices)
* -1 (for point-to-point devices and loopback devices)Кроме того, честно скажу в подробности я поленился вникнуть, но сходу попалась статья с цитатой:
The temporary addresses standardized in RFC 4941 were originally meant to mitigate some of the security and privacy issues discussed in this tip. However, we will see that they fail to mitigate a number of potential problems, while at the same time introducing additional complexity.
И такая ситуация вполне типична для самых разных аспектов IPv6 - это и есть как раз следствие его переусложнённости.
Не поленился прочитать ту статью. Автор, описав недостатки RFC 4941, предложил их решение в виде RFC 7217 (и оно реально выглядит уже значительно лучше, как на мой взгляд). К сожалению, в плане настроек по умолчанию ситуация не изменилась - оно выключено:
addr_gen_mode - INTEGER
Defines how link-local and autoconf addresses are generated.
= =================================================================
0 generate address based on EUI64 (default)
1 do no generate a link-local address, use EUI64 for addresses
generated from autoconf
2 generate stable privacy addresses, using the secret from
stable_secret (RFC7217)
3 generate stable privacy addresses, using a random secret if unset
= =================================================================Так, стоп, при выключенном фаерволе, но активном NAT разве «сосед» не может на своей машине прописать маршрут для трафика на своей машине указав nexhop-ом ваш роутер, и спокойно гнать трафик в вашу сеть?
P.S. Кроме случая overload NAT/port adress translation, там, по идее сломается. Но это частный случай NAT
Может, я экспериментировал с кинетиками, прокатывало. Поэтому меня очень печалят комментаторы, приписывающие NAT'у «свойства хорошего фаервола»
Лично я NAT файрволом не считаю, ни плохим ни хорошим. Но ещё я не считаю хорошей идеей выставлять все устройства из локалки в инет, ни полностью ни частично (от приёма ICMPv6 из инета и до публикации наружу количества устройств в локалке и их MAC-адресов).
Опять же. NAT есть и в IPv6. MAC использовать для младших 64 бит адреса тоже никто не заставляет. Это не вопрос того, что в IPv6 чего-то сделать нельзя. Это вопрос того, что настройка "по умолчанию из коробки" в случае IPv6 практически гарантированно окажется менее безопасной во-первых, и, из-за большей сложности IPv6, сделать её хотя бы идентично безопасной будет намного сложнее (и в процессе настройки будет допускаться много ошибок - сложность есть сложность, а людям свойственно ошибаться), и в-третьих из-за меньшей отлаженности IPv6 будет дополнительная кучка багов/уязвимостей в самой реализации сетевого стека для IPv6 в разных ОС/устройствах.
Иными словами, по факту, в первые годы массового перехода на IPv6 безопасность заметно упадёт у большинства. При этом именно массовый переход ещё даже не начался. А сейчас безопасность падает только у тех энтузиастов, которые уже сейчас пытаются использовать IPv6, не уделив при этом на порядок больше (чем требовалось для IPv4) времени и внимания вопросам безопасной настройки.
Не совсем. Из соседней локалки - сможет. Из инета - нет, потому что адреса локальных сетей в инете не роутятся (разве что конкретно ваш провайдер, при сильном желании забраться к вам в локалку - сможет). Но угроза, всё-таки, обычно либо из инета исходит, либо (в офисе, например) из собственной локалки, варианты когда это именно соседняя локалка встречаются реже, плюс в ситуациях когда рядом несколько локалок это обычно означает большое число клиентов (крупный офис, к примеру) и к ним обычно прилагается хоть какой-то живой админ, с квалификацией повыше домашнего пользователя.
Справедливости ради, ICMPv4 в локалку не требуется открывать из внешнего инета. Так что этот аргумент мимо.
Да, а потом вы не получаете Fragmentation Needed, и имеете проблемы с MTU.
А что представляет собой IPv6 с точки зрения всякой цензуры/блокировок интернета и противодействия оным? Кому он удобнее - тем кто блокирует или тем кто ищет пути обхода?
В качестве прогноза, могу предположить, что полный переход с IPv4 не состоится никогда, скорее интернет распадется на сегменты, которые могут быть ограниченно связанные, при этом могут использоваться разные протоколы и будут всякие шлюзы то работающие, то нет. И это может стать реальной технической "катастрофой" кстати, потому что связанность сильно пострадает.
Native: 43.02% 6to4/Teredo: 0.00% Total IPv6: 43.02%
https://www.google.com/intl/en/ipv6/statistics.html
Не так уж и плохо, по 5% в год переползаем потихоньку.И даже +20% за последние три года вроде как.
Если там же посмотреть статистику по странам - видно, что всё это благолепие в основном за счёт... сюрприз, Индии. Ну и ещё несколько пионеров внедрения IPv6 есть (причём какой-то логики по географическому соседству, экономическому развитию, политической свободе и пр. не прослеживается - в списке как Франция с Германией, но без остальных стран ЕС, так и Малайзия и Саудовская Аравия, - так что, подозреваю, это результат стараний национальных регуляторов). А в подавляющем большинстве стран с внедрением IPv6 или просто грустно, или очень грустно.
Видимо, старость мы встретим в конфигурациях "v6 для клиентов, трансляция в v4, v4 внутри сетей", а NAT никуда не денется для LAN.
А вот работает ли фильтр интернета от РКН на IPv6, или не умеет?
На работе у нас ipv6 внутренние сети (мобильный оператор в Японии, иметь больше 16 миллионов абонентов в подсети это потребность практически).
Так вот, пока самая заметная проблема ipv6 это как хреново на нём работает весь софт. Такое ощущение что половина тестов заканчивается на этапе дуал стака и поэтому когда софт кто-то актуально деплоит в ipv6-only начинаются пляски с конями. И часто никакая документация, по умолчанию отрубленная поддержка и так далее и в том же духе. Короче переход на ipv6 будет явно не простым...
Я тут хотел пример привести докер, но оказалось что в июне где-то они таки наконец обновили документацию с тем как актуально запускать ipv6 без плясок с конями. А вот что там было до июня и это без правил маскарада работать по дефолту вообще не будет.
IPv6 - все там будем )
Раньше просто взял и забанил IP "злоумышленника" в CF или nginx
Сейчас попробуй пойми, что банить
Зачем такими большими пачками выделять на устройство?
Не будет ли с ipv6 как с "640 килобайт хватит всем"?
Пачки по /64 на устройство - для корректной работы slaac, чтобы анонсировал префикс - а дальше оно само. В том числе с использованием Privacy extension для автогенерации временных адресов
А банить - точно так же, только не адресами, а префиксами
Давно объяснено по-моему регистрами: Если текущая политика выделения адресов окажется ошибочной, её для следующего большого диапазона пересмотрят. У нас сейчас 2000/3 или что-то там.
Допустим, я хочу свою домашнюю сетку и кучу лаб в разных облаках перевести на IPv6.
Сейчас на IPv4 я планирую, какой кусочек из 10.x.x.x отдать в Azure, какой в AWS... Потом из них нарезаю помельче для разных VNet, pod CIDR, service CIDR... 192.168 (чтобы не путались) для Wireguard и прочих VPN и стыков... Естественно, никаких 169.254.0.0
C IPv6 это как должно выглядеть? Аналогично выделять внутри fdb0:42fa:e71d:48f3?
В чем тогда преимущество перед IPv4, если все равно может оказаться, что потом захочется связаться с коллегой, у которого такая же сетка?
Вот если можно свой блок IPv6 получить "для дома, для семьи" - другое дело. Только на ARIN вроде и есть про Requesting Space as an End User, но вроде все равно создавать организацию и т.п. Может, конечно, гуглится устаревшая информация, но там было, мол "для домашнего использования не даем".
Считается, что провайдер выдаст клиенту /64 сетку. И большинство нормальных так и сделает, кстати. Хотя есть и отдельные провайдеры, дающие всего один адрес на клиента — а дальше тот уже страдает с NAT.
Для дома дают блок /64. А если не жадничают, то вообще /48.
Конкретный провайдер даст, когда научится в IPv6, а когда перееду отберет?
На такое я не готов завязываться, чтобы не менять всю адресацию в лабе и прочих хоум ассистантах.
Или вы можете подсказать, у кого можно для дома действительно собственный блок получить, который даже при переезде моим останется?
Я пока вижу только отдельные предложения типа
И вроде Hurricane Electric Free IPv6 Tunnel Broker что-то может выделить. Но это будет не "мое", а на него завязанное. Конечно, мои нужды не mission critical. Но...
Вот, кстати да. А ещё даже дома, а уж тем более в офисе неплохо бы иметь пару провайдеров для резерва. Если внутренние адреса выделять из подсети одного из них - как оно должно работать, если этот провайдер отвалился и внешний канал переключился на второго? Я же свой префикс /64 внешнему миру анонсировать по BGP не смогу всё равно.
С переключением адресов самое печальное. Более того, если вы попытаетесь выдавать адреса от обоих провайдеров сразу своим компьютерам — временами всё будет ломаться наиболее странным образом, когда маршрутизатор будет пытаться послать пакеты с обоих сетей по одному и тому же каналу. Тут остаётся только NAT66, но с ним почти не остаётся преимуществ самого IPv6.
Если внутренние адреса выделять из подсети одного из них
Нет, не так. Получать по адресу от каждого провайдера.
Только DHCP не умеет выдавать одному клиенту больше одного адреса. А на смартфоне с Android я сходу не нашёл даже способа вручную два адреса одному интерфейсу задать (наверняка можно через командную строку, но не факт, что без рута, ну и вообще, вручную забивать на каждый девайс по два IPv6 адреса - так себе "упрощение"). Всякие принтеры и IoT-устройства тем более такой возможности с высокой вероятностью лишены.
В общем, как-то светлое будущее с IPv6 не вырисовывается... по крайней мере, пока, кроме возможности получить /64 от провайдера, для любого клиента (в т.ч. мелкого и частного) не станет такой же общераспространённой возможность анонсировать свою /64. Но что-то мне подсказывает, что если каждый продвинутый частник или офис на 10 человек начнёт свои префиксы анонсировать - тут уже BGP чем-то заменять придётся (не погружён в эту матчасть глубоко, так что это только в порядке дилетантской гипотезы)
Изначальная идея — каждое устройство в сети получит по ДВА public IPv6 адреса(точнее 4 если это клиент — privacy адрес ж есть) и будет выбирать правильный в зависимости от адреса хоста назначения (там набор правил есть). И два шлюза по умолчанию. И все ходют по своим блокам.
Оно даже работает. Вот только если по какой то дури трафик пойдет на роутере не в тот интерфейс — будет весело, если алгоритм выбирает исходящий адрес не правильно (например не учитывая что часть адресов надо гнать через туннель и третьего блока который с туннеля — должен быть приоритет). Если же один из каналов сдохнет — если при этом анонсы с роутера пропадут — еще полбеды.
И чтобы это нормально использовать — желательно тот самый "нежелательный" NAT пусть и без трансляции портов.
М.б. вы хотите ULA? Поясню, в контексте IPv6 это совершенно нормально что у устройств есть несколько адресов. Можно одновременно иметь link-local, global, ULA (а то и несколько) и т.д.
А чем ULA в IPv6 в практическом применении лучше приватных IPv4 адресов? Если всё равно городить свою внутреннюю адресацию (а судя по всему, таки придётся) - то смысл дёргаться, оно и с IPv4 так же работает?
IPv6 сделали не ради приватных адресов, они действительно ничем не лучше. Всё это затеяно в первую очередь чтобы того чтобы иметь достаточное количество публичных.
Но получается, что в любой минимально сложной конфигурации нам без приватных адресов всё равно не обойтись. Несколько провайдеров или смена провайдера - см. выше. Необходимость защиты доступа к внутренней сети через VPN? Опять. Ну и т.п.
Т.е. пока адреса IPv4 в принципе поддерживаются и доступны не за миллион денег хотя бы в количестве 1 шт. на физическую локацию - практического смысла сейчас переводить свои внутренние сети на IPv6 (да и вообще поддерживать у себя IPv6) для конечного пользователя (дом, офис, любой небольшой бизнес) никакого.
А поскольку светлое будущее, в котором IPv4 уйдёт в историю, мне ничего хорошего, кроме лишнего геморроя, тоже, похоже, не принесёт, - то и поддерживать IPv6 из идейных соображений, приближая личным примером это будущее, тоже как-то не хочется :)
Ускоренная обработка: отсутствие контрольной суммы, в связи с чем маршрутизаторам не нужно выполнять перерасчёт для каждого пакета.
Контрольная сумма вычисляется "на лету", по мере приёма, поэтому лишних затрат времени не требует.
А вот что насчёт контроля целостности пакетов? Это отдано на откуп чему (или кому)?
это задача протоколов выше, например TCP
TCP никак не контролирует целостность всех полей IPv4. Только некоторыx. А все поля заголовка IPv4 тот контролирует сам, своей отдельной чексуммой. Из IPv6 зачем-то вообще контроль целостности заголовка выпилили, прикрываясь тем, что этим должен заниматься канальный уровень. Ну в 90ые или когда там IPv6 придумывали это было разумно, а сейчас, когда даже 5950x раз в месяц срёт в логи machine check'ом по поводу исправления ошибки в L3 кеше (или где там -- мне из логов не очень ясно), такое решение уже не выглядит очень разумным. Нынче на 5 нанометрах лишних/ненужных проверок целостности не бывает.
И не надо! Почему? Потому что именно пэйлоад чексумится на TCP уровне (L4). Кроме того весь трафик в 100G Ethernet(L1) и далее (ну и почти все over the air интерфейсы), имеет FEC. Чексуминг на других уровнях между L1 и L4 на практике оказался малополезным.
FEC езернет может иметь только в проводе, а CRC есть только от момента формирования фрейма до момента приёма с обработкой другим концом. Далее внутри при обработке уже либо не имеется ничего (сетвушка заботливо сложила фреймы в память компа без ECC) либо собственные велосипеды. Флипнется битик заголовка какой на этапе отсутствия контроля -- и в лучшем случае коннект дропнется. Чексум на заголовок IPv4 -- хороший способ (был) для сквозного контроля целостности.
Между узлами — контроль целостности пусть делает L2. End-to-end — на L4 и L7.
А что там происходит внутри узла, должно ли это заботить? У узла есть свои меры для предотвращения ошибок. Везде, где это важно, стоит ECC память. В стандарте DDR5 уже обязательный ECC. И даже в кэшах, как вы заметили, есть чексуммы. Так что возможностью флипа внутри узла возможно пренебречь (иначе это дефектный узел, и его стоит поменять).
И мы получаем разные алгоритмы подсчета для v4 и v6, хотя по логике OSI это не хорошо (но кого волнует?). Ну хотя бы для UDP CRC теперь mandatory, а не optional.
Подскажите, сейчас я использую разные методы смены внешнего IP адреса, чтобы выгружать данные, например, из инстаграма. Активно работаю через мобильные прокси, чтобы избегать банов по IP.
Что будет, если вдруг всё начнёт работать по IPV6? Не станет ли адрес фиксированным?
UPD: Пока писал, подумал, что прокси на то и прокси, чтобы показывать свой адрес, а не мой адрес. И раз попадается реклама прокси IPV6, то жить можно.
фиксированным
Скорее всего, вне зависимости от метода получения ipv6 - на интерфейсе будет статический адрес (хотя и DHCPv6 дающий разные адреса не запрещён). Но, в случае SLAAC и работающего privacy extension - исходящие адреса будут генерироваться с некоторым промежутком по времени (или по запросу приложения, а также не будут подходить для входящих соединений если приложение открыв сокет - прекратит его прослушивать). Другой вопрос что никто не помешает поступить идеологически верно, и блокнуть подсеть /64 из которой ты обращаешься к ресурсу
A сам RUVDS IPv6 поддерживает? На сайте упоминания нет.
Здравствуйте! Пока нет, и вот здесь мы рассказывали, почему.
У меня прям флешбэки из 2011 года, когда я сидел на первом ENOG, и там прям чуть ли не основной темой было то, что IPv4 - всё.
При этом блоки ipv4 дешевеют.
Просто у техногиганты решили начать монетизировать. Малые и средние компании покупают блоки и закладывают в цену, при этом цены все равно ниже, чем у грандов.
А как там ipv6 и ddos? Помогает больше защищающимся или тому кто атакует?
Сейчас IPv6 DDoS, по сути, нет. Атак на доступность не будет, если нет доступности (с) мем.
В перспективе:
Если NAT не будет распространен, можно банить /64, не опасаясь задеть легитим. Но выше пишут, что в организациях с резервными каналами NAT может и остаться.
И этих /64 станет больше, чем сейчас /32. Пресловутый бан по GeoIP останется актуальным.
Stateful пакетная обработка для IPv6 тяжелее, чем для IPv4, при прочих равных. State растет, так как больше легитимных адресов и больше сами адреса.
Сами атаки не изменятся — все интересное начинается с L4.
https://habr.com/ru/articles/501476/
Статья от 2020 года, изменений, к сегодняшнему дню, в сущности никаких. Может когда будет IPv7/IPv8 , что-то улучшится. Потребностей в IPv6 у пользователей нет.
Потребностей в IPv6 у пользователей нет.
То что вам что-то не нужно, не значит что оно никому не нужно.
Пользователю действительно в основном неинтересно про IPv6 и прочие подкапотности
Но спросите, хотят ли они играть в майнкрафт* с друганами с низким пингом и не ставя всякие хамачи — и сразу увидите интерес :р
*В зависимости от возраста пользователя, аргумент можно заменить на более качественный звук и меньшее число обрывов связи в звонках через вотсап
Как у меня бомбит от вроде бы умных людей, разбирающихся в айти, но только поверхностно знающих сети и говорящих, что ipv6 хуже ipv4. И молящихся на NAT (Я кстати тоже думал что он замечает фаервол, когда был зелёным CCNA).
Вся проблема ipv6 только в том, что куча инженеров думают, что он не нужен и я не буду поддерживать его в своей инфраструктуре. И как итог хочешь не хочешь нужно ipv4 в своей сети тоже иметь чтобы работать с такими коллегами, а если он есть и работает, то зачем что-то городить дополнительное.
Всё нормальное оборудование поддерживает ipv6 c 2007 года точно.
Кстати, у автора статьи нет главного отличия ipv6 от 4, которое первым пунктом во всех книжках - отсутствие бродкаста и замена его мультикастом.
Ноют умные инженеры, что с 6 версией им неудобно тащить свои костыли и велосипеды. А вы только подумайте сколько крутых решений не родилось, потому что ipv6 не распространён - никто не пишет софт, который может быть будет работать у 25% пользователей.
И молящихся на NAT (Я кстати тоже думал что он замечает фаервол, когда был зелёным CCNA).
Не заменяет, а служит дополнительным рубежом обороны. Так же, как отсутствие маршрутов к "жертве" существенно усложняет жизнь атакующему.
И так же, как фаервол не является "серебряной (золотой?) пулей", обеспечивающей 100% защиту, а нужно вкладываться и во всякие WAF, и обеспечивать безопасность цикла разработки...
Вся проблема ipv6 только в том, что куча инженеров думают, что он не нужен и я не буду поддерживать его в своей инфраструктуре.
Да у многих компаний в лабах он развернут. И даже в отдельных сегментах. Чисто опыта набраться. Ибо в продуктив выставлять действительно мотивации не особо много (за исключением кейсов типа "сотовый оператор").
Мне вот интересно было IPv6 пощупать, причем не на адресах, "какие сами назначутся", а более приближено к реальности. Взял сетку /56, которую Oracle Cloud раздает в рамках Always Free, побил на более мелкие, поиграл с ней на наскольких тестовых сайтах. На Российском VPS (где провайдер выдаетIPv6) поднял Nginx reverse proxy на IPv6...
Пощупал, поиграл, и на этом все закончил. ибо внятных кейсов, где это помогло бы мне или моим заказчикам, не придумал.
Совершенно новые (и при этом весьма большие) внедрения - ну возможно. Но переделывать существующее - очень вряд ли.
Пока появляются такие статьи с аргументами буквально: «у меня не открылся Github, IPv6 отстой!» (видимо, электромашины тоже отстой, раз «заправок» сильно меньше), мир строит IPv6-only сети.
+1
Удивительно что такая статья была достойна перевода, видимо vps-хостниг пытались снова оправдать почему "IPv6 не нужОн". С такими тезисами что в статье, что в коментариях противников v6 спорить бесполезно т.к. люди не углубившись в протокол и в ситуацию, аналогично ситуации с 5G кричат с пеной у рта "оператор не поддерживает, моё устройство тоже - не нужон". На эмоциях можно было собрать все эти не существенные тезисы в статью "Неасилиляторы IPv6 или по существу", но на практике показало что это бесполезно, проблема не в протоколе, в железе или провайдере, только в голове (не желании разбираться с IPv6, а тупо пытаться натянуть практики v4 на v6(сову на глобус)).
@ValdikSSприглашаем вас =)
https://t.me/version6
https://t.me/version6_offtopic
у меня не открылся Github, IPv6 отстой
а что не так с этим аргументом?
попробовал ipv6-only vps, git clone с гитхаба не работает, docker pull не работает.
настроил туннели между dc через ipv6, оказалось, что часто трафик начинает ходить неоптимальными путями (задержки заметно выше, чем через ipv4), а несколько раз и вовсе были проблемы (потери пакетов и/или полная потеря связи).
и зачем мне это счастье?
а что не так с этим аргументом?
не так с этим аргументом то, что вы свои личные, как разработчика, потребности почему-то проецируете на всех остальных, как будто бы доступность гитхаба и докерхаба являются ежедневными насущными потребностями большинства пользователей Интернета. Это, мягко говоря, не так, и такое рассуждение является жесточайшим logical fallacy, когда из невозможности реализации ваших личных хотелок через ipv6 делаете вывод что ipv6 не должен быть нужен никому.
А вот, например мои хотелки, как преподавателя, не могут быть в полной и должной мере реализованы без повсеместного внедрения IPv6. И я не вижу ни одной причины почему ваше "не хочу" хоть на миллиметр толще моего "хочу".
p.s. кстати, это не вы ли мне в один из прошлых ipv6-срачей затирали что недоступность гитхаба может глобально положить весь Интернет?
Если я правильно понял ваши хотелки, как преподавателя, вы хотите принять лабу у студента без минимальных телодвижений, без открытия порта на роутере (NAT/port mapping) или использования какого-то из массы других способов. Вы хотите этого прямо "из коробки" и видите в этом преимущество IPv6.
Но ведь это означает, что ПО УМОЛЧАНИЮ у всех пользователей Интернета все устройства должны были полностью открыты из Интернета. И наоборот, придется делать специальные телодвижения, чтобы спрятать SSH он всего мира. Чем, естественно, мало кто озаботится. Мне страшно.
Если же для IPv6 оставить "по умолчанию из Интернета ваши устройства недоступны", и для предоставления вам доступа к студенческой лабе все равно придется разбираться с протоколом, какие порты открыть (SSH, icmp...), ваши хотелки все равно реализованы не будут (преимущества IPv6 для вас исчезнут).
Или я неправильно вас понял?
Или я неправильно вас понял?
Скажем так, не совсем правильно.
Почему-то многие оппоненты думают, что адепты IPv6 вроде меня в принципе отрицают необходимость файрволлов и IPv6 нам нужен исключительно для того, чтобы заставить всех поголовно торчать голой жопой в Интернет.
Это не так. Файрволлы безусловно нужны, как и нужна предварительная конфигурация сети под эти конкретные потребности. Что-то вроде того, что в домашних роутерах сейчас называется DMZ, куда можно одной кнопкой временно вывести виртуалку с лабой, даже не обладая сакральными знаниями протоколов стэка.
Большей проблемой является то, что провайдеры уже не выдают белые адреса IPv4 просто так, их надо покупать. Я же не могу этого требовать от студентов. А сидя за провайдерским NATом (и хорошо если только одним), сколько ни открывай порт-маппингов, ничего и никому доступно не будет. IPv6 эту проблему решает, IPv4 — нет.
Большей проблемой является то, что провайдеры уже не выдают белые адреса IPv4 просто так, их надо покупать
Так большинство провайдеров в рф ipv6-адреса не выдаёт даже за деньги )
Увы, это так.
Вот поэтому и нужна просветительская работа, внедрение энтузиастами и т.п.
Причем даже если IPv6 адрес для роутера каким-то чудом можно ожидать (тетсируют все-таки), то на целую маршрутизируемую сеть для DMZ я не скоро рассчитываю.
При этом я легко делаю IPv4 туннель до Hurricane Electric, они выдали /48, и при большом желании ко мне можно подключиться по IPv6 (если открою порты). Просто тестировал.
Есть масса неизмеримо более простых способ добиться "объединения сеток" на чистом IPv4.
Есть масса неизмеримо более простых способ добиться "объединения сеток" на чистом IPv4.
А можно ознакомиться с хотя бы топ3 из этой массы?
Если нужен разовый доступ по SSH (либо другойом порту), я бы попросил студента запустить бесплатный ngrok (или аналог) и сообщить вам параметры туннеля.
Для "всего экрана" (Windows/Ubuntu Desktop...) раньше широко использвался TeamViewer. Сейчас по поиску "российские аналоги" выдается навскидку Контур.Доступ, Ассистент, RMS, ЮниДоступ, LiteManager Pro. Но, поскольку мне это не требуется, я не разбирался ни с возможностями, ни с их ценовой политикой. Можно глянуть буржуйский списочек
Стационарный вариант описал, ответив на ваше предыдущее сообщение.
Если нужен разовый доступ по SSH (либо другойом порту), я бы попросил студента запустить бесплатный ngrok (или аналог) и сообщить вам параметры туннеля.
То есть опять же зависеть от прихотей внешнего вендора платного проприетарного решения.
Вы отдаёте себе отчёт что всё, вами предложенное, является, по сути, никаким образом не "неизмеримо более простым способом", а сложными костылями, необходимость в которых обусловлена кривой архитектурой?
Мы со студентами в итоге пришли к более приемлемому решению. Они запускали с целевой машины SSH-подключение к моему серверу без авторизации и шелла, но с переадресацией удалённого порта на локальный SSH. Я подключался к нему же, но на переадресованный порт и сразу получал удалённый шелл. И то и другое делается одной командой, вызывающей ssh-клиент, который по умолчанию сейчас уже везде, не требующей никаких проприетарных платных решений, заворачивающих траффик хрен пойми куда.
Но даже такой способ я всё ещё считаю костылём по тем же причинам.
Во-первых, если студенту нужно опубликовать порт, ngrok бесплатный, что я явно указал в своем сообщении.
Во-вторых, ваш вариант с openssh очень хорош и действительно простой. Я накидывал варианты для ситуации, когда действительно нет возможности входящих подключений ни с одной стороны. И тогда без "внешнего решения", спрособному принимать коннекты извне, не обойтись. (У меня, правда, не ngrok, а Wireguard сервер на небольшой VPS, она же и ZeroTier терминирует, а дальше гонит по Wireguard туннелю дальше - очен удобно и безопасно, поскольку подключение только для авторизованных пользователй, а не порт наружу для всего мира)
В третьих, если, как оказалось, у вас IP адрес полноценный, не за NAT, и к нему можно подключиться извне, я бы поднял у себя на роутере Wireguard сервер (не обязательно иметь продвинутый MIkrotik, даже на обычном Keenetic прекрасно работает). И все студенты, даже будучи за NAT, у нему подключались бы клиентом Wireguard. Не вижу отличия от "запустить скрипт" (считаю это одинаково удобным).
Можно, конечно, сказать, что это "проприетарное решение", поскольку вы явно не сами собирали его из исходников, но мне кажется, это придирка, ибо openssh вы тоже наверняка использовали уже собранный. А риски "Wireguard уйдет со сцены" меня не очень беспокоят. Перестроить Кинетик в "самом ужасном случае" на OpenVPN или что-то еще раз в 5 лет - не самое страшное.
Да-да, осталось только найти клиента Wireguard на минимальном установочном образе Gentoo Linux.
А теперь всё-таки попробуйте объективно и честно сравнить все эти извращения с возможностью парой кликов выставить виртуалку в DMZ и подключиться к ней напрямую через IPv6.
с возможностью парой кликов выставить виртуалку в DMZ и подключиться к ней напрямую через IPv6.
Вы почему-то считаете, что сможете выставить виртуалку в DMZ и сделать доступной для вас, причем безопасным образом, как только провайдер выдаст IPv6. Но это не так.
Для виртуалки, которая включается и живёт только пока студент сдаёт лабу, безопасность не нужна вообще )
Верно. И поэтому моя обеспокоенность в том, что ради легкого и простого доступа к этой виртуалке нужно, чтобы "ожидаемый IPv6" предоставлял такой доступ "из коробки". Очевидно, что не только к виртуалке, а ко всему домашнему барахлу. Причем не только у ваших студентов, а вообще у всех.
И либо это настолько страшно, что я даже думать о таком не хочу, либо по умолчанию доступ извне все-таки будет закрыт, и "частичный доступ к конкретной виртуалке" все-таки придется настраивать.
Ожидания "провайдер выдал IPv6, ничего настраивать не надо, оно теперь само" на мой взгляд излишне оптимистичны.
Очевидно, что не только к виртуалке, а ко всему домашнему барахлу.
Нет, не очевидно, не додумывайте. Я выше уже писал про файрволлы.
"частичный доступ к конкретной виртуалке" все-таки придется настраивать.
В пару кликов.
Ожидания "провайдер выдал IPv6, ничего настраивать не надо, оно теперь само" на мой взгляд излишне оптимистичны.
Почему? Оно ведь действительно теперь само. У меня вот на пограничном роутере вообще файрволла нет, и жив здоров пока что.
И либо это настолько страшно, что я даже думать о таком не хочу
с другой стороны, те же телефоны в ipv6-сетях толпами ходят и об успешных атаках я не слышал
У меня смартфон вот прямо сейчас имеет IPv4 адрес публичный. Но он не пингуется ни с компьютера, ни с другого смартфона. Можете у себя проверить? Если у вас из приватного пула - ну просто соседей пингануть (я PingTools Pro испоьзую)
Не знаю, как называется фича у сотовых операторов, когда клиент "изолированы" друг от друга и могут только в Интернет выходить. У Cisco для WiFi, к примеру:
Public Secure Packet Forwarding (PSPF) prevents client devices associated to an access point from inadvertently sharing files or communicating with other client devices associated to the access point. It provides Internet access to client devices without providing other capabilities of a LAN. This feature is useful for public wireless networks like those installed in airports or on college campuses.
Не вижу большой разницы между публичным адресом IPv4 и публичным адресом IPv6. Думаю, что точно так же "входящие" на смартфоны запрещены по умолчанию. Потому и не слышно об успешных массовых атаках.
Для меня так это вообще показатель, что не я параноик, а профи, занимающиеся большими сетями, тоже считают, что публикация всех по умолчанию в Интернет - не дело. И смею надеяться, что и для /48 сетки, выданной вам ISP, тоже входящие будут по умолчанию запрещены. И нужно будет просить провайдера "отключить блокировки". И самому заботиться о настройках роутера для защиты "всех, кроме того, к кому реально тербуется подключение извне".
Но он не пингуется ни с компьютера, ни с другого смартфона. Можете у себя проверить?
о, мегафон опять включил ipv6.
проверил: отключил wifi на телефоне, запустил http-сервер, подсмотрел ipv6-адрес на ip.mail.ru, открыл этот адрес в браузере на компьютере — всё работает
Не вижу большой разницы между публичным адресом IPv4 и публичным адресом IPv6. Думаю, что точно так же "входящие" на смартфоны запрещены по умолчанию.
как мы видим, всё не так
У меня смартфон вот прямо сейчас имеет IPv4 адрес публичный.
точно у вашего смартфона белый ipv4 адрес? что-то не верится (такая услуга у сотовых операторов есть, но она точно не массовая и предлагается обычно на тарифах не для смартфонов)
судя по всему, это pingtools криво показывает адреса.
сетка 33.0.0.0/8 принадлежит американскому МО, явно билайн не может выдавать реальные адреса оттуда.
проверил на мегафоне, pingtools при подключении 4g пишет мне адрес из сетки 12.0.0.0/8, которая принадлежит at&t.
посмотрел вывод ip addr, такой адрес действительно есть на интерфейсе rmnet_data1. но на интерфейсе rmnet_data3 есть адрес из серой сети 10.0.0.0/8 + белый ipv6 адрес.
и по ip ro get 8.8.8.8, ip -6 ro get 2000:: видим, что для исходящего трафика используется как раз rmnet_data3 (и соответствующие адреса).
в 3g такого нет, на rmnet_data1 висит адрес из 10.0.0.0/8 (и pingtools показывает верно)
так что возникает несколько вопросов:
- зачем в 4g поднимаются два интерфейса (один для volte?);
какого хренапочему российские сотовые операторы для внутренних сетей используют блоки адресов, выделенных американским компаниям/организациям;- почему pingtools путается в случае наличия нескольких активных интерфейсов, надо бы им багрепорт оставить. в их оправдание можно сказать, что в дефолтной таблице маршрутизации нет маршрута по умолчанию, всё устроено несколько сложнее (используется магия
iptables/ip rule)
volte - да :)
Про блоки х.з. Сейчас вот из 11.104.209.0. Не удивлюсь, если они действительно делают NAT для них :)
А как у вас получилос с IPv6 на ip.mail.ru? У меня они только в IPv4 резолвятся. Соответственно иду туда по IPv4, и моего IPv6 мейлру не видит.
Вот test.cloudflare.com видит именно IPv6. Но он и резолвится в IPv6 в т.ч.
Не удивлюсь, если они действительно делают NAT для них :)
нет, в инет телефон выходит с 10.x.x.x
а эти адреса используются только для внутреннего трафика (предположительно volte), так что там nat не нужен.
но вот идея использования для этого выделенных кому-то в сша блоков адресов у меня вызывает вопросы.
А как у вас получилос с IPv6 на ip.mail.ru? У меня они только в IPv4 резолвятся
может быть у вас js отключен? сейчас глянул, страничка делает запросы на
https://v4ip.mail.ru/ip.html?callback=xxx и на
https://v6ip.mail.ru/ip.html?callback=xxx
Вариант1: Студент получает себе не 1 IPv6 адрес, а дополнительно к нему целую сетку IPv6 для DMZ. Переносит свой комп именно в DMZ (и, возможно, испытывает сложности со взаимодействием с другим своими системами, скажем, SmartTV/Колонки/ChromeCast, ибо это теперь другая сеть, не гуляют свободно броадкасты), правильно и безопасно настраивает себе туда доступ (скажем, только SSH)...
Вариант2: Студент ставит себе ZeroTier клиент и вводит код, полученный от вас. При этом все безопасно, из Интернета к нему доступа не будет, только из вашей "виртуальной сети" (в т.ч. других студентов вашей группы, если разрешите). И не требуется никаких изменений внутри сети (взаимодействие с остальными его домашними устройствами сохранится).
Я не понимаю, почему для ваших целей второй вариант настолько сложнее первого, что вы предпочитаете ждать повсеместного внедрения IPv6, отказываясь от моментального решения насущной задачи.
Вариант1:
Не надо усложнять. Пограничный роутер остаётся пограничным роутером и раздаёт адреса из выделенной /48 в домашней сети через SLAAC. В DMZ заносится всего один хост — учебная виртуалка. Всё. Не вижу причин, почему что-то другое должно ломаться в таком сетапе.
Вариант2: Студент ставит себе ZeroTier клиент
Серьёзно? Вы советуете поставить проприетарное и платное решение, чья работоспособность зависит от внешнего вендора? Это даже не смешно.
Ну ок, вот вам типичный сценарий. Студент сидит дома за NATом, у него на компе установлен VirtualBox, виртуальная сетевуха которого смотрит наружу в режиме bridge, чтобы получать те же настройки, что и остальные хосты. В виртуалке загружен установочный CD/DVD и идёт процесс установки Linux в отдельном screen с консолью. Куда в такой ситуации втыкать ваш этот ZeroTier чтобы я мог подключиться в сеанс с установкой через screen -x ?
Не надо усложнять.
В чем усложнение? Не надо у провайдера требовать /48, достаточно единственного IP, который он выдал для внешнего интерфейса роутера?
Про SLAAC - отдельный вопрос, насколько ваша виртуалка будет автоматически получать всегда один и тот же IPv6 адрес или придется совершать дополнительные телодвижения. Нужно же не "наружу выйти", а вы должны подключиться к конкретному адресу.
Про "платность" ответил выше.
у него на компе установлен VirtualBox, сетевуха которого смотрит наружу в режиме bridge, чтобы получать те же настройки, что и остальные хосты.
Не совсем понял, как вы собираетесь разделять пакеты с одной сетевой карты по разным сегментам. "С хоста" в основной сегмент (условно со SmartTV), и с виртуалки, получающей настройки с той же физической карты в режиме бриджа - в другой (DMZ). VLAN на роутере и на сетевой карте?
В виртуалке загружен установочный CD/DVD и идёт процесс установки Linux в отдельном screen с консолью. Куда в такой ситуации втыкать ваш этот ZeroTier
Туда же, откуда запускаете скрипт ssh и откуда доступна консоль. Точно такой же способ подключения. Только SSH вам дает лишь один порт, и для условного доступа к Web серверу придется запустить еще несколько ssh сессий для проброса дополнительных портов (80, 443). А через ZeroTier (опять же, на нем свет клином не сошелся, много подобных решений), вы получаете виртуальный IP для доступа к машине по любому [разрешенному] порту.
Ну правда, у вас есть норм решение для вашей задачи. Был бы ваш домашний IP тоже за Hide NAT, пришлось бы использовать другое, не сильно сложнее. Но не надо думать, что как только ваши со студентами провайдеры дадут вашим роутерам по IPv6, все заработает само.
В чем усложнение? Не надо у провайдера требовать /48, достаточно единственного IP, который он выдал для внешнего интерфейса роутера?
Я не требую, он сам даёт. Это, кстати, рекомендованная IANA практика — выдача каждому юзеру отдельной /48. Те, кто жлобятся и выдают по одному — делают неправильно.
Про SLAAC - отдельный вопрос, насколько ваша виртуалка будет автоматически получать всегда один и тот же IPv6 адрес
Дефолтное время жизни адреса в slaac — 7 суток.
Не совсем понял, как вы
Сейчас у нас VLAN не используется. С точки зрения домашних роутеров, DMZ это просто выделенный IP адрес, куда валится всё, что не замаплено и не отабличено NATом.
Туда же, откуда запускаете скрипт ssh и откуда доступна консоль
Там нет клиентов сторонних решений, тем более проприетарных. Разве что уже сидя в chroot целевой системы, можно собрать и запустить zerotier но мне опять же не кажется, что это проще.
Но не надо думать, что как только ваши со студентами провайдеры дадут вашим роутерам по IPv6, все заработает само.
Почему? В моём городе есть местный IPv6 брокер, и те счастливчики, у которых получилось к нему подключиться не имеют никаких из вышеописанных проблем.
Процесс перевода команд на IPv6 будет очень тернистым, преимущественно
из-за того, что никто ещё с этим не сталкивался. Мы многие годы
откладывали освоение этой технологии, и теперь придётся за это платить.
Приямо как переход Питона со 2-го на 3-й. Давали не то 8, не то 10 лет, а перешли все по факту только после полного отключения поддержки. Люди такие люди.
Я тут так много участвовал в дискуссии на счёт протокола IPv6, что забыл одну важную деталь, которая касается посыла статьи! AWS начинает взимать плату за драгоценный ресурс, такой, как IPv4. Так что всего этого можно избежать просто заплатив за роскошь - возможность использовать IPv4. Т. е. если ваш ресурс для вас ценен, просто оплатите услугу и забейте на все сложности, которые могут возникнуть при переходе на IPv6.
И вот что мне показалось странным. Неужели Amazon не предоставляет услуги NAT64? По мне так это самый логичный вариант. Пользователи услуги будут пользоваться готовыми шлюзами в IPv4 сеть и получать все необходимые ресурсы, при этом почти не почувствуют отсутствие IPv4, кроме разве что того, что их сервисы недоступны через IPv4. DNS для этих нужд есть у Googe и Cloudflare, например. NAT64 со специально выделенным диапазоном 64:ff9b::/96 должен предоставить ваш провайдер. Очень странно, что Amazon так не делает. У кого есть возможность, проверьте, должно быть.
Неужели Amazon не предоставляет услуги NAT64? По мне так это самый логичный вариант. Пользователи услуги будут пользоваться готовыми шлюзами в IPv4 сеть и получать все необходимые ресурсы
Не совсем понял кейс. Если речь об исходящем трафике, т.е. инстанс с приватным адресом лезет в Инет через какой-шлюз (неважно, полноценный фаервол и простой NAT gateway), то какая разница из какого семейства его приватный адрес? Вряд ли AWS берет деньги за 10.11.12.13
Сегодня попробовал TransIP GitHub Proxy для IPv6-only сервера с Ubuntu 20, чтобы иметь возможность установки с Github. Для git clone я получаю ошибку - ipv6 failed to connect to github.com port 443 no route to host. А по http - тоже самое с ошибкой на 80 порту. При этом гитхаб пингуется по IPv6. Подходящего случая в сети не нашел, это лечится?
Довольно часто используемая задача, раздача интернета через мобильного провайдера. Смартфон как точка доступа. Но вот мобильный провайдер не очень любит на тарифе для смартфона раздачу интернета. Если представить ,что у нас нет ipv4, а только ipv6. Провайдер же сможет определить количество подключенных устройств. И заблокировать или развести на деньги лишние. Как в этом случае , решается эта задача?
Статья кратко: "IPv6 не нужон, ничо на нем не работает (у меня), значет эта катострофа". В действительности, у использования IPv6 много проблем. А почему многие из них существуют? Потому что такие люди, как автор статьи, вместо того чтобы разобраться и поддерживать IPv6 в своих проектах, выписывает тонны текста про то, как все с ним плохо. Оказывается, что чтобы пользоваться чем-то новым, нужно что-то новое изучить) А чтобы это работало у всех, нужно, чтобы большое количество людей начали это поддерживать.
В действительности, у использования IPv6 много проблем. А почему многие из них существуют? Потому что такие люди, как автор статьи, вместо того чтобы разобраться и поддерживать IPv6 в своих проектах, выписывает тонны текста про то, как все с ним плохо.
Мне кажется, дело не в этом и автор статьи в проблемах использования IPv6 не виновен ни прямо, ни опосредовано. С моей дилетантской точки зрения выглядит так, что такие люди, как автор статьи, сталкиваются одновременно и независимо с переусложненностью IPv6, с низкой распространенностью и околонулевой практической ценностью для подавляющего большинства. И, героически преодолевая все препятствия, в результате получают приблизительно ничего сверх того, что и так имели с IPv4.
Попробую расшифровать во избежание недопонимания.
Дилетантская точка зрения - точка зрения пользователя или системного администратора, занимающегося в виде хобби или за небольшую зарплату работой с малыми, максимум средними по размерам сетями, далекого от уровня магистральных провайдеров и просто крупного бизнеса. Пожалуйста учитывайте этот disclaimer.
Переусложненность IPv6 мне кажется достаточно очевидной как минимум на фоне IPv4.
Низкая распространенность это просто факт. Доля IPv6, конечно, увеличивается, но медленно и пока что она все еще мала. Поддержка IPv6 оборудованием и софтом, будь она заявлена производителем, часто как бы не совсем хороша (читаем статьи таких людей, как автор этой статьи - они с "радостью" делятся примерами хождений по граблям) и не все и не всегда оказывается прямо вот так работающим "из коробки" с настройками по умолчанию.
Практическая ценность вообще чего угодно для подавляющего большинства измеряется возможностью включить и сразу пользоваться - не то, что не читая инструкцию, а вообще не думая. Это, понятно, не распространяется на сетевых специалистов - они как раз должны знать, как что работает, и уметь исправить то, что не работает, но таких специалистов ничтожно мало на фоне тех, кто просто листает фотки няшных котиков. Няшные котики на отлично листаются и через IPv4, через теплый ламповый NAT провайдера. Вот это пример практической ценности IPv6, вернее ее отсутствия для конечного пользователя.
NAT, включая таковой в бытовом роутере - ни разу не firewall и никто в здравом уме не путает эти два понятия, но фактически NAT реализует одну из важных с точки зрения сетевой безопасности функций firewall - изоляцию локальной сети от внешней. И это работает по умолчанию, без каких-либо осознанных действий со стороны пользователя - с точки зрения безопасности следует считать это костылем вместо полноценного firewall, но чисто практически это сильно лучше, чем ничего.
В общем я предлагаю открыто признать, что у IPv6 есть, скажем так, некоторые недостатки, которые препятствуют его быстрому, решительному внедрению, даже несмотря на то, что главная (а может просто единственная?) проблема IPv4 - исчерпание предусмотренного стандартом адресного пространства, подстегивает внедрение. И да, я не против IPv6, ни в коем случае нет. И исчерпание адресного пространства IPv4 - объективный факт. В теории количество адресов IPv4 более-менее приемлемо, но практически нельзя все у всех отобрать и поделить © каким-то способом, который бы хоть минимально устроил всех - уже распределенные адреса так и останутся за теми, кто смог их получить ранее и это, в общем-то, тоже справедливо, потому что те, кому не хватает адресов сейчас, вполне должны были озаботиться выделением для себя раньше, а не ждать наступления дефицита, тем более что разговоры об исчерпании адресов велись точно больше, чем десяток последних лет. Почему IPv6 получился столь переусложненным вместо стать эволюцией IPv4 - вопрос к разработчикам стандарта. По моему, как я уже не раз повторял, дилетантскому мнению, единственная причина разбираться в IPv6 сегодня - дефицит адресов IPv4, потому что больше преимуществ для среднестатистического пользователя он не дает. Ну а сетевые специалисты, работающие с крупными сетями - это не среднестатистические пользователи и им иметь соответствующее образование и нарабатывать практический опыт с IPv6 как бы очевидно необходимо. Я ценю мнение этих самых специалистов и с удовольствием читаю их статьи про IPv6, тем более что они сложны для меня и требуют разбираться в многочисленных непонятных для меня моментах, что прекрасно. Но как для себя, преимуществ IPv6 не вижу, только проблемы.
Переусложненность IPv6 мне кажется достаточно очевидной как минимум на фоне IPv4.
А мне не кажется. Разверните мысль, пожалуйста.
Я недостаточно компетентен, чтобы развернуть мысль и не наговорить чрезмерное количество глупостей.
Такое признание, конечно, делает вам честь, но не кажется ли вам, что и для заявления о переусложнённости IPv6 вам тоже малость не хватает компетентности?
Кажется. Поэтому я многократно указывал на свой недостаточно высокий уровень компетентности и что, очевидно, все мои суждения делаются исходя из имеющегося уровня, а не являются мнением опытного специалиста с приличным послужным списком успешных интеграций на крупных сетях. Встречно спрошу, готовы ли вы принять тот факт, что пользователей с подготовкой близкой к моей или даже еще хуже (хотя куда уже хуже), абсолютное и подавляющее большинство? Нам, пользователям, нужно чтобы оно просто работало, а не чтобы по любому чиху приглашать "тыжепрограмизда". Сейчас как - принес из магазина новый роутер, включил питание, и все дальше само. Роутер по DHCP получил все настройки от провайдера и сам так же раздал настройки клиентам, все остальное по умолчанию и все как-то работает. Мне трудно оценить процент тех, кто лазит глубже и как-то настраивает правила маршрутизации для каких-то нестандартных случаев, пресловутый "проброс портов" и тому подобные непонятные большинству (я серьезно про большинство, потому что считаю вообще всех, а не только аудиторию Хабра), но предполагаю, что процент статистически малозначим, тем более что UPnP с типовыми случаями справляется само. Если с IPv6 сейчас ровно так же, то признаю свою бóльшую, чем я думал, некомпетентность, и спешно отзываю свои комментарии как глубоко ошибочные - признавать ошибки не героизм, а заурядный прагматизм, поэтому я рад всем, кто указывает мне на мои ошибки и тем самым невольно заставляет меня учиться вместо продолжать упорствовать в заблуждениях.
Во многом согласен. Многим пользователям "тяжело продать идею" ipv6. Но считаю, что специалист, который занимается настройкой какого либо сервиса, обязан понимать, как работает ipv6 и должен внедрять его в проекты. Лишить себя головной боли в будущем, разобраться в чем-то новым, охватить большую часть возможного трафика.
Большой проблемой мне видится как раз сложность настройки firewall, ибо в каждом случае все уникально. Может быть появиться какой-то инструмент, который это упростит.
Но и nat как "защиту" использовать глупо. Посмотреть на ботнеты, заражающие все iot устройства просто потому, что а) трафик нормально не отфильтрован, нат пропускает запросы от абсолютно любого непонятного сервера(а вот с ivp6 можно было бы пропускать запросы только от владельца) б) во многих устройствах тонна тупейших уязвимостей.
Но и для пользователей есть плюсы. Свой адрес для устройства удобен во многих случаях, файловое хранилище, интернет вещей, упомянутые раннее. Как минимум для масс появиться возможность нормального p2p звонков без какого либо стороннего сервера.
Потому что такие люди, как автор статьи, вместо того чтобы разобраться и поддерживать IPv6 в своих проектах, выписывает тонны текста про то, как все с ним плохо
а почему они обязаны «разобраться и поддерживать»? с моей точки зрения нормальный инженерный подход — это как раз использовать максимально беспроблемное решение.
вот пример, у вас есть два двигателя. первый выдаёт 100 л.c., второй — 150, первый требует техобслуживания каждые 1000 часов, второй — каждые 100. в тех проектах, где 100 л.с. достаточно, любой вменяемый инженер выберет первый двигатель, а не засядет за адаптацию второго.
и да, покажите нормальное решение недоступности github через ipv6. использование стороннего бесплатного прокси/nat — явно не нормальное решение, а дополнительная точка отказа. поднятие своего собственного — тем более
а почему они обязаны «разобраться и поддерживать»? с моей точки зрения нормальный инженерный подход — это как раз использовать максимально беспроблемное решение.
А расскажите, как эти самые «они» умудрились начать «использовать максимально беспроблемное решение» без того, чтобы сначала в нём разобраться и начать поддерживать? Люди, насколько мне известно, не рождаются со встроенным CCNA.
и да, покажите нормальное решение недоступности github через ipv6. использование стороннего бесплатного прокси/nat — явно не нормальное решение, а дополнительная точка отказа. поднятие своего собственного — тем более
Нормальное решение это dualstack. Который работает уже и будет работать ещё годами, абсолютно прозрачно для всех пользователей.
И да, немного забавно как это у вас так получается, что NAT 4-в-4 на каждом углу это нормально и беспроблемно, а NAT 4-в-6 это фу-фу-фу, не дай бох и точка отказа.
И да, немного забавно как это у вас так получается, что NAT 4-в-4 на каждом углу это нормально и беспроблемно, а NAT 4-в-6 это фу-фу-фу, не дай бох и точка отказа.
всё просто. nat в ipv4 делаю или я, или провайдер, который мне продаёт интернет.
nat64 ipv6-only хостеры почему-то не предоставляют, использовать сторонний (поддерживаемый энтузиастами) nat и/или прокси — это действительно дополнительная точка отказа
Нормальное решение это dualstack. Который работает уже и будет работать ещё годами, абсолютно прозрачно для всех пользователей.
возникает только вопрос: а нафига нам в этом случае ipv6? тем более, что ситуации, когда его использование вызывает проблемы, мне встречались неоднократно
всё просто. nat в ipv4 делаю или я, или провайдер, который мне продаёт интернет. nat64 ipv6-only хостеры почему-то не предоставляют, использовать сторонний (поддерживаемый энтузиастами) nat и/или прокси — это действительно дополнительная точка отказа
Всё равно не понятно. Если nat 4-в-4 делаете «или вы», то кто мешает точно так же делать nat 6-в-4 «или вам» ?
возникает только вопрос: а нафига нам в этом случае ipv6?
Лично мне он нужен по ряду конкретных задач вот уже прямо сейчас. Без IPv6 эти задачи тоже решаются, но с бо́льшим геморроем и очень непрозрачно для неспециалистов.
А вам он нужен потому, что IPv4 неизбежно уйдёт во тьму веков, и чем раньше сообщество разработчиков начнёт это учитывать при проектировании своих решений, тем меньше проблем человечество встретит в будущем и тем меньше костылей придётся городить.
Вот вы помните, как в 1990-х и 2000-х у виндового софта и его установщиков, особенно у игр, была общая болезнь — они начинали безбожно глючить, будучи установленными по пути, содержащем символы за пределами множества 7-битного ASCII, типа "C:\Вася\Soft". Сейчас этого уже нигде нет — Unicode стал универсальной данностью благодаря своего рода принудительному умолчанию в самых популярных ОС, языках и средствах разработки.
А ведь, следуя вашей логике, наверняка и тогда можно было вопрошать, мол, а нафига нам в этом случае UTF, если всё и так работает, достаточно лишь не выёживаться и использовать только ASCII. Вы сильно скучаете по проблемам с кодировками? бНОПНЯ ВХРЮК, НАХРЮЕР и вот это всё. Наверняка нет. Вот так же будет и с NAT'ом.
тем более, что ситуации, когда его использование вызывает проблемы, мне встречались неоднократно
А мне неоднократно встречались ситуации, когда использование IPv6 наоборот, проблемы решает.
Всё равно не понятно. Если nat 4-в-4 делаете «или вы», то кто мешает точно так же делать nat 6-в-4 «или вам» ?
То, что реализация nat64 очевидно невозможна без ipv4-связности
Вот вы помните, как в 1990-х и 2000-х у виндового софта и его установщиков, особенно у игр, была общая болезнь — они начинали безбожно глючить, будучи установленными по пути, содержащем символы за пределами множества 7-битного ASCII, типа "C:\Вася\Soft". Сейчас этого уже нигде нет — Unicode стал универсальной данностью
Что-то вы чересчур оптимистичны, емнип в прошлом году сталкивался с таким софтом.
И да, никакого массового перехода на юникод у виндовых консольных программ не произошло (хотя не щупал windows 11, может быть там что-то изменилось)
Пример некорректный. Если уж приводить какие-то примеры, то в глобальном плане - вместо полноценной квартире мы даем людям коммуналки(условно делим одну квартиру NATом). Твой хост(сервер, компьютер или телефон) буквально не полноценный участник интернета, у него нет своего истинного адреса. Это заставляет нас использовать костыли, потому что ни p2p, ни ftp, ни прочие подобные соединения не поддерживаются нормально. Если в локальном плане - для человека, создающего сервис, важен максимальный охват аудитории. 40 процентов трафика в данный момент - ipv6. И тут нет никаких "лошадиных сил", есть простой факт, что доля ipv6 растет, забирая трафик у ipv4. И чем быстрее ты начнешь поддержку ipv6, тем меньше проблем у тебя будет в будущем. Ты не начнешь судорожный переход потеряв половину трафика, ты будешь готов и будешь знать как корректно настроить все. Поддерживая оба протокола ты потратишь больше времени на настройку и отладку, но обезопасишь себя в будущем.
Насчет гитхаба - вопрос к гитхабу. С точки зрения пользователя, который хочет использовать новую технологию, которую до конца не внедрили - вообще не вижу проблемы в том, чтобы на данный момент использовать nat64.
И чем быстрее ты начнешь поддержку ipv6, тем меньше проблем у тебя будет в будущем. Ты не начнешь судорожный переход потеряв половину трафика, ты будешь готов и будешь знать как корректно настроить все
Не представляю ситуации, в корой что-то придётся судорожно настаивать, все внедрения ipv6 конечным пользователям подразумевают доступность ipv4.
И да, вам кажется уместным писать «не будешь знать» человеку, который говорит о проблемах, которые вылезли при использовании ipv6 в проде? )))
вообще не вижу проблемы в том, чтобы на данный момент использовать nat64
Если мы говорим про использование ipv6, например, в сотовых сетях, где провайдер предоставляет ipv6+nat64, и я не вижу. По сути тут провайдер продаёт услугу доступа в интернет, nat64 является неотъемлемой частью этой услуги.
Но вот только с хостинг-провайдерами ситуация другая: они обычно готовы продавать ipv6-only серверы/vps, а nat64 — нет.
"Не будешь знать" было написано о абстрактном специалисте, а не про кого-то конкретного. А насчет доступности ipv4 - не уверен, что не настанет день, когда мы от него полностью откажемся.
А факт, что хостинг провайдеры не предоставляют по умолчанию nat64 - одна из проблем популяризации всего протокола. nat64 крайне нужен именно сейчас, пока один протокол не стал популярнее другого - это буквально необходимость, иначе половина сети тебе буквально недоступна
Оставлю здесь интересную ссылочку: https://ripe75.ripe.net/presentations/44-ipv6-cellular_v6.pdf Она старенькая, но именно из нее я узнал, что с NAT64 есть нюансы
Ускоренная обработка: отсутствие контрольной суммы, в связи с чем
маршрутизаторам не нужно выполнять перерасчёт для каждого пакета.
раз уж этот пункт за ipv6, может есть аргументы почему отказ от валидации пакета это здорово? потому что звучит не очень
IPv6 — это катастрофа (но поправимая)