Доступ в сеть с гарантией доступности %99,999… это фича для бизнеса за много денег, а не для любителей видео с котиками. По дешману можно только VPN поднять и ходить через него. Так же в принципе узлы могут оптимизировать маршрут через MIPv6, но адекватной реализации оного почему то нет даже в Linux не говоря уже про тупые лампочки.
Мы вроде обсуждаем брандмауэр в роутере? Соответственно речь об открытии портов в брандмауэре только для постоянных адресов. Временными пусть занимается conntrack и никто не достучится до программы висящей на [::]. Защита будет не хуже чем у NAT.
Требуемый уровень доверия провайдеру — нулевой, как и сейчас.
ARP и DHCP от провайдера принимаете? Значит не нулевой. С тем же успехом можете доверять ICMPv6(fe80::/10 по крайней мере).
Ну и по мелочи всякое, защита от спуфинга (если она нужна в IPv6),
А как Вы защищаетесь с IPv4?
поддержка протоколов вроде ftp/irc
В Linux соответствующие модули conntrack реализованы. И они в общем то общие для протоколов IPv4 и IPv6.
fail2ban (что, таки банить подсетями /64?)
Да.
Ещё лично мне актуален вопрос как без NAT в IPv6 делается multihoming
В домашних условиях, никак. Но и NAT для IPv6 в общем то есть. И обычный и stateless 1 в 1.
Неправильно выразился. Не локалки, а с link-local адресов, действительных только в рамках широковещательного домена. Ну можно попробовать пропускать только RA, NDP, MLD и те без которых сеть будет глючить(packet to big и т.д.). Но особого смысла в этом нет. Ожидаете ли Вы, что провайдер зашлёт Вам червя через дыру в IPv6-стеке? В отличии от IPv4 соседей в Вашем соединении с провайдером быть не должно, так как каждому клиенту нужно выдать отдельную сеть.
Адрес основанный на МАК не меняется вообще. Меняются только временные, а на них ничего открывать не нужно и даже вредно. Стандартная NAT подобная политика им подойдёт.
не потратив на это несколько недель, которых у меня на это просто нет.
Такой набор правил полностью соответствует NAT: ip6tables -P FORWARD DROP
ip6tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -m conntrack --ctstate NEW -i $LAN -j ACCEPT Порты "пробрасываются" только на неизменный IPv6-адрес и плевать сколько их у системы. А правильным решением для IPv6 является фильтрация всех входящих пакетов на порты 0-49151. Остальные порты предназначены для открытия соединений и естественно должны фильтровать TCP-стеком или программой.
что и как можно блокировать в ICMPv6
#пакеты из локалки, их фильтрация чревата полной потерей связи.
ip6tables -A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT
#без этих пакетов иногда будут проблемы, но вполне допустимо ставить лимиты
ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
В той статье 16 года действительно указывалось, что была специальная кастомная модель в которую можно было поставить m7-6Y75 и 16 Гб RAM. У HP эта модель стоила $1,925, у Best Buy $1,030. Рекомендуемая цена этого процессора на сайте Intel $393. Оптовая цена не настолько низка, чтобы всю систему продать за $300. А на eBay продаётся не просто б/у, а восстановленный, после ремонта, а не просто со вскрытой упаковкой.
Только вот данная модель ноутбука по заверениям HP поставляется только с 2/4 Гб памяти. Сам процессор не поддерживает более 8 Гб. Просто владелец либо тоже не понимает разницу между RAM и eMMC либо сознательно вводит в заблуждение. Производители ноутбуков привязывают объем памяти к общей стоимости ноутбука. Поэтому ноутбуки с 16 Гб стоят от $900, хоть сама память стоит не так уж и дорого.
в 2017 году я купил Chromebook с 16 ГБ оперативной памяти за 300 долларов.
А такие точно существовали в природе? Как так получилось, что сейчас за эти деньги Вы получите только 4Гб RAM? Зато eMMC там будет как раз 16 Гб, что заставляет меня задуматься о технической адекватности автора.
Нынче у бизнеса мода собирать максимум информации обо всех клиентах для таргетированной рекламы и сливать эту информацию агрегаторам. Если магазинчик у дома сольёт mac в базу, то вычисление станет плёвым делом.
SLAAC прост как пробка. Роутер периодически и по запросу рассылает общий конфиг сети(prefix,lifetime,mtu,gateway,...), а дальше клиенты сами разбирают адреса и делают проверку на кофликт. При выборе адреса используется очень простой алгоритм буквально склеивающий префикс и mac-адрес. Но этот адрес как cookie, позволяет отслеживать его перемещение между сетями независимо от используемых протоколов и программ. Также позволяет злоумышленнику извлечь mac-адрес и через wi-fi(при наличии) найти устройство в реале. Поэтому для исходящих соединений используются временные адреса.
Идеология автономных автомобилей опирается на машинное зрение. Оное опирается на нейросети, которые опознают только то, что им показывали. Они прекрасно распознают другие автомобили, дорожные знаки и идущих по зебре людей. Но совершенно не распознают велосипеды, детские коляски и иные необычные виды транспорта и препятствий. При таком подходе к машинному зрению обычный водитель всегда будет безопаснее робомобиля, по крайней мере пока внимательно смотрит на дорогу и не выпендривается.
Любые регенераторы работают с отдельными битами и не могут создавать задержку более 0,1нс, иначе они не успеют обработать следующий бит. Учитывая, что ставятся они раз в несколько сотен километров, задержка в наносекунду на 1000 км погоды не делает.
Один из самых прямых известных мне маршрутов это ttk-Новосибирк > vk.com-Москва, петель нет, расстояние 2818 км. Теоретический минимальный ping 28мс, фактический 40мс. Из Омска меньше на 5мс, значит есть коммутаторы по пути и волокна проложены не по прямой. И всё же задержка только 30% выше теоретической.
В магистральной сети зачастую используется DWDM и усиливать его через коммутаторы это безумно дорого. Поэтому используются EDFA усилители, которые даже не преобразуют свет в электричество. И соответственно не могут создавать ощутимых задержек. В самом волокне скорость света 1000 км за 5 мс. Все остальные задержки это коммутаторы, маршрутизаторы и кривые маршруты.
Это совершенно точно. GPON это не стандартизированная технология и если производитель не сказал, что данная конкретная модель ONT совместима с данной конкретной головной станцией. То стоит предполагать, что это не так и она сломает связь всему сегменту. Так же в их ONT прошит индивидуальный ключ авторизации и они его Вам естественно не дадут.
Нет не обрываются. Временные адреса при наличии привязки к ним хоть одного сокета, будут жить вечно. Но в таком случае существует риск, что из за какого то приложения, система захапает тысячи адресов.
Речь о том, что адрес и подсеть домашнего роутера периодически меняется. Как отреагируют удалённые хосты при создании нового соединения, если мобильный узел не сможет принять ответ на home-of-address? Мобильный узел ведь даже не в курсе, что его соединение с роутером отвалилось. И не будет в курсе пока не попытается сменить сеть.
Динамические IPv4 появились во времена Dial-Up, в те времена не было смысла иметь больше адресов, чем телефонных линий. Тогда возникла и услуга. Потом наследники PPP начали переходить на более быстрые технологии оставив биллинг как есть, то есть выдавая произвольный адрес на сессию. Потом пришёл ростелеком и сказал, что из за вечно включенных роутеров не рвущих сессию вообще не покупают услугу. Давайте рвать сессию каждую ночь, срывая все соединения.
Динамическая адресация ломает правила ipsec, а значит и Mobile IPv6. Будет неприятно если Ваш смартфон автоматически настроивший Mobile IPv6 адрес через домашний Wi-Fi, в полночь потеряет с ним связь. И сломает подключение в совершенно другой сети.
Для чего в IPv6 динамическая выдача адресов? Кто то очень любит таблицы маршрутизации перестраивать? А если провайдер принудительно сбрасывает сессию ради изменения адреса, то бежать от него, срочно!
ARP и DHCP от провайдера принимаете? Значит не нулевой. С тем же успехом можете доверять ICMPv6(fe80::/10 по крайней мере).
А как Вы защищаетесь с IPv4?
В Linux соответствующие модули conntrack реализованы. И они в общем то общие для протоколов IPv4 и IPv6.
Да.
В домашних условиях, никак. Но и NAT для IPv6 в общем то есть. И обычный и stateless 1 в 1.
Адрес основанный на МАК не меняется вообще. Меняются только временные, а на них ничего открывать не нужно и даже вредно. Стандартная NAT подобная политика им подойдёт.
ip6tables -P FORWARD DROP
Порты "пробрасываются" только на неизменный IPv6-адрес и плевать сколько их у системы. А правильным решением для IPv6 является фильтрация всех входящих пакетов на порты 0-49151. Остальные порты предназначены для открытия соединений и естественно должны фильтровать TCP-стеком или программой.ip6tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -m conntrack --ctstate NEW -i $LAN -j ACCEPT
#пакеты из локалки, их фильтрация чревата полной потерей связи.ip6tables -A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT
#без этих пакетов иногда будут проблемы, но вполне допустимо ставить лимиты
ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT
Один из самых прямых известных мне маршрутов это ttk-Новосибирк > vk.com-Москва, петель нет, расстояние 2818 км. Теоретический минимальный ping 28мс, фактический 40мс. Из Омска меньше на 5мс, значит есть коммутаторы по пути и волокна проложены не по прямой. И всё же задержка только 30% выше теоретической.
Динамическая адресация ломает правила ipsec, а значит и Mobile IPv6. Будет неприятно если Ваш смартфон автоматически настроивший Mobile IPv6 адрес через домашний Wi-Fi, в полночь потеряет с ним связь. И сломает подключение в совершенно другой сети.