Комментарии 276
Многие считают, что NAT защищает внутренние устройства, скрывая их за общим IP. Это как аварийный выход на высоте 30 метров — иллюзия безопасности. NAT не шифрует трафик, не аутентифицирует пользователей и не предотвращает атаки на приложения или устройства.
Защищает не NAT, а роутер - домашний или провайдерский. Злые люди не смогут получить прямого доступа к вашему девайсу, будут всегда упираться в роутер.
Так что если вы не пробрасываете порты для ваших лампочек, то от атак извне они будут защищены.
Белый ip на устройстве не означает, что фаервол и фильтрация трафика на роутере автоматически выключаются.
Фаервол на роутере тоже может быть дырявый или с некорректными настройками по умолчанию.
В инфобезопасности всегда работает модель швейцарского сыра - чем больше слоев, тем лучше, даже если какие-то из них дырявые.
А NAT дырявым по этой же логике быть не может?
Последствия будут сильно разные.
Если у вас фаервол - единственное звено защиты, то при дырке в фаерволе - все, you are fucked. А дырка типа "фаервол отключен по умолчанию" или "фаервол не применяет какое-то правило" довольно проста сама по себе.
А вот если у вас NAT, то во-первых это не отменяет наличие фаервола - должна быть дырка и там и там одновременно.
Во-вторых, как именно вы себе представляете эту дырку? Суть NAT'а - что внутри сети и снаружи будет разная адресация. Пакет с "внутренним" адресом до вашего роутера тупо не дойдет по сети провайдера, а пакет с внешним адресом не уйдет от роутера во внутреннюю сеть. И даже если в NAT'е будет какая-то фантастическая дырка (это прям очень сильно постараться надо), что он зачем-то объявит какой-то из внутренних адресов DMZ и устроит туда полный порт-форвардинг с трансляцией адресов, то... вас защитит еще один провайдерский NAT :)
Короче, классическая для информационной безопасности модель швейцарского сыра во всей красе.
Белый IP на устройстве обычно означает то, что оно само смотрит в интернеты, напрямую. Без роутера.
У меня белый айпи на роутере. Девайсы внутри за роутером сидят
Так про это и речь. Девайсы за роутером недоступны извне (без дополнительных настроек). Потому они и защищены от атак. И NAT тут не причём. А вот если у всех лампочек будут реальные IP, то вам придётся думать о том, как их защищать.
А вот если у всех лампочек будут реальные IP, то вам придётся думать о том, как их защищать.
Ну они же будут подключены в интернет через тот же роутер, через который они подключены сейчас. На нем и будет фаервол, как и сейчас.
Устройства за роутером тоже могут иметь белый ip. Если провайдер дал несколько. Но это прям редко-редко бывает
Если у всего оборудования реальные IP, то роутер не нужен же, простого свитча достаточно.
А если всё равно будет роутер, то нахрена оборудованию реальные IP?
Оно и так нормально живёт с приватными.
А если всё равно будет роутер, то нахрена оборудованию реальные IP?
За тем же, за чем они и сейчас – чтобы устройства могли, если это нужно, соединиться друг с другом напрямую, чего в общем случае не могут два устройства с локальными адресами, и им приходится общаться через сервер с белым IP.
Так всё равно впн является более безопасным вариантом для общения напрямую, чем прямая связь через интернеты. Не все же протоколы шифруются и т.п.
Так что возможность прямого доступа к лампочке я за достоинство не считаю.
Так всё равно впн является более безопасным вариантом для общения напрямую
Чтобы построить VPN-туннель вам все равно нужно устройство с белым адресом. В случае если в вашем распоряжении такого нет (или вам кто-либо не дал таким попользоваться), то и туннель вы не построите. Кроме того, вы ограничены направлением в котором можете строить туннель, только от серого к белому. В итоге если у вас 1 устройство с белым адресом и 5 с серым, то оно становится единой точкой отказа для вашей частной сети.
Так в любом случае точкой отказа при построении впн является впн-сервер.
является впн-сервер
Зависит от протокола. В OpenVPN одно и то же устройство может быть и клиентом и сервером одновременно. В WireGuard по сути вообще нет разделения на клиента и сервера. В итоге количество VPN-серверов в вашей сети будет технически ограниченно только количеством белых адресов.
Да-да, так и представляю впн-сервера на лампочках.
Не знаю почему вы о лампочках постоянно думаете :) Но даже так, в этом ничего нереального, как я уже говорил, в WireGuard (а это сейчас один из самых популярных протоколов для построения частных сетей) вообще нет разделения на клиента и сервер.
Так мы же начали про защиту тупых девайсов, которые сами защищаться не умеют. И про то, что лампочке накручивать системы безопасности не обязательно, если она закрыта роутером - с приватным IP злые хакеры до неё не доберутся.
Такие устройства будут точно так же закрыты роутером, только с помощью фаерволла, а не с помощью NATа. А хакеры скорее доберутся до лампочки через сервера производителя лампочек, на которые они сейчас вынуждены ходить, чтобы связаться с управляющей программой на телефоне, ведь и лампочка и телефон за NATом.
Кроме того, вы ограничены направлением в котором можете строить туннель, только от серого к белому
в 2025? Не совсем, если NAT не совсем злой, то можно и между двумя серыми. Но все равно нужен будет сервер с белым IP который поможет согласовать вам соединение, и выступит релеем в случае неудачи.
P.S. Хотя вроде старый добрый ipsec так тоже умел… но внятной инструкции я не находил, а сам доки не штудировал
в 2025? Не совсем, если NAT не совсем злой, то можно и между двумя серыми. Но все равно нужен будет сервер с белым IP который поможет согласовать вам соединение, и выступит релеем в случае неудачи.
Туннель в любом случае будет строиться от серого адреса к белому, то есть инициатором построения туннеля должно быть устройство с серым адресом. Если оба устройства с серыми адресами, то для построения туннеля между собой они оба должны инициировать построение туннеля к какому-либо устройству с белым адресом.
Хотя вроде старый добрый ipsec так тоже умел
У IPsec как раз вообще все плохо с натом и для работы за натом ему нужен NAT-T.
Туннель в любом случае будет строиться от серого адреса к белому,
Нет, координирующий сервер с белым ip может попытаться «пробить» NAT для двух участников, и передать им адреса друг друга. И в случае успеха они смогут отправлять трафик друг другу в дальнейшем без участия координирующего сервера.
Фактически туннель будет между двумя устройствами, где оба могут находиться за NAT.
Прогуглите про zerotier/tailscale/netbird...
они оба должны инициировать построение туннеля к какому-либо устройству с белым адресом.
Но технически, да, сначала инициализируется подключение к устройству с белым адресом. Но я так и написал в предыдущем сообщении
Но технически, да, сначала инициализируется подключение к устройству с белым адресом. Но я так и написал в предыдущем сообщении
Ну да, именно это я и имел в виду и мы говорим почти об одном и том же, просто я видимо "чрезмерно упростил", отвечая на сообщение aik, чтобы не закапываться в дебри реализаций. Ведь по сути без внешнего сервера не обойтись, не важно, будет ли это STUN, с помощью которого пиры найдут друг друга, как в Netbird, или трафик будет постоянно идти через это устройство с белым адресом, как в случае классического OpenVPN – это уже детали, которые зависят от конкретной реализации. Но ключевые моменты те же: устройство с белым адресом необходимо, и инициировать соединение должно устройство с серым адресом, а если их два, то они оба должны инициировать соединение с промежуточным сервером. То есть именно они обязаны начать строить туннель, отправив запрос в сторону сервера с белым адресом, а будет это STUN либо классический OpenVPN сервер это уже детали.
Ну а почему нельзя так и делать? Белый на роутере, все остальное за ним.
NAT an-mass работает именно как отличная защита пользовательских локалок с их незащищёнными устройствами от недружественного интернета с ботами и сканнерами. А отказ от NAT и переход на IPV6 наоборот требует появления поголовной грамотности у всех пользователей и поголовной смены и перенастройки CPE, чтобы зловреды не пролезли и не потёрли любимую многолетнюю подборку фоток на домашнем NAS. И это я ещё не вспоминаю о том, что IPV4 адрес ещё можно держать в голове при администрировании сетей, а IPV6 нет. Так что массовое использование IPV6 пусть и дальше остается у провайдеров вне пользовательских сетей
V6 наоборот требует появления поголовной грамотности у всех пользователей и поголовной смены и перенастройки CPE
Всякие домашние NAS-ы, которым в Интернет не надо - им вообще на Link Local адресах надо жить и в зоне .local по имени публиковаться. И точно так же не будут снаружи доступны.
это вы каждой бабушке и каждой инстамодели предлагаете знать и уметь настраивать?
Это не надо настраивать. Просто железку в порт включаешь - она это Link Local адрес берет (даже без всяких DHCP) и под своим именем публикуется.
Разумеется, если в сети не отключали 'лишнюю' поддержку IPv6.
Это не надо настраивать. Просто железку в порт включаешь - она это Link Local адрес берет (даже без всяких DHCP) и под своим именем публикуется.
Товарищ выше, под настройкой, имел в виду, что кроме железкиной Link Local надо озаботиться закрытием железки от интернета, в который она по умолчанию будет светить "голым задом", точнее "голым передом", а бабушки такое не умеют.
в который она по умолчанию будет светить "голым задом"
Да не будет она. На CPE/домашнем маршрутизаторе будет стоять файрвол с запретом соединений снаружи внутрь по умолчанию. Я подозреваю, что вот в протоколе сертификации на вот этот логотип IPv6 Ready даже требование на этот счет есть.
А потом в нем найдется бага. Не-не-не. Роутер на сером IP провайдера и серые-серые адреса за ним это прямо идеальное решение по защите всего домашнего зоопарка.
Не должны домашние железки светиться в интернете. И адресуемы быть не должны. Пусть провайдер решает все проблемы.
И на этом ipv6 в массах можно закапывать. Оно скорее вредит среднему человеку. Оставьте его для особых случаев и хватит.
Можно начать думать про ipv8. Нормальном, а не как ipv6.
будет стоять файрвол с запретом соединений снаружи внутрь по умолчанию
Как тогда удалённо войти в админку роутера?
Включить соответствующий доступ. На некоторых старых роутерах, кстати, это было включено по умолчанию. Не удивлюсь, если и сейчас с такой установкой по умолчанию выпускают
Через приложение в облаке типа Eero или Keenetic.
Админить роутер через приложение в "облаке"? Очень смешно. Особенно в свете Keenetic.
Как тогда удалённо войти в админку роутера?
Поставить галочку 'хочу рулить снаружи' и роутер сам на собственном же файрволле откроет порт на доступ с этого самого внешнего мира.
Через несколько лет эти понятия можно будет объединить
```deny ip any any``` выставленное производителем никто не отменяет
Никакой разницы по безопасности нет между IPv4+NAT и IPv6 нет.
И там и там работает Connection Tracking и прочий Stateful Firewall, который пропускает в локалку только пакеты для уже открытых изнутри соединений, поэтому микроволновок ваших из интернетов видно не будет.
NAT к этому всему вообще ортогонален, он просто присасывется к Connection Tracking и транслирует один адрес в другой для установленных соединений.
Да, conntrack с банхаммером ОЧЕНЬ хорошо отбивают всякие нападки. Как правило быстро заносят в свой блеклист, типа "с этим лучше не связываться". Но вот на роутерах "потребительского" класса почти никогда не видел. Казалось бы: ну возьмите тот же OpenWRT, натяните на веб-морду скин какой вам нравится - и... Но нет. В свое время уважал ZyXEL (со времен их модемов) - но и эти походу спаскудились. Так что Raspberry + hostapd + свои мозги = более-менее рабочий вариант.
"en masse"
Защищает не роутер, а межсетевой экран. Если его отключить или криво настроить, роутер всё отроутит и даст доступ к лампочкам даже без проброса портов — я проверял это на практике
Ну вот есть обычный бытовой роутер, берёт у провайдера интернеты и раздаёт его домашним девайсам. Что в нём надо отключить, чтобы снаружи можно было получить прямой доступ к лампочке?
Для начала определитесь, что такое «снаружи»
Если «снаружи» это провайдер — попросите его отправить какие-нибудь пакеты на внутренний IP-адрес вашей лампочки, и при отключенном на роутере межсетевом экране вы вполне обнаружите эти пакеты в своей локальной сети
Если «снаружи» это интернет — они просто не смогут найти маршрут до вашей лампочки (я не знаю способов отправлять пакеты с внутренними IP-адресами через интернет), а даже если каким-то чудом смогут, то их отфильтрует межсетевой экран провайдера (а попросить провайдера отключить его собственный межсетевой экран вы уже вряд ли сможете)
Снаружи - это злые хакеры из интернета.
попросите его отправить какие-нибудь пакеты на внутренний IP-адрес вашей лампочки
Эта... И как они дойдут?
Внешний IP моего роутера, допустим, 1.2.3.4/24, шлюз - 1.2.3.1
Внутренний роутера - 192.168.0.1, лампочки - 192.168.0.168.
Если я попрошу провайдера попасть на 192.168.0.168 даже со шлюза, то как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?
Если «снаружи» это интернет — они просто не смогут найти маршрут до вашей лампочки
Именно. Они упрутся в роутер.
Они упрутся в роутер.
До вашего роутера они вообще не дойдут, потому что не смогут найти маршрут, ваш роутер не имеет никакого отношения к этой защите
Если я попрошу провайдера попасть на 192.168.0.168 даже со шлюза, то как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?
А что должно помешать пролезть? Роутер видит входящий пакет на адрес 192.168.0.168 — роутер пересылает пакет на адрес 192.168.0.168, и я не вижу ничего, что остановило бы роутер от совершения такого действия (собственно, его ничего и не останавливает — повторюсь ещё раз, я ПРОВЕРЯЛ описанное вами действие на практике)
Проверяли во своей внутренней сети? В сети провайдера пакет на адрес 192.168.0.168 не будет маршрутизироваться, он до вашего роутера просто не дойдет
Провайдеру и не надо его маршрутизировать, бытовой роутер подключен к нему напрямую, провайдер может просто взять и отправить пакет непосредственно в Ethernet-кабель (или что там у него) без всяких маршрутизаций, если он того захочет
Под "сетью провайдера" имеется в виду широковещательный сегмент вашего роутера и куска сети провайдера. То есть вашему соседу достаточно сделать ip r a ваша.серая.квартирная.сеть/24 via внешний.адрес.вашего.роутера
Чего, частенько, будет достаточно, чтобы общаться с вашими лампочками.
Защита сети — фаервол на маршрутизаторе. И его настройки по-умолчанию могут быть как адекватными, так и нет, безотносительно версии ip.
Это если у провайдера нет изоляции клиентов (это зависит от провайдера и в общем случае, лучше когда она есть)
Ни разу не видел, чтобы была настроена подобная маршрутизация на бытовых роутерах.
Сейчас попытался так сделать - не работает. Ни трасса, ни пинги не доходят до компа за роутером. Причём роутер даже в трассе не появляется.
Вы не забыли отключить фаервол?
Отключен.
Тогда не знаю что вы делаете не так
Ладно, вы все вынудили меня снова раздолбать мою сеть и повторить эксперимент
Лабораторное оборудование:
длинк с IP-адресом 1.2.3.1 и DHCP-сервером в роли провайдера
кинетик с «внешним» IP-адресом 1.2.3.4 и внутренним IP-адресом 192.168.0.1/24 в роли бытового роутера
компьютер с IP-адресом 192.168.0.168 в роли «лампочки»
гипотетический пользователь этих бытового роутера и «лампочки», который в сетях ничего не понимает
я в роли злого людя, который устроился на работу к провайдеру специально чтобы хакать лампочки
Никакие порты не проброшены, никакие дополнительные маршруты не добавлены (на скриншоте выше кинетик сам сгенерировал маршруты для своей работы)
Итак, поехали: я в качестве злого людя, хочу найти лампочку и подключиться к ней. Процесс поиска IP-адреса опустим, предположим, что я узнал или узнаю перебором, что это именно 192.168.0.168
Так как я провайдер и имею доступ к своему собственному длинку, я могу творить тёмные дела прямо на нём. Захожу на длинк и пробую подключиться к лампочке:
Ой, Network is unreachable
Ну в общем-то логично, откуда длинку знать, куда отправлять пакеты с локальными IP-адресами
Но я же провайдер и имею полный контроль над длинком!
Не проблема — добавляю маршрут для локальных IP-адресов
Пробую ещё раз:
Опаньки
Ошибка исчезла — длинк успешно отправил пакет, но кинетик его дропнул, потому что межсетевой экран делает своё тёмное дело
В захвате трафика на кинетике можно увидеть, что он успешно получает пакеты, но дальше они дропаются межсетевым экраном
Здесь выяснилось, что выключить межсетевой экран на кинетике нельзя ¯\_(ツ)_/¯
Так что вместо выключения смоделирую немного другую ситуацию:
Пользователь пытался запустить майнкрафт-сервер и своими кривыми руками надобавлял разрешающих правил в роутер
Напомню, что мы проверяем ваше утверждение «как его пакет пролезет сквозь роутер до лампочки, если у меня никакие порты не проброшены?», поэтому в рамках данного эксперимента такое устранение влияния межсетевого экрана тоже корректно
Никакие порты НЕ проброшены
(UPnP кстати тоже не установлен)
Ну, что, ещё одна попытка?
ААААААААААА
Без межсетевого экрана кинетик успешно отроутил пакет из внешней сети во внутреннюю
Скриншот из Wireshark, запущенного на «лампочке», это подтверждает
Удаляем разрешающее правило из межсетевого экрана кинетика — пакеты перестают появляться в Wireshark на «лампочке»
Таким образом, по итогам этого эксперимента в очередной раз повторю — NAT ЭТО НЕ ЗАЩИТА, защищает именно межсетевой экран, без него пакеты до лампочки прекрасно пролезают через роутер
NAT ЭТО НЕ ЗАЩИТА
Это хороший дополнительный фактор к защите. Потому что если злоумышленник захочет зайти на условный "192.168.0.х" в домашней сетке удалённо, ему придётся сперва ломануть роутер, а уже от него пойдёт доступ. Но, если мы говорим про провайдерский NAT, сперва придётся как то ломануть именно провайдерскую железку, потому что на внутреннюю серую адресацию (которая не анонсируется в сеть, если что) извне не попасть. Иными словами, "чем помогает NAT - тем что на серую подсеть без анонса не попасть так же как если стучать через белую адресацию". IPv6 с раздачей префиксов облегчает жизнь злоумышленнику. И не надо про firewall и роутеры, уязвимости никто не отменял, а маршруты до условной лампочки с ipv6-пабликом будут
Вы во тут очень хорошо написали:
я в роли злого людя, который устроился на работу к провайдеру специально чтобы хакать лампочки
Не просто устроился. А на нормальную должность с доступом к редактированию ядра сети. И не просто хакать, а наследить в логах так что как минимум уволят а как максимум посадят без проблем и быстро.
Сравните с безымянным миллионом китайцев которые смогут делать тоже самое в вашем ipv6.
Вот это и есть настоящая защита предоставляемая всем НАТом. Вообще всем, независимо от их знаний и умений.
Не просто устроился.
После, например, провайдерского MITM на jabber.ru мой внутренний параноик предпочитает на всякий случай предполагать, что возможно всё
Не просто устроился. А на нормальную должность с доступом к редактированию ядра сети. И не просто хакать, а наследить в логах так что как минимум уволят а как максимум посадят без проблем и быстро.
Вы о чем вообще? У всех крупных операторов целые отделы занимаются воровством данных и слежкой за пользователями. Проблема роутинга внутрь сети стала широко известна когда лет 15 назад какой-то оператор засветился с этим.
Но вообще внутри сети хватает потенциальных источников и без этого. Вы уверены что пока вы читаете это сообщение, скрипты на странице с этим сообщением не подбирают пароль к вашему роутеру?
Вы серьезно? Пруфов естественно не будет? Целые отделы это прям много народа и пруфы соответствующие нужны, а не когда одного человека за 10 лет поймали. Один человек за 10 лет как раз укладывается в крайнюю редкость таких случаев.
CSP это шутка для вас? Давно все уже сделано.
В 2025-м году просить пруфы на то что опсосы подслушивают и воруют персональную информацию, это не просто незамутнённость, а прям хуцпа 80го уровня.
Ладно со скриптами в конфигурации по умолчанию доступа в большинстве случаев нет. Я то в курсе, регулярно веб-интерфейсы отлаживаю и знаю способы обхода CORS). Но остаются гигабайты говнокода на ввсех устройствах в сети. Вы готовы поручиться за каждое устройство, каждое приложение, каждую лампочку?
NAT это именно защита, но от случаев, когда защита не от провайдера. Защиты обычно эшелонированные и это просто один из эшелонов.
Linux kernel rp_filter, т.к. большинство клиентских CPE на линуксе
cat /proc/sys/net/ipv4/conf/default/rp_filter
Linux kernel rp_filter
Это на случай, когда src у пакета будет приватный, но пришел на внешний интерфейс.
Так то технически тут правильно и смаршрутизироваться должно. Вот только на каких домашних маршрутизаторах (не микротиках и самоделках) не включен файрволл "запрещаем соединения снаружи внутрь" - непонятно.
Ради интереса выполнил для default и для всех интерфейсов на своём кинетике — получил сплошные нули. Это плохо?)
зависит от настройки производителем фаерволла. Если там снаружи внутрь можно только умолчательное established/related, то всё ок, иначе провайдер имеет шанс добраться до Вашей любимой коллекции с понями на Вашем домашнем NAS при большом желании.
иначе провайдер имеет шанс добраться до Вашей любимой коллекции с понями на Вашем домашнем NAS при большом желании.
При большом. Ибо src таких пакетов - в домашней сети. Соответственно, NAS будет отдавать ответные пакеты тоже на адреса домашней сети и до провайдера они дойти бы не должны и без всяких файрволлов.
Ибо src таких пакетов - в домашней сети.
Почему? Не вижу технических причин, которые помешали бы провайдеру прописать в src свой собственный адрес — роутеры именно для того и существуют, чтобы роутить такие адреса туда-сюда между разными сетями
Речь идет про опасность отключенного rp_filter.
Он относится к тем пакетам, у которых src адрес - от внутренней сети, а пришли они - на наружный интерфейс (точнее, пришли с того интерфейса, через который по таблицам маршрутизации этот адрес недоступен).
Если провайдер поставил собственный адрес - он под этот фильтр не попадает.
если там есть default gateway прописанный руками или полученный от DHCP, то ответ наружу на маршрутизируемый адрес будет успешным. Другое дело, что по-умолчанию CPE таки не пропустит неинициированный ранее изнутри трафик снаружи внутрь, если нет проброса портов вовнутрь
Вышеупомянутую проверку на практике я делал как раз на кинетике и убеждался, что включение фаерволла начинает дропать пакеты, так что буду считать, что всё ок
Роутер видит входящий пакет на адрес 192.168.0.168 — роутер пересылает пакет на адрес 192.168.0.168
И вот так прямо любой бытовой роутер, если ему на WAN придёт пакет с адресом LAN, пробросит этот пакет в LAN? Без дополнительных настроек и т.п.?
Что такое «без дополнительных настроек»? Если под этой фразой вы имеете в виду отключение фаервола — поздравляю, вы только что сами опровергли свой самый первый комментарий
Без проброса портов, без прописывания дополнительных маршрутов...
Маршрут на локальную сеть и так есть. Иначе устройства в сети не получали бы трафик от роутера. Собственно входящий из интернета NAT трафик подсистема маршрутиззации видит именно как трафик на локальный IP, только адрес подставляется правилом SNAT.
Порты тут вообще не при чем. Вернее проброс портов работает тоже через тот же маршрут, просто правило DNAT меняет адрес назначения с публичного адреса роутера на внутренний адрес устройства в локальной сети (и опционально номер порта).
А что значит упрётся?
(далее пишу упрощенно, но чтобы не потерять суть на примере OpenWRT)
Провайдер может вам в WAN порт послать условно любой набор байт.
Если это эзернет, то любой валидный пакет с мак-адресом роутера или широковещательный на уровне L2, попадёт в ядро. Ядро в заголовке L2 посмотрит номер протокола L3, и если это IP, то передаст на уровень маршрутизации L3. Далее пробежится по таблицам маршрутизации и отправит его в LAN. Порты даже никто смотреть не будет (напомню, что я упрощаю). В правило NAT оно не попадёт т.к. направление противоположное.
В том же OpenWRT древних версий чтобы этого не было надо было добавлять фильтр. Потом вроде его добавили по умолчанию, но это не точно.
Во времена моей провайдерской молодости это была скорее проблема провайдера а не абонента. По лени админов пакеты на локальные адреса уходили по дефолтному маршруту (периодически забегая во внутренние сети провайдера где сидели управляющие интерфейсы оборудования). Плюс можно было получать такой трафик от соседей по широковещательному сегменту (не берусь сказать на сколько это распространено сейчас).
Провайдерам я бы не доверял, особенно крупным именитым, зная как они шарятся по транзитному трафику.
А так локалку может сканировать любое другое устройство в локалке. Те же лампочки. Или любая вкладка браузера через аякс (тут есть нюансы), любое приложение на смартфоне и т.п.
И именно это и есть та самая защита NAT, которой якобы "нет" по мнению авторов статьи и всех остальных, считающих так же.
Ну это слабая защита по вышеописанным причинам, но главное, что IPv6 лучше не делает
я не знаю способов отправлять пакеты с внутренними IP-адресами через интернет)
И именно это и есть та самая защита NAT, которой якобы "нет" по мнению авторов статьи и всех остальных, считающих так же.
Если злые люди завелись у провайдера — никакой NAT уже не поможет
удачи вам в поиске отдельных злых людей, квалификация которых позволит работать в интернет-провайдере за их зарплату и безнаказанно корёжить его ядро с сетью дистрибьюции и доступа только ради доступа к вашей персональной коллекции торрентов. А если вдруг вами действительно заинтересуются спецслужбы, то вы сами им всё на блюдечке принесёте и ещё и будете настойчиво интересоваться устроило ли их то, что вы принесли. Будьте проще: NAT это общественное благо, говорю это как работавший в ISP, в том числе в поддержке в тот момент, когда внешний трафик был помегабайтным и пользователи регулярно влетали в "я этого не качал, за что счёт 100500!?!?"
Ну то есть вся «защита NAT» держится лишь на вере в отсутствие заинтересованных злых людей ¯\_(ツ)_/¯
Это, конечно, хорошо работает на практике и я ничего против такого общественного блага не имею, но называть это «защитой», пожалуйста, не надо
ох уж это ситхианство с его абсолютом: "если нельзя идеально и навсегда, то значит никак нельзя и ничего делать не надо!" :) NAT это достаточно хорошо со многих сторон, включая простоту и дешевизну CPE, именно поэтому IPV6 до сих пор не в массах, хотя вроде бы о кончине блоков IPv4 уже 2 десятилетия говорят
Я надеюсь вы понимаете, что шансы того, что шанс того, что кто-то из сотрудников провайдера, имеющих доступ к ядру сети и обладающий необходимой квалификацией, захочет взломать ваши устройства - он на несколько порядков ниже, чем ваши устройства захочет взломать какой-то из миллионов кулхацкеров из Китая или любой другой точки земли, массово сканирующих интернет в поисках уязвимостей?
чем ваши устройства захочет взломать какой-то из миллионов кулхацкеров из Китая или любой другой точки земли, массово сканирующих интернет в поисках уязвимостей?
Этим миллионам хакерам сначала придется угадать, на какой из адресов обращаться. А на IPv4 сервисы долбятся просто перебором адресного пространства - логи sshd тому свидетель.
Прекрасно понимаю, но это всё ещё не делает фразу «защита NAT» корректной
Конечно-конечно. А учитывая, что злые люди могут завестись и в вашей собственной квартире, весь этот разговор о безопасности сетей вообще не имеет смысла, не так ли? И нет, это даже не шутка и не сарказм - вероятность того, что юзеру навредят его собственные родственники, физически добравшись до его девайсов, многократно превышает вероятность проблем со стороны провайдера.
Всё так, поэтому я не доверяю не только своей локальной сети, но даже локалхосту (всё, для чего нашлась техническая возможность закрыть и/или зашифровать, у меня закрыто и/или зашифровано, впрочем, я пока ещё не продумал защиту от штук вроде BadUSB или DMA-атак)
ИМХО: Если использовать NAT ради защиты - то с практически тем же успехом можно кабель до провайдера ради безопасности перерезать. Как по мне, такого рода "безопасность" сыграла довольно злую шутку - если бы не она, вполне возможно, что IoT не был бы настолько знаменито дырявыми - ведь зачем среднему производителю тратиться на хоть какую-то безопасность, если подключение к камере извне крайне маловероятно?
Не отключить upnp, лампочка сама всё сделает
an-mass только провайдер Интернета сможет отправить на CPE пользователя трафик на локальную сеть 192.168.0.0/24, тогда как злой Интернет не сможет этого сделать своими неусыпными ботосканнерами. Тем массовый NAT и хорош для общественного блага
Главный тормоз — огромный пласт старого контента и сервисов, не имеющих IPv6-версий.
Главный тормоз, это непонимание потребителями, зачем им платить за IPv6? ну и усложнение.
Сейчас будет опыт отдельно взятого хомяка в домашней сети.
Да, мой провайдер поддерживает IPv6, правда уже n-лет грозится начать брать за него деньги, и это проблема номер один - я не очень понимаю, как потребитель, за что буду платить? Сервисы работают и так, скорости не прибавится, ну и что я получу за лишние 100-200-500 рублей? youtube разблокируется начнет работать быстрее, так он и сейчас неплохо работает. Нагрузка с серверов и оборудования упадет - так это не мои проблемы, а проблемы прова\сервисов, для меня они незаметны.
Вторая проблема, безопасность и настройки firewall. Сейчас, приходя в кафе с 99.9% вероятностью я окажусь за NAT'ом и открытые порты на моем ноутбуке будут видны только посетителям этого кафе(вероятность что в нем же окажется хакер Вася, аналогично, ничтожна). Представим, что в общественных сетях IPv6 - мой ноутбук голой жопой окажется в интернете - надо настраивать firewall. А еще ноут жены, ребенка. Кстати, кто знает где и как настраивается firewall на мобиле и планшете? И ладно бы это все настраивалось разово, но ведь надо жеж все поддерживать - тут ребенок захотел создать сервер майнкрафта, тут жене подруга по скайпу p2p хочет файл передать. Это все начинает жрать время - а жонглирование правилами файрволла не то чем я хочу заниматься в свободное от работы время.
Проблема два, более глубока чем кажется. Сейчас каждое второе приложение после установки, радостно запрашивает права на доступ в сеть (да, windows)... для каждой сети мне придется создавать правила условно allow <домашняя сеть>, <корпоративная сеть>, <офис 2>, <VPN> Вы же не хотите, чтобы ваша dev-база данных, с паролем 123, развернутая в docker, оказалась доступной всем желающим? Мы же понимаем что есть пионЭры которые в дев раскатывают прод. данные для поиграться.
Третья проблема - SLAAC. Не, оно конечно классно работает, по сути DHCP-сервер переезжает к прову и становится его головной болью. Для домохозяек прям огонь. А теперь представим, что я хочу прибить гвоздями домашний NAS (ну или майнкрафт-сервер) 2001:0db8:85a3::192:168:88:123. Можно конечно прям так и задать, но вдруг пров. сменит префикс? Нужен DHCPv6, который заберет префикс у прова, раздаст в "локалку" и желательно именно в локалку, а не соседям по подъезду. Клиенты получат RA... уххх движ. В общем, я на микротике не шмог. Что там творится когда имеется два провайдеру - мне не ведомо, но есть подозрение, что так же, все усложняется.
Вот собственно и ответ почему ipv6 особо не взлетает. Боюсь представить какие пополнения у ботнетов будут, если все устройства начнут светиться в дикий интернет, с учетом текущего уровня осведомленности пользователей.
Ну чисстеоретически, все SOHO-маршрутизторы должны продаваться с правилами "запретить весь входящий траффик кроме установленных соединений" - в целом это правило и сейчас есть для IPv4. Тогда домашнему IoTу ничего не грозит.
Забыл написать - в IPv6 не осознал другого. Вот я хочу наглухо изолировать камеру от интернета. Как это сделать если она по SLAAC каждый раз получает новый IP? А компьютер? особенно с учетом того что свиндоус запрашивает два IPv6 - один постоянно меняется и через него она ходит в интернет, а второй постоянный.
Мне кажется, что за использование IPv6 людям надо давать скидки и тогда народ потянется - Кстати, AWS так и сделал, правда через ___опу - стал брать доп. плату за IPv4-адреса
Как это сделать если она по SLAAC каждый раз получает новый IP?
Файрволлы в этих маршрутизаторах вроде бы умеют применять правила по MAC-у. Оно им это для ограничений WiFi устройства надо, но и на проводных интерфейсах должно работать.
А вот если и MAC-и случайно меняются, тут уж надо где-то случайность отключать - потому что иначе как нужное устройство определять? Можно, конечно очень сильно захотеть и 802.1x на порту поднять. Но это в домашней сети делать - ну очень на любителя.
Вот я хочу наглухо изолировать камеру от интернета.
ИМХО, но VLAN + Virtual WLAN. Я так даже без IPv6 домашний IoT изолирую. На совсем примитивных SOHO, конечно, ловить нечего, но на routeros/openwrt/keenetic(?) можно все настроить.
два IPv6 - один постоянно меняется
"IPv6 Privacy Extensions" отключается через netsh, если очень нужно
особо не взлетает
https://www.google.com/intl/en/ipv6/statistics.html да пол интернета почти на нём
Боюсь представить какие пополнения у ботнетов будут, если все устройства начнут светиться в дикий интернет, с учетом текущего уровня осведомленности пользователей.
Если говорить о переборе брутофорсом, то сразу понятно - никакие.
Пользователям предлагается отдавать /64 от 128 битного пространства. Это 2^64 адресов или количество всех ipv4 адресов в квадрате.
Если злоумышленик будет перебирать ваш блок со скоростью 1 млрд адресов в секунду (на секундочку надо канал 500Гбит/c), то ему потребуется 585 лет чтобы просканировать весь блок. Что-то мне подсказывает, что за это время ваше IoT устройство успеет не один раз сломаться и замениться устройством с другим маком и стало быть ip.
Но по побочным канал конечно ipv6 будут часто утекать. Посредством просмотра трафика, посредством попадания логов в чужие руки, недобросовестных сервисов и т.д.
и конечно же никто не догадается делать это в параллельные 100500 потоков, размазав источники по ботнету и во времени. Я 10/8 параллельным nmap за 25 минут проходил в поисках принтеров с snmp-портом
В IPv6 это соответствует 25 минутам на перебор из /104. Остальные 104 бита сколько времени будете перебирать?
Остальные 104 бита сколько времени будете перебирать?
Смотря какой IoT, NASы и p2p-устройства даже перебирать не надо, они сами в DHT-сети светиться будут
значит ли это, что устройства стали недоступны? Долго, но реально, если интересно. А интерес вполне может быть ради ботнетов с участием каждой умной зубочистки и хитрого ёршика для бутылок
Вы не поняли самого главного говоря про ботнеты. Возможность сканирования ботнетами новых устройств для их последующего заражения, собственно роста и формирования этого ботнета, она качественно ограничена гиганскими числами ipv6 адресов и, внезапно, пропускной способностью самого "интернет".
Чтобы просканировать мой блок: нужно отправить (и принять) 48 (ipv6 ping) х 2^64 (моя сеть) = 8.854 х 10^20 байт трафика или 7.084 х 10^21 бит трафика.
Полоса пропускания международных каналов интернет составляет 5 петаБит/c или 5 х 10^15 бит/c. Таким образом поделив 1 на 2 (= контролирую все магистральные каналы интернета) узнаем что это сканирование можно выполнить за 1.417 млн секунд или за 16 дней. И это тот случай когда вы целенаправленно сканируете только мою сеть отключив остальной интернет и вообще не имея никакой возможности маштабирования (никаких 100500 и близко нет). Но в реальности будет гораздо хуже.
Вы для начала должны попасть в мой занятый /64 блок, какой-то из занятых в /48 у конкретного провайдера. Надо понимать что 2^16 тоже довольно много и мало у каких провайдеров будет большая его заполненость.
Вам каким-то образом еще нужно получить этот ipv6 ботнет. Добавляя единицы устройств в месяц, а потом укладывая этими устройствами удаленный канал в полочку, вы врятли добьетесь ощутимого результата. Устройства "тормозящие интернет" будут обнаруживаться самими пользователями и их провайдерами и оперативно отключаться.
Я 10/8 параллельным nmap за 25 минут проходил в поисках принтеров с snmp-портом
А теперь попробуйте посканировать хотя бы денек внешний интернет. Ваш провайдет довольно быстро вам перезвонит.
Вы не заметили главного: тот факт, что вероятность события мала не отменяет возможности события и поэтому потребность в пропуске снаружи внутрь по умолчанию только ответного трафика никуда не девается. Это как с ограблением: и одного раза и не нужно. Если этот фильтр сохраняется для CPE с ipv6, то всё хорошо, за исключением ненужности ipv6 внутри моей локалки за счёт его машиноориентированности при администрировании. Ваша ситуация может отличаться.
не надо никого сканировать. Это методы 30-летней давности. Надо сниффать траффик, посылать броадкаст/мультикаст и смотреть кто ответит, ну и воровать данные у вендора конечно.
Отлично расписано. Я вот, например, не понимаю, как с вот этими всеми ipv6 преимуществами настраивать три буквы на роутере. Если с ipv4 всё как-бы понятно, роутер по настроенным правилам сам маршрутизирует в разные туннели трафик, то с ipv6 ничего не понятно. Допустим, у меня и провайдер, и три буквы предоставляют ipv6. Как теперь на роутере настраивается маршрутизация? Даже вот в простейшем бинарном случае - устройство либо под тремя буквами, либо нет - это уже выглядит как наркомания какая-то. Нужно, чтобы разным устройствам роутер назначал айпи адреса из разных пулов? А как тогда будет маршрутизация в локальной сети работать? В общем, я ничего не понял и продолжил пользоваться "неправильными" ipv4+NAT.
Представим, что в общественных сетях IPv6 - мой ноутбук голой жопой окажется в интернете - надо настраивать firewall.
Да откуда вы эту логику-то берёте? Роутер в кафе ровно так же будет по-умолчанию блокировать соединения снаружи на ваш ноут как и с IPv4.
Третья проблема - SLAAC. Не, оно конечно классно работает, по сути DHCP-сервер переезжает к прову
SLAAC внутри вашей локалки к провайдеру вообще не относится, он работает ровно так же через ваш роутер - клиент получает Router Advertisement от него с префиксом и настраивает себе адрес.
Разберитесь уже как всё работает, перед тем как писать такие комментарии.
Да откуда вы эту логику-то берёте?
Оттуда что кто и что там в недоверенной сети настраивал никому неведомо - хорошо если люди с компетенциями, а если мамкин админ за 15 тыщ рублев? Или вы предлагаете перед каждым подключением заниматься аналитикой - как оно тут все устроено?
Разберитесь уже как всё работает, перед тем как писать такие комментарии.
О! Зашибись, чтобы включить дома IPv6 мне надо разобраться в технологии, потратить 40+ часов - вот прям то о чем мечтаю. А вы не хотите разобраться в электрике дома, ТКЗ считали перед выбором автоматов? А в установке имплантов - ортосвоскую сетку или индивидуальную мембрану?
Оттуда что кто и что там в недоверенной сети настраивал никому неведомо
Вот именно, почему вы полагаетесь что вам не дадут уже сейчас абсолютно прямой и незащищенный IPv4 адрес? Многие провайдеры до сих пор динамические прямые ipv4 выдают.
Еще раз, вы сейчас утверждаете что в каком-нибудь кафе, коворкинге или метро, ISP вместе с админом решат выдать прямые IPv4 клиентам? Вы вот прям серьезно сейчас? Я за свою жизнь таких мест не видел ни разу.
приходя в кафе с 99.9% вероятностью я окажусь за NAT'ом
А много таких мест есть вообще? Точнее говоря хотя бы парочку покажете? Не гиговских, а массовых. Это просто дорого и не делается ровно по этому.
Я утверждаю что если вы ходите в кафе и коворкинги с дырявым ноутом и полагатесь на безопасность wifi что там стоят - вас хакнут с вероятностью близкую к 100%-ам.
Дофига куча дырявых хакнутых роутеров которы дальше заражают всё то что к ним подключено, эти дырявые роутеры торчат с прямыми IP во внешний интернет с дефолтным логином паролем, не говоря просто о физических хакерах для которых сейчас доступ к любой внутренней сетки это прям сказка потому что все живут "пофиг на безопасность мы же за NAT".
Если у админа мозгов не хватает оставить включеным дефолтный фаервол (который включен по дефолту на большинстве IPv6 роутеров) - вряд ли ему хватит мозгов сменить дефолтный логин пароль.
Так вы можете показать несколько таких кафе? Я утверждаю что такого пренебрежимо мало. Как раз благодаря НАТу, особенно провайдерскому. И значит ломать то что отлично защищает ни в коем случае нельзя.
Если смотреть шире, то защита кафе менее критична чем защита дома. В кафе обычный человек приносит телефон и ноут. Они обычно современные нормально сделанные и с правильными дефолтами. А вот дома жуткий зоопарк всего. Защита домашнего роутера и домашних устройств от любого внешнего воздействия силами провайдера очень критична. Провайдерский НАТ ее обеспечивает по умолчанию.
Я утверждаю что если вы ходите в кафе и коворкинги с дырявым ноутом
Каким образом дырявость ноута относится к обсуждаемому вопросу NATа?
ИБ это _комплекс_ мер. Где каждая мера закрывает какие-то вектора атаки и угрозы. Вопрос, к вам, NAT, закрывает какие-либо угрозы?
... подумайте и ответьте себе, не мне, себе, вот беспристрастно и безэмоционально.
если ответ "нет", то пожалуйста не читайте дальше, нам просто нечего обсуждать и предлагаю каждому остаться со своим мнением.
Если ответ "да", то очевидно, что при прочих равных - парольная политика, firewall и пр. NAT это дополнительная защита которую злоумышленнику надо преодолеть. Банальный пример, хоть и высосанный из пальца - имеем три web-сервера, NAT обязует нас воткнуть reverse-proxy. Какую информацию сможет собрать злоумышленник находящийся снаружи об инфре? Да никакую, для него все 5-10-100 сервисов будут висеть на одном IP, сколько там серверов за ним и какие они да х.з. Теперь IPv6, каждый сервер торчит голой жопой... ну как бы... хлоп и сразу видно сколько нод, если IPv6 генерится из мака, то еще и вендора можно определить =\.
Можно это решить firewall'ом? Можно. И если бы все были охрененными специалистами, то проблем бы не было, но, как писал выше не все имеют CCNP, а те кто имеют периодически стреляют себе в ногу из-за человеческого фактора. Кароче, одно отключенное правило и вся инфра голой жопой в интернете.
Firewall+NAT - чтобы открыть доступ к инфре надо прям очень сильно постараться. ОЧЕНЬ. Отказ одной подсистемы не приведет к отказу компроментации инфры. Вот только ради этого NAT стоило бы придумать.
Банальный пример, хоть и высосанный из пальца - имеем три web-сервера, NAT обязует нас воткнуть reverse-proxy. Какую информацию сможет собрать злоумышленник находящийся снаружи об инфре? Да никакую, для него все 5-10-100 сервисов будут висеть на одном IP
Пример настолько высосан из пальца, что никто не запрещает посадить 5-10-100 сервисов за реверс-прокси, и разрешить им общение только с реверс-прокси. А уже реверс-прокси выставлять в интернет. И NAT заставляющий поставить эту прокси тут не нужен, а нужно понимание того что вы хотите получить, и с какой целью.
Теперь IPv6, каждый сервер торчит голой жопой... ну как бы... хлоп и сразу видно сколько нод, если IPv6 генерится из мака, то еще и вендора можно определить =\
Почему ваш фаервол позволяет общаться с ними кому угодно?
Можно это решить firewall'ом? Можно.
Нормально закрытый фаервол уже не в моде?
P.S. мне не хоть и не нравится NAT, можете даже назвать меня фанатиком, но я все же не могу сказать что я принципиально против существования этого инструмента. Но между сетью с NAT, и сетью без NAT я предпочту вторую. Сам же NAT всё ещё остается просто инструментом который может быть применён разумно, а может - нет. Но пожалуйста, не говорите что вы обеспечиваете какую-то «безопасность» (имхо, моветон говорить такое не ссылаясь на модель угроз) посредством NAT, он не инструмент безопасности и её вам не гарантирует.
А все вот эти вот вкусности, типа "всемирный пиртупир, IoT повсеместный и тд" - они же только с доступом извне работают, нет? А если на граничном роутере стоит запрет внешних входящих, то чем это отличается от ipv4 + nat?
Я не очень понимаю о чём вы. Всякие P2P давно делаются через STUN/TURN, это не проблема. Чтобы вывесить свой торрент клиент жопой к миру достаточно открыть порт в фаерволе, делать NAT более не нужно.
Ну и мы тут говорим про дефолтные настройки для домохозяек, чтобы было так же безопасно как и раньше, но с расширенным адресным диапазоном.
Причём тут IoT вообще не понял. Датчики всякие обычно тихонько куда-то свои данные заливают на сервер, им входящие не нужны.
C двумя провайдерами на самом деле должно быть проще - будут...два адреса от каждого провайдера + хитрые и весьма логичные алгоритмы (которые можно тюнить) выбора с какого адреса идет обращение.
Вот только...мало мальски сложное что-то и всплывает что один провайдер - не поддерживает, другой считает что /64 достаточно для пользователя (рекомендации про /48 и "а если вы хотите экономить то для домашних можно /56" предпочитают игнорировать) а пользователю что делать если докеры всякие (да хотя бы проводная+wifi сеть) и при этом у вконтакта едет крыша с музыкой когда к нему обращаются и по IPv4 и IPv6(там привязка к IP и случай с IPv6 некорректно учтен был когда мне вконтакт еще был интересен) а потом начинают внезапно устаревать серверы и для более менее нормальной защиты от устаревания желательно и 2 разных туннеля и разруливать трафик по ним + без туннеля. И получается что IPv6 в итоге все равно вероятно пойдет через туннель до HE.net а настройки сильно усложняются и зачем?
многократно плюсую под вашими словами; однако добавлю от себя:
на мой скромный взгляд последняя по порядку указанная вами причина первая в своей сути. Я честно пытался расковырять и погрузиться в İPv6, при этом я человек на огромном опыте в области сетей и строил сети от ipx/spx до EBGP и MPLS... но видя как сделали ipv6 у меня "волосы стыли в жилах". Нагорожено так, что как говорится "болт в трусах свернешь пока разберешься". Крайне нелогично и неюзабельно начиная собственно от самой адресации типа сокращений "::" - при этом один раз за приседание, второй раз ни-ни...кончая DHCP v6 и собственно самой маршрутизацией. Например, как вам такая сущность как "эникаст"? А? А если поизучать VPN для İPv6 то гдето заплачет практикующий психиатр по вашей головушке.
Я лично пользователь İpv4 с белым адресом, но с удовольствием перевел бы на v6, но как начинаю представлять перечень упражнений для того что бы этим пользоваться, ну уж нафиг. Если бы был какой-то нормальный v6....типа v4, без этого нагороженного идиотизма, что сейчас у v6 - перешел бы с удовольствием.
Скорее бесконечный гипермаркет, где вместо ценников на товарах приклеены ссылки, а вместо охранников — боты, которые периодически кричат «Вы не пройдете без капчи».
Так это же не так, Интернет - это не только сайты.
Но все пошло иначе: костыль превратился в протокол де-факто
NAT это не протокол вообще.
Особенно уязвимы устройства IoT, которые часто подключаются к интернету за CGNAT и не имеют собственных механизмов безопасности.
С точностью до наоборот. Не имея доступного из общей сети адреса устройства IoT защищены лучше даже без собственных механизмов безопасности.
Классический пример — сотни «умных» лампочек, объединенных под одним CGNAT-адресом, которые могут быть захвачены злоумышленниками и использованы для создания мощных ботнетов, способных запускать масштабные DDoS-атаки. Подробнее про взлом домашних приборов и не только я писал в одной из предыдущих статей.
Это вообще на грани фола. Т.к. в статье по ссылке описание атаки, число которых с внедрением IPv6 имеет только один неизбежный путь - к росту. Если сейчас принтеры и лампочки находятся за NAT и чтобы выставить открытый порт "на улицу" нужно постараться, то при использовании IPv6 порт по умолчанию открыт всему миру и нужно постараться, чтобы его закрыть.
обновить IDS/IPS для поддержки ICMPv6 и SEND
Т.е. теперь пользователю нужно будет ещё и IDS/IPS дома держать? А затраты какие на это нужны?
то при использовании IPv6 порт по умолчанию открыт всему миру и нужно постараться, чтобы его закрыть.
Stateful фаерволы на тех же cpe: "Ну да, ну да. Пошли мы нафиг"
Stateful фаерволы на тех же cpe: "Ну да, ну да. Пошли мы нафиг"
А кто их будет настраивать?
Пользователю же "умную" лампочку продают под соусом: "Вы сможете управлять ей из любой точки мира!" Перед выходом из дома заранее узнавать IPv6-подсети тех мест, которые желаем посетить плюс оператора сотовой связи? :))
Пользователь лампочку непременно прямо в точку обмена трафиком подключит. Оптикой на сто гигабит.
А не в домашний wifi, который раздаёт взятый у оператора CPE с линуксом на борту. В котором ВНЕЗАПНО из коробки практически гарантированно включен stateful фаервол, разрешающий снаружи внутрь проходить только пакеты, относящиеся только established и related соединениям. Такшта домохозяйки и бабушки ровно в такой же безопасности, как и сейчас при ipv4.
разрешающий снаружи внутрь проходить только пакеты, относящиеся только established и related соединениям
Т.е. если бабушка уедет в отпуск на море через половину земного шара, то поуправлять лампочкой дома она не сможет? Но ей же впаривали IPv6 и "умные" лампочки именно под соусом "откуда угодно и независимо ни от кого"?
Или я что-то не понимаю, и снаружи можно инициировать соединение с лампочкой без прохождения пакетов со state new внутрь сети?
Сможет. Лампочка с "управлением откуда угодно" будет сюрприз-сюрприз! По условному mqtt/websocket из облака производителя получать команды, которые в облако будет приложенька на телефоне пользователя отправлять. Сама инициировать коннект изнутри наружу и получать пуши. Вы думаете эти облачные сервисы с учетками для чего лепят то?
из облака производителя получать команды, которые в облако будет приложенька на телефоне пользователя отправлять
Вам не кажется, что тут и потерялось то самое "независимо ни от кого" под которым бабушке продавали лампочку с IPv6?
Что будет, когда производитель успешно обанкротится и закроет своё облако? Или даже не обязательно обанкротится: https://killedbygoogle.com/ Не говоря уже о банальной блокировке по стране пользователя. Лампочка превратится в ту грушу из загадки, которую нельзя скушать?
Сама инициировать коннект изнутри наружу и получать пуши
Т.е. всё будет работать абсолютно точно также, как сейчас на IPv4 с NAT? И зачем тогда пользователю этот IPv6? "Чтобы вот"(с)?
Вы думаете эти облачные сервисы с учетками для чего лепят то?
Взимать деньги, формировать vendor lock-in.
Т.е. если бабушка уедет в отпуск на море через половину земного шара, то поуправлять лампочкой дома она не сможет?
Как бабушка это делает сейчас при IPv4 и NAT?
Во-первых, получает у провайдера белый IP-адрес. Чаще всего за деньги. Либо пердолится с ZeroTier и подобными костылями, чтобы обойти провайдерский NAT.
Во-вторых, пробрасывает порт. Чтобы обойти уже NAT своего роутера.
---
Как бабушка будет делать это при IPv6?
Настроит файерволл.
---
А если для бабушки что первое, что второе - какие-то непонятные слова, которые она не хочет понимать, то к её услугам всякие облачные сервисы.
Первая версия комментария, на которую я не успел ответить, была намного лучше.
Как бабушка это делает сейчас при IPv4 и NAT?
Никак. Вы опять забываете, что при IPv4 и NAT ей никто не обещал "откуда угодно и независимо ни от кого".
Как бабушка будет делать это при IPv6?
Настроит файерволл.
Если внедрение IPv6 это "каждая бабушка будет знать, что такое фаерволл и уметь правильно его настроить с закрытыми глазами", то тут, конечно, аргументов против у меня не осталось. Просвещение в сфере информационной безопасности вещь хорошая.
большинство пользователей с трудом добираются в настройки фотоприложения своего мобильного телефона, с каковым приложением они не расстаются годами, а вы от них начинаете требовать знание устройства сетей, протоколов и фаерволлов. И что с этим может быть не так? :)
А зачем пользователю это знание? Он же не знает, как настроен файерволл на его смартфоне, но прекрасно живет, потому что файерволл уже заранее настроен производителем.
На домашнем роутере файерволл тоже включён производителем "из коробки".
На домашнем роутере файерволл тоже включён производителем "из коробки".
TP-Link продаёт или продавал с выключенным[1][2][3].
____
Ещё такие рассуждения про файрвол встретили одобрение на /r/ipv6: "For typical end user devices (modern windows, macos, android, ios) yes there's little point having a network level firewall blocking inbound traffic these days ... In fact an inbound firewall will be more of a nuisance especially with IPv6".
Или на HN: "blocking incoming connections by default is a bad habit and needs to stop".
Если выбрать противоположную точку зрения, то получится ерунда, согласно которой сторонники IPv6 отрицают отказобезопасность NAT по каким-то личным психологическим мотивам (а так они просто не считают NAT отказобезопасным, потому что не считают угрозой открытие соединений извне).
Лампочки с UPnP злобно потирают руки.
Следуя логике господ выше, отключенный на почти каждом CPE из коробки UPnP обычная домохозяйка найти и включить не сможет)
Наоборот включен, что в ролтерах из магазина, что в провайдерских CPE.
А вот IoT с локальным управлением придётся поискать - все лезут в облако за командами и хорошо если дебаг можно включить по блютусу.
IP-камеры тоже. Помню, очень удивился, когда на внешнем IP по 80 порту увидел не свой сервер, а админку камеры.
А роскомтян с IPv6 шалить сложнее или легче?
Практика показала, когда "началась деградация YT", первые дни ipv6 помогал. Потом нет. И "что бы сервис не тормозил по всей локалке" пришлось отказаться от него, "по определённым причинам которые теперь нельзя называть, но помогающие починить сервис". Доступность других заблокированных сервисов с ipv6 точно так же решается, и отключением v6 и "настройкой" на роутере.
Эквипенисуально. Для пользователя IPv6 в плане блокировок может быть даже предпочтительнее.
Например, сейчас, когда какое-то устройство за вашим домашним NAT стучится на определенный адрес, Роскомнадзор включает для вашего IP-адреса запрет доступа к определенным подсетям. Начинают страдать все домашние устройства.
С IPv6 блок словит лишь тот клиент, который постучался, куда не следует.
Всё это хорошо, но сама компания Selectel не дает на своих выделенных серверах ipv6. Только 1 адрес ipv4. А ipv6 только за дополительные деньги. Поэтому подобные статьи от Selectel выглядят для его клиентов издевательски.
С ipv4 проще и нагляднее работать в локальных сетях. А ipv6 имеет преимущество именно в интернете. Предположу вариант, что скорее со временем интернет будет только на ipv6, а подавляющее большинство частных и корпоративных пользователей будут иметь роутер, у которого внешний адрес (или пул адресов ipv6), NAT (возможно даже NAT 1:1) и далее локалка ipv4 для всей домашней инфраструктуры.
Т.е. ipv6 полностью не вытеснит ipv4. Они разделят области использования, но продолжат сосуществовать параллельно.
Т.е. ipv6 полностью не вытеснит ipv4. Они разделят области использования, но продолжат сосуществовать параллельно.
Во многих странах они просто работают параллельно сейчас, в т.ч. в домашних роутерах от провайдеров - IPv6 + IPv4/NAT
И будут так параллельно работать до тех пор пока весь интернет не переползёт на v6.
А чем они проще? Я вот дома сделал себе сеть fd22::/48. Вводить проще, чем 192.168.1.0. Хотя такая адресация не приветствуется. Но кто мне дома запретит. Да и сменить адресацию я легко смогу во всей сети изменив настройки маршрутизатора.
Пишем статью про NAT, а рассказывает про PAT. Чувствуется запашок ИИ.
Всё это безусловно прекрасно. Но работать будет только при условии, что никто не будет лезть в трафик и его тем или иным способом цензурировать.
Как только в дело вступает кто-то регулирующий куда ходить можно, а куда нельзя, сразу все эти bgp накрываются медным тазом.
А если это всё ещё и по IP6, то получается вообще винегрет, который никак не будет работать. Столкнулся с этим, когда сервера Ютуба стали внезапно деградировать. Помогло только отключение IP6, который был настроен через IP4, с выделением своего диапазона.
IP4 намного проще конфигуриукется ручками в присутствии неких злобных буратин портящих трафик.
Утомила эта методичка про опасный NAT и безопасный V6.
Замена серых V4+NAT на белые V6 безопасность не повышает.
Да, NAT не решает всех проблем с безопасностью. Ну так никто и не обещал.
Двойной NAT тоже не особенно проблема. Хоть десятерной, всё прекрасно работает. Ну там могут быть сложности с пробросом портов. И всё.
Первым делом везде в локалках убиваю V6. Потому, что мутная неудобная настройка ради ничего. Недавно после обновления у меня сдох в локальной сети KDE connect. Потому, что какие-то чуда перевели принудительно на V6.
Кстати, то с каким рвением адепты методички "каждому по белому V6" сопротивляются внедрению NAT v6-to-v6 заставляет задуматься о злом умысле.
Утомила эта методичка про опасный NAT и безопасный V6.
Восхитетельно. Никто не говорит что «nat» опасен, но «v6» тебя защитит. v6 хоть и имеет преимущества перед v4, но в обоих случаях «защитой» должен заниматься фаервол, а не ipv4v6.
Замена серых V4+NAT на белые V6 безопасность не повышает.
NAT - не защита, вообще. NAT - это про сломанную связность в сети
Да, NAT не решает всех проблем с безопасностью
Он их вообще не решает, ибо
так никто и не обещал.
Двойной NAT тоже не особенно проблема. Хоть десятерной, всё прекрасно работает. Ну там могут быть сложности с пробросом портов. И всё.
Спасибо, но нет, это не «прекрасно работает»
Первым делом везде в локалках убиваю V6. Потому, что мутная неудобная настройка ради ничего.
Мне даже любопытно, что же там такого муторного нужно настраивать, я заинтригован
Недавно после обновления у меня сдох в локальной сети KDE connect. Потому, что какие-то чуда перевели принудительно на V6.
Проблемы с вашим софтом в вашей сломанной системе решать только вам. Наверняка меинтейнеры проекта не ждали такой подставы от вас
Кстати, то с каким рвением адепты методички "каждому по белому V6" сопротивляются внедрению NAT v6-to-v6 заставляет задуматься о злом умысле.
Мне непонятен этот тезис, если можно избавиться от трансляции адресов - от неё стоит избавиться. А смысл менять один NAT на другой?
NAT - не защита, вообще. NAT - это про сломанную связность в сети
Вообще не в ту сторону уходите.
Зачем провайдеру иметь маршруты до локалхоста клиента? (речь про домашнюю или внутреннюю офисную сеть).
Зачем условному домашнему пользователю наличие до него маршрута из сети? Что бы что? У нас каждый второй поднимает дома Minecraft (или какой там) сервер?
NAT работает нормально в подавляющем большинстве случаев. Я могу понять когда операторам не сильно хочется вливать деньги в NAT, всё таки излишнее железо и издержки, а трафик растёт. Но так же я могу понять зачем условному РКН нужно что бы меньше пользователей было за провайдерскими NAT, уже были слухи о сборах данных в плане "кто, откуда, с каким протоколом и т д" использует трафик в сети, особенно "три весёлые буквы"
Зачем провайдеру иметь маршруты до локалхоста клиента? (речь про домашнюю или внутреннюю офисную сеть).
У него маршрут будет только до моего роутера, но и в случае v4 он у него есть. А дальше роутера я его не пущу, если, конечно, провайдер решил развёртывать v6 в соответствии с рекомендациями.
Зачем условному домашнему пользователю наличие до него маршрута из сети? Что бы что? У нас каждый второй поднимает дома Minecraft (или какой там) сервер?
А если человек хочет поднять Minecraft-сервер для себя и друзей, значит он какой-то не такой? Или он не имеет права на такие желания? Пользователи компьютера не ограничиваются пользователями веб-браузера. А многослойный NAT точно также может портить жизнь при звонках в интернете и играх с мультиплеером, где архитектура рассчитана на связь в том числе игроков и напрямую
NAT работает нормально в подавляющем большинстве случаев.
У нас разные представления о нормальности, кроме того это тоже накладные расходы на вычислительную мощность сети провайдера.
Я могу понять когда операторам не сильно хочется вливать деньги в NAT, всё таки излишнее железо и издержки, а трафик растёт
Мне кажется железо всех магистралов умеет в v6, да и провайдеры мельче все же потихоньку оборудование обновляют, а если даже есть железки которые не могут - так сколько им лет уже? Да и издержки… isp все равно поступят также как и всегда, перенесут их на клиентов.
Но так же я могу понять зачем условному РКН нужно что бы меньше пользователей было за провайдерскими NAT
Им всё равно, их коробка стоит перед провайдерским NAT, со внутренней сети провайдера. Насколько я понимаю.
"кто, откуда, с каким протоколом и т д" использует трафик в сети, особенно "три весёлые буквы"
В v6 в этом никак РКН не поможет, но и никак не навредит
У него маршрут будет только до моего роутера, но и в случае v4 он у него есть.
Да, но.... Вот допустим есть локалка с делегированным префиксом от провайдера. Получается внутри домашней сети "белый" IPv6 будут иметь всё что поддерживает, от компьютера до смартфона и "умных вещей". В случае v4 маршрут упирается в роутер, а в случае v6 он спокойно дойдёт до конечного девайса.
В v6 в этом никак РКН не поможет
Когда раздаётся префикс, он именно что белый. Зная с какого префикса идут запросы - проще составить "запрос оператору" на идентификацию пользователя, т.е. легче сопоставить данные, чем если мы имеем серый паблик с NAT'ом. Просто дополнительный фактор для облегчения работы РКН.
А если человек хочет поднять Minecraft-сервер для себя и друзей, значит он какой-то не такой?
Обычно такие пользователи подключают услугу статического IP, который практически всегда подразумевает именно белую статику, всё просто.
За других операторов не подскажу, у Дом.ру долгое время была опция просто выключить серый IP, и за это не надо платить, паблик будет просто меняться. По факту провайдеры не мешают (за некоторыми исключениями) сделать свой домашний сервер, но доля таких пользователей небольшая, и их вопросы решаемы
Зачем условному домашнему пользователю наличие до него маршрута из сети?
Например, чтобы голосовая и видеосвязь работали напрямую, а не через промежуточный сервер.
Тут достаточно одного STUN, который разруливает вопросики между клиентами за NAT.
NAT - не защита, вообще. NAT - это про сломанную связность в сети
Только всё наоборот.
Нарушение связанности вполне себе один из методов защиты. И раз уж вы упомянули, то нат связанность повышает, а не понижает. А фаервол это как раз "про сломанную связанность".
Проблемы с вашим софтом в вашей сломанной системе решать только вам.
Проблема не только у меня одного, добрые люди патчик сделали. Я просто пока не хочу дистрибутив ломать, до этого они так не лажали, может, починят.
Кстати еще одну дырень IPv6 вспомнил. Имея отдельные адреса на конечных устройствах пров может их как минимум посчитать (точнее, чем за натом). И использовать эту информацию во зло (не буду подсказывать), как и любую другую информацию.
А если человек хочет поднять Minecraft-сервер для себя и друзей, значит он какой-то не такой?
Ну так пусть поднимает у себя хоть v6, хоть что угодно. А я у себя v6 дальше роутера пускать не буду до тех пор пока это возможно или пока мне не понадобится.
И раз уж вы упомянули, то нат связанность повышает, а не понижает
ну не может технология увеличить связность сети, если она блокирует возможность прямого соединения.
А фаервол это как раз "про сломанную связанность".
Это про блокировку того, что не разрешено, а не разрыв связности
Имея отдельные адреса на конечных устройствах пров может их как минимум посчитать (точнее, чем за натом)
Эмм, нет, он дал тебе префикс, а сколько устройств он не знает. Это может быть как тысяча устройств, так и одно с тысячи адресов.
Ну так пусть поднимает у себя хоть v6, хоть что угодно. А я у себя v6 дальше роутера пускать не буду до тех пор пока это возможно или пока мне не понадобится.
Не пускай, наличие IPv6 не запрещает тебе поступить так. А вот отсутствие IPv6 мешает человеку поднять сервер.
Из раза в раз, одно и тоже, люди не понимают и не хотят понимать IPv6. Люди привыкли к IPv4 и тащат свои паттерны поведения в IPv6 не смотря на то, что там это антипаттерны и так делать не стоит
ну не может технология увеличить связность сети, если она блокирует возможность прямого соединения.
НАТ ничего не блокирует.
Устройство может иметь несколько адресов. С IPv6 это обычное дело.
Это может быть как тысяча устройств, так и одно с тысячи адресов.
Так или иначе добавляется еще один канал утечки информации.
Ну и калейдоскоп адресов точно не упрощает управление всем этим. И эту ротацию кстати придумали позднее в качестве костыля. Не везде она поддерживается.
Люди привыкли к IPv4 и тащат свои паттерны поведения в IPv6 не смотря на то, что там это антипаттерны и так делать не стоит
Вы не думали о том, что ваш v6 вместе с его паттернами может быть кому-то просто не нужен?
Это про блокировку того, что не разрешено, а не разрыв связности
Кстати, если говорить про какой-нибудь iptables на на openwrt, то он опасен тем, что может вообще не подняться. Например из-за ошибки в конфигурации (там даже накостылили команду тестирования конфигурации), но не только. Плюс есть (по крайней мере раньше был) временной лаг (пусть и маленький) между поднятием маршрутиззации и поднятием фаервола.
Я например для одного относительно ответственного применения из-за этого выключал маршрутизацию по умолчанию. А после загрузки тестировал фаервол и только потом включал маршрутизацию. На сколько я знаю в SOHO так не упарываются.
По этому отсутствие маршрутизируемых адресов надёжнее препятствует установлению соединения снаружи.
У моего роутера внешний IP 10.2.1.214 Вы наверно легко отправите на него один пакет, раз NAT ничего не блокирует?
У моего роутера внешний IP 10.2.1.214
Если у вашего роутера такой адрес, то это означает, что у него нет внешнего адреса. Даже если он на WAN интерфейсе.
Автор выше решил поспорить за терминологию. Раз уж вы подхватили его выпавшее знамя...
NAT это система трансляции адресов. Т.е. алгоритм, программа, модуль ядра и т.п.
Если я отправлю пакет на этот адрес, он убьется фаерволом или маршрутизатором по destination unreachable или попадёт в routing loop и убьется по ttl expired. Есть другие менее вероятные сценарии, но в любом случае NAT не будет иметь к этому ни малейшего отношения.
Если я вдруг окажусь вашим соседом по провайдеру без изоляции абонентов с адресом 10.2.1.213, то пакет прекрасно дойдёт до вашего роутера, но в обработку NAT не попадёт.
Т.е. ни в одном разумном сценарии NAT ничего блокировать не будет.
Зайдём с другой стороны. Если вы отключите НАТ это как-то повлияет на возможность установки соединения извне?
Т.е. причина не в нат, а как выше верно заметили в том, что у вас нет "внешнего" адреса.
Даже деревенские провайдеры освоили vlan-per-user. Нет, не окажетесь.
Так если нат ничего не блокирует отправьте один пакет на мой внешний адрес.
Есть второй провайдерский нат. Нет не повлияет. Мой местный нат просто для удобства. Ну и дополнительный слой защиты на всякий случай. Шанс взлома провайдера мал, но не равен нулю. Так что пусть будет. Есть не просит.
Не надо ломать то что хорошо работает. Клиентское оборудование скрыто от дикого интернета бай дизайн. Это оказалось очень хорошим решением. Любое новое решение должно поддерживать этот кейс.
Даже деревенские провайдеры освоили vlan-per-user. Нет, не окажетесь.
vlan-per-user как раз удел деревенских провайдеров (был лет 20 назад).
Вообще изоляция портов это немного другое, но в любом случае я могу попытать счастья и отправить пакет на шлюз, а он его с некоторой вероятностью переправит вам.
Не надо ломать то что хорошо работает. Клиентское оборудование скрыто от дикого интернета бай дизайн. Это оказалось очень хорошим решением. Любое новое решение должно поддерживать этот кейс.
Если вы мои сообщения в этой теме полистаете, то увидите что я примерно тоже самое и пишу. Просто выше я стал оппонировать стороннику другого мнения его же аргументами. А вы, видимо, эти аргуменнты приняли за поддержку.
Так если нат ничего не блокирует отправьте один пакет на мой внешний адрес.
Тут нет причинно следственной связи.
К тому же отправить то мне ничего не помешает (кроме лени). А то, что вы его не получите, так это "проблема на вашей стороне".
А вот отсутствие IPv6 мешает человеку поднять сервер.
Кому мешает? Чем мешает? У меня дома динамический IP на провайдерском домашнем роутере, к которому даже особо доступа нет. Я через DMZ прокинул свой роутер (двойной нат? Тройной?) и без проблем 24/7 занимаюсь хостингом пары игровых серверов для друзей по всему миру, держу несколько вебсайтов и личное интернет радио. Проблем с подключением не наблюдалось ни у кого.
У тебя либо «белый» ipv4, либо провайдер транслирует адрес 1-в-1. В обоих случаях проблем нет. И оба эти случая неинтересны, так как не вызывают особых проблем, хотя и иногда устройству предварительно нужно узнать свой внешний адрес
А то что это «динамика» - это другое свойство, так же не имеющее отношения к вопросу
динамический IP
Динамический но белый, а вот без белого у вас бы это не получилось так просто. Хотя сейчас есть конечно всякие Zerotier с бесплатными тарифами, которых хватит на поиграть с друзьями, или Cloudflare Tunnel чтобы опублиуовать сайт с серого адреса, но это в любом случае костыли, и я слабо понимаю почему за них все так цепляются. Ну и наличие возможности выдать каждому устройству в локальной сети свой ip во первых не означает обязанности это делать, а во-вторых, не отменяет фаервола. Само же по себе наличие возможности на мой взгляд всегда лучше, чем ее отсутствие.
пров может их как минимум посчитать
Устройство может иметь несколько адресов. С IPv6 это обычное дело.
Расскажите про CGNAT властям Казахстана.
С недавних пор налоговая отслеживает, с каких IP-адресов отправляются формы налоговой отчетности.
Если зафиксирована отправка отчетов разных юрлиц с одного и того же IP-адреса, считается, что это один и тот же бухгалтер в по сути одном и том же предприятии, которое злонамеренно подробили на несколько юрлиц с целью ухода от налогов.
Соответственно, все такие юрлица берутся «на карандаш».
То есть под это попадают и все юрлица с бухгалтерией на аутсорсе?
Ну он не говорит, что их сразу наказывают, просто берут на карандаш, а дальше у них будет "белый" список аутсорс контор.
Так в это и цель, КМК.
Раньше руководители фирм давали аутсорс-бухгалтерараи ЭЦП для авторизации и отправки всевозможных документов. Сейчас передачу ЭЦП запретили и ввели за это большой штраф.
CGNAT властям Казахстана.
Это же не только cgnat, любой нат с пулом адресов (которые строго говоря могут быть просто набором адресов, списком, а не cidr)
Не знаю, сколько не крутил, NAT позволяет выстроить в квартире четкую систему что с чем взаимодействует и это без выхода наружу. IP6 даст только проблемы. Длинные адреса, которые никак не запомнить нормально, все взаимодействие через фаервол теперь?
Две конторы, соединение через приватную сеть, а роутер уже сам решает что в инет, что по приватной сети пускать, а что внутри сети так и остается. А с отдельными адресами у каждого ящика что делать? Не хочу камеру наблюдения в инете иметь. В локалке с любого места доступ, а по IP6 нужно как-то отслеживать все изменения адресов, и камера и не только легко могут оказаться где-то снаружи портами. Несколько раз в день следить не поменял ли кто адрес в сети, ну так себе идея. Гораздо лучше смотрелась бы концепция NAT IP6. Тогда и свой мирок проще контролировать и от провайдера местами абсолютно не зависишь внутри сети и просто безопасней. Когда придумывали IP6 часто было дома только одно устройство, ну еще парочку добавить и все. Тогда логичным казалось всему дать свой адрес. Сейчас, когда только дома может быть десятки устройств, те же смартфоны имеют опцию динамического изменения MAC при подключении, и куча устройств его позволяет менять настроить сеть адекватно когда все смотрит напрямую в инет еще а задача будет. Я жду NAT IP6-to-IP6. Что бы я решал что в инет смотрит, что нет и это был прозрачно и удобно.
В упор не понимаю как NAT решает
что в инет смотрит, что нет и это был прозрачно и удобно
NAT транслирует адреса в заголовках. Связность - вопрос роутинга. Безопасность - фаервола. В любом пользовательском CPE/условном микротике/всяких мелкоэнтерпрайзных роутерах/ngfw и прочих таких штуках есть всё из вышеперечисленного.
Есть гайды как это настроить? Пишу не ради флуда, реально интересно увидеть, как это всё разруливается.
Фаерволы не панацея их тоже ломают, тоже имеют баги. NAT же просто еще один слой шелухи в защите.
По домам покупают обычно самое дешевое. Был случай в небольшой конторе, посоветовал микротик купить типа надежно и вам хватит. Купили, приперли к провайдеру, провайдер поудивлялся и отказался хоть что-то делать в этим микротиком ибо сложно. Нужно будет более грамотная настройка более дорогое оборудование. Для дома тоже дороже. взаимодействие сложнее прописать будет всего и вся.
Не хочу камеру наблюдения в инете иметь.
Ну и скажете этим IPv6 камерам сидеть только на Link Local - эти адреса маршрутизироваться не должны. Соответственно, и с интеренета будут недоступны.
Ну или постоянные из тех же приватных адресов, но уже IPv6 версий.
NAT-то зачем? К какому-то серверу чтобы они цеплялись? Ну вот тут VPN нужно использовать по оригинальному назначению - приватный сегмент с его помощью дотягивается до сервера и камеры отлично с ним общаются, образуя 'свой мирок'.
Вот. И тут мы подошли к тому, что адресов у одного устройства несколько, разных, 9 похоже не потолок. Если мне видеокамера нужна в другой подсети для просмотра? Сколько в фаерволе появится различных правил на 1 устройство с разными адресами? Ведь даже появляется несколько вариантов выхода в интернет через различные механизмы у разных адресов. Зачем это внутри маленькой сети нужно? В большой похоже сложно будет очень это разгребать. VPN смотрится для своего мирка в данном случае проблемно. Камера должна уметь, сервер должен уметь, должны работать внутри сети без внешнего IP6... На пустом месте сильно усложнили задачу.
Я не встречал еще описания перевода сети конторы с подсетями и связью через VPN на IP6. Это возможно и явно делали. Но какие проблемы возникали, как разгребали и что в конце концов получили? Было бы все так просто уже давно бы сидели на IP6.
Это надо чтобы камера давала такое настроить. А если такая настройка просто недоступна? Фильтровать по mac?
Длинные адреса, которые никак не запомнить нормально, все взаимодействие через фаервол теперь?
Зачем их запоминать? Зачем тебе длинный адрес, нельзя дать после префикса пачку нулей?
Не хочу камеру наблюдения в инете иметь
И не надо, пусть камеры общаются только с вашим сервером видеонаблюдения, а уже с ним - я думаю вы придумаете что-то
а по IP6 нужно как-то отслеживать все изменения адресов
Почему они должны меняться?
не только легко могут оказаться где-то снаружи портами
Если она общается только с вашим сервером, то как? И почему ваш фаервол разрешает такое свободное подключение?
Несколько раз в день следить не поменял ли кто адрес в сети, ну так себе идея
Не, пасиб, я таким заниматься не буду. И вам не советую.
Сейчас, когда только дома может быть десятки устройств, те же смартфоны имеют опцию динамического изменения MAC при подключении, и куча устройств его позволяет менять настроить сеть адекватно когда все смотрит напрямую в инет еще а задача будет
Если не тащить привычки из v4 все должно получиться.
Я жду NAT IP6-to-IP6
NPTv6? Или оно не подходит?
Фаервол во первых должен иметься и производительный похоже. Во вторых судя по всему через ip6 есть несколько вариантов получения интернета устройством, их все нужно предусмотреть, как и взаимодействие на различных адресах, которое тоже может дублироваться.
Провайдер обычно выделяет каждому клиенту сеть IPv6/64 Это сколько адресов? Мне нужно как минимум в диапазоне прописывать все адреса, и вариации адресов и трансляций. И что это мне даст в итоге? NAT какая никакая, но защита, да не лучшая, но ощутимая. А если вся надежда только на фаервол, то это -1 уровень "защиты". А если в фаерволе дыра? Сейчас не так и мало обнаруживают уязвимостей и там все на блюдечке уже и в мешанине адресов и правил попробуй разобрать, что что-то новое появилось даже если его видно.
В NPTv6 трансляция адресов производится 1:1 по адресам т.е. прописывать в фарволе нужно все адреса. Что делать если один провайдер отпал, и интернет пошел от второго или вообще третьего?
NPTv6 изменяет только что изменяются только первые 12 символов (48 бит), остальные символы остаются неизменными.
Провайдер обычно выделяет каждому клиенту сеть IPv6/64
Это очень ленивый провайдер.
Этот /64 о котором говорится - это адрес/префикс на внешнем интерфейсе роутера а не адрес для использования клиентом внутри своей сетки.
И этот адрес клиента не должен интересовать от слова совсем. Потому что дополнительно к этому оператор должен настроить маршрут еще какого-то /56 (ну или /48, если клиент большой) через этот самый IP. Ну в самом-самом крайнем случае (не знаю, из каких соображений - экономить адреса тут явно смысла не имеет) -- еще один /64
И уже вот эту /56 клиент и должен использовать, нарезая и раздавая внутрь своей сети как ему надо.
Мне нужно как минимум в диапазоне прописывать все адреса
Префиксы
В NPTv6 трансляция адресов производится 1:1 по адресам
И префиксам, адреса будут одинаковы
остальные символы остаются неизменными
Зачем их тебе менять? Ты изменил префикс и всё
Длинные адреса, которые никак не запомнить нормально
Ну тут проблема только с префиксом, да. Народ сейчас активно "столбит" вские dead:beef:feed:face
С суффиксом все проще - во-первых можно тупо использовать десятичную систему поверх шестнадцатеричной: :0192:0168:0088:0001 и сокращать это до :192:168:88:1Во-вторых, 4 группы, каждой можно забить логические устройства, ну там в первом хекстете у нас IoT, во-втором ПК, в третьем принтера, в четвертом коммутаторы
Третье - DNS, да.
Длинные адреса, которые никак не запомнить нормально
Нахрена их вообще запоминать?
Например, у меня в локалке подняты 4 виртуальные машины. Так вот, в какой-то момент я обнаружил, что могу к ним подключаться вообще не указывая IP-адрес, чисто по имени хоста. В принципе, я и раньше не запоминал их адреса, для этого у меня есть KeePass, в котором удобно хранятся реквизиты подключений, приватные ключи и прочее, так что достаточно буквально двойного клика по записи, чтобы подключение поднялось автоматически. Но, даже если мне придётся подключаться вручную, я просто имя хоста укажу.
Фокус в том что резолв между именем и адресом выполняет .... (барабанная дробь)...ДНС сервер...если его в сети нет, то и резолвить никто не будет. Вы можете не запоминать адреса и помнить только имена хостов, но тогда их запомнить должен сервер. Можно иметь днс, можно иметь кипас и прочую требуху....но когда у тебя в сети 3 хоста...то запомнить в голове намного проще 192.168.1.(1...2...3) и можно днс не прописывать.
ДНС сервер...если его в сети нет, то и резолвить никто не будет.
Неверно. Смотри mDNS. Именно через него (и то что рядом) оно и работает в сети из трех хостов.
Одним ООП не нравится, другим вдруг перестал NAT нравится. Что следующее? Отказ от мышки потому что это вредно для здоровья?
У меня есть несколько будущих заголовков:
«Клавиатуры устарели: Будущее за управлением голосом через крики в микрофон»
«Git — это слишком сложно: Почему возврат к FTP — это прогресс»
«Тёмные темы в IDE вызывают слепоту: Почему белый фон — это must-have»
«Отладка — это харассмент: Настоящие программисты пишут код с первого раза»
«Кэш — это зло: Зачем хранить данные, если можно вычислять их заново?»
«Agile — это секта: Почему водопадная модель вернётся в 2025»
Такие статьи должно быть помечены как юморные.
иногда кэш - это действительно зло. Если не понимать, как он работает
«Клавиатуры устарели: Будущее за управлением голосом через стоны в микрофон»
вот это точно найдет применение в известно какой сфере :D
1 - это сейчас есть, Гугл ассистент, Алиса, GPT (пока частично), так то да, Будущее за управлением голосом через крики в микрофон»
5 - тут тоже не однозначно, раздутый и тухлый кеш - такое себе.
Отказ от мышки потому что это вредно для здоровья?
Ну так уже давно. Любой линуксоид знает, что лучший интерфейс в emacs'е.
Извините, а это постирония или просто сарказм/ирония? Я так-то с половиной пунктов согласен безоговорочно, а еще с одним пунктом согласен условно.
ну формально FTP и GİT - несколько разные вещи как "кислое" и "красное"...ну и ФТП это очень зря забытый протокол...есть SFTP ему на замену, но к сожалению люди склонны "жрать кактус" и посему не используют очень хороший протокол. GİT не решает задач которые решает файлообменный протокол...да и не должен решать, у него другие задачи.
Немного не понял вот этих слов про то, что ipv6 не поддерживают маленькие региональные провайдеры.
Мне бы очень хотелось получить списочек хотя бы из пяти-шести крупных провайдеров масштабов России, которые все поголовно предлагают шестую версию клиентам.
Их сотовых проде только МТС. Би и теле забили болт, мега с йотой вообще изобретают какие-то велосипеды, и шестерка в их названиях отсутствует. РТ, возможно, что-то и предлагает, у них по стране сервисы сильно разнятся. В общем, даже захочешь попробовать - а не у кого почти! В то время как маленькие реоиональные операторы иногда и пилят ipv6 поддержку. Но - и правда, они маленькие и погоды не делают.
А вот что клиентов надо учить ipv6 "настоящим образом" - это факт.
Есть пример с городским провайдером на IPv6 (опциональным). Подключили клиенту вместо IPv4 и понеслась. Интернет есть на всех устройствах - да, супер. Дальше надо закинуть что-то на NAS. А какой у него адрес? Подключиться к видеорегистратору - а как это сделать? Молчу про то, что даже сами камеры с регистратора отвалились, потому что больше нет никаких 192.... Конечно, наверно надо было сильно раскуривать как это работает. Но проще оказалось позвонить в ТП и попросить вернуть IPv4/
на мтс смешно, хочешь белый ип - держи, но только в4 и в6 с ним работать не будет
Не везде, но у Дом.ру (ЭР-Телеком) есть IPv6, главное условие - подключение должно быть через PPPoE, тогда можно через ЛК включить выдачу префикса и роутер должен быть настроен для раздачи локальным клиентам. Но такая опция не везде присутствует, и на части купленных активов (типа InterZet) такого нет. У Ростелекома где-то был ipv6 с PPPoE, про других операторов не слышал даже про тестовые включения, но возможно тут люди подскажут.
А чем все-таки плох именно двойной NAT? Нигде не видел разумного объяснения, только пишут о возможных проблемах в онлайн играх и VoIP приложениях. Можно было бы предположить, дело в том, что P2P трафик между клиентами не может ходить - но тут никакой разницы между NAT и двойным NAT нет. Даже если на домашнем роутере есть UPnP для автоматического (без вмешательства со стороны пользователя) проброса портов через NAT, провайдерский CGNAT все равно P2P не пропустит.
Другой нюанс, что на старых роутерах NAT отнимал и так скромные ресурсы домашних маршрутизаторов, что увеличивало пинг и снижало скорость. Но уже давно и почти везде есть Hardware NAT, который способен переварить полную пропускную способность, предоставляемую провайдерами.
В общем, если кто-то знает, почему весь интернет (и теперь еще ИИ) запомнил, что двойной NAT - это плохо, поделитесь, пожалуйста. Правда интересно, чем это исторически вызвано.
Что касается IPv6 - чтобы он полностью вытеснил IPv4 нужно очень много денег и маркетинга. Если провайдеры придумают, как продать конечному пользователю услугу типа "IPv6 ready", и пользователи поймут, за что им предлагается заплатить, может что-то и поменяется. А пока соцсети и прочий тикток прекрасно работают на том, что есть.
тут никакой разницы между NAT и двойным NAT нет.
Очень даже есть. Двойной NAT накладывает похожие на симметричный NAT ограничения. Настоящий P2P без ГМО пробития дыры в NAT, конечно, не будет работать ни там, ни там, но P2P с пробитием через STUN работает везде, кроме симметричного NAT. А бесплатных серверов STUN в мире более чем предостаточно, в отличие от ретранслирующих TURN, являющихся единственным способом связать двух людей за симметричным NAT.
Сейчас роутеры красиво и понятно организуют подсети внутри периметра. А что будет при использовании IPv6? Вот мне надо с одного хоста по VNC подключиться к другому внутри локалки. Это надо запоминать гигантский белый адрес для этого? И все устройства будут светиться в сеть? Хотелось бы почитать гайды или реальные кейсы в стиле "наша корпоративная сеть 200+ хостов перешла на IPv6. И вот как это работает". И примеры повседневных задач. Как подключиться к серверу, как сделать двойной горизонт DNS и так далее. РЕАЛЬНЫЕ кейсы, а не "переходим на IPv6, потому что надо".
Как подключиться к серверу
Я не знаю, как в большой сети, но в моей локальной я поставил первый попавшийся дебиан на мелкий сервачек. И после этого он сразу, без лишних движений и конфигурирований со моей стороны, себя в зоне .local по имени обнаружил и сразу же заработал как раз по IPv6 Link Local. Вот прямо по человеческому имени коробочки.
PS C:\> ping nettop.local
Обмен пакетами с nettop.local [fe80::201:2eff:fe2b:dad6%18] с 32 байтами данных:
Ответ от fe80::201:2eff:fe2b:dad6%18: время<1мс
Ответ от fe80::201:2eff:fe2b:dad6%18: время<1мсssh и разные samba так же по этому IPv6 ходят. Адреса, да еще с номером интерфейса я, разумеется не помнил и не помню.
Правда, IPv6 от провайдера у меня нет. А внутренний IPv6 - как видим, есть и работает без всяких конфигураций.
Но когда я экспериментировал с IPv6 от Hurricane Electric (давно уже) - тоже, вроде, ничего не ломалось.
Если 'маленькая сеть' - это все таки не один сегмент а несколько с разными подсетями - то все имена - через DNS сервер, разумеется. То что внутренние адреса не раскрывать наружу - ну не верю я, что сильно больше головной боли чем в IPv4.
Да это так и работает сам сделал себе сеть но только нормально приватный диапазон это FD::00 и так далее
Доооо, отличное, волшебное решение. Подсказать что будет если вы подключитесь к своей домашней сети через VPN? А если я такой извращенец что у меня есть гостевой wi-fi (о боже!) или не дай бог подсеть для умных устройств со своим сводом правил доступа? Мне теперь чтобы поработать с домашней инфрой надо будет бежать домой или выставлять целиком сервер в интернет?
Доооо, отличное, волшебное решение.
Нормальное решение, когда сегмент в сети один или пока работаешь в том же сегменте, что целевой сервер. Что есть большая часть домашних хозяйств.
Если мне понадобиться VPN-ы в домашнюю сеть, выделенные сегменты и так далее - я сгенерирую сеть из Unique local, нарежу ее на кусочки и раздам на интерфейсы VPN-а, гостевого сегмента, сегмента умных подсетей и так далее. Ну и DDNS сервер, может, подниму. Но скорее всего обленюсь и просто в hosts адреса пропишу, что устройства получили - там постоянный адрес для этих целей есть а не только те, что по privacy extension меняются.
или mDNS reflector включу на маршрутизаторе - тогда, вроде бы эти опубликованные имена будут резолвится (уже не в link local, а в полученные адреса из Unique Local диапазона) между сегментами. (Заглянул в интерфейс маршрутизатора - галочка для этого сервиса из коробки есть)
Вот мне надо с одного хоста по VNC подключиться к другому внутри локалки.
Такой себе пример. Я бы не стал светить VNC сервером напрямую в интернет. Лучше использовать VPN. Но если принять условие, что вы открываете безопасный сервис в интернет, то всё, что вам нужно сделать - открыть нужный порт в правилах файервола на вашем маршрутизаторе. А чтобы адрес не запоминать, можно использовать DNS. К тому же адрес можно сделать минимальной длины, например, за счёт маленького значения идентификатора интерфейса. А префикс у вас будет постоянным (для переменного тоже можно сделать костыли через DNS).
Не до конца уверен, что сделал правильно, но на своём роутере отключил фильтрацию для динамических портов (49152-65535 (tcp,udp), чтобы VoIP приложения и прочие p2p могли нормально подключаться напрямую по IPv6.
Отсюда вопрос - какие порты стоит открывать для своей локальной сети (и стоит ли)?
Про "NAT нк фаервол" было уже здесь же. https://habr.com/ru/articles/134638/
ipv6 -- реальность и его дальнейшее распостранение лишь вопрос времени. Если в России переход затянется (10% -- ничто), то мы (россияне) можем остаться на задворках прогресса.
Сколько лет уже это слышно. По факту мало что меняется, и слава богу.
Как говорится некрасивый самолет не может хорошо летать, такая уродливая штука как ипв6 не может нормально прижиться где-то дальше провайдера.
Вы прям-таки уверены что перейти на стандарт 1998 года это охренный прогресс? Ну и я лично как CCNP не вижу никакой проблемы от того что в моей домашней сети используется только ipv4.
Скажу по секрету уже как минимум 1 год МТС и мегафон раздают белые адреса устройствам на мобильном интернете
Только есть другая проблема что сайтов которые нормально работают на ipv6 без ipv4 дихпор мало так как некто нечего менять сделать прямые схемы без ферм nat
Истинная причина не в этих вот факторах, что описаны в статье. Госдуарственный контроль - вот истинный тормоз прогресса. На этом можно завершить обсуждение темы готовности или неготовности общества к ipv6. Государство говорит, что ipv6 не нужен, поэтому он не нужен, и его не будет ровно столько, сколко решит государство. Пока этот фактор не уберется, можно даже не пытаться оседлать эту "лошадь".
Скажу по секрету уже как минимум 1 год МТС и мегафон раздают белые адреса устройствам на мобильном интернете
Только есть другая проблема что сайтов которые нормально работают на ipv6 без ipv4 дихпор мало так как некто нечего менять сделать прямые схемы без ферм nat
Касаемо пиринговых сетей, причем самого разного назначения, то в самых разных странах, имеется очень много государственного и негосударственного лобби, мягко скажем не приветствующего перспективу коннекта без "человека по середине", или хотя бы без вспомогательного центрального узла(будь то хоть TURN-сервер, хоть торрент-трекер), который гораздо легче поставить под контроль, или просто грохнуть.
Я понимаю что это не очень вежливо, но про такие статьи хочется сказать секта свидетелей ipv6»
"белый ip" - это 150-200 руб. с клиента в месяц. Если ipv6 всем даёт белый ip, то это плохая технология для провайдера. А для всех желающих за деньги ipv4 хватает. Вот и всё.
Пришел работать в один из достаточно крупных московских интернет-провайдеров в 2000 году. Тогда ужеговорили, что IP v4 адреса вот-вот закончатся и все мы скоро перейдем на IP v6. Прошло 25 лет...
Лампочка быстро погаснет, если она доступна на IPv6. IoT совершенно не предназначен для Интернет. И дело не в уязвимостях. Дело исключительно в производительности лампочек.
С NAT такой проблемы нет. Получается, переходя на IPv6-only вы обнажаете проблему, которой у вас раньше не было. Решить ее может firewall, закрытый по умолчанию. Но в этом случае вы теряете все плюсы IPv6, которые перечислили. Круг замыкается. Смысл теряется.
Но в этом случае вы теряете все плюсы IPv6, которые перечислили. Круг замыкается. Смысл теряется.
Ложное утверждение, закрытый фаервол не отбирает преимущества которые нормальная связность сети
Т.е. вы думаете что если лампочка получит v6 то на неё сразу можно будет со всего миру пакеты отправить?
Нет. В дефолтном случае домашний роутер будет ровно так же рубить всё снаружи как и в случае v4.
Пользуясь случаем.... Есть у кого нибудь примеры успешной конфигурации NAT под ipv6 на микротиках с RouterOS 7? Схема схожая с v4 совершенно не работает, и я не понимаю почему, пробовал так же шаманить с роутами - никак. Схема стандартная с PPPoE и префиксом от провайдера
NAT — как наследие старого интернета мешает будущему