Там вроде как довольно много всяких зарезервированных диапазонов. Некоторые из них уже не рекомендуются к использованию, но на современных ОС работают и обеспечивают связность без проблем при назначении их клиентам, всякие там fec0::/10
Unique local address-диапазоны, а fec0::/10 относится именно к таким, при обращении к GUA-адресам имеют приоритет ниже, чем IPv4. Можете хоть нерабочие адреса выдавать клиентам VPN, чтобы они вообще не пытались использовать IPv6.
Не знаю, как ULA на одном интерфейсе и GUA на другом поведут себя при наличии двух маршрутов по умолчанию, нужно проверять.
UPD: проверил, при такой конфигурации будет использоваться интерфейс провайдера (не VPN), даже если метрика у маршрута по умолчанию через VPN ниже. ULA добавляются только со scope: site.
И только из комментов узнаю что он про алгоритмы на элептических кривых.
Kyber (он же ML-KEM) основан на решетках, не на эллиптических кривых. Он (и другие алгоритмы) придуманы для защиты от расшифровки данных в квантовую эпоху.
И потом присматриваюсь к модно-зумерскому названию алгоритма X25519Kyber768
Такое название у алгоритма потому, что он гибридный: генерирует общий ключ и на основе X25519, и на основе Kyber (ML-KEM) одновременно. Гибридный алгоритм нужен из-за того, что Kyber очень свежий метод, и если в нём обнаружится критическая проблема, все установленные соединения окажутся не защищены ни пост-квантово, ни пре-квантово. Такая конфигурация позволяет обеспечить надёжность шифрования, пока хотя бы один из компонентов остаётся невзламываемым.
Поясняю - в RSA есть закрытый ключ. По идеи если сохранить сессию. Прийти в датацентр, ломиком достать сервер. Выковырять закрытый ключ. То можно будет восстановить сессию.
В элиптики для каждой сессии генерируется отдельный закрытый ключ. После сессии удаляется. И да - уже 100 лет все используют элиптику.
RSA, эллиптические кривые и обмен ключами Диффи-Хеллмана — это не связанные вещи. Если сессия устанавливается с помощью DH, владение закрытым ключом RSA не даст вам возможности её расшифровать. И наоборот, сессия без DH на эллиптических кривых может быть расшифрована при владении ключом.
А это уже следствие блокировки российским цензурирующим оборудованием, которое не умеет пересобирать TCP-поток и блокирует доступ, если домен в ClientHello не распознан.
Основная проблема в том, что не все сервисы правильно обрабатывают фрагментированный ClientHello, а именно это и происходит при использовании Kyber, т.к. размер пакета получается больше размера стандартного MTU 1500.
Проблема не нова, встречается у разных сервисов и продуктов в том или ином виде по меньшей мере 7 лет, с момента начала разработки GoodbyeDPI. Часть сервисов её устранили после моих сообщений, часть — забили.
Причина, похоже, всё же не совсем в этом. Наиболее вероятно то, что цензурирующей системе не нравится что-то в ответе сервера, а не в запросе клиента. Я воспроизвёл проблему на своём сервере (не IP Cloudflare), проксируя запросы к Cloudflare.
Это объясняет, почему с TLS 1.3 нет проблем (у TLS 1.2 и 1.3 ответы прилично различаются), и почему изменение Cipher'ов исправляет проблему (ответ сервера меняется, возможно, просто сравниваются определённые байты на определённых местах).
Заблокированы, в частности, vk.com и yandex.ru. Блокировки также осуществляют сторонние компании, обнаружил на публичном DNS-резолвере от Cogent/Sprint.
У них есть куда круче выходки, например, когда они в прямом эфире депутатам местной думы отправляли СМСки от имени других депутатов с подменой номера, согласуя обсуждение реформы морали: https://www.ztohoven.com/mr/index-en.html
чтобы воспользоваться этой дырой в IPv4 необходимо как-то обеспечить роутинг своего пакета предназначенного адресу локалки до WAN интерфейса
А чтобы воспользоваться ей в IPv6, злоумышленнику сперва нужно каким-то образом узнать адрес. Почти все устройства используют Privacy Extensions с периодически меняющимися адресами, а если не используют, то всё равно генерируют себе из RA самостоятельно.
По сути это ограничивает возможность её эксплуатации ближайшими соседями по подъезду/дому, максимум - клиентами своего провайдера
Вы узко мыслите — подумайте об этом в рамках датацентра.
Т.е. если iptables не поднимется (а такое случается порой), то локалка будет светить в сеть и хуже всего то, что я этого не увижу.
Справедливо, это действительно так.
С натом такой проблемы нет, там наоборот - нет ната нет связи.
Это не совсем правда, но принимается.
Еще момент - провайдер тупо по адресам может считать мои домашние устройства.
IPv6 Privacy Extensions включены, полагаю, везде, или почти везде. У каждой машины могут быть десятки адресов, меняющиеся через определённые интервалы.
По этому очевидно, что в первом случае открыть сеть по ошибке куда проще.
Настраивайте конечные устройства так, чтобы их можно было подключить к любой сети, не опасаясь за их безопасность.
Речь идёт о разрешении отрисовки интерфейса/меню, а не видеоконтента.
Использование меньшего разрешения интерфейса, чем позволяет вывод видеовывод, широко распространено на телевизорах и ТВ-приставках даже сейчас: часто интерфейс на 4К-телевизорах рисуется в 2К, а раньше это вообще было повсеместно. Мой ТВ Samsung из начала десятых рендерит меню в 960p, отображает видео в 1080p.
Видеоконтент декодируется, скейлится и рендерится аппаратно, в максимальном разрешении матрицы.
Только в одной, официальной от Ubuntu, инструкции приводится скрипт для корректной настройки маршрутизации. В остальных 10 инструкциях сеть настраивается так, что позволяет и маршрутизировать трафик и через саму машину (она начинает выступать NAT-шлюзом для всех устройств на WAN-порту без ограничений или с ограничением по диапазону IP-адресов, но не интерфейсов), и в другие интерфейсы на машине.
Иными словами, при настройке по подобной инструкции машина из WAN может получить прямой доступ к вашим машинам из LAN. Потому что NAT не защищает от такого, а защищает межсетевой экран. Он работает одинаково что для IPv4, что для IPv6.
Возможно. Но глядя на то, сколько лет уже идёт процесс внедрения IPv6 и его текущий прогресс - при нашей жизни мы отказ провайдеров от IPv4 можем и не застать.
У некоторых крупнейших операторов связи сети IPv6-only: T-Mobile US, Orange Poland, Telstra, SK-Telecom. Выход в IPv4 осуществляется через псевдо-туннель 464XLAT, требующий поддержки со стороны ОС (встроено в смартфоны и десктопные ОС).
это требует дополнительных усилий во-первых, и во-вторых большинство об этом даже не догадывается (из-за чего в результате внедрения IPv6 они создадут дополнительные уязвимости для своих локальных сетей).
Это так. Это одна из причин, почему провайдеры России не включают его по умолчанию, и кажется, что внедрение IPv6 не слишком широкое. Попробуйте обратиться к вашему провайдеру — есть немалая вероятность, что он может вам просто включить поддержку этого протокола.
Есть ли обратные переходники задёшево? Периодически нужно подключить обычные USB-клавиатуру и мышь в компьютеры с PS/2.
Unique local address-диапазоны, а fec0::/10 относится именно к таким, при обращении к GUA-адресам имеют приоритет ниже, чем IPv4. Можете хоть нерабочие адреса выдавать клиентам VPN, чтобы они вообще не пытались использовать IPv6.
https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/
https://blog.ipspace.net/2022/05/ipv6-ula-made-useless.html
Не знаю, как ULA на одном интерфейсе и GUA на другом поведут себя при наличии двух маршрутов по умолчанию, нужно проверять.
UPD: проверил, при такой конфигурации будет использоваться интерфейс провайдера (не VPN), даже если метрика у маршрута по умолчанию через VPN ниже. ULA добавляются только со scope: site.
Kyber (он же ML-KEM) основан на решетках, не на эллиптических кривых. Он (и другие алгоритмы) придуманы для защиты от расшифровки данных в квантовую эпоху.
Такое название у алгоритма потому, что он гибридный: генерирует общий ключ и на основе X25519, и на основе Kyber (ML-KEM) одновременно. Гибридный алгоритм нужен из-за того, что Kyber очень свежий метод, и если в нём обнаружится критическая проблема, все установленные соединения окажутся не защищены ни пост-квантово, ни пре-квантово. Такая конфигурация позволяет обеспечить надёжность шифрования, пока хотя бы один из компонентов остаётся невзламываемым.
RSA, эллиптические кривые и обмен ключами Диффи-Хеллмана — это не связанные вещи. Если сессия устанавливается с помощью DH, владение закрытым ключом RSA не даст вам возможности её расшифровать. И наоборот, сессия без DH на эллиптических кривых может быть расшифрована при владении ключом.
А это уже следствие блокировки российским цензурирующим оборудованием, которое не умеет пересобирать TCP-поток и блокирует доступ, если домен в ClientHello не распознан.
Основная проблема в том, что не все сервисы правильно обрабатывают фрагментированный ClientHello, а именно это и происходит при использовании Kyber, т.к. размер пакета получается больше размера стандартного MTU 1500.
Проблема не нова, встречается у разных сервисов и продуктов в том или ином виде по меньшей мере 7 лет, с момента начала разработки GoodbyeDPI. Часть сервисов её устранили после моих сообщений, часть — забили.
Причина, похоже, всё же не совсем в этом. Наиболее вероятно то, что цензурирующей системе не нравится что-то в ответе сервера, а не в запросе клиента. Я воспроизвёл проблему на своём сервере (не IP Cloudflare), проксируя запросы к Cloudflare.
Это объясняет, почему с TLS 1.3 нет проблем (у TLS 1.2 и 1.3 ответы прилично различаются), и почему изменение Cipher'ов исправляет проблему (ответ сервера меняется, возможно, просто сравниваются определённые байты на определённых местах).
https://mixnews.lv/latviya/2022/10/19/neplp-zapretil-dostup-k-veb-saytu-kotoryy-ugrozhaet-natsbezopasnosti/
Перенаправляют на страницу http://nelegalssaturs.lv/
Заблокированы, в частности, vk.com и yandex.ru. Блокировки также осуществляют сторонние компании, обнаружил на публичном DNS-резолвере от Cogent/Sprint.
Paralelní Polis основан выходцами из Ztohoven, которые и подменяли эфир: https://www.youtube.com/watch?v=DcbgjyX9G-o
У них есть куда круче выходки, например, когда они в прямом эфире депутатам местной думы отправляли СМСки от имени других депутатов с подменой номера, согласуя обсуждение реформы морали: https://www.ztohoven.com/mr/index-en.html
https://letmegooglethat.com/?q=telegram+xmpp
Обратитесь к поисковой системе для получения подробностей.
Это уже происходит. Уже крупные провайдеры имеют сети только с IPv6, а IPv4 предоставляется через 464LAT.
https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464XLAT
домашний роутер по умолчанию блокирует входящие соединения по IPv6.
А чтобы воспользоваться ей в IPv6, злоумышленнику сперва нужно каким-то образом узнать адрес. Почти все устройства используют Privacy Extensions с периодически меняющимися адресами, а если не используют, то всё равно генерируют себе из RA самостоятельно.
Вы узко мыслите — подумайте об этом в рамках датацентра.
Справедливо, это действительно так.
Это не совсем правда, но принимается.
IPv6 Privacy Extensions включены, полагаю, везде, или почти везде. У каждой машины могут быть десятки адресов, меняющиеся через определённые интервалы.
Настраивайте конечные устройства так, чтобы их можно было подключить к любой сети, не опасаясь за их безопасность.
Речь идёт о разрешении отрисовки интерфейса/меню, а не видеоконтента.
Использование меньшего разрешения интерфейса, чем позволяет вывод видеовывод, широко распространено на телевизорах и ТВ-приставках даже сейчас: часто интерфейс на 4К-телевизорах рисуется в 2К, а раньше это вообще было повсеместно. Мой ТВ Samsung из начала десятых рендерит меню в 960p, отображает видео в 1080p.
Видеоконтент декодируется, скейлится и рендерится аппаратно, в максимальном разрешении матрицы.
А я не сомневаюсь, что на типичных линукс-боксах типичный системный администратор настроит IPv4 уязвимым образом, с недостаточной фильтрацией.
Вот первые попавшиеся 11 инструкций из поисковика:
Hidden text
https://www.howtoforge.com/nat_iptables
https://howtoforge.com/internet-connection-sharing-masquerading-on-linux
https://www.linuxjournal.com/content/linux-networking-configuring-network-address-translation-nat
https://kifarunix.com/configure-ubuntu-20-04-as-linux-router/
https://www.cyberciti.biz/faq/howto-configure-network-address-translation-or-nat/
https://ixnfo.com/en/ubuntu-ip-masquerading.html
https://www.server-world.info/en/note?os=Ubuntu_22.04&p=ufw&f=2
https://medium.com/@lfoster49203/setting-up-ubuntu-as-a-router-with-advanced-routing-features-4511abc5e1eb
https://www.linode.com/docs/guides/linux-router-and-ip-forwarding/
https://blog.oshim.net/2013/01/configure-ip-masquerading-for-ubuntu/
https://help.ubuntu.com/community/Router
Только в одной, официальной от Ubuntu, инструкции приводится скрипт для корректной настройки маршрутизации. В остальных 10 инструкциях сеть настраивается так, что позволяет и маршрутизировать трафик и через саму машину (она начинает выступать NAT-шлюзом для всех устройств на WAN-порту без ограничений или с ограничением по диапазону IP-адресов, но не интерфейсов), и в другие интерфейсы на машине.
Иными словами, при настройке по подобной инструкции машина из WAN может получить прямой доступ к вашим машинам из LAN. Потому что NAT не защищает от такого, а защищает межсетевой экран. Он работает одинаково что для IPv4, что для IPv6.
У некоторых крупнейших операторов связи сети IPv6-only: T-Mobile US, Orange Poland, Telstra, SK-Telecom.
Выход в IPv4 осуществляется через псевдо-туннель 464XLAT, требующий поддержки со стороны ОС (встроено в смартфоны и десктопные ОС).
Это так. Это одна из причин, почему провайдеры России не включают его по умолчанию, и кажется, что внедрение IPv6 не слишком широкое. Попробуйте обратиться к вашему провайдеру — есть немалая вероятность, что он может вам просто включить поддержку этого протокола.
Это получение IEEE 1284 Device ID.
С HP 1000 не сталкивался, но 1015/1018 такой проблемы не имеют: повторная загрузка прошивки проходит без проблем.
Если вы хотите идентифицировать принтер по VID/PID, то самый простой вариант — сделать скрипт, использующий lsusb, либо же просто читающий дерево USB-устройств в sysfs.
Собственно, в wiki openwrt есть пример hotplug-скрипта: https://openwrt.org/docs/guide-user/services/print_server/p910ndprinterserver#debugging
Рестарт заданий обычно делается открытием/закрытием крышки.
См. ниже