Практически все статьи, которые я видел на тему «чем хорош IPv6 и почему на него стоит пошустрее переходить», говорят только о просто более широком адресном пространстве. В лучшем случае, упомянут автоматическую конфигурацию адресов и маршрутов (stateless address autoconfiguration (SLAAC)). Это удручает, а ведь IPv6 имеет много ещё других неявных плюшек, являясь очень продуманным стеком протоколов (IPv6 + ICMPv6 + NDP)! Создаётся впечатление, что IPv6 это просто тупо про расширение адресов, а дальше то особо никакого профита. Или же некоторые статьи плачутся о том, что они не видят сиюминутного профита от внедрения/перехода. Простоту и удобство, гибкость и расширенные возможности (из-за одного только избавления от NAT-а) не так то легко измерить, как какие-нибудь задержки и пропускную способность. Решил поэтому собрать моё видение прекрасного мира IPv6 протокола и его плюсы в этой статье.
Не использовать IPv6 для построения чего-то нового, новых сетей — просто не имеет смысла, так как лишаемся массы удобств и возможностей, получая кучу геморроя от лишения этой массы удобств и возможностей. IPv6 поддерживается даже с Windows XP версии. Последний раз я проверял пять лет назад, но уже тогда SLAAC+RDNSS/DNSSL поддерживали и iOS и Android и даже Windows 10 устройства, не говоря о GNU/Linux и BSD системах.
IPv4 не является плохим протоколом. Его проблема только в том, что он никогда не задумывался для создания большой глобальной сети, где почти у каждого человека на Земном шаре будет доступ к ней прямиком из штанов (где лежит смартфон). Он создавался во времена, когда компьютеры были более быстрыми чем сети (странное сравнение?) и с кучей памяти. Сейчас наоборот: сделать 10 Gb канал связи можно тривиально и дома, но из коробки ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.
Конечному пользователю сложно представить получаемые преимущества, так как Интернета, по факту, уже давно мало кому дают: преобладающая часть людей всегда сидела за NAT-ом и считает, что изобретение протоколов типа WebSocket, есть нечто штатное, нормальное, логичное и разумное, и ничего кроме TCP, UDP и ICMP у нас особо-то и не ходит поверх IP.
Сетевому инженеру, чисто психологически, сложно будет пересиливать себя в понимании того, что адресов и сетей реально очень много выдаётся и не имеет смысла (и даже будет только вредить удобству и простоте обслуживания) экономить на их использовании. Большая проблема — осознание того, что IP адреса уже не являются дефицитным ресурсом и думать приходится чаще всего в понятиях не единичных адресов, а целых огромных сетей минимум с /64 префиксом.
IPv6 имеет более серьёзные требования (эту часть можно обозвать недостатками):
Что же даёт IPv6, какие плюсы имеет:
Отдельно хочется упомянуть отлично продуманный Mobile IPv6. Имея всего-лишь относительно простого демона (home agent) в домашней сети и демона на мобильном хосте (mobile agent), можно иметь полностью работающий мобильный IPv6, когда, обращаясь по домашнему адресу, всегда можно достучаться до мобильного. В отличии от Mobile IPv4, без каких-либо дополнительных требований к сети где находится мобильный агент. IP пакеты при этом просто будут эффективно (всего-лишь добавляя расширенный IPv6 заголовок) проксироваться с домашнего агента на мобильный. Кроме того, если сторонний инициатор соединения тоже поддерживает MIPv6, то он прозрачно договорится с домашним и мобильным агентами о том, что трафик он будет слать напрямую мобильному хосту, без проксирования через домашний, обеспечивая максимальную возможную эффективность (с учётом одного расширенного IPv6 заголовка) передачи. А благодаря быстрому NDP NUD, смена мобильной сети будет приводить к минимальным временным задержкам из-за обновления адреса мобильного хоста. И всё это с минимальными добавлениями в ICMPv6/NDP протоколы, введением простого расширенного IPv6 заголовка и Mobility Header.
Даёшь IPv6 и полноценный Интернет в массы!
Не использовать IPv6 для построения чего-то нового, новых сетей — просто не имеет смысла, так как лишаемся массы удобств и возможностей, получая кучу геморроя от лишения этой массы удобств и возможностей. IPv6 поддерживается даже с Windows XP версии. Последний раз я проверял пять лет назад, но уже тогда SLAAC+RDNSS/DNSSL поддерживали и iOS и Android и даже Windows 10 устройства, не говоря о GNU/Linux и BSD системах.
IPv4 не является плохим протоколом. Его проблема только в том, что он никогда не задумывался для создания большой глобальной сети, где почти у каждого человека на Земном шаре будет доступ к ней прямиком из штанов (где лежит смартфон). Он создавался во времена, когда компьютеры были более быстрыми чем сети (странное сравнение?) и с кучей памяти. Сейчас наоборот: сделать 10 Gb канал связи можно тривиально и дома, но из коробки ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.
Конечному пользователю сложно представить получаемые преимущества, так как Интернета, по факту, уже давно мало кому дают: преобладающая часть людей всегда сидела за NAT-ом и считает, что изобретение протоколов типа WebSocket, есть нечто штатное, нормальное, логичное и разумное, и ничего кроме TCP, UDP и ICMP у нас особо-то и не ходит поверх IP.
Сетевому инженеру, чисто психологически, сложно будет пересиливать себя в понимании того, что адресов и сетей реально очень много выдаётся и не имеет смысла (и даже будет только вредить удобству и простоте обслуживания) экономить на их использовании. Большая проблема — осознание того, что IP адреса уже не являются дефицитным ресурсом и думать приходится чаще всего в понятиях не единичных адресов, а целых огромных сетей минимум с /64 префиксом.
IPv6 имеет более серьёзные требования (эту часть можно обозвать недостатками):
- Минимальный допустимый MTU канала: 1280 байт.
- Канал должен быть с обнаружением (или даже исправлением) ошибок.
- NDP протокол работает активно поверх multicast адресов, требуя работоспособных multicast рассылок в Ethernet-е.
- PMTUD является обязательным для (эффективной) работы, так как в IPv6 нет фрагментации пакетов на уровне маршрутизаторов.
- ICMPv6 протокол играет очень большую роль для работоспособности IPv6 сетей, как минимум для NDP и PMTUD — заблокировав его (как многие админы любят делать в IPv4 сетях), сеть, скорее всего, перестанет работать.
Что же даёт IPv6, какие плюсы имеет:
- У конечного пользователя появляется Интернет, а не удалённый доступ до ряда служб корпораций типа Facebook, ВКонтакте, WhatsApp, YouTube и т.д.! Буквально появляется возможность обмениваться произвольными данными между произвольными компьютерами. Можно использовать, зачастую гораздо более эффективные, peer-to-peer протоколы, разгружая сервера. Количество перерастает в качество: все мы знаем насколько революционен был BitTorrent только для обмена файлами.
- Исчезает NAT (всё ломающий костыль, абсолютное зло): теперь можно использовать гораздо более эффективные протоколы для различных задач. Например, SCTP для удобной гарантированной in-order передачи сообщений параллельных потоков, в противовес TCP, передающему поток байт, да ещё и с head-of-line blocking. Использовать протоколы без ненужной инкапсуляции, с лишним overhead-ом и бесполезной тратой ресурсов, например, на пересчёт контрольных сумм, как это делают с IPsec (или любыми VPN) и SCTP протоколами инкапсулированными в UDP пакетах. Использовать протоколы где не нужно разделение на порты, убирая громоздкие заголовки транспортного уровня. Это эффективно и удобно!
- Работающий IPsec, как правило, требующий доступности хостов. Наконец-то его можно использовать не только для VPN-ов/туннелей, но и для обезопашивания хоть каждой TCP сессии по отдельности: setsockopt может делать per-socket IPsec policy, в купе с возможностью задания ожидаемых идентификаторов участников IKE соединения (sadb_ident), это с лихвой покрывает все задачи решаемые SSL/TLS-ом! Был бы IPv6 внедрён раньше, то и SSL/TLS, с очень долгой историей небезопасности, в принципе бы не появился. IPsec имеется сразу же из коробки во всех современных ОС и его трафик обрабатывается на ядерном уровне, с централизованным (один IKE/KINK/whatever демон) управлением рукопожатиями. Это очень эффективно, продуманно и удобно!
- Не нужно заниматься выделением отдельных портов для разных демонов запускаемых на одном IP адресе — проще на отдельных IP адресах поднимать несвязанные между с собой демоны, без неудобств с отличающимися от default-ных значений портов. Каждому пользователю всё-равно выдаётся минимум /64 сеть. Это просто и удобно!
- Глобальных префиксов так много выдаётся конечным пользователям и организациям, что просто не имеет смысла использовать site-local адреса сетей (fc::/7), рискуя иметь коллизию с какой-нибудь домашней сетью пользователя, подключающегося по VPN к сети организации (хорошо известная проблема в IPv4 мире, иногда вынуждающая переделывать адресацию домашней сети). Везде надо привыкать к тому, что стоит использовать глобальные префиксы сетей. Это очень удобно!
- На практике, адреса сконфигурированные руками/человеками, зачастую проще запомнить чем 4 несвязанных десятичных числа, особенно если их делать мнемоническими (типа :dead:babe:): 2a02:6b8::2:242 (ya.ru), :face:b00c: в сети Facebook, 2001:4860:4860::8888 публичный DNS Google-а, 2620:0:ccc::2 (OpenDNS). А если что-то длинное автоматически сгенерированно, то человеку это на практике и не нужно запоминать/продиктовывать, так как он хоть мышкой выделит в терминале и вставит куда надо.
- Так как все адреса выдаются иерархическим образом, то таблица маршрутизации на каждом узле/маршрутизаторе маленькая и компактная. Даже за /48, /56 или /64 сети конечных пользователей отвечают маршрутизаторы самих пользователей, которым эти префиксы делегированы. Это очень эффективно, продуманно и удобно!
- Если умные инженеры всё же просчитались и раздача /48, /56 и подобного размера сетей каждому конечному пользователю является чересчур нерациональной и безалаберной идеей, то ничего страшного: штатно адреса для глобальных адресов сейчас раздаются только из 2000::/3 диапазона, то есть всего-лишь из 1/8 части всего возможного адресного пространства. Если это было плохим решением, то у нас ещё есть 7 попыток раздавать адреса по другим политикам. Это продуманно!
- Killer-feature: link-local адреса. Автоматически создаваемые на каждом канале link-local адреса гарантируют наличие работающего сетевого уровня между компьютерами. Не нужно настраивать руками временные IPv4 приватные сети. Для большой организации не нужно тратить время и силы на разрезание на подсети какой-нибудь 10/8 сети, раздавая из неё адреса для маршрутизаторов, следя чтобы не пересеклось ничего. Так как IPv6 позволяет иметь много адресов на одном интерфейсе и один и тот же адрес на разных интерфейсах, то можно какой-нибудь fe80::1 на каждом интерфейсе общения с виртуальными машинами назначить и зашить намертво в образах машин как адрес шлюза. Это невероятно удобно!
- Некоторые well-known multicast адреса позволяют легко узнать какие компьютеры вообще есть в сети (broadcast домене Ethernet-а), моментально в ad-hoc режиме их найдя и имея возможность сразу же подключиться:
# ping6 ff02::1%igb0 PING6(56=40+8+8 bytes) fe80::be5f:f4ff:fedd:2752%igb0 --> ff02::1%igb0 16 bytes from fe80::be5f:f4ff:fedd:2752%igb0, icmp_seq=0 hlim=64 time=0.036 ms 16 bytes from fe80::be5f:f4ff:fedd:98f1%igb0, icmp_seq=0 hlim=64 time=0.239 ms(DUP!) 16 bytes from fe80::be5f:f4ff:fee6:c37e%igb0, icmp_seq=0 hlim=64 time=0.344 ms(DUP!) 16 bytes from fe80::be5f:f4ff:fedd:9c5d%igb0, icmp_seq=0 hlim=64 time=0.479 ms(DUP!)
- Killer-feature: SLAAC. Автоматическое конфигурирование адресов, буквально plug-and-play, буквально без каких-либо клиентов и серверов с базами данных для хранения состояний. Просто подключая кабель, ОС делает одну приёмо-передачу ICMPv6 пакетов, после чего является полноценным участником глобальной полностью работающей (со всеми настроенными адресами маршрутизаторов, MTU, DNS) IPv6 сети. На маршрутизаторе, с каким-нибудь rtadvd, или вообще не требуется конфигурационных файлов, или не сложнее чем одна строчка на интерфейс. Например:
igb0:addr="2001:dead:beef::":mtu=1320:rdnss="2001:dead:beef::1":
- Anycast адреса штатно поддерживаются и обрабатываются NDP протоколом, прозрачно с ними работая из коробки.
- IPv6 заголовок существенно проще обрабатывать: нет контрольных сумм, фиксированной длины фиксированные поля, в противовес IPv4 с варьируемой длиной заголовка и пересчётом контрольной суммы на каждом hop-е. Плюс в два раза меньше полей чем в IPv4. Это эффективно и просто!
- Flow label в IPv6 заголовке позволяет иметь состояние сессий/соединений не по (src, dst, proto, portSrc, portDst), для которого нужно распарсить и заголовок сетевого и транспортного уровней, а по (src, dst, flowLabel) которые находятся в фиксированных местах одного IPv6 заголовка. А если IP пакет фрагментирован, да так, что заголовок транспортного уровня разбит, то это задача уже не тривиальная. Flow label может быть очень эффективным!
- Multicast рассылки NDP протокола не грузят большие сети и не прерывают работу хостов, как это делает broadcast, используемый IPv4, как минимум, для ARP и DHCP. Это эффективно!
- Работа NDP, DHCPv6 протоколов поверх ICMPv6, поверх сетевого уровня, максимально старается разделять всё что касается сетевого и канального уровней. В идеале, NDP/ICMPv6 не нужно знать про то, поверх чего оно работает: Ethernet ли, PPP или ещё какой канал. В отличии от IPv4 мира с его ARP и DHCP, например при работе не на Ethernet, а на PPP, необходимо было встраивать в сам PPP поддержку/эмуляцию этих протоколов. В IPv6 все подобные протоколы просто работают поверх link-local адресов. Кроме того, это позволяет ещё и применять IPsec политики к ним! Это очень удобно и продуманно!
- NDP NUD (neighbour unreachability detection) позволяет быстро определять двустороннюю (не)доступность хоста, быстро переключаясь на использование другого next hop-а или маршрутизатора, если хост перестал отвечать. Это, по сути, автоматический heartbeat хоста, в противовес просто большим timeout-ам в IPv4. Это просто и эффективно!
- NDP RA (router advertisement) и NDP redirect пакеты сразу же содержат адреса канального уровня, а не только сетевые, не требуя совершать дополнительные round-trip-ы для NDP address resolution, как это было в IPv4 мире. Это продуманно и эффективно!
Отдельно хочется упомянуть отлично продуманный Mobile IPv6. Имея всего-лишь относительно простого демона (home agent) в домашней сети и демона на мобильном хосте (mobile agent), можно иметь полностью работающий мобильный IPv6, когда, обращаясь по домашнему адресу, всегда можно достучаться до мобильного. В отличии от Mobile IPv4, без каких-либо дополнительных требований к сети где находится мобильный агент. IP пакеты при этом просто будут эффективно (всего-лишь добавляя расширенный IPv6 заголовок) проксироваться с домашнего агента на мобильный. Кроме того, если сторонний инициатор соединения тоже поддерживает MIPv6, то он прозрачно договорится с домашним и мобильным агентами о том, что трафик он будет слать напрямую мобильному хосту, без проксирования через домашний, обеспечивая максимальную возможную эффективность (с учётом одного расширенного IPv6 заголовка) передачи. А благодаря быстрому NDP NUD, смена мобильной сети будет приводить к минимальным временным задержкам из-за обновления адреса мобильного хоста. И всё это с минимальными добавлениями в ICMPv6/NDP протоколы, введением простого расширенного IPv6 заголовка и Mobility Header.
Даёшь IPv6 и полноценный Интернет в массы!
gudvinr
Всё очень вкусно и весело, но сложность настройки, особенно на маршрутизаторах, намного выше чем для v4.
Для обычного человека с SOHO роутером, если производитель сразу хорошо сделал, никаких проблем нет и SLAAC — это может быть и круто, всё само раздалось, у устройств в сети белый внешний адрес появился.
Но недавно пытался настроить IPv6 на RouterOS и, несмотря на то, что провайдер поддерживает и в openwrt завелось всё сразу, микротик либо не выдаёт клиентам адреса, либо себе, либо не пускает трафик наружу через себя.
А все материалы сводятся к тому же, что у вас написано: настройте SLAAC, это стильно, модно и молодёжно. Но при этом стек технологий вокруг IPv6 крайне сложный, и если ты не зароешься в RFC на долгие дни, то разобраться весьма проблематично.
Wexter
SLAAC на ROS настраивается в 2 клика, просто кто-то всё ещё считает что ROS для домохозяек и всё должно предельно просто настраиваться.
gudvinr
И всё тоже самое, с точностью до вариаций перевода пишут в ответах на форумах микротика, на реддите, на stackexchange.
Что всё настроить тривиально, просто автор не разобрался. Но никто не говорит, как это сделать в два клика, чтобы при этом работало.
Wexter
Достаточно открыть вики и осмысленно прочитать.
SLAAC настраивается в добавлении адреса.
Если у вас статика — вешаете /64 адрес на интерфейс и ставите advertise=yes, если получаете по DHCP-PD — вешаете адрес ::1/64 (например, так то любой какой захотите), указываете пул адресов из которого брать и так-же включаете advertise. Допом в IPv6 — ND можете покастомизировать что микрот будет отдавать в SLAAC.
Если же вы из отряда тех кто хочет префикс отличный от /64 заставить работать с SLAAC — вам путь в RFC где определено что SLAAC должен работать только для /64.
edo1h
ну вот у меня дома есть динамическая подсеть /64 от провайдера.
есть wifi-сеть.
есть проводная сеть (даже не одна на самом деле, поделены vlan'ами)
есть сети для виртуалок.
и какой мне толк от сети /64 провайдера, если я не могу её нарезать?!?
stargrave2 Автор
Нарезать можете без проблем: у меня дома и /126 сетей не одна. Да, SLAAC на меньших размерах не будет работать.
edo1h
хорошо, и как будет выглядеть подключение к сети с телефона без SLAAC?
stargrave2 Автор
Если вам его хочется засунуть в сеть меньшего размера: руками (статика) или DHCPv6. Мне не мешало отдавать и /64 сеть SLAAC-у и одновременно нарезать её для хостов на одном и том же маршрутизаторе.
Только вопросы: а зачем вам её нарезать? У 99.9% пользователей не возникнет такой надобности (SLAAC удовлетворяет их). И чтобы вопросов «как нарезать» не возникало, дают рекомендации выдавать /56 или даже /48 сети конечным пользователям. Насколько видел статистику, большинство провайдеров выдавало /56 или больше.
edo1h
не мониторю ситуацию, но по состяюнию на год назад из трёх провайдеров в моём доме ipv6 предлагал только один, у него /64
Tolmy
Да, только вот есть явно больные на всю голову провайдеры, которые даже /64 выдавать жлобятся, а выдают /128. и когда просишь у них /56 смотрят на тебя, как на идиота. Хотя, с другой стороны, это ещё более-менее вменяемые провайдеры, совсем невменяемые говорят, что у "нас IPv6 нет и не планируется".
edo1h
а можно детали?
Tolmy
А главное, чтобы маршруты не пересекались. приоритет разный раскладываешь на route и всё работает.
edo1h
гугл привёл на:
https://version6.ru/isp
список провадйеров, предоставляющих ipv6, небольшой, почти у всех /64.
плюс там же список "Провайдеры, ранее предоставлявшие IPv6" размером чуть ли не с половину основного.
Wexter
попросите у провайдера /48, я не думаю что он разорится от этого
stargrave2 Автор
Полностью согласен! Именно поэтому рекомендуют давать больше чем /64. HurricaneElectric туннельный брокер например просто так даёт людям /48 префиксы, бесплатно и без проблем — так что это точно не проблема.
edo1h
имея опыт общения с провайдерами — даже пробовать не буду.
речь идёт о массовой услуге, вся вариативность ограничивается тем, какие "галочки" есть в личном кабинете и у девочек из колцентра. для vip-клиентов (юриков) могут быть варианты, но не для платящих 400р в месяц физиков.
stargrave2 Автор
Мне кажется всё может зависеть буквально просто от одного человека на той стороне, как повезёт (к сожалению). Ростелеком вот с трудом, но сказал что PTR записи для статических IP он будет выдавать только юрлицам. А вот NetByNet просто одним email-ом без проблем меняет и прописывает их.
nlykl
Мелкие провайдеры могут пойти навстречу. Мне два провайдера делали статику IPv4 абсолютно бесплатно.
netch80
> попросите у провайдера /48, я не думаю что он разорится от этого
«После пятнадцатого отрывания провода злобной уборщицей умоляешь провайдера перевести тебя на ppp. Провайдер добрый, посылает на [censored] только первые 82 раза, потом соглашается.» ©
netch80
> SLAAC настраивается в добавлении адреса.
OK, хочу послушать конкретные рецепты, как это выглядит — с именами производителей и моделей, которые это уже сделали (после 26 лет разработки IPv6). А именно для следующего юзкейса:
1. Провайдер выдал /56 (хороший, добрый провайдер). Как это происходит на протокольном уровне, и что надо нажать/написать у устройства, пригодного для раутера фирмочки на 20 человек.
2. Как этот же шлюз передаст информацию о выданной сети на раутер отдела, который будет выдавать уже /64 на отдел.
3. Что будет, если провайдер сменит этот адрес: как он пришлёт нотификацию, как она пробежится вниз до каждого конкретного компа/телефона/etc, заставляя их сменить адрес.
4. Как эта смена адреса будет отражена в DNS, поддерживаемом этими раутерами/шлюзами.
Упрощённый вариант — домашняя сеть, получено /56 или /64 от провайдера, точно так же раздаётся на уже одну локальную сеть (простым аппаратом с WiFi рогами ценой до 100$).
Варианты с домашним устройством дороже 100$ или SOHO дороже 300$ не принимаются. Варианты, где оповещение вниз вплоть до каждого аппарата (компа, телефона, принтера, умного дверного замка...) не раздаётся, и он тормозит часами, прежде чем перезапросить адрес — тоже.
Если такого варианта нет, он чудовищно дорог или требует больше, чем включить 2 галочки с понятными названиями на вебе раутера — все рассказы про SLAAC и прочие страшные слова это «в пользу бедных».
ivlad
Это делается за счёт prefix delegation. Иерархический PD тоже в принципе возможен, но я не уверен, что в «фирмочке на 20 человек он нужен». Такое, пожалуй, двумя кликами не настроить. Иерархические сети требуют больше усилий в настройке.
А вот второй вариант, да, в моем роутере, полученном от провайдера настроился двумя кликами.
Почитайте про PD. И не думайте, что эта проблема не была осознана и решена.
netch80
> А вот второй вариант, да, в моем роутере, полученном от провайдера настроился двумя кликами.
Вот я и прошу назвать модель, а также параметры (какие времена он позволяет задать, в первую очередь, для router advertisement). Как клиентские терминалы на это реагирует. Как оно отражается в DNS. Что это в принципе возможно и по каким словам — я знаю. Интересует именно практика на своём опыте.
> Почитайте про PD. И не думайте, что эта проблема не была осознана и решена.
Читал. Осознана — по крайней мере теми, кто способен осознать — спора нет. Решение — 1) таки вопрос о точных моделях. 2) Что с DNS? Это из коробки где-то есть? Заниматься сексом по скрещиванию какого-нибудь dhcpd с dnsmasq я-то смогу, а как быть админу мелкой конторы?
> Иерархический PD тоже в принципе возможен, но я не уверен, что в «фирмочке на 20 человек он нужен». Такое, пожалуй, двумя кликами не настроить. Иерархические сети требуют больше усилий в настройке.
Пусть не 20, а 50. Всё равно — уровень сложности настройки?
ivlad
https://www.asus.com/Networking/RT-AC1200G-plus/specifications/
Я поленился смотреть, что там можно настраивать. В RA прилетает 600 секунд lifetime и RDNSS.
Ожидаемо: настраивают префикс и DNS. В системных настройках появляются оба адреса роутера: v4 и v6. v6 появляется тот, что с глобальным скоупом.
Я без понятия. У меня маршрутизатор не умеет динамически апдейтить DNS для локальной зоны — что для v4, что для v6. Я не в курсе, какие SOHO маршрутизаторы такое умеют.
Мне кажется, вы хотите скрестить ужа с ежом: сначала говорите про SOHO маршрутизаторы и минимальную настройку в два клика, а потом сразу — про Active Directory. Насколько мне известно, AD в два клика не настраивается, а требует заметной работы при установке. В компаниях на 20 и даже на 50 человек не встречается, возможно, за исключением самых редких случаев. SOHO маршрутизатор — обычно 1-2-3 VLAN, затерминированные на нём. Резолв адресов — через mdns или LLMNR, никакого внутреннего DNS.
Как AD DC переживают изменение префикса, я не знаю, не сталкивался.
Я же написал, что двумя кликами не настроить, скорее всего. Это за пределами потребностей и способностей людей в малом бизнесе.
netch80
> Я поленился смотреть, что там можно настраивать. В RA прилетает 600 секунд lifetime и RDNSS.
OK. 600 секунд это настолько много, что слово «чудовищно» недостаточно, это ещё хуже. В идеале это всё должно реагировать за полсекунды, а на смену адреса эти самые RA должны лететь не ожидая таймаута и пачкой в несколько штук для дублирования. А для надёжности корпоративного уровня оно ещё должно заглянуть в lease DB и пинать каждого, кто не переключился.
> Я без понятия. У меня маршрутизатор не умеет динамически апдейтить DNS для локальной зоны — что для v4, что для v6. Я не в курсе, какие SOHO маршрутизаторы такое умеют.
Значит, пишу: этого ещё нет ;(
> Мне кажется, вы хотите скрестить ужа с ежом: сначала говорите про SOHO маршрутизаторы и минимальную настройку в два клика, а потом сразу — про Active Directory.
Нет, это вопрос по разным уровням, от минимума до близкого к максимуму. Но AD вполне возможен и на 50 сотрудников.
В общем, пока с практической доступностью этих возможностей явно не плохо, а очень плохо :(
ivlad
На что оно должно реагировать за полсекунды и почему? И какой протокол так уже сейчас делает?
Вы всё-таки определитесь, вы про "надёжность корпоративного уровня", или про SOHO маршрутизаторы.
Вполне возможен и на 5. Только обычно его нет.
Я ещё раз повторюсь, определите задачу. Если задача про SOHO маршрутизатор, обслуживающий два VLAN и меньше сотни клиентов — это одно. Если задача про AD и сотни клиентов с дополнительными маршрутизаторами внутри сети — другое. Пока вы перескакиваете с одной позиции на другую и жалуетесь, что SOHO коробка за сотню долларов не даёт вам достаточного времени сходимости. Так в IPv4 она тоже не даёт.
netch80
> На что оно должно реагировать за полсекунды и почему? И какой протокол так уже сейчас делает?
Протокол — не делает. А вот NAT — устраняет необходимость зависеть от внешних адресов в принципе.
Внутренняя сеть строится на site-local или ULA адресах, на границе — NAT. Проблемы известны, на некоторые я традиционно вою волком (как SIP media transport), но если выбирать, что лучше — знание внешними хакерами структуры внутренней сети или проблемы с отдельными сервисами — я выберу второе.
> Я ещё раз повторюсь, определите задачу. Если задача про SOHO маршрутизатор, обслуживающий два VLAN и меньше сотни клиентов — это одно. Если задача про AD и сотни клиентов с дополнительными маршрутизаторами внутри сети — другое.
В том и дело, что разницы здесь нет. Есть задача, универсальная на все случаи: если мы не используем постоянные внутренние адреса, а строим на внешних адресах — то имеем грабли, которые надо решать (и список этих граблей я привёл). Home или корпорация с AD — объём проблем тот же, меняются только те сетевые средства, которые надо лечить.
Тут, однако, надо заметить, что можно пытаться выставлять на каждый внутренний хост одновременно site-local/ULA и внешний адрес, во внутренний DNS выставлять внутренние адреса, и надеяться на маршрутизацию. Наверно, можно, но я ещё не видел dhcpd с выдачей нескольких адресов одновременно. Если это будет — можно будет обсудить грабли такого решения (но срочное оповещение при переключении таки всё равно будет полезно).
> Так в IPv4 она тоже не даёт.
В IPv4 частные адреса внутри — норма, и нет апологетов тотального отказа от них, которые на формулировки проблем начинают рассказывать, что сегодня потребности в колбасе нет.
ivlad
Если у нас возникает необходимость сменить префикс при переключении, маршрутизатор рассылает старый префикс с lifetime 0 и новый с lifetime больше 0. И после этого хосты получают новые адреса, думаю, как раз за те полсекунды или меньше.
Вы всё-таки в традициях RU.OS.CMP задаёте не тот вопрос, на который хотите ответ услышать, а потом жалуетесь, что вам ответ не подходит.
Это всё и лучше есть в OpenVMS, как говорится.
Не уверен, причём тут DHCP, если мы говорим про RA. IPv6 хосты могут иметь несколько адресов на интерфейсе (в том числе от разных маршрутизаторов), это им никак не мешает.
Корпорация — это наверняка PI адреса и BGP с парой провайдеров. Тут ничего не поменялось относительно IPv4. Разница между IPv6 в Яндексе и IPv6 у меня дома существенна. И я уверен, что вы про это в курсе, но специально делаете вид, что нет.
Это что они traceroute могут сделать или адреса порезолвить? Или какое знание?
netch80
> Если у нас возникает необходимость сменить префикс при переключении, маршрутизатор рассылает старый префикс с lifetime 0 и новый с lifetime больше 0. И после этого хосты получают новые адреса, думаю, как раз за те полсекунды или меньше.
Это теория или практика?
И как быть с возможными потерями в сети?
> Вы всё-таки в традициях RU.OS.CMP задаёте не тот вопрос, на который хотите ответ услышать, а потом жалуетесь, что вам ответ не подходит.
Я формулирую как общий вопрос, так и частные вопросы о предполагаемых наиболее типичных проблемах и методах реализации. Второе, естественно, уточняется по ходу общения. Но если собеседники отвечают только на частности (причём часто не на те вопросы, что задавались) и игнорируют общий вопрос — приходится ходить кругами.
RU.OS.CMP тут ни при чём, кроме того, что там тоже часто обсуждение велось из сравнения каких-то локальных абсолютов собеседников. Но там это часто была любимая система или привычный метод работы, а я таки иду от основной задачи.
> Не уверен, причём тут DHCP, если мы говорим про RA.
RA тоже устроит, если он будет уметь надёжно обновлять мировые адреса и поддерживать параллельные site-local/ULA.
> Корпорация — это наверняка PI адреса и BGP с парой провайдеров.
Хм, а почему сразу «наверняка PI»? По моим данным, это как раз далеко не типичный случай даже для крупных корпоративных сетей. Наоборот, многие отказывались именно потому, что им казалось надёжнее опираться на провайдера, даже если возникает какой-то внутренний балансинг.
> И я уверен, что вы про это в курсе, но специально делаете вид, что нет.
В курсе. «Специально» что — не признаю тотальность стремления к PI для таких целей? Верно, не признаю — потому что вижу обратное — PI таких мало.
> Или какое знание?
Какие хосты входят в какие сети (грубый пример: наверняка у безопасностников своя локалка; вот пришёл кто-то явно по профилю => всех из того же /64 более активно подозреваем, что у них есть спецдоступ, и готовим трояны для них).
Какие запросы ходят с одного хоста (вот этот вот ...:01:02:ff:fe:03:04 явно бухгалтер, а сосед — явно продажник).
И прочая и прочая. Если против фирмы начат APT, то на этом можно собрать много информации для будущих диверсий.
ivlad
RFC4861 разделы 6.3.4 и 6.3.5. Если вы скажете, что это теория потому, что кто-то может не следовать RFC, то я сразу могу ответить, что крупные игроки RFC в основном следуют, а те, кто не смог правильно реализовать, не реализуют IPv6.
Самое худшее, если клиент пропустит все RA, то оттаймаутится.
А по моим — наоборот. И что теперь?
Если они решили опираться на провайдера, они могут договориться с провайдером о статическом префиксе. Это те же компании, которые договариваются о статическом IPv4 на внешнем интерфейсе, чтобы поднимать IPSec.
А то вы опять смешиваете SOHO и средние и крупные компании.
Сейчас большие сети так делать не рекомендуют. Делают L3 между доступом и агрегацией и выделяют /64 (или больше) на коммутатор на уровне доступа. Поэтому да, можно извне отличить восьмой этаж офиса от пятого. Эта проблема существует.
Wexter
Статика или DHCP-PD?
DHCP-PD
Кстати интересный вопрос, надо будет проверить на досуге, но скорее всего большая часть производителей не рассчитывала на такой вариант.
Тут увы я бессилен, с виндовой инфраструктурой к счастью не приходилось работать. Хотя сдаётся мне что для компании получать от провайдера динамику — признак плохого тона. 99% проблем решится договорённостью с провайдером на статику.
Не знаю как в в длинка/тплинках/etc, в микротике (что забавно он попадает и до 100$ и больше 300$, ибо ось одна на всех) можно настроить время делегирования префикса, опять же нужно проверить на практике, есть у меня большая уверенность что микротик разошлёт всем в сети новый префикс.
netch80
> DHCP-PD
Это реально работает, что корневой DHCP сервер передаёт подчинённому, а тот — пинает уже своих листовых подчинённых?
> Кстати интересный вопрос, надо будет проверить на досуге, но скорее всего большая часть производителей не рассчитывала на такой вариант.
Вот как раз я слышал про фиаско поиска такой возможности. А это значит, что динамика тут не работает.
> можно настроить время делегирования префикса
Нужно не время делегирования, а прямой пинок всем, а то и с повторами.
И это я ещё не поднял тему пропинать всех внутри OS (что, если, как сейчас чуть менее, чем все, держат всякие websocket?)
ivlad
А какой протокол так делает?
netch80
См. соседний ответ.
dimaaannn
Именно так. Имел аналогичный опыт в настройке микротика, с попыткой прогнать всё это через туннельного брокера. Я совершенно не понимаю комментаторов, которые говорят что «настраивается в 2 клика», рассуждая с точки зрения обывателя
Немного нытья, почему я выпилил нафиг IPv6 из своей небольшой сетки:
1. Совершенно нечитабельные и не запоминаемые адреса. Зайти на удалённую машину вбивая IPv6 руками? Нет, спасибо. Продиктовать его кому-то по телефону? Селестия упаси.
Гораздо проще настроить локальный DNS, но делать это для каждого ресурса совершенно нет желания.
2. Непонятность принципов работы. Я использовал туннельного брокера для получения глобальной подсети, и надеялся что при небольших усилиях смогу получать доступ к определённым ресурсам внутренней сети извне.
Однако реальность была другого мнения. Машины сами назначают себе случайные адреса, маршрутизатор раздаёт адреса, но они не работают извне, raspberry pi вообще отказалась адекватно взаимодействовать с IPv6, выдавая ошибку при попытке обновления.
3. Общая сложность наворотов технологий. Как настроить фаерволл, шоб не накосячить? Как настроить маршрутизацию с внешними сетями? Какие это вообще даёт преимущество лично мне, как «SOHO администратору»?
Я не пытаюсь кого то убедить что IPv6 это плохо, просто рассказываю своё видение как «не специалиста по сетевым технологиям» а как «немного шарящего в сетях чувака»
Wexter
Ну начнём
Ну такая себе претензия, DynDNS никто не отменял, думаю в ближайшее время появится такой функционал у большинства девайсов.
Адреса у вас скорее всего раздались по SLAAC, при таком варианте устройство получает 2 адреса, один постоянный на основе MAC адреса (EUI-64), второй сгенерированный рандомно и сменяемый с некоторым интервалом.
Про «не работали извне», либо у вас некорректно настроен файрвол на маршрутизаторе, либо на хосте. Либо и там и там.
Да так-же как в ипв4. Разрешить ICMP и входящий трафик для ESTABLISHED/RELATED соединений. Ну и по желанию открыть полный доступ к хостам имеющим свой файрвол, либо для каждого хоста прописывать правила для портов/протоколов на роутере.
Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.
Собственно говоря настройка файрвола на IPv4 и IPv6 ничем не отличается, просто у вас никогда небыло своей хотя бы /24 белой в IPv4 которая маршрутизируется глобально. Скорее всего вы всю жизнь считали что NAT это файрвол и он защищает всю вашу сеть, что в корне неверно
dimaaannn
Настроить банальную маршрутизацию — это НЕ админские задачи, максимум — уровень эникейщика. С IPv4 проблем в этом плане никогда не было, как и с фаерволлом для него.
Согласитесь, чтобы установить роутер в квартиру и сделать «шоб работало» — это уровень домохозяек, но никак не эникейщиков.
В данном случае, мы перепрыгиваем с уровня домохозяйки на уровень полноценного админа, для выполнения довольно банальной задачи.
Мне кажется, это совершенно не приемлимо как в плане безопасности, так и для юзабилити системы в целом
Wexter
Банальную это прописать шлюз? В таком случае естественно это не админские задачи, вот только про это я ничего и не писал, с чего вы начали переводить стрелки?
Установить роутер и включить получение адреса по DHCP одинаково легко для домохозяек как для ipv4, так и для ipv6. Выше спрашивали про более сложные конфигурации, выходящие за пределы «домашнего» использования.
netch80
> Ну такая себе претензия, DynDNS никто не отменял, думаю в ближайшее время появится такой функционал у большинства девайсов.
IPv6 — 26 лет. Новое поколение выросло. Где функциональность?
Но DNS — это тут не ответ. Как только начинаются реальные проблемы «только где же этот кто-то и куда он мог залезть?» — начинается поиск на уровне IP адресов. И вот тут-то оно и стукнет. Запомнить среднему админу даже пару десятков IP адресов не проблема. А v6?
> Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.
Ну я админом разных уровней, вплоть до CTO провайдера, был 10 лет, так что представляю себе.
Да, проблем не так много по их чисто количеству — длинные адреса, дублирование адресных пространств, сложность одновременной поддержки DHCPv4 и RAv6 (если кому-то нужно), дублирование в DNS (и необходимость управления логики резолвинга), шлюзы адресаций, всё назвал? Но каждая сама по себе бьёт достаточно серьёзно.
Wexter
А кто его за последние 26 лет торопился внедрять и тестировать в массах? По вашему IPv4 на старте не имел проблем и там всё сразу было?
У админа пара триллионов серверов в сети? Запомнить пару десятков адресов точно так-же просто. Если у вас проблемы с запоминанием — это не проблема протокола.
Все проблемы что вы перечислены чисто надуманные и относятся к разряду «я привык на ipv4 и нафиг мне ваш ipv6, чего вдруг я должен что-то ещё изучать и понимать для внедрения?». Хотя там все новшества изучаются за один вечер неспешно.
Нужно дождаться массового внедрения (хотя бы 50% мирового трафика) и поддержки у 80% производителей софта/железа, тогда уже можно будет говорить о реальных проблемах, а не об этих детских придирках.
Лично у меня пока никаких проблем не возникает с внедрением IPv6 (кроме тугих провайдеров не желающих разбираться).
netch80
> А кто его за последние 26 лет торопился внедрять и тестировать в массах? По вашему IPv4 на старте не имел проблем и там всё сразу было?
Проблема с миграцией адресов в сети по сигналу от провайдера — не требует какого-то особого «тестирования». Она понимается любым, кто хотя бы 5 минут спокойно посидит подумает над проблематикой и захочет решать осмысленно, а не затыканием дырки — и, кстати, неоднократно озвучивалась ещё в 90-е. Но ни вендоры, ни IETF оказались не заинтересованы в минимальном предвидении хотя бы на полшага вперёд.
> Все проблемы что вы перечислены чисто надуманные
Ни капельки. Даже проблема размера адреса это следствие известного правила «7±2»: v4 адрес ещё влезает в объём запоминаемого одной порцией, v6 — уже надо специально дробить на части и применять особые мнемотехники. Это, да, не юзерам (большинству) головная боль, это админам.
Если вы лично от этого не страдаете — считаем, вам повезло.
> Хотя там все новшества изучаются за один вечер неспешно.
«Изучить новшества» да, можно за один вечер. Но от этого до реальной практики — километровая пропасть.
> а не об этих детских придирках.
Вот эти «детские придирки» и начали реально выстреливать на вопросе того же использования NAT.
Wexter
Если вендоры и IETF не приняли это за проблему то тут два варианта
1) Это действительно не проблема
2) Это проблема касается крайне малого процента людей и видимо вызвана изначально неправильной структурой сети.
Понятно, я походу общаюсь с толстейшим троллем который даже понимать не хочет зачем IPv6 был создан. А одна из причин его появления это полный отказ от NAT, который вообще появился как костыль на половине жизненного пути IPv4
netch80
> Понятно, я походу общаюсь с толстейшим троллем который даже понимать не хочет зачем IPv6 был создан.
Вы общаетесь с тем, кто 1) наблюдал ещё очень ранние шаги и хайп по поводу будущих перспектив IPv6, 2) в отличие от (похоже на то) большинства присутствующих, читал не только отдельные финальные RFC, но ещё и обсуждения и мотивации, а также плотно наблюдал несколько попыток радостного внедрения, с их последствиями.
Эмоции мне ваши пофиг, так что про тролля можете не фантазировать. А вот ответы на возникшие вопросы, неожиданные интересные мысли — очень даже, но, видимо, их тут уже не будет.
> А одна из причин его появления это полный отказ от NAT
Верно — в детских фантазиях его первых авторов так и было бы. Но это было ещё в том интернете, где не было ни спама, ни хакеров в нынешнем количестве, и где вообще защищаться ни от чего не было нужно (а червь Морриса пробежал и был прочно забыт, как курьёз), и даже «два Bay» ещё не взрывались. Для нынешнего мира все эти наивные мечтания не годятся в принципе.
> Это проблема касается крайне малого процента людей
Верно, те, кто сейчас может наткнуться на такую проблему — вытребывают статические адреса. Но это пока не началось реально широкое распространение за пределы мобильщиков и прочих чисто-end-user групп плюс высоких корпоратов.
> и видимо вызвана изначально неправильной структурой сети.
Да-да, плавали, знаем. «У вас кривые руки» на любое отклонение от генеральной линии партии, 640KB хватит всем, а пони розовые и летают. Заранее прошу: если нет конструктивных ответов — не увеличивайте локальную энтропию.
edo1h
я правильно понимаю, то с модератором RU.UNIX.PROG?
netch80
Да.
Только что толку, если последний активный тред в ней был 2 года назад, а предпоследний — летом 15-го.
Ну, могу постить в неё копии заметок из блога, поможет?
edo1h
нет, конечно.
fido мёртв, кто же с этим спорит.
но именно профессиональные эхи мне жалко.
P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )
netch80
> но именно профессиональные эхи мне жалко.
RU.UNIX.BSD на удивление живая. Но там ветераны :)
Для RU.UNIX.PROG таких не нашлось, а следующее поколение думает уже на другом уровне и другими категориями — это типа тех, кто только Linux, но с nodejs в контейнере. Им та тематика тупо не нужна.
> P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )
Вопросов не задают. А сгружать весь stackoverflow в него как-то некошерно.
dvserg
Неужели NAT такой весь из себя злой и ужасный? Мне кажется у него есть очень большой плюс в качестве барьера от внешних угроз внутренним сетям. Что IPv6 может предложить в этом плане? Плоская всемирная сеть хорошая идея для идеального мира. В реальности концепция приватных сетей находит большое применение.
stargrave2 Автор
NAT это просто сломанная связанность между хостами. С таким же успехом можно просто перерезать провода и сказать что это ещё более безопасно (и с этим тоже не поспорить). Для безопасности всю жизнь предполагалось и предполагается использовать firewall. Правило блокирующее внешние подключения к хостам локальной сети наверное в большинстве firewall-ов занимает одну строку.
ky0
В том-то и дело, что блокировать всё подряд — легко. А если всё-таки некоторые доступы нужны? А у нас всё подряд автоматически раздаёт себе адреса, а то и здоровенные диапазоны, пингует всё вокруг по ICMPv6, мультикастом и т.д.?
Я умом понимаю все те плюсы, которые перечислены. Но с точки зрения обеспечения безопасности и настройки фаерволла, который делает нечто большее, чем блокирует входящие подключения — глаза пока ещё боятся, если честно.
stargrave2 Автор
А чем настройка разрешения доступа на firewall будет отличаться от настройки прокидывания портов на NAT? И там и там по одной строчке правил, грубо говоря. NAT никогда не избавлял от firewall-а и необходимости его настройки.
stetzen
Кажется, что основной плюс NAT — то, что его «из коробки» тяжело приготовить небезопасно. Если домашняя сеть сидит за NAT, то производитель роутера не может легко и непринуждённо решить, что «а все входящие запросы мы направляем вот этой конкретной машине» и выставить её тем самым голым фронтом в интернет, проброс портов — это всё же осознанное действие, направленное на конкретные машины и конкретные порты. В то же время с v6 простое и в целом естественное решение для производителя роутера — направлять все входящие запросы по соответствующим айпи и тем самым да, создать проблемы с безопасностью. Действительно, если роутер из коробки будет иметь правило «все входящие рубить на роутере», а для внешнего доступа надо будет руками открывать конкретный порт к конкретной машине, то это ничем особо не будет отличаться от NAT с точки зрения безопасности, но у меня как-то нет уверенности, что все производители домашних роутеров будут вести себя именно так.
ivlad
Самое естественное решение — дропать по умолчанию все соединения извне внутрь. Собственно, так производители SOHO маршрутизаторов и поступают.
powerman
Ну т.е. с одной стороны декларируется (автором статьи, как минимум) "настоящий" Интернет, а с другой стороны мы прикрываемся магией conntrack, который должен определить какой UDP/ICMP/другой левый не-TCP-протокол пакет относится к мифическому "соединению", а какой нет? И для корректной работы которого хотя бы с некоторыми известными ему протоколами нужно ещё не забыть собрать и подгрузить модули-helper-ы.
MIKEk8
На мой взгляд обычному пользователю в роутере проще тыкнуть что к этим 2 компам(т.к. у каждого есть свой внешний ip) будет доступ по ftp. Чем заморачиваться, что входящие запросы на порт 20 и 21 ты переадресовывай на порт 20 и 21 на компьютер А, в запросы на порты 22 и 23 на порты 20 и 21 на комп Б, а потом ещё надо SSH прокинуть, а порт 22 ты уже заюзал, «ой ай аяяйай», а потом ещё на клиентах порты менять…
netch80
Так conntrack, если ему не мешать, для основных протоколов это делает сам.
С NAT: FTP с внутренней стороны написал «шли мне данные на 192.168.23.198 порт 20» — тот поменял на 1.2.3.4 порт 61296 и исправил в проходящем FTP запросе.
Без NAT: хост и порт никто не менял, только дырочка проковыряна — результат тот же, входящее соединение будет принято и отраучено внутрь.
Проблемы начинаются, когда
— Какой-то свой нестандартный протокол, или даже стандартный (как SIP с SDP сессиями), но в шлюз не вложили понимание протокола
— Когда протокол стандартный, но шлюз его не опознал (классика — FTP, но на другом порту, не на 21)
— Когда таймаут на жизнь такого временного доступа (где 30 секунд, а где и полчаса) истёк, а данные всё не пошли (ну перегружен сервер, что делать)
Потому когда-то HTTP стал счастьем для файлового доступа, даже если это просто экспортированное в мир файловое дерево; а потом websocket для постоянного потока внутрь. IAX[2] — для VoIP, потому что нет мучений с тем, что шлюз не увидел SDP или не знает, что с ним делать. Можно ещё поискать примеров.
Увы, security — если не хочется всё выставлять всем в мир — всегда будет вызывать какие-то ограничения и проблемы. v4/v6, NAT/неNAT — тут уже второстепенное.
ivlad
Сдесь была дискуссия о том, что NAT — не инструмент безопасности. Межсетевой экран — инструмент безопасности. Межсетевой экран можно выключить, если хосты сами будут заниматься фильтрацией трафика. NAT выключить нельзя. Вот в этом разница.
Положим, есть Маша и Петя, живущие вместе и любящие он-лайн игры. Для он-лайн игры нужно открыть какой-то конкретный порт на вход, туда будет литься трафик. Как такая схема реализуется с NAT?
netch80
> Для он-лайн игры нужно открыть какой-то конкретный порт на вход, туда будет литься трафик. Как такая схема реализуется с NAT?
Я пропущу про жизнь Маши и Пети вместе (непонятно, они за одним NAT или разным) и непонятку с тем, сервер онлайн игры публичный или нет, отвечу со всеми случаями.
1. С этого порта изнутри открывается исходящее соединение, по которому будет вливаться поток. Это работает со всеми типами NAT и именно это считается основным универсальным путём. Если сервер онлайн игры публичный, то он будет принимать все входящие и именно это будет безусловно работать.
Вариант имеет проблемы, если обе стороны за NAT (см. пункт 2). Но тогда и просто stateful firewall будет иметь проблемы, см. ниже.
2. Если NAT «конусового» типа, внешний адрес универсален (соответствует внутреннему) для всех ремотных. В этом случае клиент за NAT делает пробу с STUN-сервером, узнаёт свой внешний адрес и анонсирует его удалённой стороне. Также STUN-сервер может сказать, что NAT не конусовый, а симметричный, и эта мера не проходит. Реально конусовых NAT среди мелких — большинство, и подобный подход работает. С точки зрения секурности нет никакой разницы с тем, что вообще пришёл кто-то неизвестный, кроме того, что сверку адресов по сигнальному протоколу надо заменить сверкой содержимого. В случае обеих сторон за NAT, конусовость хотя бы одного из их NAT достаточна для установления связи.
3. NAT может опознать в протоколе посылку адреса порта и подменить, создав ассоциацию для входящих соединений. Для какого-то распространённого протокола, типа FTP, работает. Для онлайн игры со своим протоколом — скорее всего, нет.
4. Некоторые NAT имеют средства управления типа «а проковыряй мне дырочку». Фактически результат сходен с cone NAT + STUN, но со внутренним управлением. Уже не помню ключевые слова к этому средству, и вообще оно очень редкое, так что ставлю вариант в конец. (Практически, SOCKS чаще даёт то же самое, и надёжнее.)
По поводу первых двух вариантов — с моими 10+ годами VoIP я потоптался по всем вариантам подобных проблем и их решений ;) Самое надёжное, разумеется — это прокси на открытом «белом» адресе между сторонами. Тогда связность гарантирована. Если только одна сторона за NAT/SFW (stateful firewall) — тоже. Если обе — вот тут начинаются проблемы. Проблемы бывают двух источников:
1. Обе стороны за симметричным NAT, прокси нет. Шансов связаться — нет.
2. Обе стороны за своими SFW. Связь есть только если обе стороны одновременно могут издать исходящие пакеты. Для медиатрафика в VoIP (SIP, H.323) это норма, и вообще для UDP — не проблема. Для TCP — сильно сложнее, не все стеки разрешают одновременные встречные connect() без listen(). Для SCTP невозможно по дизайну, там всегда одна сторона изначально в listening.
И вот как раз пункт 2 переходит на IPv6 в полный рост: если там файрволлы с обеих сторон и их нельзя изнутри убедить «впусти мне входящие и дай свой адрес» — связи не получится.
ivlad
Как это будет работать, если Маша и Петя играют одновременно и им одновременно нужен один и тот же порт?
netch80
В каком смысле «один и тот же порт»?
Если вы имеете в виду соединение с разных внутренних адресов на один и тот же удалённый адрес, то NAT поставит их разным внутренним адресам разные внешние на своей границе.
Например, удалённый (игрового сервера) 1.2.3.4:5000, внутренние — у Маши 192.168.0.1:54230, у Пети 192.168.0.2:37665. Внешний адрес NAT шлюза — 5.6.7.8. Тогда, например, для 192.168.0.1:54230 (Маша) будет назначен внешний 5.6.7.8:1025, для 192.168.0.2:37665 (Петя) будет внешний 5.6.7.8:1026. В результате, для удалённого сервера это будут разные клиенты. Каждая такая ассоциация между внутренним и внешним адресом живёт некоторое фиксированное время от прохождения последнего пакета по ней, для UDP типичное время порядка минуты, для TCP может составлять, например, 1 час, если не прошёл явный FIN.
Если был вопрос только в этом, советую перечитать основы NAT, чтобы не плавать настолько в азах.
Если вопрос в чём-то другом — сформулируйте так, чтобы его можно было понять.
ivlad
Нет, Маша и Петя должны получать трафик на порт 5000 одновременно.
netch80
Повторю:
>> Если вопрос в чём-то другом — сформулируйте так, чтобы его можно было понять.
О каком порте 5000 на каком из хостов идёт речь? Пожалуйста, формулируйте сразу так, чтобы не надо было вытягивать подробности клещами.
ivlad
Повторюсь:
Маша и Петя, живущие вместе и любят он-лайн игры. Они хотят играть одновременно. Для он-лайн игры нужно открыть какой-то конкретный порт на вход (например, 5000), туда будет литься трафик извне. То есть, этот порт должен извне быть 5000 потому, что другие игроки будут туда отправлять трафик. Этот порт внутри тоже будет 5000 потому, что их игра слушает на этом порту.
Как это сделать с NAT?
netch80
Вы всё ещё не можете чётко сформулировать задачу, но, насколько я смог расшифровать эту постановку… как говорится, вы или крестик снимите, или трусы наденьте.
Если у онлайн-игры сервер _снаружи_ локалки Маши и Пети, то ситуации типа «игра слушает на этом конкретном, заданном жёстко самой игрой, порту» не бывает. Клиентская сторона никогда не фиксирует у себя конкретный порт, она полагается на аллокацию операционной системой динамического номера порта, и или открывает одно соединение с этого порта, или, если ей нужны дополнительные соединения, передаёт уже полученный порт другой стороне или серверу. Времена, когда фиксировали клиентские порты, закончились вместе с первыми опытами жизни FTP в гетерогенной среде (и не только из-за NAT), то есть это не позже середины 90-х. Сейчас просто нет таких требований.
(Исключение: есть игры, которые для сетевого режима используют один и тот же порт для всех участников и бродкастят сообщения. Но это работает только в пределах одного L2 сегмента, не масштабируется на большее количество, и я не видел такого со времён первой халвы: кажется, последний, что такое умел, был Duke3D. А, может, ещё раньше закончилось, память уже теряет такие подробности.)
Если кто-то из Маши и Пети поднял у себя в локалке _сервер_ игры, то у них будет один сервер. Именно для этого сервера строится явное правило статической трансляции внутрь: все входящие соединения на порт 5000 перебрасываются на указанный внутренний адрес на порт 5000. Эта возможность присутствует даже на мелких домашних раутерах, начиная со знаменитого DI-604, и тем более на любых более продвинутых средствах. Для внутреннего получателя его IP будет внутренним, но IP другой стороны — мировым (если это не в его локалке). Исходящие пакеты от него будут транслироваться с заменой адреса отправителя на установленный настройкой внешний адрес.
Второй участник (предположим, что сервер у Маши — тогда это Петя) может подключаться к серверу Маши или по внутреннему адресу, или по внешнему — это на большинстве мелких раутеров тоже работает.
Если Маша и Петя хотят каждый у себя поднять по серверу… да, в этом случае им надо будет прописать разные порты в конфигурации статического NAT — и это ничем не будет отличаться от ситуации, например, выделенного сервера в ДЦ с одиночным IP и двумя процессами сервера игры на разных портах.
Если я всё ещё не угадал… ну пока у меня есть настроение — можете ещё покрутить, но лучше вы всё-таки научитесь формулировать так, чтобы было понятно с первого раза. Достаточный набор терминов для этого или присутствует в базе IP (хост, порт), или мной уже несколько раз упомянут в описании NAT (как внутренний, внешний и удалённый адреса).
ivlad
Нет, это не сервер. Это многопользовательские игры, в которых для уменьшения RTT клиенты могут общаться друг с другом напрямую.
Такой длинный ответ вместо простого "нет".
Ясно, спасибо.
netch80
> Нет, это не сервер. Это многопользовательские игры, в которых для уменьшения RTT клиенты могут общаться друг с другом напрямую.
«Это» это где? В том, что вы хотели получить? Ну тогда это случай варианта 1 из моего описания, с некоторой дополнительной службой, которая оповещает участников об адресах друг друга, но дальше они взаимодействуют напрямую. И при этом ни хосты, ни порты не фиксируются, а определяются через эту службу имён.
> Такой длинный ответ вместо простого «нет».
Если ответ сократить до одного слова, то это «да». Но вы его не поняли.
> Ясно, спасибо.
Таки не за что. У меня не сработал /dev/telepathy, а вы не захотели ни объяснить, ни понять. Что ж, с таким я бессилен. Другие, надеюсь, захотят.
Tolmy
И всё таки ответ "нет".
Пример. MMORPG, у которой сервер работает только как сервер авторизации, остальная связность работает как огромная mesh-сеть, где теоретически каждый может быть связан с каждым, на практике образуются ячейки связанных между собой игроков. Каждый из компов игроков — это тоже сервер по сути. И их может быть десятки тысяч. Если у кого-то сетевые проблемы, то ответ техподдержки категоричен и вынесен в FAQ — получите выделенный белый "адрес" и откройте порт XXXX на входящие соединения. Как, нас не волнует.
И вот как раз с территории бывшего уже, я так понимаю, СНГ, больше всего стонов "мой провайдер белые адреса принципиально не выдает, что мне делать?" И стандартный ответ, "поздравляем, похоже вы зря потратили на игру своё бабло".
netch80
Понятно. То есть со всего огромного игрового мира нашлись какие-то шизанутые ламеры-ретрограды, которым принципиален конкретный номер порта… да, в таком случае чистая возможность получить больше адресов становится полезным.
(Но, поднявшись над конкретной проблемой, это выглядит примерно такой же дикостью, как если бы они потребовали держать связь по UUCP поверх диалапа и Netware на узлах.)
kbkbkb
А потом следить за актуальностью софта на каждом хосте, чтобы его не взломали (к примеру, какие-нибудь дешевые камеры)? Вы утрируете, говоря, что NAT «это просто сломанная связность» — для большого количества кейсов это удобный механизм как с точки зрения безопасности, так и удобства настройки.
stargrave2 Автор
Не спорю что сломанная связанность может быть удобна в каких-то случаях. Но это остаётся сломанной связанностью.
kbkbkb
Это вы назвали эту связность «сломанной». Можно назвать ее, например, «непрямой», или «усложненной». Сломанная — это если бы вообще не работала. Несимметричные маршруты, неоптимальные маршруты, низкие MTU и пр. — вы тоже назовете «сломанной связностью»?
stargrave2 Автор
Можно назвать полудуплексной. В одну сторону соединяться можно, в другую нет.
netch80
Тогда она формально симплексная, что значит — в одну сторону. Полудуплексная — это когда стороны чередуются :)
Про ценность такой односторонности уже написал рядом.
Но, кроме того, NAT позволяет скрыть: количество хостов внутри сети, их группировку по сетям; группировку запросов по их источникам (до хоста); связность между запросами во времени (приходят с одного хоста или с разных). Для какого-нибудь фейсбука это, безусловно, зло — он хочет отслеживать каждого юзера отдельно. Но для клиента, которому реально надо хоть немного параноить, это безусловное благо. Потому NAT будет сохраняться и для IPv6, независимо от доступности адресов — и я бы его рекомендовал всем, по этим же причинам.
vibornoff
И проблема трекинга уже сейчас решается выдачей по 2 адреса через SLAAC:
— «белого» для входящих соединений
— «серого» периодически реролящегося для исходящих соединений.
netch80
> «серого» периодически реролящегося для исходящих соединений.
То есть те соединения, которым нужно долговременное существование, будут постоянно обрываться и клиентская система должна будет их пересоздавать? Вы серьёзно?
none7
Нет не обрываются. Временные адреса при наличии привязки к ним хоть одного сокета, будут жить вечно. Но в таком случае существует риск, что из за какого то приложения, система захапает тысячи адресов.
netch80
> Но в таком случае существует риск, что из за какого то приложения, система захапает тысячи адресов.
Или из-за многих разных :)
Ответ понятен, спасибо. Как решение в принципе это может работать, да. Но откровенно выглядит как «на какое только извращение люди не пойдут, чтобы только не использовать уже проверенные годами технологии». :crash:
vibornoff
Или, в случае v4, затрэшит табличку трансляции.
Tolmy
Windows 10. Хром и открытые на фейсбук закладки. А если есть одновременно и IPv6, и IPv4, то винда по умолчанию всегда использует IPv6. Через сутки количество временных адресов на интерфейсе переваливает за сотню. Именно из работы этого механизма в сочетании с забавным механизмом доставки push-сообщений.
Вообще, противники IPv6 в чем-то правы, граблей по нем раскидано немеряно, и, хотя жить они в общем не мешают, по крайней мере обычному пользователю, которому всё равно, что там работает транспортом, но сетевикам про эти нюансы лучше знать.
vibornoff
Подробности в RFC.
От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма. А то, что соединения постоянно обрываются, — так это вы сами придумали.
netch80
> А то, что соединения постоянно обрываются, — так это вы сами придумали.
Ну вы сами сказали про 2 адреса, а не произвольное количество :) Единственный вывод. Если недоговариваете — будьте готовы к подобному. RFC почитаю на досуге, спасибо.
> От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма.
Для v4 это тоже уже много лет как норма. Вопрос в том, как между ними распределять роли.
Я так полагаю, за счёт чего-то определяется, что на один адрес соединения вешаются по умолчанию, а на второй — только явным указанием в bind()? Если да — можете не отвечать, найду в тех же RFC. Но если нет — то прямо работать не будет.
cartmenez
Что за смех? Миллионы домохозяек будут сидеть и править iptables? Nat в нынешних реалиях это скорее благо, нежели зло. Можно сидеть на уязвимом во все дыры тп-линке и не париться.
И да, что конкретно ломает домохозяйкам (подавляющему большинству пользователей сети)?
netch80
> NAT это просто сломанная связанность между хостами.
Односторонне ограниченная, а не сломанная. Про перерезанный провод — спишем на полемический задор.
> Для безопасности всю жизнь предполагалось и предполагается использовать firewall.
Это вы рассматриваете единственный аспект безопасности — отсутствие возможности прямого несанкционированного доступа извне.
Почему вы игнорируете, например, необходимость сокрытия внутренней структуры, количества хостов, группировки размещений сервисов, связи между запросами разных клиентов?
Кроме безопасности: как вы будете отражать факт смены адресов провайдером так, чтобы это прошло прозрачно для пользователей? Минимум потребностей я описал тут, причём не уверен, что не пропустил ничего важного.
andreymal
NAT никак не изолирует внутреннюю сеть от подключения извне. https://habr.com/ru/post/402187/#comment_18100189
От внешних угроз защищает фаервол.
Jogger
Не совсем так. Вот смотрите, есть сеть1 и сеть2, есть роутер видящий обе эти сети. Сети никак не связаны. Что в данном случае защищает сеть1 от сети2? Никаким фаерволом там не пахнет. Теперь добавляем между сетями NAT — теперь у нас есть частичная связь, например сеть1 может отправлять запросы в сеть2 и получать ответ, но входящие соединения из сети2 в сеть1 не попадут. Сеть1 всё так же частично защищена от сети2, однако никакого фаервола мы не добавляли! Что в этом случае защищает сеть1 от сети2? Да то же самое что и в первом случае — неполная связанность сетей. Да, сам по себе NAT никого не защищает, скорее наоборот, поскольку он даёт частичную связанность, а не убирает остальные связи. Но и говорить что защищает фаервол — неверно. А поскольку именно NAT даёт возможность использовать частично связанные сети, то в быту и говорят, что защищает NAT.
stetzen
Насколько я могу понять, там по ссылке естественный способ обхода такого рода «защиты». Если атакующий находится в сети 2, то он может указать адрес (из сети 2) роутера сети 1 в качестве шлюза, после чего обратиться к адресу из сети 1 напрямую — и NAT сам по себе, без дополнительных настроек (которые, впрочем, зачастую активны по умолчанию), позволит ему это сделать.
andreymal
Попадут. Если сеть2 знает адрес конкретного компьютера из сети1 и отправит запрос к этому адресу через роутер, то роутер его прекрасно перенаправит по своим маршрутам в сеть1 без всяких там NAT, независимо от его наличия или отсутствия.
Я пожертвовал своей сетью и перед написанием комментария провёл эксперимент, подключив к своему роутеру вместо интернет-провайдера один из компьютеров, который имитировал сеть2. И он прекрасно получал доступ к сети1 (домашней сети за роутером) в обход NAT, пока я на роутере не врубил фаервол.
AWSVladimir
Можно по подробней с айпишниками про этот фантастический кейс?
Как можно через NAT достучатся даже зная внутренний айпишник (например на 192.168.1.10), без проброса портов?
Для TCP это в принципе невозможно, для UDP есть возможность, но только когда сам 192.168.1.10 полез по UDP через NAT.
Если же 192.168.1.10 только ожидает подключения, как через NAT можно к нему достучаться?
edo1h
они про подключение по l2 к wan-порту роутера
andreymal
Очень просто: отправить роутеру IP-пакет, в получателе указав нужный адрес (192.168.1.10). Роутер просто его отроутит по прописанным в нём маршрутам и всё. NAT'у здесь просто неоткуда взяться — он действует, только если отправлять пакеты непосредственно на адрес роутера, причём адрес принадлежащий сети2 (то есть не 192.168.1.1, а какой там интернет-провайдер выдаст роутеру)
Это работает для любых протоколов на базе IP, в том числе для TCP. Я проверял это, открывая http-сайтик, запущенный на своём компьютере в сети1, и на компьютере из сети2 он успешно открылся в обход всех NAT.
a1888877
В той статье есть небольшое передергивание. NAT сам по себе не изолирует, а вот NAT вместе с маршрутизацией провайдера — идеальный фаервол. Если ты напрямую подключен к роутеру, то да, можно маршрутизировать пакеты в сеть за NAT-ом, а если между злоумышленником и тобой есть хоть один маршрутизатор — то всё, внешней угрозы не получится.
andreymal
Да, но это если доверять провайдеру и не считать его внешней угрозой
kbkbkb
А теперь объясните, каким образом злоумышленнику попасть в подсеть WAN интерфейса роутера, чтобы обойти NAT?
Если немного пофилософствовать, то в контексте обсуждения глобальной адресации/маршрутизации первично то, что у внутренних хостов нет реальных IP адресов, поэтому и реализован NAT (это вторично). И безопасность — это следствие самого факта серой адресации в локальной сети, а не NAT. А кто там именно в вашей коробке занимается отбрасываением пакетом — натер, роутер, файрвол или полисер — это уже не имеет отношения к глобальной адресации/маршрутизацииandreymal
Вариант, что интернет-провайдер является или может стать злоумышленником, не рассматривается принципиально?
kbkbkb
Речь про глобальный интернет. Защищает не нат, а адресация и невозможность маршрутизации в глобальном адресном пространстве. Провайдер в данном контексте это локальная сеть и его не рассматриваем.
korzunin
А почему провайдера не рассматриваем? Ростелеком вон уже сегодня не брезгует рекламу в http подставлять, а что им придет в голову завтра?
Да и кулхацкера Васю из соседнего подъезда со счетов сбрасывать наверно не стоит.
Так что все что не под вашим контролем — потенциально враждебно.
netch80
> NAT никак не изолирует внутреннюю сеть от подключения извне.
В общем случае (включая вырожденные виды) — не изолирует. Типичный — изолирует от любых не инициированных изнутри соединений, кроме явно прописанных в конфигурации. (Сразу оговорюсь: см. конец сообщения про тот случай, который выдаётся за фатальную проблему.)
NAT устанавливает ассоциацию внешнего адреса внутреннему. У большинства их множество внутренних адресов больше множества внешних адресов, доступных для назначения NAT'ом — этого уже достаточно, чтобы произвольный входящий пакет не имел внутреннего адресата, если в NAT не назначена ассоциация для этого. Исключением являются те вырожденные NAT, для которых конструктивно установлено такое соответствие 1:1. Я ещё ни разу не видел такого вживую применённого, и сомневаюсь, что увижу.
Symmetric NAT (в терминах STUN RFC), кроме того, не позволяет проникнуть на внутренний адрес запросу ни с какого удалённого адреса, кроме того, для которого этот внешний адрес был назначен. Для Cone типа такое возможно — на время жизни соответствующей ассоциации. Но Cone применяется в основном на домашних раутерах и крайне нетипичен даже для small office сегмента.
Обсуждение по ссылке абсолютно неконструктивно, главный флеймер этого треда откровенно уводит разговор в сторону, а оппоненты оказались не в состоянии возразить по сути.
> От внешних угроз защищает фаервол.
Само правило работы NAT «впускаем только по наличию ассоциации» тут уже является таким элементов файрволла. Если в устройстве нет явных ляпов дизайна, то дополнительный файрволл для этого и не нужен.
Наличие ingress filter при этом я считаю элементом обязательной конструкции. Проблема обсуждения по ссылке — и ваших примеров — в том, что зацикливание на возможности «а давайте отправим напрямую на внутренний адрес через хак» уводит от обсуждения принципиальной ценности NAT для большинства случаев, включая крякеров из Интернета (что на порядки типичнее взлома через соседа по локалке, который может подделать целевой MAC).
be52
в ipv6 можно просто фаирвол использовать, вместо «защитного» ната, запретить подключение снаружи вовнутрь
правда это создает необходимость в механизме похожем на upnp :) а его нету
нет в жизни счастья
extiander
нат все таки не про входящие пакеты, а про входящие сессии, те мы опять же вернемся на уровень сессий
что иногда для всяких там юдп весьма нетривиальная задача без таблиц нат :-)
aram_pakhchanian
UPnP не привязан к IPv4, и должен работать поверх IPv6. Вы, наверное, имели ввиду конкретно NAT Traversal, но если нет NAT, то не нужен Traversal. Нужно только прописать правило firewall c правильным адресом машины, откуда пришел UPnP запрос, я думаю, маршрутизаторы этому быстро научатся, если еще не умеют.
vibornoff
Правильно! Даешь UPnPv6, чтобы все эти полу-умные камеры и дверные замки радостно торчали голой *опой в недобный интернет в обход стандартного правила файрвола.
Tolmy
NAT — не файервол.
NAT — не файервол.
NAT — не файервол.
…
NAT — не файервол.
Нет, NAT не обеспечивает большей безопасности по сравнению с прямым соединением.
dvserg
Допустим файрвол отключён. Как в ipv4 при включённом NAT осуществить сканирование хвостов в локальной сети за ним из вне?
Tolmy
Вы изначально предполагаете добропорядочность внешней сети. Попробуйте представить, что вся сеть за роутером с NAT подконтрольна злоумышленнику. Результаты вас огорчат.
А я, к примеру, не могу себе представить, почему я должен доверять инфраструктуре своего провайдера.
dvserg
Ещё меньше я доверяю владельцам внешних ресурсов и транзитных узлов, которые при ipv6 видят напрямую мое устройство, которое при наличии NAT маскируется внешним роутером.
Хотелось бы все таки узнать, как NAT не защищает (он же не файрвол) и позволяет злоумышленнику отсканировать моё устройство за ним?
Tolmy
Я, находясь во внешней по отношении к вашему роутеру сети, шлю ему пакеты с src своим, dst — перебираю 192.168.0.0/16, 10.0.0.0/8 и 172.16.0.0/12
Ваш роутер совершенно честно передает пакеты внутрь вашей сети, он же не файервол, правда? Внутреннее устройство отвечает на мои запросы и через роутер (он же не файрвол, да?) отправляет их во внешнюю сеть. Всё, мне доступны все ваши внутренние ресурсы. Как я это делаю? Да как угодно. Ломаю комп ваших соседей и маршрутизатор вашего провайдера. Но в большинстве домосетей всё гораздо проще, фомкой открываю ящик с коммутатором у вас подъезде и просто включаюсь к вам в разрыв. Или рву кабель, если он проложен по стенке в коридоре. Да у меня просто уйма разных методик, как это сделать.
sergey-b
Итак, чтобы не взломать, а просто хотя бы найти хост за NAT-ом, нужно что-то одно из:
Это достаточно высокий уровень безопасности. Меня такой вполне устраивает.
Tolmy
Не пугайте страуса, пол бетонный (с)
Ваш этот "достаточно высокий уровень безопасности" имеет неопределенную величину, от нуля до бесконечности(нет, не правда, гораздо меньше).
Но я ничего не собираюсь доказывать. Я как был убежден, что должно быть защищено каждое устройство в сети, даже локальной и уже защищенной, так и буду дальше считать, что оно, это устройство, всегда находится во враждебном окружении. А если каждое устройство в локальной сети защищено файерволом, на котором запрещено всё, что не нужно для правильного функционирования этого устройства, политиками безопасности запрещены и не используются пароли, подверженные брутфорсу, а где возможно, так пароли и вообще не используются, а версии софта не имеют известных уязвимостей, то мне всё равно, есть ли возможность проникнуть ко мне во внутреннюю сеть. Это просто только один из многих заборов.
kbkbkb
Если вы непрерывно следите за всеми обновлениями безопасности и уязвимостями на всех телевизорах/камерах/умных замках и прочей мелочи, то это не значит, что все остальные тоже хотят тратить на это свое время.
zurapa
Хотел бы я посмотреть на твою домашнюю сеть. У меня есть подозрения, что кто-то здесь не до конца честен.
powerman
Всё это так, Вы абсолютно правы. Но это в теории. А на практике большинство домашних пользователей сейчас защищает в основном комбинация их NAT плюс добропорядочность (по крайней мере в данном отношении) их провайдера. При переходе на IPv6 они этой "защиты" лишатся… и самое плохое, что никто их об этом не предупредит, не научит правильно настраивать файрвол "для IPv6", и даже не выдаст роутер с изначально безопасно настроенным файрволом.
stargrave2 Автор
Ну это уже вопрос простейшей образованности. Про брэндмауеры в Windows регулярно все говорят в статьях/лекциях на темы простейшей безопасности при использовании Интернета.
powerman
Простейшей образованности??? Мне кажется, Вы сильно оторвались от реальности. Нет ничего плохого в том, чтобы чем-то сильно увлекаться, писать такие статьи, и агитировать за свою точку зрения в дискуссии, НО — берега терять при этом всё-таки не стоит.
Я считаю, что лично у меня эта "простейшая образованность" имеется: я не сетевой инженер, но я разработчик со стажем в 30+ лет и админю линух немногим меньше (с 1994), когда-то даже сделал собственный дистрибутив и поддерживал его несколько лет, сейчас на Gentoo. У меня дома кучка VLAN-ов, VPN-ов, два ISP — порядка 10-20 сетевых интерфейсов не считая докерных. И достаточно сложные правила iptables, чтобы всё это работало, и работало безопасно. Как по-вашему, тянет это на "простейшую образованность"?
Так вот. Лично я к IPv6 присматриваюсь очень давно. Несколько раз пытался погрузиться в него всерьёз. Но каждый раз это заканчивалось тем, что моя "простейшая образованность" и серьёзное отношение к безопасности домашней сети (и сетей проектов, которые я в той или иной мере админил), приводили к простому выводу: НАФИГ этот IPv6. Причин для этого несколько:
Резюмируя, IPv6 для абсолютного большинства — это сильное ослабление безопасности (относительно текущего уровня для IPv4), и значительное увеличение сложности настройки и поддержки сетевой инфраструктуры (как минимум просто из-за необходимости продолжать поддерживать IPv4, даже если не учитывать сложность самого IPv6).
Лично я в принципе включил в ядре поддержку IPv6 буквально месяц-два назад (выяснилось, что без этого у телеграма не работают звонки), и при этом тут же выключил её через sysctl. Да, я понимаю, что рано или поздно, скорее всего, мне придётся включить и настроить IPv6. Может быть. Поэтому и интересуюсь статьями вроде этой. Но пока что настройка IPv6 не даст мне ничего, кроме проблем, и ни одной причины этим заниматься я пока не вижу.
stargrave2 Автор
Замечание про простейшую образованность касалось только того, что пользователь сам дурак если не помнит и не заботится о правилах firewall-а. Это как винить кого угодно в том, что вылетел из окна автомобиля при столкновении — пристёгиваться надо всегда.
stargrave2 Автор
Снова повторюсь, прочитав полностью ваш комментарий: простейшая образованность касалось только того, что я считаю что человек обязан самостоятельно думать о безопасности своей: ремень безопасности, нескользящие ботинки (а не надежда что асфальт замой будет чист), презервативы, firewall-ы.
Работая с IPv4 и IPv6 я наоборот увидел что с IPv6 значительно проще работать, да и в самом протоколе его link-local-ы и прочие полезности очень упрощают жизнь. Да даже просто банальное огромное количество адресов — очень удобно, не нужно ютиться. Но да, соглашусь что если это в купе с IPv4 делается (dual stack), то это увеличивает повернхность атаки и теперь нужно буквально с двумя стэками работать сетевыми. Но так всегда: переходный период, когда лошади и конные повозки существуют совместно с автомобилями, означает что какое-то время будет сложнее, чем оставаться на лошадях или жить сразу полностью с автомобилями.
powerman
Так и я о том же. Моей образованности как раз хватило, чтобы понять, что IPv6 мне пока лучше всего выключить вообще. Именно потому, что я примерно представляю себе сложность настройки IPv6 чтобы получить эквивалент моим текущим настройкам для IPv4, и понимаю, что в конечном итоге потратив на это недели две всё, что я получу взамен — ухудшение безопасности за счёт увеличения поверхности атаки, и всё. Никаких "плюшек" от IPv6 я не получу, просто потому, что у меня нет потребности открывать доступ снаружи в свою локалку, нет потребности увеличивать связность между текущими сетями, нет даже потребности (пока) подключаться к IPv6-only сайтам.
И, будем откровенны, у большинства обычных пользователей интернета образованность в этой теме сильно отстаёт от моей. И даже если они искренне попытаются настроить себе файрвол для IPv6 (ха-ха-ха! вот прям сейчас они бросят свои дела и займутся этим… они вообще даже слов таких не знают, в основной массе) — вряд ли у них это получится сделать достаточно качественно. Скорее всего этот файрвол в их исполнении будет больше напоминать закрытые ворота посреди чистого поля.
stargrave2 Автор
К вашей образованности у меня претензий нет и я уверен у меня есть чему у вас поучиться. Просто аргумент о том, что пользователям навредят потому что они не включают firewall — не серьёзный аргумент (для меня).
Ну у кого какой опыт и выводы. Ничего не бывает что одинаково бы всем нравилось или бы все соглашались с чем-то. У меня прямо противоположный опыт: я получаю массу экономии времени, удобства, отсутствия раздражения (потому что удобно).
Большинству пользователей я уверен что достаточно иметь firewall разрешающий исходящие соединения, запрещающий входящие (ну плюс ICMPv6 и другие мелочи). Это можно производителям ОС и делать как preset, мне кажется, ибо он удовлетворит 99.(9)% людей, как удовлетворяет NAT без firewall.
powerman
Да, наверняка можно сделать такой preset. Проблема в том, что сначала 20 лет провайдерам было сложно/дорого поменять своё оборудование, а теперь прикиньте, сколько лет займёт поменять домашние роутеры всех пользователей по всему миру — потому что в текущих роутерах таких preset-ов нет (впрочем, тут я могу ошибаться, но скорее всего — нет, либо те, что есть, сделаны чисто формально и не выдерживают никакой критики — просто потому, что производители никогда не заботятся о таких вещах пока их конкретно не прижмут).
stargrave2 Автор
Соглашусь что домашние маршрутизаторы не выдерживают никакой критики в вопросах безопасности. Но я имел в виду firewall на конечных устройствах (компьютер с Windows/GNU/BSD/whatever, iOS+Android).
sergey-b
Если под брандмауэром Windows вы имеете в виду поделие, которое управляется при помощи wf.msc, то я вас уверяю, что оно не работает даже для IPv4. Чтобы просто браузер поставить, нужно включать в нем правило вида Разрешить любой трафик любой программе на любой адрес, иначе ничего не скачается.
dvserg
Вы поняли мои мысли. Я уверен, что приватная (локальная) сеть должна существовать, и должен быть механизм сохранения данной приватности. С другой стороны демоны локальной сети должны в ней и оставаться. Думается с развитием применения ipv6 очень сильно изменится подход к настройке файрволов
Tolmy
Вы вообще уверены в том, что у большинства домашних пользователей этот NAT вообще существует? Многие просто включают кабель от провайдера в свой нотбук и даже не подозревают о вашей надежде, что NAT их защитит.
powerman
Может кто-то так и делает, но у очень многих сейчас дома намного больше одного устройства — помимо ноута есть умные телевизоры, телефоны, планшеты, нередко второй компьютер… так что чаще всего этот кабель воткнут в WiFi роутер (нередко предоставленный и настроенный провайдером).
Tolmy
У меня сын некоторое время работал в саппорте интернет-провайдера, у него совсем другие сведения. Умные телевизоры, планшеты, два компьютера…
Вы очень преувеличиваете средний уровень обычного домашнего пользователя.
Больше двух третей абонентов обычных домосетей — обычные одиночные компы или нотбуки. И да, огромное количество пользователей даже не догадываются о том, что через WiFi роутер можно подключить несколько потребителей интернета к одному кабелю. Из статистики моего сына одним из самых популярных вопросов пользователей является "у меня уже есть ваш кабель, сколько стоит провести ещё один такой? А разветвители для интернета бывают?"
А ещё дешевые тарифные планы у мобильных операторов сделали ненужными подключения по WiFi для смартфонов. А зачем?
И ещё один аргумент. Вы видели, как выглядит радиоэфир на частоте 2.4ГГц в центре микрорайона из пяти 30-этажных жилых домов? И как оно "надежно" после этого работает? Обычный пользователь, поигравшись пару недель в "танчики" по вайфаю и сломав вокруг все ломающиеся предметы, звонит в техподдержку и рассерженно орет "ваш интернет нихрена не работает!", и, получив совет от саппорта попробовать включить кабель в порт компа напрямую, обнаруживает, что интернет таки стабильно работает, после чего исполняется чувства праведного негодования по поводу мошенников, которые ему этот вайфай предлагали.
edo1h
вы сами себе противоречите, откуда же берутся десятки wifi сетей в любой многоэтажке, если NAT'ом (читай домашними роутерами) никто не пользуется? )))
Ankoroid
Провайдеры впаривают роутеры с wifi, настраивают, к примеру, ноутбук — и все.
А на телефоне зачем wifi? Ведь это нужно где-то еще пароль взять, а он записан на бумажке, которая потерялась.
nidalee
Лично я вот понятия не имею, как подключить GPON МГТС без роутера этого самого МГТС. В последний раз, когда читал — вроде, левые устройства они не дают подключать. Но это не точно.
none7
Это совершенно точно. GPON это не стандартизированная технология и если производитель не сказал, что данная конкретная модель ONT совместима с данной конкретной головной станцией. То стоит предполагать, что это не так и она сломает связь всему сегменту. Так же в их ONT прошит индивидуальный ключ авторизации и они его Вам естественно не дадут.
Tolmy
Не противоречу. Просто когда в зоне досягаемости любого устройства 3000 квартир, даже 25% пользующихся вайфаем — это просто офигительно много. А 5 домов стоящих напротив друг друга по кругу так, что можно прочитать название компании на пакете молока, которые стоит на столе в доме напротив, похоже позволяют на переотражении от соседних домах видеть всех. Вот абсолютно всех.
edo1h
ну это вы крайний случай таки рассматриваете.
в обычной отдельностоящей девятиэтажке увидеть 20 сетей — обычное дело. и в пятиэтажке 10 тоже. из чего я делаю вывод, что почти у всех, у кого подключен интернет, есть wifi-роутер (неудивительно, провайдеры сегодня предлагают поставить свой роутер пратически бесплатно)
Tolmy
Очевидно у меня в округе какие-то другие провайдеры. Которые выдают просто шнурок Ethernet в квартиру. А роутер у них стоит… ну в Ашане он ровно столько же стоит. Не могу сказать "дорого", но и покупать его будет только тот, кто точно знает, зачем он ему нужен, и почему ему не нужны для других целей эти $25.
edo1h
Tolmy
Везет. Вот реально завидую. Аренда за 10руб. в месяц. Я бы тоже взял бы не задумываясь. У моего текущего провайдера есть IPv6 прямо из шнурка. С одной сетью /64 и /48 по запросу. Собственно, из-за них я к нему и перешел. Но вот аренды оборудования — вообще никакой.
edo1h
странно, у нас, кажется, все провайдеры предоставляют роутер в аренду.
если смотреть на крупных (покрывающих весь город), то 2 из 3 готовы за дать роутер 10р в месяц.
alliumnsk
Я вот недавно у своего провайдера узнавал. Вроде бы как цена аренды рутера 1 руб/мес. Но на самом дешевом тарифном плане (моем) такой опции нет. Чтобы арендовать рутер, мне пришлось бы перейти на тарифный план с такой же скоростью, но на 100 рублей абонплаты дороже. Т.е. получается что цена аренды составила бы 101 рубль, а не 1
ivlad
Большинство домашних пользователей как получали маршрутизатор от провайдера с управлением через TR-069, так и будут получать.
Tolmy
На практике абсолютно такой же уровень защиты (нет, на самом деле даже больше) дает одно единственное правило в файерволе на роутере — "разрешить соединения только со стороны LAN. И такой пункт есть в распоследних дешевых SOHO роутерах. И да, обычно он по умолчанию включен. NAT — он не для защиты, это просто костыль.
Dimasmir0
Попробую описать текстом. Представьте, что мы с вами в одной провайдерской сети 10.10.10.0/24. Вам провайдер выдал адрес 10.10.10.2, мне 10.10.10.3.
За вашим роутером находится ваша домашняя сеть 192.168.0.0/24.
На своей стороне я прописываю маршрут в сеть 192.168.0.0/24 через 10.10.10.2. Если у вас отключен фаерволл, то я смогу обратиться к хостам внутри вашей домашней сети.
netch80
Итого, случай опасности при «файрволл отключён» сводится к опасности только в особой конфигурации, в которой:
1. WAN стороны жертвы и атакующего находятся в одном broadcast-сегменте формата «типичный Ethernet». Не выполняется в случае хакера из чуть более дальнего интернета.
2. Это именно broadcast-сегмент с прямым бесконтрольным взаимодействием между сторонами. Не выполняется уже, например, на DOCSIS-сетях, где головные станции пропускают трафик через свой доступ и раутинг, и прямое взаимодействие между клиентами сегмента по их MAC невозможно. Кроме того, некоторые свичи позволяют организовать то же на Ethernet. Не выполняется при подключении каждого клиента персональным VLAN'ом.
Ну да, формально можно засчитать один гол за счёт такого эффекта. Но:
1) Практическая ценность его только в весьма частных условиях
2) Простейший ingress filtering на входе его останавливает, и надо быть совсем зелёным админом, чтобы не поставить такое правило.
Более того, формально, поскольку пакеты проходят в обход NAT, проблема тут не в NAT, а в раутере сбоку от него;) а может, его и нет? NAT ведь не означает раутинг вне NAT механизмов. Нет, что-то гол сомнительный :)
А ещё варианты будут?
Jogger
Да, возможностей больше. Но ведь палка о двух концах — в IPv6 гораздо труднее разобраться, особенно человеку, для которого администрирование сетей — не профессиональная деятельность. Даже в IPv4 хватает нетривиальных вещей, а в IPv6 их на порядок больше. Поэтому зачастую и делается выбор в пользу «вот оно работает и более-менее понятно» а не «надо потратить годик на обучение, зато потом я смогу настроить IPv6 и иметь кучу возможностей, из которых я дай бог 1% использую».
ivlad
Когда такое пишут, мне интересно становится, какой именно аспект работы IPv6 делает его «гораздо» более сложным. Вот у вас лично — понимание каких принципов работы IPv6 вызвало сложности?
artemlight
Автор забыл рассказать о том, насколько ипв6 привязан к мультикасту.
Плюшки, безусловно, крутые — но для корректной работы ипв6 придётся менять не только л3, но и всю коммутацию. В противном случае все линк-локал фишки будут работать в широковещательном режиме.
stargrave2 Автор
Не IPv6, а NDP и подобного уровня протоколы. Это отмечено в абзаце про требования, которые можно назвать и недостатками.
PAE
Ещё лет 7 назад помню, как один друг, занятый сетевыми технологиями в академической и, одновременно, провайдерской среде утверждал, что переход на IPv6 — дело решённое и через пять лет все будут относиться к нему как к основному, забыв "старый" IPv4 как страшный сон.
Тем не менее, "воз и ныне там" и всё строится по IPv4, IPv6 же интересует лишь энтузиастов и любителей радикально решить их же проблемы, специфичные для четвёрки. Плюс некоторые технологические компании.
Абсолютное и подавляющее большинство пользуется интернетом для потребления контента или для решения конкретной задачи, когда "удобно" — это браузер, клиент или API, "красиво и эффективно" на сетевом уровне — увы, нет, это попросту невостребовано.
Бизнес прекрасно понимает, что решить "костылями" и NAT — в разы дешевле и быстрее, чем переводить software/hardware на IPv6, поэтому и поныне IPv4 остаётся абсолютно доминирующим, а рост IPv6 трафика в основном чисто техническая заслуга отдельных контент-сервисов.
Рискну высказать непопулярное мнение, но поймите меня корректно:
А что про NAT и абстракции — контейнеризация и бурное развитие SDN — это всё позволяет не обращать внимание на IPv6 вообще, для связности с "внешним миром" достаточно будет и одного адреса.
hjornson
Ага. При этом как раз то что упоминается в статье как достоинство — оно как раз этим самым службам корпораций нафиг и не сдалось. Идеал корпораций — чтобы пользователь фб не знал ничего кроме фб и за пределы его экосистемы носу не казал, а для этого v4 за глаза и зауши достаточно.
ivlad
но почему же тогда эти самые корпорации так пропагандируют IPv6? Почему и у Google, и у Facebook сервисы отвечают по IPv6?
powerman
Скорее всего потому, что трекать юзера надёжно по уникальному IPv6 (а то и по всей /64, чтобы трекать все его девайсы как единое целое), без всяких кук — мечта для таких корпораций.
Tolmy
Как раз RFC4941, который Privacy Extensions for Stateless Address Autoconfiguration in IPv6, позволяет каждому устройству в IPv6 сети выбирать любой адрес из 4 миллиардов и делать это в любой момент по своему разумению. Windows 10, как самая популярная пользовательская ОС, умеет это делать из коробки. И делает это по умолчанию. Так что трекинг по IPv6 — плохая идея. Гораздо хуже, чем трекинг по адресу IPv4.
powerman
Вы в своём ответе проигнорировали эту часть сознательно?
Tolmy
Это же IPv6, здесь нет бродкастов. Вообще нет. Нельзя обратиться к /64 как к единому целому. Нет никаких признаков внутри /64, одно там внутри устройство, или 4 миллиарда. Ну вот есть у меня дома /64 на всех домашних (пять компов, пять телефонов, два телевизора и планшет) Что трекать? Какой смысл в таком трекинге? Мне от 22 до 61 года, с полом я не определилось, иногда мужской, иногда женский, меня интересуют игры, гитары, электроника, красивые шмотки, подводное плавание, IT, кулинарные рецепты и схема разборки двигателя Skoda Octavia. Угу, вот трекинг по /64
powerman
2-3 человека и сейчас могут пользоваться одним компом с одним набором кук. Тем не менее, это не сильно мешает их различать — разные наборы посещаемых сайтов, разные группы интересов, разное время работы, … Но куки можно удалить или вообще заблокировать соответствующими плагинами, а вот свою подсеть /64 скрыть/изменить намного сложнее.
ivlad
Так что сейчас — один внешний IP, что в IPv6 — общий префикс, какая разница. Гуглу сложно отличить телефон от десктопа? Несложно.
И кроме того, зачем тогда они строят IPv6-only датацентры?
none7
Потому, что альтернатива CG-NAT, а значит меньше информации о пользователе. Представьте, что пользователь вошёл в интернет через открытую Wi-Fi точку. Гугл точно узнает где она находится, благодаря гугломобилям. А если она будет за CG-NAT, то он сможет определить в лучшем случае город. К тому же IPv6 продвигают гики, а таковых у IT-компаний полно.
Tolmy
CG-NAT — крайне плохая альтернатива. Достаточно одного спамера в сети, чтобы заблокировали всех, кто за этим NAT-ом сидит. Под спамером я понимаю не только и даже не столько обычного спамера по SMTP протоколу. Просто неимоверное количество сервисов блокирует доступ на уровне IP. И мне совсем не улыбается лишиться доступа к своим любимым фоточкам котиков, потому что в соседнем доме мамкин кулхацер решил развлечься.
ivlad
По-моему, сейчас таких не существует. Везде captive какой-нибудь. Но, даже, положим, андроид до этого подключился к этой точке и гугл знает, что этот внешний IP тогда соответствовал этим координатам. Дальше вариантов два:
Я не спорю, пространство для утечки расширяется, но учитывая масштабы распространения Хрома и Андроида это не очень важно гуглу.
none7
Для чего в IPv6 динамическая выдача адресов? Кто то очень любит таблицы маршрутизации перестраивать? А если провайдер принудительно сбрасывает сессию ради изменения адреса, то бежать от него, срочно!
ivlad
То есть, IPv4 вы всё-таки хотите себе неизменный, но неизменный IPv6 префикс вас пугает?
none7
Динамические IPv4 появились во времена Dial-Up, в те времена не было смысла иметь больше адресов, чем телефонных линий. Тогда возникла и услуга. Потом наследники PPP начали переходить на более быстрые технологии оставив биллинг как есть, то есть выдавая произвольный адрес на сессию. Потом пришёл ростелеком и сказал, что из за вечно включенных роутеров не рвущих сессию вообще не покупают услугу. Давайте рвать сессию каждую ночь, срывая все соединения.
Динамическая адресация ломает правила ipsec, а значит и Mobile IPv6. Будет неприятно если Ваш смартфон автоматически настроивший Mobile IPv6 адрес через домашний Wi-Fi, в полночь потеряет с ним связь. И сломает подключение в совершенно другой сети.
stargrave2 Автор
Вы не правы касательно MIPv6. Точнее это зависит от реализации. В MIPv6 и при проксировании трафика через home agent и при прямой поссылки трафика с corresponding node на mobile agent, добавляется дополнительный IPv6 заголовок, говорящий что это как-бы адресовано home-of-address, а не care-of-address напрямую. При этом, скорее всего, будет использовать транспортный режим (host-to-host же). Корректная IPsec реализация должна учесть дополнительный IPv6 заголовок, превратив его в пакет как-будто с destination-ом равным HoA, а не CoA и поэтому для правил IPsec ничего не будет меняться при перемещении ноды. Так что тут никаких проблем не должно быть.
stargrave2 Автор
Да, собственно, и с туннельным проблем нет, так как на концах туннеля будет HoA адрес, а не CoA.
none7
Речь о том, что адрес и подсеть домашнего роутера периодически меняется. Как отреагируют удалённые хосты при создании нового соединения, если мобильный узел не сможет принять ответ на home-of-address? Мобильный узел ведь даже не в курсе, что его соединение с роутером отвалилось. И не будет в курсе пока не попытается сменить сеть.
stargrave2 Автор
SLAAC-ом (RA пакетом) выдаётся lifetime. Адрес штатно может меняться, как и префикс — всё так. Но постоянно работает NDP NUD чтобы понимать живность маршрутизатора. При смене префикса, для NDP есть особый «мобильный» режим работы, при котором мобильная нода очень часто опрашивает RA о его параметрах, чтобы минимизировать время простоя при смене адреса. Он быстро оповестит corresponding ноду о смене, снова произойдёт binding на новый адрес. Это штатно заложено всё в MIPv6. Повторюсь: в IPv6 работает NDP NUD (neighbour unreachability detection) как-раз чтобы быстро понимать отвалились ли мы и предпринять действия. При смене адреса мобильный агент сразу же оповестит домашнего.
Tolmy
В IPv6 процесс смены адреса по RA несколько отличается от IPv4.
Можно жить некоторое время со старым и новым адресом одновременно, причем старый будет использоваться ровно столько, сколько на нем будут открыты соединения. Новые — будут использовать новый полученный адрес.
edo1h
то есть роутер отслеживает, что старый адрес ещё используется, и только потом удаляет запись в таблице маршрутизации?
Tolmy
Отслеживает, что выдавал этот адрес, и тестирует, что он ещё жив. По NDP NUD. Но на самом деле это уже костыль над SLAAC. Сначала мы делаем stateless протокол, а потом костылями подпираем то, что от него отваливается. IPv6 он такой, да. Хотя, DHCP же вроде тоже есть, так что можно сделать один в один, как в IPv4.
ivlad
ok.
У вас был тезис, что статический префикс в IPv6 улучшает трекинг пользователя. По моему пониманию, это принципиально не отличается от статического IP. Дискуссия о том, кто и почему стал менять адреса клиентов, если честно, мне не интересна и к IPv6, по-моему, не относится.
Tolmy
Уже сейчас есть, к примеру, VPS IPv6 only c привлекательными скидками. Хочешь IPv4 адрес — добавь $5 в месяц к стоимости. Очень даже стимулирует.
aram_pakhchanian
У нас в Армении все крупные провайдеры домашних сетей уже дают IPv6 адреса, включая местную дочку Ростелекома.
Я думаю, причина очень простая: практически не осталось оборудования, которое НЕ поддерживает IPv6, поэтому чем потом массово апгрейдится на него, нарываясь на всевозможные грабли, куда проще поддерживать IPv6 в рабочем состоянии по мере роста и развития сетей.
А переходить на IPv6 придется, так как операторы домашнего интернета видят свое развитие в предложении дополнительных цифровых услуг своим клиентам, чтобы от канала, который все менее рентабелен, перейти к сервисам. А для этого нужен доступ к устройствам, которые клиенты в том числе берут и будут брать в аренду (всякие приставки, роботы, изделия IoT, и т.д.). Все NAT-ы являются большой помехой в этом деле.
Ankoroid
Дешевле как раз без NAT — у сотовых CGNAT требует немалых инвестиций, к примеру.
Если происходит внедрение, как, например, у МТС — то дальше все работает хорошо и стабильно, абоненты даже не знают, что у них ipv6.
В целом сейчас доля ipv6 трафика — 30% (для тех, кто перешел на ipv6).
Странно, почему habr не переедет на ipv6 :)
JayK
А теперь представим что все провайдеры в рф раздали клиентам в6 адреса, и обеспечили прозрачную маршрутизацию. Роскомнадзору вы что делать при этом прикажете? Как быть? Вы модуль «ревизор» видали? Тама столько памяти нет сколько этих адресов)))
ne_kotin
Дак пусть
едят пирожныеестественным образом погибают.JayK
Угу, ипв6 в рф не будет потому что черные ящики сорм в его не умеют, а даже если научатся то для провайдеров поменять их сразу все совершенно неподъемно, учитывая ОЧЕНЬ специфическое ценообразование.
ne_kotin
То есть реестр блокировок по v6 адресам есть, а вот ящики его еще не умеют. Удивительно.
З.Ы. У меня, кстати, в России v6 есть. И он будет, просто до какого-то времени будут закрывать глаза на то, что v6 не заблокировать качественно. Ну не умеет железо. Яровая вон тоже три года хотела трафик хранить. До того как выяснилось, что это требует от мирового производства HDD только на Россию и работать.
edo1h
ящики сорм — это одно, реестр блокировок — другое.
блокировать "плохие" сайты обязан провайдер самостоятельно, от государства только список сайтов и проверки (и штрафы, если плохо блокирует).
P.S. сейчас проверил rutracker.org через ipv6 с "правильным" dns — заблокирован, как и ожидалось
Sugrob
А вы по http или по https пробовали?
В случае DPI необходимо использовать https
Как видно из размера по http приходит заглушка от провайдера.
edo1h
Ankoroid
Умеют, к сожалению :( У Ростелекома даже используют.
JayK
roskomsvoboda.org/41214
Умеют только самые новые и самые дорогие. Которые надо КУПИТЬ ЗА СВОИ ДЕНЬГИ, ростелеком купит, мелкий провайдер из задрищенска…
В 18 году модуль ревизор точно не умел проверять в6 адреса, ну и сама идея вести реестр запрещенных в6 аресов выглядит настолько идиотской, что проще отказаться от в6
none7
Так они же и подсетями банят. Будут по умолчанию добавлять всю /64. В особых случаях, весь PI-блок.
happy-cat
Все это красиво на бумаге — но движение начнется когда домашние провайдеры а-ля МГТС с его gpon (и это в Москве! я про регионы умолчу..) соизволят раздавать ipv6 — а пока поддержки нет то можно все благополучно спустить на тормозах...
Extravert34
МГТС как раз раздаёт. Динамический правда, и только /64, но всё же раздаёт.
https://version6.ru/isp/mgts
happy-cat
Не выдает, я общался с ТП неделю назад, мне сказали что однозначно НЕТ.
PS даже если бы и выдавали — у меня платный статичный IPV4 — и по вашей же ссылке сказано что они вместе не уживаются — так что дважды нет....
nidalee
Пробовал на МГТС с год назад — работало. Аналогично с вашей ситуацией, лишился его, подключив статику. Ну, не велика потеря.
Aqarus
IPv6 хорош и прекрасен ровно до того момента, как тебе надо добавить его поддержку, например, в ембедед девайс и работать с ним на уровне чуть глубже, чем выставление режима static, dhcp или auto в /etc/network/interfaces. Практически любой, кто сталкивался с ним подтвердит это.
happy-cat
О да! я давеча пару недель вволю налюбился поднимая ipv6 на впсе хецнера :)
в конце концов когда все заработало я подумал — а накуя я тратил свое время на никому не нужное? и отключил нафиг все обратно… И поверьте, мир не заметил потери бойца :)
ne_kotin
А расскажите пожалуйста — зачем вы налюбились, когда он там по умолчанию поднят и настроен?
Просто работает. Из коробки.
Дома на роутере (Asus средней цены, гигабитный двухдиапазонник) настроен 6in4 от HE в SLAAC, всем девайсам опять же выдаются глобальные v6-адреса.
Ну, т.е. если в сети есть роутер с v6 аплинком и RADVD — ничего не надо делать, кроме как воткнуть кабель.
happy-cat
Роутер Хуавей от МГТС GPON да, сам генерит и выдает IPV6 внутри — но какой в этом смысл если тот же провайдер НЕ работает (читай никак не выпускает из своих сетей) весь IPV6 траффик…
Касаемо Хецнера — да, интерфейс поднимается, только надо еще
net.ipv6.conf.default.forwarding=1
И таких явных и не явных моментов везде понатыкано. Я то его в итоге запустил и даже nginx настроил (мечтатель блин..) но большого смысла в этом не оказалось, поисковики больше и чаще заходить не стали, зато сканирующих ботов в той черной дыре ооочень много, для интереса гляньте raw логи — будете неприятно удивлены..
ne_kotin
А ваш Хуавей не умеет в 6in4 аплинк до Hurricane Electric, например? Мой — умеет, так и живу. HE выдал мне /64, которую раздает роутер в локалке. Все работает как задумано — есть автоконфигурация адресов, есть подсеть /64, есть глобальная связность.
Зачем? Вы роутите несколько v6 сетей? Потому как эта опция нужна для того, чтобы разрешить форвардинг v6-трафика между интерфейсами. А достукиваться до сервера это не мешает.
Ну, пока скан не вызывает отказ в обслуживании — пофигу, честно говоря, тем более, у меня там не web-сервер, а прокси к телеге. nginx кстати по дефолту настраивается слушать все v4 и v6 адреса.
Tolmy
С чего бы им больше заходить? Для них единица измерения — доменное имя, а не адрес.
Ой ли?
"Пустой" среднемесячный трафик трафик на интерфейсе, доступном из инета по IPv4 100-160kbit/s
по IPv6 — 2-4kbit/s
И вот не надо про "неуловимого Джо" — в условиях гигантского адресного пространства сканирование становится сильно дорогим. Оно не исчезло полностью, особо упоротые сканят и весь IPv6, я видел примеры в логах. Но это реально сильно дороже по затратам. Можно конечно сказать, "вот будет у каждого пользователя по терабиту, будут и IPv6 сканить", но вы представляете себе, что будет в сетях IPv4, если у всех будет терабит?
stargrave2 Автор
Мне хватило парсинга заголовков IPv6 пакетов и его протоколов и IPv4 онных: лично у меня с IPv6 всё проще и кода меньше получалось. Реализация подмножества NDP для address resolution — очень проста и приятна тем, что это всё сетевой уровень, а не канальный как в ARP.
Tolmy
Как раз для embedded IPv6 в работе сильно проще. Памяти может надо чуть больше, но код — меньше.
OleksiyT
Спецам хорошо, домохозяйки ничего не поймут.
Здравствуйте, новые ботнеты.
amarao
Вы меня сильно удивляете.
Вы пишите:
ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.
Конечно, можем в софте. И 10G, и 20G, и даже 40G — вполне возможно. Вот в районе 100+ уже проблемы.
stargrave2 Автор
Работать то будет, и bandwidth выжимать. Я имел в виду очень высокие показатели pps, для которых уже нужно что-то типа en.wikipedia.org/wiki/Data_Plane_Development_Kit использовать. Речь про то, что *из коробки*, даже чтобы иметь дело с 1Mpps, часто приходится что-то подкручивать и настраивать (https://blog.cloudflare.com/how-to-receive-a-million-packets/). Сети современные могут легко нагружать компьютеры, тогда как раньше они были очень медленными.
amarao
У меня 2 Mpps на OVS прекрасно переваривается, на серверах нескольколетней давности. Без dpdk. Вы даёте ссылку на статью 2015 года, а на дворе 2020.
stargrave2 Автор
Я не буду доказывать что DPDK (и подобные решения) не просто так возникли и используются.
amarao
DPDK и множество полуаппаратных акселераторов OVS'а — это вполне важно и нужно. Но оно начинает играть важную роль на цифрах, которые существенно выше, чем 1Mpps.
10-20G современный сервер может обработать в любом варианте. Хоть мелкими пакетами, хоть крупными.
Мой поинт был, что "медленность" современных компьютеров в обработке сетевого трафика — это такое тонкое передёргивание вендоров сетевого железа. Да, никакой сервер не переварит 100Mpps. Но редко какой сервер окажется в ситуации, что ему надо столько переваривать.
extiander
есть задача на 100Gbps
поэтому смотрел что есть и как работает на бытовом железе
в общем где то на 40 (реже 80) все упирается где то во внутренние шины. какие именно PCI/Mem/CPU не проверял, но general servers/OSes работают без мега шаманства до 40ка, дальше все
amarao
100G вы задёшево не протащите. (Это тезис из оригинальной статьи). Даже во времена "медленной сети" (про которую писали) были плезиосинхронные линки невиданных скоростей. Конечного оборудования они не касались.
stargrave2 Автор
Повторюсь: вопрос не в пропускной способности по трафику, а в кол-ве пакетов/сек. 10-20Gb трафика сервер переварит — полностью согласен. Но на 10G можно выжимать 10-14Mpps — а вот это уже сложно. Я это и хотел подчеркнуть в ответе: что существенно высокие pps-ы из коробки сложнее выжать, ибо упрёмся не в железо прежде.
Я согласен что мало кому придётся переваривать много pps-ов. Изначально вся эта тема в статье поднята исключительно от того, что раньше каналы связи были такие медленные, что компьютер нельзя было нагрузить ими, грубо говоря. Количество перерастает в качество — сильно быстрые сети, качественно требуют существенно более простых протоколов, чтобы облегчить жизнь компьютерам, которым уже много много pps так легко не переварить.
amarao
Упс, моя ошибка. Я глянул мои бенчмарки и там светились цифры > 2Мpps. А сколько mpps максимум в 10G пролазит я не пересчитал (и полагал, что 1.4Mpps — это как раз 10G). Это было ошибочное предположение из которого вся моя аргументация и строилась.
Пардон.
edo1h
а на каком железе это было? сейчас с доступностью процов на много десятков ядер ситуация быть может и изменилась
edo1h
если мне нужны изолированные локальные сети, то я могу сделать их пересекающимися и в ipv4, непересекающиеся нужны только для единого адресного пространства.
вот у меня дома два интернет-провайдера, в офисе три. как это будет работать без nat? получать as и поднимать bgp? в офисе ещё можно попробовать, но дома-то?!?
хотя и в офисе проблемы, вполне нормальная ситуация, когда в каком-то филиале падает интернет, на несколько дней ставится 4g-модем и всё работает. что будет в случае использования глобальных префиксов?
P.S. главное, пока полно софта (и оборудования), поддерживающего только ipv4. то есть от внедрения ipv6 никакие проблемы ipv4 никуда не денутся, только добавится ещё возня с ipv6.
stargrave2 Автор
Для общения маршрутизаторов, зачастую, как-раз, и не нужно как таковые внутренние маршрутизируемые сети. Нужно общение link-to-link, не более.
В чём проблема с вашим multi-homing-ом? В чём проблема с BGP? NAT не вариант в принципе: за ним не работает куча протоколов и нет связанности между хостами.
Я давно не встречал софта не поддерживающий IPv6.
edo1h
какие адреса должны быть в локалке?
я же написал уже, повторюсь: о нём нужно договариваться отдельно. далеко не все провайдеры готовы (особенно если речь о каком-нибудь мелком офисе на 3 человека, который платит тысячу в месяц).
"воткнул 4g-модем и всё заработало", "договорился с первым попавшимся провайдером и через пару дней появился проводной интернет" — вообще нереально.
и кто вам поверит, когда у каждого дома стоит wifi-роутер с nat?
+vpn
вот только сегодня смотрел прогу для управления холодильной камерой. никакого ipv6 не увидел.
stargrave2 Автор
Я для начала не пойму что именно вам нужно с вашим multihoming-ом. Если отправлять ответные пакеты на интерфейс с которого пришли (самое распространённое желание) — решается множеством способов, без BGP.
У всех этих людей дома с WiFi-роутером есть Интернет? Я им не верю. Удалённый доступ за NAT-ом вовне — есть. Интернетом я это не могу назвать.
VPN? Вы серьёзно? Начали с IPv6 с сплошными белыми адресами, закончили NAT+VPN как возможное решение?
Ну… прога для управления камерой может и не умеет. Будем считать что отсталость софта для холодильных камер тормозит внедрение IPv6.
edo1h
мне нужно чтобы браузер на компьтере открывал хабр, чтобы контакт на телефоне жены работал и т.д., и т.п.
ещё нужно, чтобы при отказе одного провайдера трафик автоматически переходил на другого. ну и желательно, чтобы на некоторые сети можно было выставить приоритетным какого-то провайдера (связность между местными провайдерами оставляет желать лучшего, маршрут через m9 — далеко не самый плохой вариант).
это мы считаем, что светлое будущее уже наступило и второй провайдер тоже стал предоставлять ipv6
stargrave2 Автор
Всё что вы описали для multihoming делается людьми всякими source based routing policies (например): как-раз это самая распространённая задача когда несколько провайдеров. NAT или BGP она не требует.
Зло это NAT :-). Site-local имеет право на существование (я у себя и дома его использую для транспорта IPsec туннелей), но нужно *очень* хорошо задуматься нужен ли он. Что будет плохого в том, что вы в локальной сети с 1С и прочими будете использовать глобальные адреса? Вы же в любом случае firewall-ом и так будете обеспечивать безопасность и невозможность подключения к ним из вне (или, скорее всего, напишете IPsec security policy говорящий что из вне только с ESP шифрованием). Так какой смысл в site-local? Так как site-local часто будет каким-нибудь fc::/64 (или /7), то есть отнюдь не нулевая вероятность что у кого-нибудь дома такое же используется, а он захочет подключиться туннелем к сети предприятия (удалённая работа). Смысла не использовать имеющиеся глобальные адреса просто нет, как минимум они дают гарантирю что не пересекутся с инфраструктурой кого-нибудь другого.
Если вам нужна невозможность подключения извне — для этого есть firewall.
edo1h
Я вроде несколько раз отвечал на этот вопрос. Чей будет адрес? Провайдера? У меня их в центральном офисе больше одного. Свой? Тогда мне нужно озаботиться as и bgp. Не то, что это было так уж плохо, но мы сейчас приходим к тому, что во всех периферийных точках тоже должны быть резервные каналы (хотя бы в виде 4g-модема). Поднимать по as на каждую точку с несколькими пользователям? (а у меня их несколько сотен)
stargrave2 Автор
Любой из префиксов провайдера. Если вы не хотите извне к ним подключаться, то зачем вам задумываться о BGP/AS и подобном? Просто вместо fc:: используйте один из префиксов любого вашего провайдера, исключительно для того, чтобы знать что эти прописанные в локальной сети префиксы никем не будут более заняты, как это легко произойдёт с fc/7 сетью, используемой cjdns и наверное ещё кем-нибудь.
stargrave2 Автор
Добавлю к своему комментарию: используйте глобальные адреса. Я не говорю что нужно полноценную маршрутизацию делать, и вообще при этом как-то общаться с внешним миром. Провайдер и так, как правило, выдаёт вам сколько-то (много) префиксов — просто используйте один из них вместо fc.
edo1h
а не получится, что завтра я ушёл от этого провайдера — и он те адреса отдал кому-то ещё
stargrave2 Автор
Если ушли, то безусловно легко отдаст. Парировать этот аргумент не могу, признаю. Но неужели вероятность того, что у вас ну вообще нигде не найдётся префиксов которые вы вряд ли будете менять, выше чем вероятность коллизий с fc/ сетью любого произвольного сотрудника или того, что вы не захотите соединить VPN-ом две корпоративные сети и вам fc/ на обоих концах помешает? Если вероятность выше, то да, стоит использовать fc::.
edo1h
да вроде бы получить PI блок несложно.
только вот я не вижу потребности в переходе на ipv6 в корпоративной сети, а dual stack… не, подождём ещё лет пять, а потом ещё раз вернёмся к этому вопроcу.
stargrave2 Автор
Ну многие плюсы IPv6 описаны тут: habr.com/ru/post/490378. Если IPv4 хочется иметь только для хождения по сайтикам из корпоративной сети, то можно использовать (я делал — работает) NAT64+DNS64. IPv4 dual stack хотя бы будет только на маршрутизаторе.
Tolmy
У меня есть работодатель, у которого в корпоративной сети только IPv6. Они решили, что поддерживать такое проще и дешевле, чем городить зоопарк из частных сетей, vpn, nat и целенаправленно к этому шли пару лет. Как там результаты, к примеру, по финансам и трудовым ресурсам — я не знаю, но доступ к внутренней инфраструктуре снаружи сильно упростился. И нет, не стал от этого более небезопасным, IPsec, все дела, всё на месте. Админить такое — чистое удовольствие. И да, поскольку теперь дома IPv6 у меня must have, то я все свои домашние сервисы перевел в IPv6 only. Это реально очень удобно. Понятно, что исчезновением лично меня с моим десятком хоббийных сайтов из IPv4 пространства никто этого не заметил, да и те несчастные, кто попытавшись открыть напрямую ссылку из поиска гугла никуда попасть не могут, но всегда могут "открыть сохраненную страницу", но рано или поздно эта тенденция таки станет массовой.
edo1h
я правильно понимаю, это "сильно упростился" — это ipv6-туннель (большинство же провайдеров не предоставлят нативного ipv6) + ipsec? это правда проще, чем l2tp или openvpn с конфигом в несколько строчек?
stargrave2 Автор
Я гарантирую что это существенно проще и сильно удобнее. На своём опыте это всё познал. OpenVPN… с этим я совершенно не хочу больше иметь дела после удобства IPsec (при наличии IPv6). Как минимум, я в живую вроде даже и не видел OpenVPN с современными алгоритмами шифрования/аутентификации: AES-GCM, ChaCha20/Poly1305 уже давно в IPsec есть. OpenVPN, мягко говоря, архаичен. Если не IPsec, я бы уж в сторону WireGuard посмотрел бы.
a1888877
В OpenVPN есть все алгоритмы из OpenSSL, включая AES-GCM, ChaCha20/Poly1305. А вот с IPSec, наоборот поддержка алгоритмов очень слабая и, что ещё хуже разная на разных устройствах. Того же ChaCha20 нет даже в Windows 10, а к примеру, в 8.1 он никогда и не появится. Поэтому в гетерогенной среде, где разные клиенты, IPSec совсем не так хорош, как хотелось бы.
stargrave2 Автор
Согласен что IPsec современные алгоримы есть не везде. В моём текущем OpenVPN действительно AES-GCM обнаружился, а вот на работе поддерживаются только не-AEAD алгоритмы. В любом случае это не столь критично всегда, но если уж попридираться к производительности, то последний раз когда я работал с OpenVPN, то это был user-space однопоточный демон, в котором я всегда упрусь в одно ядро процессора. IPsec параллелится (как правило). Плюс OpenVPN это переключение в user-space для дешифрования, затем переключение в ядро для дальнейшей маршрутизации пакета. Всё это, само собой, не помеха и не проблема для преобладающего большинства пользователей, но всё же c IPsec эффективностью сложно конкурировать (конечно, зависит от конкретной реализации).
IPsec далёк от идеала, не спорю. Но… при всех своих недостатках, для меня он однозначно лучший выбор чем OpenVPN, который худший выбор, особенно с наличием WireGuard. И я уж лучше SSH-TUN туннель бы поднял, но не OpenVPN. Но эта тема не касается IPv6 :-). OpenVPN можно и поверх IPv6 использовать наверняка.
edo1h
ну это уже религиозное ИМХО
stargrave2 Автор
Ну SSH сервер/клиент на любой *nix машине будет, а на сервере наверняка уже запущен, а OpenVPN из коробки я не помню чтобы шёл в каком дистрибутиве. Тупо удобнее.
Tolmy
OpenVPN давно умеет из коробки и ходить по IPv6 транспорту, и пускать IPv6 в туннеле.
stargrave2 Автор
Самое то главное: IPsec это не про VPN. Им можно туннелировать пакеты (целые сети), но в нём есть транспортный режим и стандартный setsockopt вызов позволяет буквально per-socket шифровать (TCP/UDP/whatever) IP пакеты. Сейчас IPsec в головах людей это VPN, потому что в IPv4 мире транспортный режим, грубо говоря, не получится использовать, ибо нет host-to-host связанности. IPsec это штука которая в транспортном режиме может полностью заменить то, что сейчас делает TLS. Но это тоже придирка: IPsec это всё же существенно сильно шире чем просто VPN.
Tolmy
Я помахал ручкой одному провайдеру, который сказал "IPv6 нет и не предвидится" и подключился к другому, у которого /64 из коробки и можно бесплатно просто по письму получить ещё /56
И обхожусь без ipv6-туннелей. (Хотя вот прямо сейчас я не дома и тут у меня да, ipv6 туннель)
И да, это проще и понятнее, чем l2tp. Потому что разделено на две назависимые сущности — туннель и шифрование.
stargrave2 Автор
Ещё можно было бы сделать NAT64+DNS64 и тогда IPv4 сайты смотреть IPv6-only пользователям, без IPv4 сети внутри корпоративной сети. Но… это уже безусловно усложнение администрирования и вновь притягивание IPv4 мира, но как временная мера оно вполне работоспособно.
edo1h
в ipv4 не так?
stargrave2 Автор
Попробуйте. Нет, не так.
edo1h
попробовал
stargrave2 Автор
Ну я вот в трёх совершенно разных сетях (где есть IPv4) проверил, firewall точно не мешает, но 0 packets received, 100.0% packet loss. Так что нет, не работает это из коробки вот нигде. Это в сетях и с Windows и GNU/Linux и FreeBSD и с умными и тупыми коммутаторами.
edo1h
в линуксе это
да, сейчас везде по умолчанию выключено. честно говоря, не знаю по каким причинам, но странно считать преимуществом ipv6 то, что пока в нём это не отключают.
stargrave2 Автор
Странно это отключать в IPv6 мире, где всё-равно NDP активно использует multicast и в принципе он активно участвует в жизни хостов, в отличии от IPv4.
С вашим подходом можно всё что угодно обозвать странным преимуществом, ведь всё-равно сломается/заблочится/отключится/не нужно/итд.
powerman
А в чём смысл выдавать каждому пользователю /64? Нет, я допускаю, что это может заметно разгрузить таблицы маршрутизации на роутерах, но если не фокусироваться на ограниченных возможностях роутеров — зачем это нужно? По сути ведь это просто бессмысленное уничтожение громадного количества адресов — ведь у абсолютного большинства пользователей, даже после выдачи IP каждой лампочке в доме и каждому контейнеру докера, будет реально использоваться несколько сотен адресов максимум. Хотите выдать с диким запасом, чтобы хватило навсегда — ну выдайте /112, это 64K адресов каждому. А при выдаче всем /64 мы, по сути, минимум 48 бит адресного пространства выкидываем в мусор… что возвращает нас к изначальному вопросу: для чего это нужно?
stargrave2 Автор
/64 сети используются как минимум для работы SLAAC-а, где из MAC-адреса получается автоматически адрес хоста, подставляющийся в данный префикс. Плюс ещё ряд протоколов ожидает префиксы не меньшего размера.
На самом деле у меня такой же вопрос: разве это не слишком ли расточительно. Ну коммитеты посчитали что вроде нет, должно хватить даже так, даже выдавая /56 или /48 конечным пользователям. Но, на данный момент все адреса выдаются только из 2000::/3 — используется 1/8 всего возможного пространства. Если же умные коммитеты обосрались с рассчётами и прикидыванием, то у нас есть ещё 7 попыток, где могут быть в корне совершенно другие политики выдачи.
powerman
Отличная новость! Т.е. люди, которые потенциально таки совершили эту ошибку, из 128 бит умудрились оставить нам всего 7 попыток сделать правильно?
stargrave2 Автор
Ну речь же про то, что это десятилетия должны пройти чтобы понять что обосрались. Но вообще даже отдалённо пока нет никаких опасений что адресов может не хватить.
Я бы не стал считать что эти люди потенциально совершили ошибку. Точнее так: потенциально абсолютно все совершают ошибки изобретая любой протокол, правила, алгоритмы и прочее. Но эти хотя бы задумываются о запасном плане, чтобы не пришлось, как с IPv4, полностью менять все маршрутизаторы и софт.
stargrave2 Автор
Если выдавать по /112, то уже нельзя будет создавать автоматически длинные большие адреса, где вероятность коллизии будет мала. А эта возможность — очень удобна.
Потери при выдаче /64 будут не /48 бит, а все 60-62, ведь у многих буквально несколько устройств всего-лишь подключено. Но не стоит забывать что и подходы работы в IPv6 сетях надо менять и не ютиться на одном IP-адресе. Лично я вот не редко выношу некоторые службы на отдельные IP, чтобы персонально к этим IP применять IPsec политики. Это просто удобно. Возможно массово это никто и не будет использовать, а возможно нам и этого будет не хватать — никто не знает что будет в будущем.
Tolmy
/64 хосту позволяет использовать RFC 4941 — Privacy Extensions for Stateless Address
И все скрипты, которые обходят весь интернет для поиска открытых ssh портов превращаются в тыкву, потому что теперь каждый хост в IPv6 — это как весь интернет в IPv4(нет, в реальности гораздо больше)
powerman
Честно говоря, я ждал этого аргумента. Риторический вопрос: не кажется ли Вам, что прятать порт ssh таким образом — это дикий overkill? Я уже молчу о том, что многие в IPv6 всё-равно поставят адреса вроде …::1 чтобы ленивее было набирать/запоминать/различать, что можно перевесить ssh на нестандартный порт, и, главное, что если защита периметра строится на том, что порт ssh не найдут, то у меня для Вас плохие новости…
stargrave2 Автор
Думаю что почти наверняка всё что предполагает соединение извне или прописывает себя в DNS или, как вы верно про ::1 заметили, конфигурируется руками статично. Лично я аргументом тоже не могу считать безопасностью невозможность перебора адресов.
Tolmy
Речь про другое. Речь скорее про компы обыкновенных пользователей, у которых проблемы с безопасностью из-за их безалаберности. Не нравится вам 22-й порт, окей, пусть это будет 3389. Суть от этого не меняется. в IPv4 сети сканером одного порта полностью обходится весь интернет за несколько часов. В IPv6 на это уйдут месяцы, даже если сканить только уже распределенные сети, не трогая зарезервированные и неиспользуемые. Это в общем случае не безопасность "меня никогда не найдут", а значительное увеличение стоимости атаки. Поэтому отпадет огромное количество мамкиных кулхацкеров, поскольку вероятность получить результат за приемлемое время сильно падает. А ещё это не такой стремительный рост ботнетов, это тоже пассивная безопасность, потому что ботнеты на сотни тысяч пораженных устройств позволяют легко делать то, что меньшим количеством просто не делается.
powerman
Есть способы сильно эти "месяцы" сократить, не без своих ограничений, но, тем не менее. И увеличение стоимости атаки получается уже не столь значительным, как нам бы хотелось. Вот, быстро погуглил, и сразу попался список подходов (скорее всего далеко не окончательный):
Tolmy
Ни один из методов не работает на обычной Windows 10, получившей IPv6 адрес по SLAAC. В которой пользователь даже не знает, что надо что-то там настраивать. Купил в магазине нотбук и пользуется. Напоминаю, если что, это и есть порядка 95% всех хостов в интернете. А сервера, что сервера, у серверов должны быть админы. Так что мой тезис скорее подтверждается, чем был опровергнут.
a1888877
В статье повторяется мантра про «продуманный», «эффективный», «удобный» — только это не про IPv6. Он уже четверть века как не может заменить IPv4, потому что является крайне не удачным протоколом на фоне предшественника.
Метания с DHCP (а сделаем два протокола — RA и DHCPv6), NAT (абсолютное зло, а добавим IPv6-to-IPv6 NPT), диапазонами (fec0:/fc00:: или ::ipv4/::ffff:ipv4), EUI из MAC/рандомно, меняющаяся длина префикс (6 vs 8) прекрасно демонстрируют компетенции авторов IPv6.
— Удаленный доступ: NAT + маршрутизация провайдера надежно закрывает абонентские терминалы, на которых некоторые пользователи так любят отключать межсетевые экраны. IPv6 автоматом несет коллапс ИБ.
— NAT иногда нужен вовсе не для экономии адресов, а для эмуляции окружения сегментов сетей. И заменить его нечем. И, да, читаем про IPv6-to-IPv6 NPT.
— IPSec/ESP вполне себе работает и в IPv4/NAT. Но, всё же OpenVPN, Wireguard, SSH/TLS проще и в настройке и как протоколы (а значит и потенциально менее уязвимы).
— «минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.
— Идея использовать глобальный префикс прекрасна, если помнить, что провайдер, которому этот префикс принадлежит может и поменяться. Вместе с префиксом.
— Я честно не смог найти мнемонику между 2a02:6b8::2:242 и ya.ru — и назвать четыре числа простому пользователю, не смыслящему в этих ваших сетях и английском, сильно проще чем многосимвольную щестнадцатиричную «штуку».
— Насчет иерархии IPv6 адресов. Старые сетевые инженеры помнят, зачем в древних cisco нужно включать бесклассовую маршрутизацию и почему в 80-х от неё отказались. Думаю, со временем откажемся и здесь.
— link-local были прекрасно сделаны в Windows и без IPv6, показывая, что переделывать сетевые протоколы ради автоматически настраивающихся сетей не требуется.
— well-known multicast адреса в IPv4 назвались широковещательным пингом — и его похоронили ради безопастности. Удивительно, что теперь это преподносится как преимущество.
— Магия SLAAC уходит, когда мы вспоминаем про обычные роутеры с 192.168.1.1/24 и DHCP — ведь для простого пользователя ничего не меняется.
— Магия anycast уходит, когда выясняется, что в отличии от существующего сейчас Anycast, здесь эти адреса нельзя использовать в качестве адресов отправителей.
— В IPv6 вообще то НЕ фиксированные заголовки из-за extension headers. И агитация IPv6, в которой их якобы отсутствие преподносится преимуществом хороший пример переусложненности протокола.
— Flow Label сложно сказать насколько жизнеспособно, пакеты не фрагментируются до нечитаемости заголовков TCP/UDP/SCTP и я не уверен, что он когда-либо будет применен в живых системах из-за потенциальных проблем с безопасностью при балансировке нагрузки.
— Multicast NDP работает в Ethernet сетях так же как и ARP/DHCP. Вот если у вас X.25, тогда да, нагрузка на сеть будет меньше (RFC 4861).
— NDP NUD в общем-то действительно плюс. Одна из базовых причин продвижения Google своего QUIC вместо связки IP/TCP/TLS.
Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства. Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско. А потом в целях безопасности, что бы не светить MAC, заменим это случайным числом — действительно, в заголовке каждого пакета, два 8 байтных случайных числа, вместо полезных данных. Действительно IPv6 — «эффективный» и «продуманный» протокол.
Ну и главный минус IPv6 — это заведомо заложенная несовместимость с IPv4, какие-то работоспособные варианты Dual Stack стали появляться лет через 10-15, после выхода протокола — и это очень сильно тормозило его внедрение. Удивительно, как имея IPv4 — далеко не идеальный и не беспроблемный протокол, десять лет его эксплуатации в живых сетях и решения проявившихся проблем можно было создать IPv6.
aram_pakhchanian
У меня есть простой принцип: если человек пишет полный негатив, то его позицию вряд ли можно считать объективной. Впрочем, и позиция автора статьи тоже далека от объективности.
У меня дома /56. Пожаловаться на провайдера?
В чем фиаско-то? Ну дублирует.
a1888877
Справедливости ради, NDP NUD я похвалил. Остальное по пунктам соответствует тезисам автора статьи.
Насчет /64 я ошибся — комментарий слишком длинный вышел, а аспектов связанных с IPv6 много. Имелось в виду сужающееся пространство — изначально, конечным пользователям планировали давать /48. Потом начали сокращать — у вас /56, у кого-то до /64. Меньше в текущих реалях уже нельзя.
Насчет дублирования — эти байты лишние. Если их убрать из заголовка, то на работоспособности протокола это не скажется. Но из-за них длина адреса сокращается вдвое и каждый пакет (от 300 до 1500 байт) содержит лишние 16 байт — меньше пропускная способность сетей, больше энергопотребление и т.д…
aram_pakhchanian
Как я понимаю, разработчики ipv6 учли тот факт, что предсказать будущее трудно, поэтому чрезмерная оптимизация (ну не нужно же!) завтра может стать болью. Вот вы считаете, что не нужны эти биты, а кто-то в комитете сказал, что он считает, что нужны, и привел конкретный кейз, и у остальных, наверное, не нашлось доводов убедить, что этот кейз нерелевантен. Именно потому, что все, кто чрезмерно уверены, чаще ошибаются.
a1888877
IPv6 это сетевой протокол — его нельзя просто так взять и заменить на оптимизированный, когда/если проект «взлетит». Он должен быть оптимален изначально. Да и для решения «боли» там есть extended headers в которые можно положить всё забытое при стандартизации. Хотелось бы конечно верить, что авторы IPv6 разбирались в сетях и были гениальны настолько, что остались не поняты. Однако, критерий истины — время. То как RFC сменяли друг друга и менялся конгломерат протоколов IPv6 указывает на многочисленные ошибки его авторов. И то, как IPv6 25 лет пытается заменить IPv4 тоже свидетельствует о некоторых проблемах, потому как IPv4 пусть и не мгновенно, но несколько десятков аналогов и конкурентов вынес. Я тот же IPX через wiki кое-как нашел, а он лишь один из многих, ныне забытых.
aram_pakhchanian
IPX был куда лучше для локальных сетей, чем TCP/IP, но совершенно не работал в глобальном пространстве. Помню, как мы долго плевались, когда переходили с IPX на TCP/IP в офисе в начале 90-х, и переходили только потому, что нужно было с компов выходить в интернет. IPX не проиграл, он просто автоматом вышел из игры, но стал популярен с нуля и выигрывал у tcp/ip почти 15 лет при том, что tcp/ip существовал с начала 80-х как официальный стандарт. Ровно так же автоматом уйдёт ipv4, потому что в мире IOT он не релевантен.
powerman
С миром IoT всё сложно, на самом-то деле. Он ещё не наступил, и пока неясно, наступит ли. У него уже проявилось две большие проблемы, у которых пока что решения нет: во-первых китайские умные лампочки и прочие вибраторы/радионяни с "закладками" стучащие домой (а потом с серверов компании всё это утекает в паблик), и во-вторых "окирпичивание" умных устройств если что-то случается с серверами компании-производителя.
Первая проблема больше волнует незначительный процент населения обеспокоенного приватностью и безопасностью, и их беспокойство вполне могут проигнорировать "во имя великого IoT" (хотя тут я уже не уверен — пока это касалось лампочек всё так и было, но вот случившиеся утечки через вибраторы и радионяни подняли намного бо?льший шум). Но вот вторая касается всех и каждого — никто не хочет платить кучу денег за более дорогое "умное" устройство, срок жизни и работоспособность которого (напр. после автоматического некорректного обновления) никто не может гарантировать.
Эти проблемы, конечно, решаемые. Но это решение сильно удорожит продукт, и вполне может сделать большую часть IoT нерентабельным.
aram_pakhchanian
Я разговаривал с операторами — они видят в обеих проблемах возможности. Они могут взять на себя и вопросы безопасности и вопросы обслуживания устройств, плюс локализация в широком смысле этого слова. Собственно, многие уже выстраивают соответствующую инфраструктуру.
Ankoroid
Проблемы с IoT для корпоратов будут решены 5G слайсами и стыками MPLS.
Никакие «лампочки» никуда попадать не будут и до них будет не достучаться.
Ну а физики должны страдать, они же хотят все нахаляву :)
stargrave2 Автор
>Он уже четверть века как не может заменить IPv4, потому что является крайне не удачным протоколом на фоне предшественника
Он не может заменить из-за инертности мышления людей, и банально из-за того, что Интернет, как таковой, мало кому нужен. Деньги приносят конечные пользователи. А им нужен удалённый доступ к ряду сервисов.
>— Удаленный доступ: NAT + маршрутизация провайдера надежно закрывает абонентские терминалы, на которых некоторые пользователи так любят отключать межсетевые экраны. IPv6 автоматом несет коллапс ИБ.
Отсутствие Интернета (возможность общения хостов между собоу) означает повышенную безопасность. Да, я это от многих уже слышал и считаю маразмом. Отключите кабель — будет ещё безопаснее. Потому что пользователи и без firewall-а умудрятся что-нибудь сделать небезопасное.
>— NAT иногда нужен вовсе не для экономии адресов, а для эмуляции окружения сегментов сетей. И заменить его нечем. И, да, читаем про IPv6-to-IPv6 NPT.
Не нужно смешивать людей придумывавших IPv6/NDP/etc с всегда-найдётся-человеками которые придумают нечто странное. В RFC много всякого странного и ненужного.
>— IPSec/ESP вполне себе работает и в IPv4/NAT.
С костылями в виде NATT. А если оба за NAT-ом, то тут как всегда…
>Но, всё же OpenVPN, Wireguard, SSH/TLS проще и в настройке и как протоколы (а значит и потенциально менее уязвимы).
Зависит от IKE демонов. Настройка strongSwan — одно удовольствие и возвращаться к OpenVPN никогда. TLS — только версия 1.3 выглядит достойно с криптографической точки зрения. Среди всех вышеназванных протоколов (кроме ультрасовременного WireGuard) — только IPsec за свою историю не имел криптографических проблем. Даже первые версии ESP и IKE имеют отличный уровень безопасности.
>— «минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.
Это явно не соответствует правде. Нигде не встречал чтобы выдавали меньше.
>— Идея использовать глобальный префикс прекрасна, если помнить, что провайдер, которому этот префикс принадлежит может и поменяться. Вместе с префиксом.
Да, и все NDP/MIPv6 и прочие заточены под то, что всё может меняться. В SLAAC-е даже lifetime-ы есть из серии часов для префикса/адреса.
>— Я честно не смог найти мнемонику между 2a02:6b8::2:242 и ya.ru — и назвать четыре числа простому пользователю, не смыслящему в этих ваших сетях и английском, сильно проще чем многосимвольную щестнадцатиричную «штуку».
Тут мнемоники нет. Это просто короткий и запоминающийся адрес. Нет, безусловно с «8.8.8.8»/«8.8.4.4» ничто не может соревноваться, но на практике адреса всё-равно достаточно короткие и легко запоминающиеся.
>— Насчет иерархии IPv6 адресов. Старые сетевые инженеры помнят, зачем в древних cisco нужно включать бесклассовую маршрутизацию и почему в 80-х от неё отказались. Думаю, со временем откажемся и здесь.
Помнят, потому что классовая адресация крайне нерационально использовала пространство адресов и чтобы моментально не произошёл коллапс от нехватки всего IPv4 пространства — придумали CIDR. Только причём тут иерархия и классовость/безклассовость? В IPv4 мире нарезали на маленькие кусочки и маршрутизировали хаотично, потому что кому как и где уж выдали.
>— link-local были прекрасно сделаны в Windows и без IPv6, показывая, что переделывать сетевые протоколы ради автоматически настраивающихся сетей не требуется.
Про Windows не знаю. Но вот вне Windows как-то не прижилось.
>— well-known multicast адреса в IPv4 назвались широковещательным пингом — и его похоронили ради безопастности. Удивительно, что теперь это преподносится как преимущество.
Удивительно, но в IPv4 мире любят даже ICMP полностью блокировать, уничтожая возможность делать PMTUD, считая что у кого не native-1500-bytes-MTU — нищеброд и сам виноват.
>— Магия SLAAC уходит, когда мы вспоминаем про обычные роутеры с 192.168.1.1/24 и DHCP — ведь для простого пользователя ничего не меняется.
Не понял причём тут какой-то 192.168.1.1, SLAAC и DHCP.
>— Магия anycast уходит, когда выясняется, что в отличии от существующего сейчас Anycast, здесь эти адреса нельзя использовать в качестве адресов отправителей.
Это явно не соответствует действительности. Я даже не знаю откуда такое вы взяли или увидели.
>— В IPv6 вообще то НЕ фиксированные заголовки из-за extension headers. И агитация IPv6, в которой их якобы отсутствие преподносится преимуществом хороший пример переусложненности протокола.
Решения о маршрутизации принимаются на основе фиксированного заголовка. Почти все расширенные маршрутизатор в общем-то может игнорировать. Полная картина — не фиксирована. Для маршрутизаторов — фиксирована.
>— Flow Label сложно сказать насколько жизнеспособно, пакеты не фрагментируются до нечитаемости заголовков TCP/UDP/SCTP и я не уверен, что он когда-либо будет применен в живых системах из-за потенциальных проблем с безопасностью при балансировке нагрузки.
Действительно flow label на практике ещё не понятно насколько полезен. Но вредит он максимум только наличием 20 лишних бит — попытка не пытка.
>— Multicast NDP работает в Ethernet сетях так же как и ARP/DHCP. Вот если у вас X.25, тогда да, нагрузка на сеть будет меньше (RFC 4861).
Не всегда так, но да, он может превратиться в broadcast.
>Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства.
На самом деле они 128 битные, посколько никто вас не обязывает использовать только этот один автоматический EUI64 адрес. Вы можете сгенерировать ещё 1<<64-XXX адресов. То что современные приложения учаться «ужиматься» на куче портов на одном единственном IP адресе — да, факт. IPv6 это другой мир, где для *более* эффективной работы стоит применять другие подходы. В самом адресе уже можно зашивать «порты», экономя на более простых транспортных заголовках, например.
>Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско.
Ну не половина, а 48-бит. И IP не предполагает использование исключительно поверх Ethernet/WiFi сетей. Канальный уровень может быть любым. И в идеале он должен быть point-to-point без ненужного (для IPv6 мира) overhead-а от адресов канального уровня.
>А потом в целях безопасности, что бы не светить MAC, заменим это случайным числом — действительно, в заголовке каждого пакета, два 8 байтных случайных числа, вместо полезных данных. Действительно IPv6 — «эффективный» и «продуманный» протокол.
Проблемы и мысли людей делающих подобное не стоит мешать с теми, кто продумывал IPv6 протокол. Если я ногами кручу руль автомобиля, демонстрируя неудобные сидения для такого действа, то вряд ли стоит винить создателей автомобиля что они это не продумали. Вы уже второй раз странные и не лучшие идеи прикрепляете к создателям IPv6.
>Ну и главный минус IPv6 — это заведомо заложенная несовместимость с IPv4
Не всегда стоит нести совместимость с чем-то предыдущим. О лошадях и конных повозках, благо, сейчас не задумываются при проектировании автомагистралей.
edo1h
И сразу же
Спасибо за отличный пример двойных стандартов
powerman
Это не так — за это же время сменились целые эпохи в других областях, и инерция мышления этому не помешала.
А вот это правда — и она блокирует большую часть аргументов из статьи, просто потому, что большинство этих аргументов актуальны только для сетевых инженеров.
Всё так. Любой файрвол по своей сути эту связность ломает, это его работа — блокировать небезопасные связи. А Интернет большинству не нужен, как мы уже выяснили. (А кому нужен — мне, например — тот давно получил у провайдера белый IP.)
Вот, кстати, хороший вопрос: а как без этого "странного" в IPv6 предполагается обходить блокировки и вообще маскировать свой адрес от слежки? Ну, то самое, для чего сегодня поднимается VPN, на котором NAT?
Но зачем же исключать WireGuard? Он как раз хорошо показывает, как на самом деле просто всё это должно настраиваться, и настройку strongSwan на его фоне воспринимать удовольствием… ну, немного отдаёт мазохизмом. От большой любви к IPv6, конечно же, можно на это закрыть глаза, но если смотреть объективно…
А это уже отдаёт Стокгольмским синдромом. На всякий случай уточню: нет, этот адрес не короткий, и нет, не легко запоминающийся.
Ничего удивительного, просто он создавал проблемы с безопасностью когда-то, а потом все тупо копировали уже не очень актуальные правила файрвола со stackoverflow. В этом смысле ICMPv6 скорее всего будет ещё более проблемным, потому что он более сложный и нагруженный функционалом, так что с безопасностью у него может быть заметно хуже. Собственно, быстрый поиск это элементарно доказывает: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=icmpv6
stargrave2 Автор
>Это не так — за это же время сменились целые эпохи в других областях, и инерция мышления этому не помешала.
Это так, так как видно что помешала. Это не единственная причина. Стоимость оборудования (особенно в 90-х и 2000-х, когда оно не держало IPv6), ненужность провайдерам и конечным пользователям, и т.д…
>А кому нужен — мне, например — тот давно получил у провайдера белый IP.
Как и я всю жизнь был за статическим IP. Но таких то людей крайне мало.
>в IPv6 предполагается обходить блокировки и вообще маскировать свой адрес от слежки? Ну, то самое, для чего сегодня поднимается VPN, на котором NAT?
VPN-ы которые я поднимал и которыми пользовался — были без NAT. Вопрос блокировок, анонимизации и прочего, мягко говоря, выходит за рамки эффективной сети передачи данных (IP). Можете посмотреть моё выступления на тему анонимизации :-): www.youtube.com/watch?v=FJ68Kha78Lo
Анонимизация и эффективность работы — даже не вспомню чтобы были не на разных чашах весов.
>Но зачем же исключать WireGuard? Он как раз хорошо показывает, как на самом деле просто всё это должно настраиваться, и настройку strongSwan на его фоне воспринимать удовольствием… ну, немного отдаёт мазохизмом. От большой любви к IPv6, конечно же, можно на это закрыть глаза, но если смотреть объективно…
1) Исключаю потому что он появился *совсем* недавно. Грубо говоря, год назад мы бы о нём не заикнулись. А так да: он хорош. 2) IPsec это не VPN. IPsec может использоваться для VPN, но он может даже для обеспечения безопасности per-socket использоваться. WireGuard это только VPN.
>2a02:6b8::2:242 … На всякий случай уточню: нет, этот адрес не короткий, и нет, не легко запоминающийся.
На всякий случай напомню, что он достаточно короткий для запоминания, в отличии от мифа о том, что все адреса всегда длинные (128 бит!) типа 2a03:5a00:17:123:50c2:1bff:fea8:dd3.
>В этом смысле ICMPv6 скорее всего будет ещё более проблемным
Любая новая и более сложная технология (решающая больше задач) (и софт) потенциально такой будет, очевидно. Автомобили тоже требовали десятилетий опыта, отладки, и высокой квалификации для обслуживания и создания, в отличии от лошадей которых только приручить и впрячь в повозки. Это всё очевидно. Хочется железобетонной надёжности, то можно использовать (MS-)DOS.
powerman
Автомобили, в отличие от лошадей, давали явные преимущества всем и каждому. А IPv6, как Вы сами верно заметили в начале комментария, это "ненужность провайдерам и конечным пользователям". Стоимость оборудования за это время изменилась, а вот насчёт ненужности — всё по-прежнему актуально, даже не смотря на то, что IPv4 совсем-совсем кончились.
stargrave2 Автор
Вы перевираете. Я говорил про ненужность Интернета как такового для пользователей (и обеспечения Интернетом провайдерам этих пользователей, следовательно). А для Интернета очевидно что жизни без IPv6 нет. Сейчас оборудование уже и заменилось за столько лет и уже давно поддерживает IPv6. Именно поэтому мы видим, не смотря на мою убеждённость что людям Интернет не нужен, что больше половины трафика в США идёт по IPv6, что больше половины людей там, в Великобритании и в Германии у крупных операторов, имеют IPv6.
powerman
Они все имеют IPv6 просто потому, что ISP им его выдаёт по умолчанию, их OS его поддерживает по умолчанию, и трафик возникает потому, что ютуб им по умолчанию выдаёт AAAA запись.
Сами пользователи в Интернете и IPv6 по-прежнему не нуждаются, ничего про него не знают, и не подозревают о том, что вся эта выдача им IPv6 "по умолчанию" ослабляет их безопасность.
Я к тому, что объёмы трафика тут не показатель. Показателем свершившегося внедрения IPv6 станет исключительно точка, в которой у обычных пользователей не получится по IPv4 заходить на часть нужных им и достаточно популярных сайтов. А такого может ещё лет 20 не случиться.
stargrave2 Автор
Лично у меня полно личных ресурсов/серверов где только по IPv6 можно попасть. Да и блоги людей я знаю которые доступны только по IPv6. Сейчас сложнее найти ресурсы которые бы *не* были доступны по IPv6 (к сожалению, удивительно, но до сих пор остаются ещё такие, тот же Хабр :-)).
edo1h
взял alexa top 50, скормил dig -t aaaa, оказалось 12 сайтов из списка имеют ipv6 адреса
stargrave2 Автор
YouTube, всё что у Google, Facebook, VK, Yandex, Instagram — всё на IPv6 (многое уже как лет 10).
none7
VK IPv6 не осилил и давно уже AAAA записей не отдаёт. Основные скрипты работали как положено, а выдача статики и скрипты на сторонних сайтах падали.
andreymal
ВК когда-то имел IPv6, но через некоторое время его отключили. По заверениям поддержки, из-за спамеров. (В чём связь между спамерами и IPv6, объяснять отказались)
stargrave2 Автор
Ого, ничего себе! А я ведь застал время когда ВК был полностью IPv6. Про такое слышу впервые, что от IPv6 избавляются :-)
a1888877
Я обрезал цитаты, что бы сократить текст:
Ближайший аналог — 2G/3G/4G. Инертность мышления не мешала переходу.
Вообще да, с отключенным кабелем действительно будет ещё безопаснее. Отсутствие полной симметричной связанности мешает лично вам, но для большинства потребителей интернета — эта плюс.
NAT нужен. И для IPv6 тоже. Не что бы у пользователей отбирать белые адреса и давать серые, а для управления сетями, отладки, эмуляции сетевого окружения и т.д. Благодаря NAT, можно полностью переделать сегмент сети, с заменой сервисов в ней, протестировать всё это, в том числе на части живых пользователей и выкатить в прод незаметно для пользователей одной командой в консоли маршрутизатора. И в таких задачах у NAT замены нет.
Да, как всегда, когда жадность потребителей мешает оплатить белый адрес. А производителей железа внедрить протокол без дефицита адресов.
Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.
Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.
Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6. И возможности сокращения, демонстрируемые в статья плохо релевантны адресациям в реальных сетях — я на свой ближайшей сервер зашел, там префикс 2a03:b0c0:3:d0::27b:e009, это ну никак не «достаточно короткие и легко запоминающиеся».
В IPv6 я вижу повтор этой истории.
Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.
Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.
Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.
RFC3513. Но ОК, новый RFC4291 это ограничение снял.
Сейчас, в IPv4 это работает так же.
Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.
Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.
Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.
Это то, во что IPv6 эволюционировал. Текущее положение дел. Исправление и свидетельство ошибок тех, кто придумывал IPv6. Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.
Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.
stargrave2 Автор
>Ближайший аналог — 2G/3G/4G. Инертность мышления не мешала переходу.
Они не так отличаются по сути работы своей.
>Вообще да, с отключенным кабелем действительно будет ещё безопаснее. Отсутствие полной симметричной связанности мешает лично вам, но для большинства потребителей интернета — эта плюс.
Не стоит их называть потребителями Интернета. Это потребители удалённых сервисов. Поднять IPsec между компьютерами они не смогут — какой же тут Интернет?
>NAT нужен
Единственное для чего он был нужен — как-то выжить в условиях нехватки IP адресов. На этом всём.
>Благодаря NAT, можно полностью переделать сегмент сети, с заменой сервисов в ней, протестировать всё это, в том числе на части живых пользователей и выкатить в прод незаметно для пользователей одной командой в консоли маршрутизатора. И в таких задачах у NAT замены нет.
Это решается маршрутизацией.
>Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.
Microsoft всегда в своём духе.
>Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.
Ваша идея использовать site-local адреса, без очень веских на то причин (они могут быть, не спорю, просто не верю что часто), гарантированно вызовет геморрой при коллизии сетей объединённых VPN-ом.
>Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6.
Это ваше субъективное мнение. Наверное мозг людей по разному устроен. Но мне абсолютно несвязанные 4 десятичных числа не просто запомнить, вот честно, правда.
>В IPv6 я вижу повтор этой истории.
Где-то есть опасения что адресов уже начало не хватать?
>Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.
Ну вот за столько десятков лет IPv4 так ничего подобного и не сделали чтобы везде было и работало. IPv6 сделал.
>Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.
Мне то странно видеть что вы её кладёте на этот путь. По вашей логике вообще не нужно ничего нового изобретать и писать новый софт. Нет, я тоже в целом приверженец идеи «работает — не трожь» и противник «движения ради движения» (кто-то считает прогрессом ради прогресса), но всему есть разумные пределы применимости. Видеохостинг изначально можно поднять на одном сервере с хранением видео файлов на ФС как есть. Но с ростом популярности такого сервера, придётся делать системы как в ivi.ru, где работают сотни программистов и сетевых инженеров. IPv4 уже не удовлетворяет потребностям.
>Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.
Обывателю достаточно оставить с дюжину сайтов типа YouTube, VK, FB, и т.д., а всё остальное отрубить — я уверен что 99% не заметят разницы тоже. Обыватели меня не интересуют.
>Решения о маршрутизации принимаются на основе фиксированного заголовка
>Сейчас, в IPv4 это работает так же.
Только заголовок обрабатывается сложнее (разная длина, плюс пересчёт checksum на каждом hop). А так да: в IPv6 аналогично, просто проще.
>Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.
Вы придумываете. Когда у меня был /64, то я дробил на маленькие сети, между разными устройствами (FreeBSD машины). Про Tier1 ничего не скажу, но ok, там поверю что ради оптимизации они не смотрят на 64-бит. Там это крайний случай.
>Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.
48 бит становятся 64 битами, да. Просто энтропии в этом адресе всё-равно 48 бит. Плюс два байта константы вставляются.
>Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.
NDP как-раз говорит о том, что он адреса канального уровня явно может и не быть — поэтому поля переносящие *внутри* ICMPv6 link-layer адрес: опциональны. На самом деле отличная apenwarr.ca/log/20170810 статья как-раз и предлагает делать на каждом порте коммутатора IPv6 сеть сразу же. По сути же оно так уже и есть: у нас точка-точка соединения чисто физически.
>Это то, во что IPv6 эволюционировал.
IPv6 это RFC описывающие IPv6. Плюс NDP. Плюс ещё несколько. Не нужно приплетать странные (дурные) RFC ко всей кучи и считать что их или кто-то обязан реализовывать или хотя бы даже прислушиваться. Эти дурные вещи никто никуда не тащит, в здравом уме.
>Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.
Ну… потому что вот прям буквально так и думаю, действительно. Я программист и прекрасно знаю что можно делать костыли побыстрее, решая сиюминутные задачи. А можно хорошо что-то продумывать, просто сложнее и дольше внедрять потом придётся. Сколько коммитетов/разработчиков — столько и подходов может быть. Все они профессионалы, бесспорно, но я сам, будучи разработчиком, не со всеми разработчиками согласен в решениях. Текущая статья: полная солидарность с разработчиками IPv6/NDP/MIPv6/и т.д…
>Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.
Ну а в США больше половины трафика это IPv6 *уже*. Можно и дальше бесконечно вспоминать старые времена как оно не получилось. 7 лет назад SLAAC-RDNSS мало кто поддерживал, сводя на нет его как возможную замену DHCP. Я IPv6 пользуюсь уже 10+ лет, но только сейчас вот написал про него статью, только сейчас считаю что пора.
a1888877
2G/3G/4G:
Между ними лежит пропасть сильно большая, чем между IPv4 и IPv6.
То, что лично вам NAT чем-то мешает не делает его автоматически не нужным. Я уже дважды писал для чего он требуется. И насчет всех этих идей про «выживание при нехватке IP адресов» – изначально NAT работал 1 к 1. А серые IP (нынешний NAT) назывались PAT и появились сильно позже. Поэтому NAT ортоганален нехватке адресов и вообще не для нее создан был.
Для некоторых конфигураций, тот же результат можно получить через маршрутизацию. Но, только вы вообще представляете себе какую конфигурацию нужно наворотить для полноценной Anycast маршрутизации эквивалентной NAT-у? Я вот на вскидку знаю пару человек, которые за пол дня смогут сделать тоже самое, что за пару минут делается 2-3 строчками через NAT. И уж молчу про дополнительное оборудование и ценник на него.
Что неожиданно легко решается NAT-ом. Зато ваша идея убьет сеть при смене провайдера.
Тоже цифры, также несвязанные, только шестнадцатеричные и больше.
Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.
Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP. Просто лет через 10 будут блочить уже ICMPv6 и всё.
Но у вас популистская статья, для обывателей. Не техническое сравнение, не примеры ваших кейсов и настроек — а ведь по комментариям видно, что у вас хорошо заработала связка IPv6 + IPSec для развертывания своих AutoConf сетей поверх интернета. Опиши вы её часть народа ломанулась бы повторять – вот вам и способствование внедрению IPv6.
Я просто не знаю откуда вы это взяли…. Какая разница какая длина, если смещение адресов от начала пакета одинаковое? Для маршрутизации IPv4 лучше IPv6 из-за более коротких адресов для простых маршрутизаторов, а IPv6 лучше IPv4 из-за пока сильно менее раздутого числа маршрутов для Full View маршрутизаторов.
Проблема не во FreeBSD, а в «альтернативных» стеках. Всякий IoT, роутеры, IP камеры и т.д., одно такое устройство, в котором одаренный программист не выполнил RFC (а у IPSec их здоровая куча) и всё – ваша дробленая сеть со сложной маршрутизацией с этим устройством работать не будет. А во всех этих девайсах лютый треш бывает.
Статья ИМХО весьма противоречивая. Такое интересный идеализм игнорирующий и физическое устройство коммутаторов и смысл SDN-на и местами здравый смысл. Но реально слишком много — там целую статью писать можно в ответ.
Зачем это куда-то тащить? И Windows и Linux исполняют RFC 7217, а до этого RFC 4941, которые как вы наивно думаете являются «странными (дурными)».
Но я же говорю не об каких-то абстрактных материях – это то, что реализовано в операционных системах ещё со времен Windows XP. Да и как-бы конгломерат RFC описывающих IPv6 – эта здоровая куча из десятков взаимосвязанных документов, по несколько на все эти SLAAC, RA, DHCPv6, Address Architecture и т.д.
Из ваших комментариев становятся понятны и проблемы, с которыми вы столкнулись из-за серых адресов и как IPv6 хорошо лег на конкретно ваши задачи. Но я хочу заметить, что вы упорно пытаетесь экстраполировать свой сугубо положительный опыт на все кейсы. Однако, как правило, есть вторая сторона и плюсы уравновешиваются какими-то минусами. И я уверен, что если бы вы в статье сконцентрировались не столько на положительных (для вас) сторонах IPv6, сколько на условиях когда они проявляются и были бы менее категоричны в сторону NAT — статья бы выиграла.
stargrave2 Автор
>Между ними лежит пропасть сильно большая, чем между IPv4 и IPv6.
Ваше субъективное мнение.
>То, что лично вам NAT чем-то мешает не делает его автоматически не нужным.
Штука которая делает неработоспособными любой протокол про который её явно не обучили? Какой бы костыль не был, но лучше без костылей.
>Что неожиданно легко решается NAT-ом.
Все ваши доводы по поводу NAT-а для меня выглядят абсолютно безумно нерациональностью. Вы представляете тяжеловесность NAT-а? Ну, в принципе что это за технология, как устроена? Очевидно что да. С таким же успехом, можно предлагать всё делать на прикладном уровне. Ну например HAProxy/nginx-ы разбирающие и балансирующие (или что там понадобится) HTTP запросы. Бывают места где без этого просто никак. А есть места где это сделать и просто, только крайне не эффективно с точки зрения ресурсов компьютеров. NAT относится к последнему. Просто все описанные вами usecase-ы, как их на лету подключать/отключать, меня конфигурацию и прочее — вовсю и по полной делается в ivi.ru, где я когда-то работал (не над сетями): о NAT-ах речи просто не может идти, когда трафик в сотни гигабит несколько лет назад был. Вопрос не в том что можно или нет решить эти задачи NAT-ом, а эффективно ли это или нет. Большинству людей просто поставить NAT на домашнем маршрутизаторе, чем писать правила firewall-а. Молоток предназначен для забивания гвоздей, а ещё им можно двери подпирать — это не значит что им стоит подпирать двери, если конечно он всё-равно при этом постоянно и для забивания гвоздей используется. В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.
>Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.
Только из коробки эти zeroconf мало в каких дистрибутивах идут.
>Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP.
Ну, тут я и остановлюсь пожалуй, ибо в RFC NDP (одного только NDP!), раз в моей статье этого не видно, не одна страница сравнения с IPv4 и сколько он нового привнёс. Если не замечать и всего остального в таком же масштабе…
netch80
> Штука которая делает неработоспособными любой протокол про который её явно не обучили? Какой бы костыль не был, но лучше без костылей.
И чем это отличается от того, что вы будете иметь без NAT?
Пусть у вас внутренняя сеть на мировых адресах, выданных из провайдерского /48, и вам протокол по каким-то причинам предлагает у клиента открыть порт и принимать на него соединения извне. Вы будете пускать всех, кто знает IP конкретного клиента? Спасибо, админ, предложивший такое, будет уволен за глупость и нулевые знания в области безопасности. Значит, файрволл по какому-то условию (клиент его оповестил, что есть внутри порт, или изнутри начали стучаться)? Тогда нет разницы с тем, что в случае NAT: за счёт граничного файрволла — протокол не работает.
Покажите мне, как вы будете решать эту проблему в случае вашего тотального IPv6 и без открытия внутренней сети всем мировым ветрам на вход. Покажете надёжный метод — ok, можно будет поверить, что это лучше NAT. Пока что сколько я ни спрашивал апологетов IPv6, мне никто на это не смог ответить.
На практике же в результате вместо, например, SIP — для которого задача пропустить медиапоток за NAT требует костылей вроде промежуточных прокси, STUN-серверов, ICE и т.п. — используют IAX2, у которого всё бегает по одной UDP ассоциации. Вместо FTP, с проблемами активного режима, массово используют HTTP. И так далее. И с таким уже нет разницы, NAT или не NAT, главное, что диверсанты снаружи внутрь не проходят.
> Все ваши доводы по поводу NAT-а для меня выглядят абсолютно безумно нерациональностью. Вы представляете тяжеловесность NAT-а? Ну, в принципе что это за технология, как устроена? Очевидно что да. С таким же успехом, можно предлагать всё делать на прикладном уровне.
Подробности в студию — как это по-вашему делается «на прикладном уровне». Один метод — завернуть всё в одно соединение (ассоциацию) я уже описал. Есть другие предложения?
> В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.
Всё те же проблемы в том же виде.
alliumnsk
Из этой поста, злоупотребляющем полужирным выделением и словами-лозунгами, создается впечателение, что молоток здесь именно как ipv6
edo1h
вы ошибаетесь, записей уже не меньше (то есть сам fw уже заметно толще). а если и правда каждая фирма будет брать себе as, то вообще коллапс настанет.
sumanai
У меня уже второй хостер выдаёт IPv6 поштучно за деньги.
netch80
> Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства. Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско.
Когда его задумывали, предполагалась при этом и замена MAC адресов напрямую IPv6 адресами с отменой ARP. Можно поискать — например, по публикациям Radia Perlman (много агитировала за упрощение L2/L3 взаимодействия). Но на Ethernet это не состоялось. Состоялось только на Infiniband — там 16-байтный адрес формируется из GUID адаптера (это как MAC, но 8-байтный) стандартным link-local IPv6 префиксом.
> Удивительно, как имея IPv4 — далеко не идеальный и не беспроблемный протокол, десять лет его эксплуатации в живых сетях и решения проявившихся проблем можно было создать IPv6.
А они не думали толком. IPv6 стабилизировался в базовых спецификациях ещё до того, как IPv4 CIDR начал массово распространяться. Но отменять поспешные решения никто уже не хотел.
В 1994-м (год окончательного принятия 128 бит) шли шатания в предложениях; было одновременно 64 и 128, причём 128 вначале состояли из двух разных уникальных адресов (!) — 64 на глобально уникальный и 64 на локально уникальный. Окончательным аргументом в пользу 128 стало письмо:
==={{{ <9407072035.aa15952@sundance.itd.nrl.navy.mil>
Yes, you said the magic words, «FIXED LENGTH.» I have espoused the virtues
of fixed length addresses before. My biggest beef with variable length
addresses is the issue of maintaining additional state or taking additional
time to parse an address whose length I don't know at the start.
[...]
> 8 byte fixed length address.
I have no problem with this, but this alienates many people. Also, there
seems to be a trend toward low percentage of allocated address space used.
(I offer NRL itself as an example, though not the worst, of such waste.)
If we could pull it off with 8 bytes, I'd be all behind it.
> 16 byte fixed length address.
This eliminates much alienation. Furthermore, wasted address space is not
a significant problem here.
[...]
My position can be best summarized as:
The SMALLEST possible fixed-length address. And that length
better have a good justification for why it cannot be smaller.
===}}}
Источник: ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/1994-07
Видимо, это было последней каплей — безо всякого обсуждения данного письма все резко переключились на единственный вариант драфта — со 128-битными адресами.
roller
NAT давал (призрачную) защиту от прямого сканирования портов вашей дырявой винды с любого хоста интернета. Теперь же (с приходом великоолепного ipv6) вы стоите голым посреди площади где трутся всяких сомнительные личности.
Думаю, большинство обычных людей не готовы к такой (свободе).
stargrave2 Автор
2020-ый год, а люди считают что можно выходить в Интернет без firewall…
edo1h
А почему нельзя? Говорят, что даже винду сейчас со встроенным файерволом можно выставлять, не пробовал. Линуксовых хостов с реальными ip и пустыми iptables есть у меня в достаточном количестве.
roller
Если у вас ss -lnt пустой (ну или только ssh) то вам и iptables не нужен.
edo1h
хотя, конечно, я понял про что вы, просто поёрничать захотелось.
мне в этом споре сторонников выхода локалки через nat и сторонников файервола на роутере вообще непонятен предмет спора. по сути это одно и то же же, в linux используются одни и те же таблицы conntrack, настраивается через тот же самый iptables (или что там сейчас модно? nftables?)
заметной разницы с точки зрения настройки, внутреннего устройства и безопасности всего этого ИМХО нет.
только nat таки нужен, так что и в ipv6-only сетях он иногда будет встречаться (и вы вроде бы уже согласились с этим).
le1ic
защита должна быть эшелонированной
ivlad
Мне кажется, в 2020 году эта проповедь смысла не имеет.
Примерно все, кто хотел разобраться в IPv6, уже разбираются. Мировое проникновение на клиентской стороне сейчас находится между 25% и 30% и продолжает рости. Поддержка на стороне софта не повсеместная, но достаточно массовая. Будут, конечно, какие-то странные личности, которые до последнего станут цепляться за IPv4 и это будет продолжаться ещё долго, но прогресс неостановим.
Странные личности — это повод для шуток, я встречался в 2001 году с людьми, которые на полном серьёзе говорили, что Ethernet скоро отомрёт и все перейдут на TokenRing. Примерно также можно относиться к апологетам тезиса "NAT is a security feature".
Единственное, что стоит делать — продолжать внедрять IPv6, у себя дома, у друзей и родственников, на работе. Возможно, стоит в качестве благотворительности обучать людей, но я не уверен, что на всю Москву или Питер надётся десяток человек, которые хотят учиться.
powerman
NAT сам по себе не является security feature. Но существование NAT и самого понятия "локалка" в 2020 отрицать столь же бессмысленно, как отрицать сам IPv6. Является NAT вселенским злом или нет — не суть важно, важно другое: из-за NAT все уже привыкли к тому, что безопасность внутри локалки можно поддерживать на уровне сильно ниже того, который необходимо поддерживать для доступных извне узлов. И сегодня бессмысленно давать этому оценку — хорошо это или плохо, корректно такое отношение или нет — потому что факт в том, что устройства и сервисы в локалке зачастую абсолютно ничем не защищены — ни файрволами, ни аутентификацией (либо аутентификация там уровня admin:admin).
Открывать ко всем этим устройствам и сервисам прямой доступ из внешнего интернета в текущих реалиях — безумие (что подтверждается недавними громкими атаками, когда JS в браузере юзера использовался для сканирования и атаки сервисов в локалке или на localhost). Обеспечить перенастройку локальных сервисов под стандарты безопасности внешних — даже не знаю, реально ли это в принципе (в мелких компаниях нередко используется в т.ч. самописный софт, в котором аутентификацию никто даже не предусматривал, потому что он же "только для своих" — его переделывание, учитывая что разработчик уже много лет тут не работает, а исходники потеряли… в общем это может оказаться похлеще проблемы 2000 и перехода на 64-битные процы вместе взятых). И даже если это реально — кто этим всем будет заниматься, и будет ли кто-то заниматься в принципе? И сколько времени на это уйдёт? В каждой SOHO локалке? Там обычно просто нет достаточно квалифицированных спецов для этой работы, равно как и нет понимания необходимости в этих изменениях.
Даже в этом треде отписалось несколько человек, которые пытались у себя внедрять IPv6 по собственной инициативе, и потом от него отказались, в т.ч. из соображений безопасности. Угадайте, что случится, когда в SOHO массово заработает IPv6, и следом их пойдут массово взламывать? Первым делом все они отключат IPv6, потому что с одной стороны будет паника, а с другой нет другого быстрого и дешёвого способа вернуть старый уровень безопасности для локалок. И уговорить их снова его включить может оказаться не так просто, как в первый раз.
Tolmy
IPv6 уже массово заработал в SOHO. В практически любом месте в смартфоне в США по умолчанию будет включен IPv6. Более того, особо упоротые мобильные операторы грозятся в ближайшем будущем отключать IPv4 по умолчанию и включать его только по явному требованию пользователя. Аналогично дела обстоят и с кабельным доступом.
Я админю некоторое количество серверов в США и веб-серверов в том числе, и это крупная международная компания. Не IT. Вот, полез проверил, у них на сайте примерно 60% запросов — из IPv6.
Что-то это не вызывает никакой паники.
powerman
Паника будет, когда его начнут массово ломать. А взлом дело такое, он работает от цены — как только текущими методами станет слишком дорого ломать, так сразу и переключатся на альтернативные методы, включая активное использование IPv6. Те же дыры в процах существовали лет 15, если не больше, и никому до них не было дела — пока были более дешёвые способы ломать. Аналогично будет и с IPv6 — чем больше вокруг IPv6 и чем лучше защищены системы на IPv4 — тем выше шанс, что начнутся массовые атаки на IPv6. Просто это случится ещё не сегодня, и даже не завтра. Но через 3-4 года — запросто.
ivlad
Ну, где-то бесмысленно, а где-то — осмысленно. Гугл вот в своём Beyond Corp отрицает и ничего. Я тоже отрицаю для достаточно больших организаций. Для SOHO — не отрицаю.
"все" — это слишком сильное утверждение. Не все. Большие компании не привыкли. SOHO, наверное, да, в этих терминах думают. Это неважно, потому, что SOHO маршрутизаторы по умолчанию точно так же запрещают подключение извне к устройствам внутри. Вот у меня сейчас адрес
2401:7400:c802:16e3:4867:450c:79d5:4932
— пингуется, а подключиться к netcat, который слушает на порту31337
снаружи не получается, маршрутизатор дропает пакеты. Можете попробовать. И NAT тут вообще не при чём.Я думаю, они плохо понимают безопасность в сетях IPv6.
Еще, кажется, есть люди, которые ненавидят то, что не понимают. Это, конечно, нормально, но слушать их не надо.
powerman
Я написал: переход на IPv6 прямо сейчас сильно снизит безопасность SOHO; плюс многие из тех, кто в состоянии безопасно настроить IPv4, не готовы выделить достаточно много времени чтобы сделать то же самое для IPv6, потому что это значительно сложнее.
Вы ответили: IPv6 можно настроить безопасно если иметь достаточную квалификацию.
Поговорили, в общем.
Tolmy
Как только гугл закончит свою бессмысленную войну за хороший https и против гадкого http, вполне может оказаться, что следующей причиной для изменения рейтингов выдачи сайтов будет наличие AAAA записи в DNS. А однажды — отсутствие A записи в DNS ;)
И тогда все те, что горой стоят против внедрения IPv6, молча козырнут и бегом начнут переводить все свои сервисы на IPv6. А пока всё и так работает — "работает? Ничего не трогай!" (с)
edo1h
вот вы сами и констатировали, что никому этот ipv6 не нужен
ivlad
Не нужен, не нужен, не переживайте. TokenRing вот-вот победит.
edo1h
ага. я насмотрелся уже на любителей бежать впереди паровоза, например провайдер построил сеть на atm, который "вот-вот победит", в результате сеть сейчас перестроена на ethernet, сколько денег было вбухано впустую — страшно представить.
и таких примеров несть числа — infiniband, itanium, rdram, …
да, я немного передёргиваю, ipv6 взлетит. когда-нибудь. но пока большинство провайдеров ip4-only — о чём говорить?
gxcreator
На самом деле все это очень круто выглядит на бумаге, а на деле нужны всякие temp-адреса для секурности, т.к. хз как вообще решать проблему что провайдер, сайты и все на пути видят(=собирают данные) идентификаторы устройств.
Еще на практике сразу же прилетают другие грабли — чтобы работал SLAAC надо емнип чтобы провайдер выдавал /48 минимум, а это далеко не все провайдеры делают. Т.е. из-за SLAAC получается что деление на подсети прибито гвоздями RFC. Так и получаются всякие уродливые костыли типа NAT66.
Еще не совсем понятно как правильно организовывать зоны RLOC — тут тоже есть разночтения(например в 6LoWPAN).
ivlad
Для SLAAC нужно /64. RFC 4941 по-моему по умолчанию включено на популярных клиентских OS.
Не понял, как SLAAC связан с NAT66. И причём тут RLOC — тоже не понял.
gxcreator
Ну по сути провайдер должен давать больше чем /64, из RFC7084:
Из-за того, что провадер дает меньше /64(некоторые дают вообще один адрес или /16), на помощь приходят всякие костыли типа NAT66.
Это не по теме SLAAC, но некоторые стандарты, которые основаны на IPv6 RFC, по разному определяют Realm Local.
ivlad
Это же не про провайдера, это про то, что маршрутизатор должен назначать /64 на каждый свой внутренний интерфейс. Да, разумеется, должен.
А, вы говорите, что есть провайдеры, которые нарушают RIPE-690. Да, наверное, есть. Это тоже происходит от непонимания того, как IPv6 работает.
Теперь я понял, кажется, о чём это:
Вот BCP, на который я сослался, говорит "/48 каждому или /48 бизнесам, /56 SOHO". Провайдеры, которые так не делают, творят дичь, но, к сожалению, никто не может им этого запретить. Я видел на провайдерском форуме как-то "выдадим /64 на район". Это не проблема IPv6, это проблема в недостаточной технической грамотности этих провайдеров.
alliumnsk
Не так давно считал плотность адресов ipv4 по бесплатному набору данных от ip2location.com.
Карта:
https://alliumnsk.netlify.com/images/gradientm.png
ipv4 адреса распределены сильно неравнмерно. В китае ~4 человек на 1 айпи4 адрес, а в Канаде ~2.5 адреса на человека
p.s. благодаря написанию этого комментария осознал ошибку у себя
можно глупый вопрос? А ipv6 как-нибудь решит проблему того, что траффик, скажем из Сибири до Японии идет не напрямую, а через Москву, Западную Европу (опциально США) и только потом в Японию?
Tolmy
Нет конечно. Это две ортогональных сущности, роутинг и адресация.
alliumnsk
если у нас такие адреса 128 бит, то туда можно класть широту долготу и подсказку по роутингу
ну и собственно в статье написано, что ipv6 это не просто более длинный адрес, но и много других хороших фич, так что можно было подумать и машрутизация лучше тоже
Tolmy
Нет, вот не нужно смешивать адресацию, маршрутизацию и ещё и географические координаты. Вот вообще не нужно, даже руководствуясь благими намерениями. Потому что вот прямо сейчас у меня на компе адреса, принадлежащие польскому и американскому провайдеру. Гугл, к примеру, считает, что я в США нахожусь. Потому что маршрут ко мне именно так и выглядит. И я лично хочу, чтобы так и продолжалось и впредь.
alliumnsk
Я почему-то воспринимаю ваш комментарий как то, что сетевые протоколы должны позволять вам указывать подложное местонахождение, но не позволять другим получать близкий к оптимальному рутинг. Почему один юзкейс важнее другого? И почему они несовместимы?
Если добавлять в длинный адрес поля, подсказыващие географическое положение, никто же не запретит вам точно так же указывать подложные координаты?
А давайте я напишу вот только не нужно смешивать сетевые протоколы и методы анонимности в сети. Вот вообще не нужно, даже руководствуясь благими намерениями.
Tolmy
Нет, я совсем про другое. Про то, что пути роутинга неисповедимы и маршрут между двумя соседними домами на одной улице запросто может проходить через Варшаву, Ганновер и Хельсинки. И это правильно, не надо это ломать. Даже из благих побуждений.
Из этого следует прямой вывод, что географические координаты в адресе — бессмысленны. Адрес, он для машин, а не для людей, а раз географические координаты в адресе машинам не нужны, то и толкать их туда не надо.
alliumnsk
Кажется, где-то я уже это слышал… пути божьи неисповедимы, поэтому не следует пользоваться контрацепцией (вариант: делать прививки, и.т.д.)
Некоторые вещи, однако, весьма исповедимы, такие как ограниченная скорость распространения сигнала (скорость света в вакууме поделить на показатель преломления оптоволокна) и вытекающая отсюда латентность на дальних расстояниях. Также весьма исповедима лень некоторых людей, не желающих править таблицу маршрутизации (пока это не влияет на их доход) и изобретающих весьма сложные отговорки.
(Автор статьи, кстати, предлагал пихать в адрес человеко-читаемые рюшечки, по сути дублирующие DNS)
Tolmy
Людям, которые пытаются порулить таблицами маршрутизации, надо бить по шаловливым ручкам. Разные там BGP не зря придуманы и десятки лет отлизывались.
А машинные алгоритмы при выборе маршрута как раз и оперируют той же задержкой сигнала, как одним из многих параметров. Но только одним из многих.
И как этому может помочь впендюривание географических координат в IP адрес?
Универсальный совет, хотите небольшой пинг до XYZ — езжайте жить поближе к XYZ и выберите правильного провайдера с нужной связностью. Мне, к примеру, пинг в 90мс до Кореи не светит принципиально, потому что это физически невозможно.
alliumnsk
Понятия не имею, где вы живете. Для Москвы, где наибольшая плотность хабраюзеров, пинг 90 мс до Кореи физически возможен. В Новосибирске, где я живу, тем более.
вы это серьезно? Зачем тогда этот энторет если можно взять лошадку и приехать к человеку лично?
Мне теперь под каждый сайт подбирать провайдера? А перед провайдерами еще слой аки костыльный NAT ставить?
Вы привели пример traceroute из IPv4. Автор поста указывает, что в IPv6 адреса выдаются иерархически, поэтому таблицы маршрутизации получаются меньше и проще. В IPv4 же у одной страны масса несмежных диапазонов, адреса в цепочке traceroute похожи на хэши. Вот я и подумал — может в сети ipv6 быть пинги хоть немного ближе к физически возможным станут… разве это не одна из первоочередных задач сети? (а не обеспечивать сетевых инженеров зарплатой).
Tolmy
Вы основываетесь на предположении, что существует прямой оптоволоконный кабель Москва-Сеул. Или Новосибирск-Сеул. Что цена на аренду канала в нем конкурентноспособна с остальными вариантами. Да что там цена, вообще просто есть возможность аренды, он не перегружен. Что Ваш провайдер прямо заинтересован в быстрой доставке контента из Южной Кореи своим потребителям и готов понести на это некоторые финансовые затраты. В таком идеальном мире да, до Новосибирска возможен пинг в 90мс. До Москвы — сильно сомневаюсь, на одной ретрансляции только больше потеряется. Это если не считать 50-60мс чистой задержки в стекле. Будет ближе к 200мс. Сорри, законы физики не обмануть.
Нет, это вообще никоим боком к версии IP не имеет. Физический и канальный уровень определяет всё и он никак не зависит от (желаемой) сетевой маршрутизации. А именно он будет определять задержки в канале. Есть прямой канал из X в Y, возможно на сетевом уровне будет принято решение использовать его. Нет прямого, из X в Y пакеты пойдут через Z. Из моего опыта пинги в IPv4 и в IPv6 примерно одинаковы, плюс-минус. Чуть меньше в IPv6 только из-за того, что там пока чуть меньше загрузка канала.
alliumnsk
отнюдь нет. Расстояние до Сеула через Владивосток, Хабаровск ненамного длинее прямого.
"зоконы физики" не определяют задержки на ретрансляцию, они могут быть сколь угодно малыми. То что может быть у провайдера клиенты хотят больше смотреть 4к видео на ютубе, чем пинг до Кореи, это не физика, это экономика. Но, простите, как говорил ОП, я хочу иметь интернет а не удаленный доступ до гугла и фейсбука.
Я всего лишь прошу чтобы пинг до Кореи у меня был в ТРИ раза хуже физически возможного, а не равным физическому пределу. А сейчас у меня до некоторых сайтов там пинг 450.
в чьем юскейсе примерно одинаковы? Между Роттердамом и Франкфуртом наверное и так маршрутизация неплохая что в 4 что в 6. А у кого-то что-то в юзкейс как раз и не входит из-за плохого соединения. Как соединения поменяются, юзкейс тоже может поменяться.
Tolmy
А кто Вам сказал, что существует канал Владивосток-Сеул или Хабаровск-Сеул, что он не загружен настолько, что в этом канале возникают потери и маршрутизация на автомате не начинает избегать этого канала?
Вы по прежнему основываетесь на предположении, что существует какие-то особые специальные физические каналы для Интернета. На практике цифра и голос делят одни и те же мощности и выделение нового канала передачи данных — это выделение очередного контейнера в SDH в магистральном канале. Да, может быть такое, что Ваш провайдер по IPv4 подписал один договор, и по IPv6 — другой, с другим поставщиком. Но вероятность этого исчезающе мала исключительно по экономическим причинам.
Это только Вам так кажется. В реальном, неиллюзорном мире все цифровые электронные устройства имеют вполне ощутимые задержки в обработке сигнала. Точно так же, эти же самые законы физики не дают построить компьютер с бесконечно большой производительностью. То, что частоты процессоров уперлись в потолок и практически не растут — это оно, физические ограничения.
Tolmy
Уже всё давно придумали до нас
Это всё просто замечательно, адреса типа ru/msk/south_butovo/gorchakova_st/43/app123 вообще прекрасно человекочитаемы и вполне себе содержат географические данные. Но. Сущая малость. Надо теперь научить машины(маршрутизатор, он тоже машина, только сильно заточенная на один специфический вид деятельности) разбирать такие адреса миллионами в секунду и на их основе строить маршрут доставки. Это такая малость, но портит абсолютно всё.
alliumnsk
Strawman
Tolmy
Ну нет же. Вы, вместе с авторами NDN, пытаетесь в сущности, предназначенные исключительно для машинной обработки, вложить удобные человеку понятия, категории и смыслы. Безусловно, это можно сделать. Но это лишь усложнит машинную обработку и, внезапно, не принесет никакой выгоды человеку. Вы на практике не пользуетесь IP адресами, вы используете DNS имя, которое как раз и предназначено для удобного использования человеком. А маршрутизатору абсолютно всё равно, есть ли какой-то физический смысл в IP адресе, который он сейчас форвардит, ему достаточно одной записи в таблице маршрутизации, по которой он примет решение.
MikFoxi
Отсутствие NAT — это огромный недостаток ipv6, изза которого я для себя буду максимально оттягивать всеобщий приход ipv6, и так будут делать миллионы. NAT это естественный фаервол для всех «умных» устройств, которые нужны в локалке, и которым интернет не нужен. «умные» в кавычках, потому что на самом деле большинство устройств тупое было всегда и будет всегда и заброшенное разработчиками/производителями сразу же после продажи юзеру. Телевизор, видео/радио няни, градусники, принтеры и прочее. Если все это выпустить в свободный интернет — это будут постоянные кражи персональных данных, взломы всего, и вообще это будет всемирный ботнет.
Tolmy
Вообще-то никто не мешает использовать NAT для IPv6. Это же только транспорт, ему все равно, какие технологии поверх него используются.
MikFoxi
Готовых костылей запилить ipv6 nat вроде ж нету. Лучше иметь ipv4 локалку с локальными адресами.
Tolmy
Угу. И однажды не получить доступ к очень нужному в данный момент ресурсу, который IPv6 only. А такие уже вот прямо сейчас есть. Мне лично транспорт как таковой неинтересен, мне ехать, а что там под капотом, всё равно. Но ведь жизнь заставила сесть и всё настроить. Так вот, заглянув под капот, я понял, что там в общем всё в порядке, ездить можно. Но тут уже сотни сообщений настрочили, что я ошибаюсь, и мне IPv6 не нужен и даже вреден. Ну ок.
MikFoxi
Не бывает важных IPv6 only ресурсов и в ближайшие лет 20 не будет.
Tolmy
Ну вот у меня есть ;) Ресурсы, которые позволяют мне зарабатывать деньги — это достаточно важные ресурсы?
powerman
Список в студию, плз.
Tolmy
Я на них деньги зарабатываю, NDA.
Я об этом выше уже писал. Внутренняя сеть компании — IPv6 only. Active Directory, IIS, ERP, MS SQL и Oracle, всё на доменных именах и IPv6. Nginx вот правда, с веб-сайтом компании, наружу торчит в IPv4. Вернее, в dual stack. В запросе к сетевикам, когда я хочу новую виртуалку задеплоить, вопрос про IPv6 вообще не стоит, а вот вопрос "нужно ли выделение IP4 адреса" имеется. И потом в списке из семи пунктов, почему нужно выделять IPv4 адрес, нужно выделить один или несколько пунктов. Первый пункт — "будет использоваться ПО, которое не поддерживает IPv6 и нет возможности это ПО не использовать". Последний — "требуется для разработки и тестирования". Тогда под виртуалку выделят отдельную железку, которая включена в отдельный влан из отдельного коммутатора. После чего мне нужно будет, по имеющемуся опыту, от двух недель до месяца ждать, пока вся эта корпоративная бюрократия предоставит мне к такой виртуалке удаленный доступ. А вот если она обычная, IPv6 only, то через пару дней максимум. Поэтому у меня никогда не возникает соблазна поставить галку "нужен IP4", ну его нафиг. Да и не было необходимости никогда.
powerman
Если я правильно понял MikFoxi (а если нет — он поправит), то речь шла вовсе не о внутренних ресурсах, а о популярных сайтах во внешнем инете.
Tolmy
А. В этом смысле да, не думаю, что это будет скоро, популярные сайты только на IPv6. Наиболее вероятный сценарий — гугл начнет снижать рейтинги показов сайтов в поиске за наличие IN A записи в DNS. И вот как только он об этом только объявит, начнется массовый отказ от IPv4 ;) А он вполне такое может запилить. Но, как я уже говорил, мне в общем всё равно, что, кто и как использует. Мне не шашечки, мне ехать. Будет IPv6 Ok, хорошо. Запилят какой-нибудь IPv2020 — ну да ладно, будем его использовать, когда надо. В начале 90-х я в одном министерстве убеждал типа именитых профессоров и к.т.н., великих технических специалистов, что X.25 это безусловно круто, но будущее за TCP/IP. Было весело видеть их унылые лица, да. А ещё раньше, в начале 80-х, я получил трояк за курс "теория СВЧ устройств", потому что сказал, что однажды технология производства полупроводников позволит работать в гигагерцовом диапазоне без всяких магнетронов и всей этой посеребренной канализации. Жаль, что препод не дожил до IEEE 802.11ac в коробочке, которая продается в каждом супермаркете.
MikFoxi
Да тут уже кто о чем, каждый о своем ))
Мое мнение:
Как клиенту инет провайдера, ipv6 мне не нужен и даже вреден (если внедрять по полной и пров будет раздавать подсеть чтоб каждому утюгу по выделенному ипу), потому что это нарушит безопасность моей локалки, да и куча устройств у меня которые не поддерживают ipv6.
Как админ сайтов — надобности в ipv6 мне нету, т.к. у всех посетителей всегда есть ipv4, сайты мои в РКН не забанены, чтоб иметь запасные ипы. Зато вред от ipv6 сайтам есть, изза того что их безлимит (благодаря утюгам, имеющим белый ipv6 и выход в интернет и которые уже взломаны), хоть поштучно, хоть подсетями учитывай, с них немерянно валится чернухи — ддосеры, брутфорсеры, поиск уязвимостей, создающих нагрузку и опасность серверу, тенденция эта постоянно растет и будет расти. Потому я даже сайтам которые за cloudflare отключаю ipv6, чтоб видеть меньше мусора в логах.
А популярные сайты, инста, фб, ютуб и т.п. которым как бы по статусу для солидности надо иметь ipv6 — их от этого парсить проще, дешево взять ipv6 проксей и качай сколько хочешь, с ipv4 проксей их парсить можно разориться.
MikFoxi
Мне тоже без разницы что там за ip, но куча девайсов в локалке никогда не даст мне избавиться от изолированной локалки. И вообще куча моих локальных девайсов ipv4 онли на старинных андроидах )))
Tolmy
ну так dual stack вроде пока никто не отменял. Я на хабре тоже не с IPv6 адреса пишу, у него его даже нет.
zurapa
Вы уже тратите администрирование сетей больше. Хотите чтобы все этой х… ней занимались? Оставьте только ipv6, коли вы такой евангелист и напишите мне через полгодика, сколько ресурсов из вас нужных вам не ответило.
Я правильно полагаю, что пока Хабр не включится в ipv6, вы мне не ответите?
Ankoroid
Ну так не выпускайте — настройка ipv6 firewall часто это просто 1 крыжик в веб-интерфейсе.
Он даже может быть уже включен по умолчанию.
ivlad
у вас просто в какой-то момент IPv4 связанность исчезнет, да и всё. Мне попадались уже публичные WiFi сети с IPv6 only и NAT64. Не замечал, пока не захотел что-то пингануть.
Вы не понимаете, как устроена безопасность и чем трансляция адресов отличается от фильтрации трафика. Ничего не мешает SOHO устройствам фильтровать по умолчанию соединения изне внутрь. Более того, они так и делают.
Да и вообще, вот публичная оферта: адрес моего домашнего принтера
2401:7400:C802:16E3:8625:19FF:FE73:ED3D
. Первый, напечатавший на нём свой PayPal адрес получит туда перевод в 100 USD. Роутер RT-AC1200G+ с настройками IPv6 по умолчаниюю. Вперёд.dragoangel
+++ люди от непонимания и не знания путают Nat с Firewall.
В добавку к всем плюсам IPv6 добавлю что DNSSEC который имеет в мире распространение в 2% всех клиенских зон (3 уровня и выше) на мой взгляд тормозится именно из-за IPv4, ибо SlitDNS с DNSSEC эта та еще боль, которая попросту не нужна в случае использования прозрачной маршрутизации IPv6. Что бы его завести приходится вырубать DNSSEC валидацию для своих субдоменов, либо делать свои приватные DNS публичными и на них настраивать IP Scope
JayK
Это все крайне хорошо, но с современными тенденциями, деглобализации, нацификации, ренессанса религий, обособления чебурнетов по признаку контроля определенной территории определенными силовыми стркуктурами, мы это светлое будущее увидим никогда. Поскольку айпивишесть крайне сильно осложняет работу всяческих роскомнадзоров и прочих, следящих за духовностью моральностью и уровнем одобрения солнцеликого вождя и неоскорбляемого божества, ведомств в одних странах, и уровнем одобрения мультигендерного мультикультуралистичного и прочих равенств, а также соблюдения прав животных (включая червей паразитов), а главное охране копирайта, в других.
Например люди работающие в крупном сотовом операторе, и паре региогиональных провайдеров, на вопрос, а когда айпивишесть, сказали что никогда, поскольку оборудование сорм с оным не работает, и есть полунегласные директивы от руководства даже не смотреть в ту сторону, хотя самый главный препон, наличие легаси оборудовния уже практически преодолен, а через примерно лет пять будет преодолен полностью.
А так то да, половина маршрутизации это есть костыли направленные на устранение несоответствия числа хостов числу айпи адресов…
DJArty
Предлагаю автору от теоретического описания плюсов ipv6 перейти к практической демонстрации как всё в действительности сейчас. Как все это выглядит для среднестатистического пользователя.
На примере среднего роутера типа упоминавшегося в ветке asus ac1200g+ показать что где включалось, настраивалось. Какой провайдер какой ipv6 выдал. Какие разные устройства подключаются к этому роутеру и как безопасно они себя чувствуют "вывалившись" в сеть. Какой фаервол на роутере, какие фаерволы на компе с виндой с линуксом, вайфай часах, каком нибудь увлажнителе с файфаем, принтере, телефоне на андроиде или иосе, каком нибудь шлюзе умного дома и лампочках с вайфаем, медиаплеере.
Как подключаются в эту схему старые устройства с ipv4 только.
А главное показать безопасность всего этого. Попробовать провести "проникновение". Проверить не светит ли в сеть какойнибудь домашний медиасервер с домашним видео или nfs шара или самба. Нужны ли и есть ли фаеволы на конечных пользовательских устройствах или достаточен файервол на обычном роутере и достаточен ли.
Вот тогда на реальном примере станет яснее хорош ли ipv6 и не пора ли его использовать.
JayK
-Как все это выглядит для среднестатистического пользователя.
Никак оно не должно выглядеть, плагэндплей.
-Какой провайдер какой ipv6 выдал
В РФ никакой не выдаст, version6.ru/isp, вы видели в списке роскомпозора в6 адреса? А какой выдаст там все это ограничится внутренней сетью без маршрутизации в интернет, на радость мамкиным хацкерам из этой сети.
-Нужны ли и есть ли фаеволы на конечных пользовательских устройствах
Файрвол? Какой файрвол? Астрологи объявили неделю снижения цен на дедики!
ne_kotin
МТС и Скайнэт выдают. Глобально маршрутизируемые.
stetzen
Ростелеком в Москве тоже выдаёт, во всяком случае некоторым пользователям.
JayK
Хм, а как это выглядит? Из коробки? А на заблокированные сайты можно зайти если у них есть в6 адрес? 2a02:4680:22::214 2a03:42e0:0:0:0:0:0:214 например
ne_kotin
для МТС в APN надо включить IPv4+IPv6.
Скайнет пока в тестовом режиме — заходишь в личный кабинет, взводишь галочку, забираешь префикс и настраиваешь его в роутере.
JayK
Так открывается рутрекер или нет? Нету к сожалению мтс проверить.
ne_kotin
Нет, не открывается.
MoreDerevo
проверил не открывается
на ипв6 очень много сайтов не открывается, в яндексе есть проверка — мол работает сайт через ипв6 или нет
StJimmy
Какая разница, какая используется версия сетевого протокола, если по крайней мере rutracker заблокирован по домену?
edo1h
мтс проводной не выдаёт. у нас, во всяком случае
ne_kotin
сорри, речь про мобильный МТС
alliumnsk
хм, интересно… два телефона с ipv6 адресами могут связаться напрямую, минуя провайдера?
ne_kotin
Ессна. Адреса же глобально маршрутизируемые.
Tolmy
Что понимается под словами "напрямую, минуя провайдера"? Минуя маршрутизацию через оборудование мобильного оператора? Нет, и тут версия протокола или адресация не при чем. Канальный уровень, передача сигналов в сотовой сети так устроена, что это невозможно.
alliumnsk
Понимается, что по вашему совету, юзеры взяли лошадок и едут навстречу друг другу. Пока они далеко, сигнал идет через провайдера. Как они оказались в прямой видимости, маршрутизация прозрачно меняется.
Вопрос в том, насколько это достижимо на практике
ton1
Такое возможно в случае альтернативного mesh протокола — yggdrasil например. Провайдерам делать такое очень западло — они потеряют возможности контроля.
Tolmy
Это недостижимо по политическим причинам. Государство просто не допустит существование таких протоколов передачи данных. Ни у нас, ни в самых распрекрасных оплотах демократии. Но особенно у нас. Поэтому только так, любой чих — через мобильного оператора. И — в папочку.
Sugrob
> В РФ никакой не выдаст, version6.ru/isp, вы видели в списке роскомпозора в6 адреса? А какой выдаст там все это ограничится внутренней сетью без маршрутизации в интернет, на радость мамкиным хацкерам из этой сети.
1) Выдают глобально маршрутизируемые
2) У меня свой роутер, настраивал сам
3) Рутрекер доступен по https
gxcreator
Дом.ру в НН на PPPoE выдает глобальные
ivlad
На линке я вижу 8 устройств. Кажется, это 2 ноутбука, 2 телефона с iOS, NAS, Apple TV, принтер, маршрутизатор. Sonos и Kindle Paperwite не умеют IPv6 и в том же L2 сегменте получают адреса посредством DHCP, ходят через NAT. Kindle Fire, на андроиде, как пишут, умеет IPv6, но мне куда больше нравится Paperwhite.
Встроеный.
Встроенные или никаких. В принтере точно никакого нет. Я уже предлагал: адрес моего домашнего принтера 2401:7400:C802:16E3:8625:19FF:FE73:ED3D. Первый, напечатавший на нём свой PayPal адрес получит туда перевод в 100 USD.
zurapa
Я на дня выступление слушал, там человек про iOS странности в ipv6 рассказывал. Если резюмировать, то в ipv6 iOS голой жопой наружу, и весьма несложно ломается и ничего с этим не поделаешь, там ещё описывался факт подмены маршрутизатора для iOS. Ей можно широковещательным пульнуть, что её ip хотят и она новый попросит у маршрутизатора. Так что с ipv6 мальчики просто не сталкивались ещё с проблематикой, когда поведение смартфона в сети никак не откорректировать, остаётся с этим жить. Только с ipv6 придётся с этим жить в публичной сети. Кстати, кто знает, как в iOS настраивается фаервол?
ivlad
Можно ссылку на выступление?
zurapa
Кто-нибудь! Расскажите этому мальчику о недостатках и нерешённых проблемах, которые ставят под вопрос целесообразность внедрения этой технологии. Ситуации с wi-fi, который везде и всюду уже достаточно, чтобы не продолжать.
ne_kotin
Что не так с v6 в Wi-Fi, расскажите пожалуйста?
В домашней сети с /64 на роутере — просто работает (SLAAC, RADVD).
develop7
Раз вы, без сомнения, осведомлены о, и уж наверняка во всей полноте, может, стоило бы взять, да снизойти до убогих, осияв их светом подлинного знания, нет? Такую миссию кому попало доверять, знаете ли, неразумно — могут не донести.
zurapa
А вы бы не тратили время на чтение комментариев, псевдоучёных, которые в основном зарабатывают рейтинг перед будущим работодателем, а почитали бы больше статей по проблематике использования ipv6. Или вас родители не научили кучку сначала нюхать, потом пробовать на зубок?
Тут пару тролей засело, и уже массу времени потратили люди на аргументацию, однако бесполезно. Предпочитаю намекнуть, а там уже каждый сам для себя решит: почитать или минуснуть. Пока, что получается собрать статистику по минусам. Адекватных людей сложней вычислить.
ne_kotin
Это так не работает. Изволите постулировать — аргументируйте.
IPv6 хорош как раз тем, что убирает массу болячек v4 — дефицит адресного пространства, как следствие — необходимость в NAT, зависимость конфигурирования сети от DHCP. При наличии /64 на роутере и разрешенном SLAAC+RAD все просто работает автомагически — вставь провод и готово.
Выдача /64 из /56 или /48 тоже вполне регламентированная процедура.
Т.е. проблем с внедрением и использованием v6 нету. Есть проблема с ленивыми задницами в операторском бизнесе.
develop7
следует понимать, что ссылок ждать от вас не стоит?
alliumnsk
Пост очень длинный, поэтому я сделал короткий реферат, оставив только самое важное.
zurapa
Красавчик! Прям тезисы! Ты наверняка отличник был в университете! Я бы два плюса поставил, но могу только один. Извини.