Тут уже писали про OpenWrt в комментариях. Но решил описать свой кейс. У меня провайдер выдаёт динамически префикс /56. Чтобы правило работало, я просто добавил в настройки файервола ::dead:beef/-72, где ::dead:beef - адрес интерфейса узла, а -72 - это маска сети, только наоборот (в Cisco, вроде, есть подобное для IPv4). Можно ещё так записать ::dead:beef/::ff:ffff:ffff:ffff:ffff. Эффект будет аналогичный. Какой бы префикс не выдали, узел будет доступен изве по нужным портам. Ну а дальше просто вешаю DynDNS и имею доступ домой, как делал когда-то через IPv4. Но с IPv4 нужно ещё порты пробросить правильно.
Если вы строите сеть исключительно на IPv6, то NAT вам не нужен. Архитектура такая!!! Если вы где-то используете NAT, то у вас что-то в сети неправильно настроено. Единственная вещь сейчас, где нужен NAT в IPv6 - это доступ к IPv4 ресурсам из IPv6. Тут даже не то, что он нужен IPv6, просто без NAT невозможно нормально пользоваться IPv4 глобально в большинстве случаев.
О! Надо будет дописать одну свою заметку. Я решил познакомиться со списком костылей. А пока не дописал, советую изучить примерно такой набор:
STUN;
TURN;
ICE;
UPnP и NAT-PMP;
PCP.
А ещё можно посмотреть всякие ALG:
FTP ALG;
SIP ALG;
ESP/IPsec ALG;
RTSP ALG;
H.323 ALG;
IRC ALG;
AIM ALG;
NetMeeting ALG;
TFTP ALG;
PPTP ALG;
MGCP ALG;
SCCP ALG;
Skinny ALG.
Не у верен, что все ALG сейчас актуальны, но если у вас есть NAT и вы хотите использовать эти протоколы, то добро пожаловать в чудный мир костылей специально заточенных под NAT.
Справедливости ради, некоторые вещи перетекли и в IPv6. Но их не обязательно использовать. Всё может работать и без них.
Я не домохозяйка, но у меня на двух маршрутизаторах точно был настроен файервол для IPv6. Первый - маршрутизатор Asus купленный ещё во времена, когда доллар был по 32 рубля (наверно году в 2014, если не в 2013) и второй с прошивкой OpenWrt из коробки. Никаких «голых жопь» сразу из коробки. Примерно также, как домохозяйки не настраивают свой NAT на IPv4.
20 лет назад все верстальщики рвали на себе волосы из-за Internet Explorer, который нафиг никому не упирался, но под него необходимо было верстать и ставить костыли для совместимости, потому что в корпоративном сегменте люди использовали то, что было у них на компах, а ставить нормальные альтернативы было нельзя. Сейчас такая же ситуация с IPv4. Если внедряешь IPv6, то приходится делать костыли для доступа к IPv4 (кстати, костыли того же вида, что и в самом IPv4, которые нужны ему для существования - NAT). Ему уже давно пора на покой, но люди продолжают его использовать. Но, ничего. Придёт то время, когда IPv4 также выкинут на помойку, как это стало с Internet Explorer.
В РФ только у Яндекса есть IPv6. А вот во всём мире все гиганты, которые создают большие объёмы трафика, поддерживают IPv6. Просто тупо потому, что, например, видео создаёт довольно большую нагрузку на CGNAT провайдерский. А, за счёт перевода этого трафика в обход, проблема решается.
Нормальных фаерволлов и вообще средств защиты под v6 мизер.
Тут ничего особо про железные устройства не могу сказать. Но любой Linux имеет всё необходимое. На OpenWrt - прошивке для маршрутизаторов, по умолчанию включен глухой файервол для IPv6. Выпускает только из LAN в WAN. Если хотите обратно, добро пожаловать в настройки.
NAT скрывает внутреннюю архитектуру сети
Блажен, кто верует. NAT - это не файервол. Есть техники, которые позволяют прощупать сеть снаружи через NAT. А щупать там особо нечего. У тебя обычная сеть /24 содержит 256 адресов, /16 - 65536. Пощупать такую сеть через NAT можно не торопясь и создавая особой нагрузки. Уже можем что-то про сеть узнать. С IPv6 так не выйдет. Там 2^64 адресов. Даже просто послать 1 байт на каждый адрес такой сети уйдёт 468 лет, если скорость этой сети будет 1 гигабит/с. А эти узлы IPv6 ещё и норовят сменить свой адрес. Некоторые меняют раз в сутки. Вот только ещё есть одна загвоздка - файервол, который обычно прикрывает сеть. И его тупо не обойти, как тот же NAT. Так что для хоть какого-то анализа сети придётся проникать внутрь её контура. Так что ещё неизвестно какая сеть безопаснее и устойчивей к атакам снаружи.
То самое легаси. Древняя бизнес-критичная система может быть написана несколько десятилетий назад. Ее модернизация будет золотой.
Такое же древнее железо. Условно терминал на складе, касса, счетчик в АСУТП, станок, принтер этикеток могут не поддерживать v6 и менять их ради этого никто не станет.
Эм… и вы вот так просто легаси держите в основной сети? Лично я бы для подобного выделил отдельную сеть, тем более для устройств производственных. А для них можно и островок IPv4 выделить. Всё-таки дорогостоящие устройства от которых зависит твоё производство, да ещё и без патчей безопасности.
И надо ещё всех сетевиков мира научить IPv6. И домохозяек.
Сетевики, вроде, люди не глупые. Разберутся. С IPv4 как-то же разобрались.
А домохозяйкам ничего не нужно знать. Просто берёт маршрутизатор, вводит реквизиты доступа у провайдера (если провайдер такой ленивый и сам всё не настроит) и всё. Можно пользоваться. Мелкие домашние сети на IPv6 автоконфигурируются. Там даже DHCP не нужен, как в сетях IPv4. Всё будет работать и без него. И вбивать какие-то адреса на сетевых интерфейсах не нужно. SOHO маршрутизаторы сами себя объявляют и все устройства в сети знаю как выйти в интернет.
По сути надо решить ровно одну проблему: добавить один октет к ipv4 адресу. Все остальное должно быть только про совместимость и как с этим жить не ломая ничего.
Ну да, ну да… Сотни специалистов со всего мира обсуждали как должен быть устроен IP нового поколения, но тогда пришли к выводу, что без потери обратной совместимости никак. В результате решили, раз уж совместимость теряем, то хотя бы давайте попутно косяки исправим, что нашли за время эксплуатации IPv4. Но через 30 лет появляется какой-то гений и говорит, что он решил эту проблему с добавлением октета. И я бы даже допустил, что мог быть такой, если бы не прочитал то, что было про этот, так называемый IPv8. Там мало того, что нужно будет кучу нового железа ставить. Так ещё и в самое ядро интернета лезть, где уже давно спокойно ходит IPv6 трафик и ничего менять не нужно.
последнее, что нужно принтеру, это маршрутизируемый внешний ip
То, что он может общаться с интернетом ещё не означает, что к нему можно будет обращаться из интернета. У меня в локалке так по умолчанию. Чтобы подобный принтер, если у меня будет, засветился в интернете мне нужно зайти и руками всё это сделать.
Ну так вы включите файервол. Точнее даже так: зачем вы выключили файервол? Лично у меня на маршрутизаторе он включен по умолчанию. Чтобы ко мне зашли в локалку по IPv6 адресу мне нужно зайти и разрешить, что к такому-то узлу можно подключаться по такому то порту и по TCP или UDP. Только после этого устройство начинает светиться снаружи. И никаких NAT не надо.
У Ростелекома есть во многих областях. Но есть места, где его нет. Кроме того, на Ростелекоме IPv6 официально не предоставляют, так что поддержки не жди, скажут просто выключить. Ну и на BCOP 690 они наплевали и выдают префиксы динамически. При всём при этом, это пока лучшее, что я видел у провайдеров. На Дом.ру хоть префикс и постоянный можно было получить, но только один /64…
Вообще какая-то школьная поделка. Не удивлюсь, что чисто через ИИ склепали. Плохо всё, от оформления до неработающего логина. Пусть ничего в школьной поделке плохого нет, пусть развлекаются и учатся. Но реально использовать не советую.
Игра в безопасность — она такая. Делаешь юзерам удобнее — становится уязвимым для большых вариантов атаки, делаешь безопасным — либо пользователи взвоют, либо просто мало кто будет пользоваться твоим продуктом.
С моей точки зрения клиенты маха — такие же, как и у других клиентов других мессенджеров. Все могут допускать ошибки и ставить удобство в ущерб безопасности. Но нужно не забывать, что в случае с мах, дьявол кроется на серверной стороне.
Да. Токен вполне может быть и рандомной строкой. Сервер сам решает когда токен протух. Тогда интересно, сколько времени проживёт токен. Я бы не давал много времени токенам, что лежат в localStorage. Сам таким пользуюсь, время жизни - пол часа. Если просто украдут, то время на совершение действий не больше этого времени. Дальше надо снова токен добывать, т.е. нужно контролировать устройство всё время. Эта заметка навела меня на мысль переделать всё на httpOnly cookies. Раньше не знал как сделать, а сейчас нашёл.
Если бы был jwt, из него можно было бы извлечь информацию, но тоже не всегда (иногда контент шиыруют, например, ЕСИА). А сервер может проверить валидность такого токена по закрытому ключу. Здесь не так.
Какая-то бредовая статья. У людей стоит старый маршрутизатор с WiFi на 2,4ГГц. Его всё устраивает. это его проблемы. Диапазон забит? Так он пользуется и не собирается ничего менять.
Вот за что стоит реально беспокоиться, так это за то, что устаревшие устройства могут быть подключены к ботнетам. Вот об этом надо думать. Куча устаревшего железа на которое нормальной пошивки не поставить.
Это немного не так работает. Обычно выдаётся короткоживующий токен, очень часто JWT, где прописан срок протухания. Пока он жив, ты можешь обращаться к сервису. Срок его жизни может быть и пол часа и час. Когда токен протухает, в ход идёт рефреш токен, который можно хранить уже в Cookie, которые недоступны из JS, а значит его через JS уже не угнать, только лезть в кишки баузера, а потом также через кишки вставлять эту cookie в другой браузер. Так что угон этой cookie даст тебе доступ к сайту максимум на час, если, конечно, разработчики не идиоты и не выставили время жизни access токена на большой срок. Через час токен протухнет и старый браузер обновит его, а новый браузер обломается, поэтому что у него нет refresh токена.
Жаль автор не глянул хотя бы через jwt.io что там внутри токена. Если это был обычный JWT, то там должна быть информация, когда токен протухает. Если время протухания далеко в будущем, то это точно будет фейл.
Тут уже писали про OpenWrt в комментариях. Но решил описать свой кейс. У меня провайдер выдаёт динамически префикс /56. Чтобы правило работало, я просто добавил в настройки файервола
::dead:beef/-72, где ::dead:beef - адрес интерфейса узла, а-72- это маска сети, только наоборот (в Cisco, вроде, есть подобное для IPv4). Можно ещё так записать::dead:beef/::ff:ffff:ffff:ffff:ffff. Эффект будет аналогичный. Какой бы префикс не выдали, узел будет доступен изве по нужным портам. Ну а дальше просто вешаю DynDNS и имею доступ домой, как делал когда-то через IPv4. Но с IPv4 нужно ещё порты пробросить правильно.Если вы строите сеть исключительно на IPv6, то NAT вам не нужен. Архитектура такая!!! Если вы где-то используете NAT, то у вас что-то в сети неправильно настроено. Единственная вещь сейчас, где нужен NAT в IPv6 - это доступ к IPv4 ресурсам из IPv6. Тут даже не то, что он нужен IPv6, просто без NAT невозможно нормально пользоваться IPv4 глобально в большинстве случаев.
О! Надо будет дописать одну свою заметку. Я решил познакомиться со списком костылей. А пока не дописал, советую изучить примерно такой набор:
STUN;
TURN;
ICE;
UPnP и NAT-PMP;
PCP.
А ещё можно посмотреть всякие ALG:
FTP ALG;
SIP ALG;
ESP/IPsec ALG;
RTSP ALG;
H.323 ALG;
IRC ALG;
AIM ALG;
NetMeeting ALG;
TFTP ALG;
PPTP ALG;
MGCP ALG;
SCCP ALG;
Skinny ALG.
Не у верен, что все ALG сейчас актуальны, но если у вас есть NAT и вы хотите использовать эти протоколы, то добро пожаловать в чудный мир костылей специально заточенных под NAT.
Справедливости ради, некоторые вещи перетекли и в IPv6. Но их не обязательно использовать. Всё может работать и без них.
Я не домохозяйка, но у меня на двух маршрутизаторах точно был настроен файервол для IPv6. Первый - маршрутизатор Asus купленный ещё во времена, когда доллар был по 32 рубля (наверно году в 2014, если не в 2013) и второй с прошивкой OpenWrt из коробки. Никаких «голых жопь» сразу из коробки. Примерно также, как домохозяйки не настраивают свой NAT на IPv4.
20 лет назад все верстальщики рвали на себе волосы из-за Internet Explorer, который нафиг никому не упирался, но под него необходимо было верстать и ставить костыли для совместимости, потому что в корпоративном сегменте люди использовали то, что было у них на компах, а ставить нормальные альтернативы было нельзя. Сейчас такая же ситуация с IPv4. Если внедряешь IPv6, то приходится делать костыли для доступа к IPv4 (кстати, костыли того же вида, что и в самом IPv4, которые нужны ему для существования - NAT). Ему уже давно пора на покой, но люди продолжают его использовать. Но, ничего. Придёт то время, когда IPv4 также выкинут на помойку, как это стало с Internet Explorer.
Не пользуйтесь сувенирной продукцией, покупайте настоящее.
В РФ только у Яндекса есть IPv6. А вот во всём мире все гиганты, которые создают большие объёмы трафика, поддерживают IPv6. Просто тупо потому, что, например, видео создаёт довольно большую нагрузку на CGNAT провайдерский. А, за счёт перевода этого трафика в обход, проблема решается.
Тут ничего особо про железные устройства не могу сказать. Но любой Linux имеет всё необходимое. На OpenWrt - прошивке для маршрутизаторов, по умолчанию включен глухой файервол для IPv6. Выпускает только из LAN в WAN. Если хотите обратно, добро пожаловать в настройки.
Блажен, кто верует. NAT - это не файервол. Есть техники, которые позволяют прощупать сеть снаружи через NAT. А щупать там особо нечего. У тебя обычная сеть /24 содержит 256 адресов, /16 - 65536. Пощупать такую сеть через NAT можно не торопясь и создавая особой нагрузки. Уже можем что-то про сеть узнать. С IPv6 так не выйдет. Там 2^64 адресов. Даже просто послать 1 байт на каждый адрес такой сети уйдёт 468 лет, если скорость этой сети будет 1 гигабит/с. А эти узлы IPv6 ещё и норовят сменить свой адрес. Некоторые меняют раз в сутки. Вот только ещё есть одна загвоздка - файервол, который обычно прикрывает сеть. И его тупо не обойти, как тот же NAT. Так что для хоть какого-то анализа сети придётся проникать внутрь её контура. Так что ещё неизвестно какая сеть безопаснее и устойчивей к атакам снаружи.
Эм… и вы вот так просто легаси держите в основной сети? Лично я бы для подобного выделил отдельную сеть, тем более для устройств производственных. А для них можно и островок IPv4 выделить. Всё-таки дорогостоящие устройства от которых зависит твоё производство, да ещё и без патчей безопасности.
Сетевики, вроде, люди не глупые. Разберутся. С IPv4 как-то же разобрались.
А домохозяйкам ничего не нужно знать. Просто берёт маршрутизатор, вводит реквизиты доступа у провайдера (если провайдер такой ленивый и сам всё не настроит) и всё. Можно пользоваться. Мелкие домашние сети на IPv6 автоконфигурируются. Там даже DHCP не нужен, как в сетях IPv4. Всё будет работать и без него. И вбивать какие-то адреса на сетевых интерфейсах не нужно. SOHO маршрутизаторы сами себя объявляют и все устройства в сети знаю как выйти в интернет.
К вашим услугам RFC 1924 аж от 1 апреля 1996 года!!! :-D
Ну да, ну да… Сотни специалистов со всего мира обсуждали как должен быть устроен IP нового поколения, но тогда пришли к выводу, что без потери обратной совместимости никак. В результате решили, раз уж совместимость теряем, то хотя бы давайте попутно косяки исправим, что нашли за время эксплуатации IPv4. Но через 30 лет появляется какой-то гений и говорит, что он решил эту проблему с добавлением октета. И я бы даже допустил, что мог быть такой, если бы не прочитал то, что было про этот, так называемый IPv8. Там мало того, что нужно будет кучу нового железа ставить. Так ещё и в самое ядро интернета лезть, где уже давно спокойно ходит IPv6 трафик и ничего менять не нужно.
То, что он может общаться с интернетом ещё не означает, что к нему можно будет обращаться из интернета. У меня в локалке так по умолчанию. Чтобы подобный принтер, если у меня будет, засветился в интернете мне нужно зайти и руками всё это сделать.
Ну так вы включите файервол. Точнее даже так: зачем вы выключили файервол? Лично у меня на маршрутизаторе он включен по умолчанию. Чтобы ко мне зашли в локалку по IPv6 адресу мне нужно зайти и разрешить, что к такому-то узлу можно подключаться по такому то порту и по TCP или UDP. Только после этого устройство начинает светиться снаружи. И никаких NAT не надо.
У Ростелекома есть во многих областях. Но есть места, где его нет. Кроме того, на Ростелекоме IPv6 официально не предоставляют, так что поддержки не жди, скажут просто выключить. Ну и на BCOP 690 они наплевали и выдают префиксы динамически. При всём при этом, это пока лучшее, что я видел у провайдеров. На Дом.ру хоть префикс и постоянный можно было получить, но только один /64…
МТС и Мегафон.
Вообще какая-то школьная поделка. Не удивлюсь, что чисто через ИИ склепали. Плохо всё, от оформления до неработающего логина. Пусть ничего в школьной поделке плохого нет, пусть развлекаются и учатся. Но реально использовать не советую.
Игра в безопасность — она такая. Делаешь юзерам удобнее — становится уязвимым для большых вариантов атаки, делаешь безопасным — либо пользователи взвоют, либо просто мало кто будет пользоваться твоим продуктом.
С моей точки зрения клиенты маха — такие же, как и у других клиентов других мессенджеров. Все могут допускать ошибки и ставить удобство в ущерб безопасности. Но нужно не забывать, что в случае с мах, дьявол кроется на серверной стороне.
Да. Токен вполне может быть и рандомной строкой. Сервер сам решает когда токен протух. Тогда интересно, сколько времени проживёт токен. Я бы не давал много времени токенам, что лежат в localStorage. Сам таким пользуюсь, время жизни - пол часа. Если просто украдут, то время на совершение действий не больше этого времени. Дальше надо снова токен добывать, т.е. нужно контролировать устройство всё время. Эта заметка навела меня на мысль переделать всё на httpOnly cookies. Раньше не знал как сделать, а сейчас нашёл.
Если бы был jwt, из него можно было бы извлечь информацию, но тоже не всегда (иногда контент шиыруют, например, ЕСИА). А сервер может проверить валидность такого токена по закрытому ключу. Здесь не так.
Какая-то бредовая статья. У людей стоит старый маршрутизатор с WiFi на 2,4ГГц. Его всё устраивает. это его проблемы. Диапазон забит? Так он пользуется и не собирается ничего менять.
Вот за что стоит реально беспокоиться, так это за то, что устаревшие устройства могут быть подключены к ботнетам. Вот об этом надо думать. Куча устаревшего железа на которое нормальной пошивки не поставить.
Это немного не так работает. Обычно выдаётся короткоживующий токен, очень часто JWT, где прописан срок протухания. Пока он жив, ты можешь обращаться к сервису. Срок его жизни может быть и пол часа и час. Когда токен протухает, в ход идёт рефреш токен, который можно хранить уже в Cookie, которые недоступны из JS, а значит его через JS уже не угнать, только лезть в кишки баузера, а потом также через кишки вставлять эту cookie в другой браузер. Так что угон этой cookie даст тебе доступ к сайту максимум на час, если, конечно, разработчики не идиоты и не выставили время жизни access токена на большой срок. Через час токен протухнет и старый браузер обновит его, а новый браузер обломается, поэтому что у него нет refresh токена.
Жаль автор не глянул хотя бы через jwt.io что там внутри токена. Если это был обычный JWT, то там должна быть информация, когда токен протухает. Если время протухания далеко в будущем, то это точно будет фейл.