IPv6 — прекрасный мир, стоящий скорого перехода на него

    Практически все статьи, которые я видел на тему «чем хорош 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 имеет более серьёзные требования (эту часть можно обозвать недостатками):

    • Минимальный допустимый 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 и полноценный Интернет в массы!

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 455

      +5

      Всё очень вкусно и весело, но сложность настройки, особенно на маршрутизаторах, намного выше чем для v4.


      Для обычного человека с SOHO роутером, если производитель сразу хорошо сделал, никаких проблем нет и SLAAC — это может быть и круто, всё само раздалось, у устройств в сети белый внешний адрес появился.


      Но недавно пытался настроить IPv6 на RouterOS и, несмотря на то, что провайдер поддерживает и в openwrt завелось всё сразу, микротик либо не выдаёт клиентам адреса, либо себе, либо не пускает трафик наружу через себя.
      А все материалы сводятся к тому же, что у вас написано: настройте SLAAC, это стильно, модно и молодёжно. Но при этом стек технологий вокруг IPv6 крайне сложный, и если ты не зароешься в RFC на долгие дни, то разобраться весьма проблематично.

        0
        Но недавно пытался настроить IPv6 на RouterOS и, несмотря на то, что провайдер поддерживает и в openwrt завелось всё сразу, микротик либо не выдаёт клиентам адреса, либо себе, либо не пускает трафик наружу через себя.

        SLAAC на ROS настраивается в 2 клика, просто кто-то всё ещё считает что ROS для домохозяек и всё должно предельно просто настраиваться.
          +5

          И всё тоже самое, с точностью до вариаций перевода пишут в ответах на форумах микротика, на реддите, на stackexchange.


          Что всё настроить тривиально, просто автор не разобрался. Но никто не говорит, как это сделать в два клика, чтобы при этом работало.

            –2
            Достаточно открыть вики и осмысленно прочитать.
            SLAAC настраивается в добавлении адреса.
            Если у вас статика — вешаете /64 адрес на интерфейс и ставите advertise=yes, если получаете по DHCP-PD — вешаете адрес ::1/64 (например, так то любой какой захотите), указываете пул адресов из которого брать и так-же включаете advertise. Допом в IPv6 — ND можете покастомизировать что микрот будет отдавать в SLAAC.
            Если же вы из отряда тех кто хочет префикс отличный от /64 заставить работать с SLAAC — вам путь в RFC где определено что SLAAC должен работать только для /64.
              0
              Если же вы из отряда тех кто хочет префикс отличный от /64 заставить работать с SLAAC

              ну вот у меня дома есть динамическая подсеть /64 от провайдера.
              есть wifi-сеть.
              есть проводная сеть (даже не одна на самом деле, поделены vlan'ами)
              есть сети для виртуалок.


              и какой мне толк от сети /64 провайдера, если я не могу её нарезать?!?

                +1
                Нарезать можете без проблем: у меня дома и /126 сетей не одна. Да, SLAAC на меньших размерах не будет работать.
                  0
                  Да, SLAAC на меньших размерах не будет работать.

                  хорошо, и как будет выглядеть подключение к сети с телефона без SLAAC?

                    0
                    Если вам его хочется засунуть в сеть меньшего размера: руками (статика) или DHCPv6. Мне не мешало отдавать и /64 сеть SLAAC-у и одновременно нарезать её для хостов на одном и том же маршрутизаторе.

                    Только вопросы: а зачем вам её нарезать? У 99.9% пользователей не возникнет такой надобности (SLAAC удовлетворяет их). И чтобы вопросов «как нарезать» не возникало, дают рекомендации выдавать /56 или даже /48 сети конечным пользователям. Насколько видел статистику, большинство провайдеров выдавало /56 или больше.
                      0

                      не мониторю ситуацию, но по состяюнию на год назад из трёх провайдеров в моём доме ipv6 предлагал только один, у него /64

                        0

                        Да, только вот есть явно больные на всю голову провайдеры, которые даже /64 выдавать жлобятся, а выдают /128. и когда просишь у них /56 смотрят на тебя, как на идиота. Хотя, с другой стороны, это ещё более-менее вменяемые провайдеры, совсем невменяемые говорят, что у "нас IPv6 нет и не планируется".

                          0
                          Мне не мешало отдавать и /64 сеть SLAAC-у и одновременно нарезать её для хостов на одном и том же маршрутизаторе.

                          а можно детали?

                            +1

                            А главное, чтобы маршруты не пересекались. приоритет разный раскладываешь на route и всё работает.

                            0
                            большинство провайдеров выдавало /56 или больше

                            гугл привёл на:
                            https://version6.ru/isp


                            список провадйеров, предоставляющих ipv6, небольшой, почти у всех /64.
                            плюс там же список "Провайдеры, ранее предоставлявшие IPv6" размером чуть ли не с половину основного.

                        0
                        попросите у провайдера /48, я не думаю что он разорится от этого
                          0
                          Полностью согласен! Именно поэтому рекомендуют давать больше чем /64. HurricaneElectric туннельный брокер например просто так даёт людям /48 префиксы, бесплатно и без проблем — так что это точно не проблема.
                            0
                            попросите у провайдера /48, я не думаю что он разорится от этого

                            имея опыт общения с провайдерами — даже пробовать не буду.
                            речь идёт о массовой услуге, вся вариативность ограничивается тем, какие "галочки" есть в личном кабинете и у девочек из колцентра. для vip-клиентов (юриков) могут быть варианты, но не для платящих 400р в месяц физиков.

                              0
                              Мне кажется всё может зависеть буквально просто от одного человека на той стороне, как повезёт (к сожалению). Ростелеком вот с трудом, но сказал что PTR записи для статических IP он будет выдавать только юрлицам. А вот NetByNet просто одним email-ом без проблем меняет и прописывает их.
                                0
                                Мелкие провайдеры могут пойти навстречу. Мне два провайдера делали статику IPv4 абсолютно бесплатно.
                                0
                                > попросите у провайдера /48, я не думаю что он разорится от этого

                                «После пятнадцатого отрывания провода злобной уборщицей умоляешь провайдера перевести тебя на ppp. Провайдер добрый, посылает на [censored] только первые 82 раза, потом соглашается.» ©
                              +1
                              > SLAAC настраивается в добавлении адреса.

                              OK, хочу послушать конкретные рецепты, как это выглядит — с именами производителей и моделей, которые это уже сделали (после 26 лет разработки IPv6). А именно для следующего юзкейса:

                              1. Провайдер выдал /56 (хороший, добрый провайдер). Как это происходит на протокольном уровне, и что надо нажать/написать у устройства, пригодного для раутера фирмочки на 20 человек.

                              2. Как этот же шлюз передаст информацию о выданной сети на раутер отдела, который будет выдавать уже /64 на отдел.

                              3. Что будет, если провайдер сменит этот адрес: как он пришлёт нотификацию, как она пробежится вниз до каждого конкретного компа/телефона/etc, заставляя их сменить адрес.

                              4. Как эта смена адреса будет отражена в DNS, поддерживаемом этими раутерами/шлюзами, а также в других средствах вроде Active Directory, если им это нужно.

                              Упрощённый вариант — домашняя сеть, получено /56 или /64 от провайдера, точно так же раздаётся на уже одну локальную сеть (простым аппаратом с WiFi рогами ценой до 100$).

                              Варианты с домашним устройством дороже 100$ или SOHO дороже 300$ не принимаются. Варианты, где оповещение вниз вплоть до каждого аппарата (компа, телефона, принтера, умного дверного замка...) не раздаётся, и он тормозит часами, прежде чем перезапросить адрес — тоже.

                              Если такого варианта нет, он чудовищно дорог или требует больше, чем включить 2 галочки с понятными названиями на вебе раутера — все рассказы про SLAAC и прочие страшные слова это «в пользу бедных».
                                0

                                Это делается за счёт prefix delegation. Иерархический PD тоже в принципе возможен, но я не уверен, что в «фирмочке на 20 человек он нужен». Такое, пожалуй, двумя кликами не настроить. Иерархические сети требуют больше усилий в настройке.


                                А вот второй вариант, да, в моем роутере, полученном от провайдера настроился двумя кликами.


                                Почитайте про PD. И не думайте, что эта проблема не была осознана и решена.

                                  0
                                  > А вот второй вариант, да, в моем роутере, полученном от провайдера настроился двумя кликами.

                                  Вот я и прошу назвать модель, а также параметры (какие времена он позволяет задать, в первую очередь, для router advertisement). Как клиентские терминалы на это реагирует. Как оно отражается в DNS. Что это в принципе возможно и по каким словам — я знаю. Интересует именно практика на своём опыте.

                                  > Почитайте про PD. И не думайте, что эта проблема не была осознана и решена.

                                  Читал. Осознана — по крайней мере теми, кто способен осознать — спора нет. Решение — 1) таки вопрос о точных моделях. 2) Что с DNS? Это из коробки где-то есть? Заниматься сексом по скрещиванию какого-нибудь dhcpd с dnsmasq я-то смогу, а как быть админу мелкой конторы?

                                  > Иерархический PD тоже в принципе возможен, но я не уверен, что в «фирмочке на 20 человек он нужен». Такое, пожалуй, двумя кликами не настроить. Иерархические сети требуют больше усилий в настройке.

                                  Пусть не 20, а 50. Всё равно — уровень сложности настройки?
                                    0
                                    Вот я и прошу назвать модель

                                    https://www.asus.com/Networking/RT-AC1200G-plus/specifications/


                                    а также параметры (какие времена он позволяет задать, в первую очередь, для router advertisement).

                                    Я поленился смотреть, что там можно настраивать. В RA прилетает 600 секунд lifetime и RDNSS.


                                    Как клиентские терминалы на это реагирует.

                                    Ожидаемо: настраивают префикс и DNS. В системных настройках появляются оба адреса роутера: v4 и v6. v6 появляется тот, что с глобальным скоупом.


                                    2) Что с DNS? Это из коробки где-то есть? Заниматься сексом по скрещиванию какого-нибудь dhcpd с dnsmasq я-то смогу, а как быть админу мелкой конторы?

                                    Я без понятия. У меня маршрутизатор не умеет динамически апдейтить DNS для локальной зоны — что для v4, что для v6. Я не в курсе, какие SOHO маршрутизаторы такое умеют.


                                    Мне кажется, вы хотите скрестить ужа с ежом: сначала говорите про SOHO маршрутизаторы и минимальную настройку в два клика, а потом сразу — про Active Directory. Насколько мне известно, AD в два клика не настраивается, а требует заметной работы при установке. В компаниях на 20 и даже на 50 человек не встречается, возможно, за исключением самых редких случаев. SOHO маршрутизатор — обычно 1-2-3 VLAN, затерминированные на нём. Резолв адресов — через mdns или LLMNR, никакого внутреннего DNS.


                                    Как AD DC переживают изменение префикса, я не знаю, не сталкивался.


                                    Пусть не 20, а 50. Всё равно — уровень сложности настройки?

                                    Я же написал, что двумя кликами не настроить, скорее всего. Это за пределами потребностей и способностей людей в малом бизнесе.

                                      0
                                      > Я поленился смотреть, что там можно настраивать. В RA прилетает 600 секунд lifetime и RDNSS.

                                      OK. 600 секунд это настолько много, что слово «чудовищно» недостаточно, это ещё хуже. В идеале это всё должно реагировать за полсекунды, а на смену адреса эти самые RA должны лететь не ожидая таймаута и пачкой в несколько штук для дублирования. А для надёжности корпоративного уровня оно ещё должно заглянуть в lease DB и пинать каждого, кто не переключился.

                                      > Я без понятия. У меня маршрутизатор не умеет динамически апдейтить DNS для локальной зоны — что для v4, что для v6. Я не в курсе, какие SOHO маршрутизаторы такое умеют.

                                      Значит, пишу: этого ещё нет ;(

                                      > Мне кажется, вы хотите скрестить ужа с ежом: сначала говорите про SOHO маршрутизаторы и минимальную настройку в два клика, а потом сразу — про Active Directory.

                                      Нет, это вопрос по разным уровням, от минимума до близкого к максимуму. Но AD вполне возможен и на 50 сотрудников.

                                      В общем, пока с практической доступностью этих возможностей явно не плохо, а очень плохо :(
                                        0
                                        OK. 600 секунд это настолько много, что слово «чудовищно» недостаточно, это ещё хуже. В идеале это всё должно реагировать за полсекунды, а на смену адреса эти самые RA должны лететь не ожидая таймаута и пачкой в несколько штук для дублирования.

                                        На что оно должно реагировать за полсекунды и почему? И какой протокол так уже сейчас делает?


                                        Значит, пишу: этого ещё нет ;(

                                        Вы всё-таки определитесь, вы про "надёжность корпоративного уровня", или про SOHO маршрутизаторы.


                                        Но AD вполне возможен и на 50 сотрудников.

                                        Вполне возможен и на 5. Только обычно его нет.


                                        Я ещё раз повторюсь, определите задачу. Если задача про SOHO маршрутизатор, обслуживающий два VLAN и меньше сотни клиентов — это одно. Если задача про AD и сотни клиентов с дополнительными маршрутизаторами внутри сети — другое. Пока вы перескакиваете с одной позиции на другую и жалуетесь, что SOHO коробка за сотню долларов не даёт вам достаточного времени сходимости. Так в IPv4 она тоже не даёт.

                                          0
                                          > На что оно должно реагировать за полсекунды и почему? И какой протокол так уже сейчас делает?

                                          Протокол — не делает. А вот NAT — устраняет необходимость зависеть от внешних адресов в принципе.
                                          Внутренняя сеть строится на site-local или ULA адресах, на границе — NAT. Проблемы известны, на некоторые я традиционно вою волком (как SIP media transport), но если выбирать, что лучше — знание внешними хакерами структуры внутренней сети или проблемы с отдельными сервисами — я выберу второе.

                                          > Я ещё раз повторюсь, определите задачу. Если задача про SOHO маршрутизатор, обслуживающий два VLAN и меньше сотни клиентов — это одно. Если задача про AD и сотни клиентов с дополнительными маршрутизаторами внутри сети — другое.

                                          В том и дело, что разницы здесь нет. Есть задача, универсальная на все случаи: если мы не используем постоянные внутренние адреса, а строим на внешних адресах — то имеем грабли, которые надо решать (и список этих граблей я привёл). Home или корпорация с AD — объём проблем тот же, меняются только те сетевые средства, которые надо лечить.

                                          Тут, однако, надо заметить, что можно пытаться выставлять на каждый внутренний хост одновременно site-local/ULA и внешний адрес, во внутренний DNS выставлять внутренние адреса, и надеяться на маршрутизацию. Наверно, можно, но я ещё не видел dhcpd с выдачей нескольких адресов одновременно. Если это будет — можно будет обсудить грабли такого решения (но срочное оповещение при переключении таки всё равно будет полезно).

                                          > Так в IPv4 она тоже не даёт.

                                          В IPv4 частные адреса внутри — норма, и нет апологетов тотального отказа от них, которые на формулировки проблем начинают рассказывать, что сегодня потребности в колбасе нет.
                                            0
                                            но срочное оповещение при переключении таки всё равно будет полезно

                                            Если у нас возникает необходимость сменить префикс при переключении, маршрутизатор рассылает старый префикс с lifetime 0 и новый с lifetime больше 0. И после этого хосты получают новые адреса, думаю, как раз за те полсекунды или меньше.


                                            Вы всё-таки в традициях RU.OS.CMP задаёте не тот вопрос, на который хотите ответ услышать, а потом жалуетесь, что вам ответ не подходит.


                                            Это всё и лучше есть в OpenVMS, как говорится.


                                            Наверно, можно, но я ещё не видел dhcpd с выдачей нескольких адресов одновременно.

                                            Не уверен, причём тут DHCP, если мы говорим про RA. IPv6 хосты могут иметь несколько адресов на интерфейсе (в том числе от разных маршрутизаторов), это им никак не мешает.


                                            Home или корпорация с AD — объём проблем тот же, меняются только те сетевые средства, которые надо лечить.

                                            Корпорация — это наверняка PI адреса и BGP с парой провайдеров. Тут ничего не поменялось относительно IPv4. Разница между IPv6 в Яндексе и IPv6 у меня дома существенна. И я уверен, что вы про это в курсе, но специально делаете вид, что нет.


                                            но если выбирать, что лучше — знание внешними хакерами структуры внутренней сети или проблемы с отдельными сервисами — я выберу второе.

                                            Это что они traceroute могут сделать или адреса порезолвить? Или какое знание?

                                              0
                                              > Если у нас возникает необходимость сменить префикс при переключении, маршрутизатор рассылает старый префикс с 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, то на этом можно собрать много информации для будущих диверсий.
                                                0
                                                Это теория или практика?

                                                RFC4861 разделы 6.3.4 и 6.3.5. Если вы скажете, что это теория потому, что кто-то может не следовать RFC, то я сразу могу ответить, что крупные игроки RFC в основном следуют, а те, кто не смог правильно реализовать, не реализуют IPv6.


                                                И как быть с возможными потерями в сети?

                                                Самое худшее, если клиент пропустит все RA, то оттаймаутится.


                                                По моим данным, это как раз далеко не типичный случай даже для крупных корпоративных сетей.

                                                А по моим — наоборот. И что теперь?


                                                Наоборот, многие отказывались именно потому, что им казалось надёжнее опираться на провайдера, даже если возникает какой-то внутренний балансинг.

                                                Если они решили опираться на провайдера, они могут договориться с провайдером о статическом префиксе. Это те же компании, которые договариваются о статическом IPv4 на внешнем интерфейсе, чтобы поднимать IPSec.


                                                А то вы опять смешиваете SOHO и средние и крупные компании.


                                                И прочая и прочая. Если против фирмы начат APT, то на этом можно собрать много информации для будущих диверсий.

                                                Сейчас большие сети так делать не рекомендуют. Делают L3 между доступом и агрегацией и выделяют /64 (или больше) на коммутатор на уровне доступа. Поэтому да, можно извне отличить восьмой этаж офиса от пятого. Эта проблема существует.

                                                  +1
                                                  Я вернусь немного к этой теме и попрошу уточнение про SLAAC. Итак, предположим, что NAT мы отвергли, у нас есть выдаваемые хосту временные адреса, которые он может использовать для своих целей.
                                                  Пусть протокол определяет, что часть соединений будет входящими — локальный хост открыл сокет и передал его координаты куда-то, и ждёт ответа. Есть протоколы, где это важно (и мне рядом тут пытались проесть мозг какой-то игрушкой с фиксированным портом).

                                                  Если внешний файрволл существует и знает протокол… ok, считаем, проблем нет, кроме того, что он должен знать все протоколы (нереально).

                                                  Если он не знает протокол — соединения не будет.

                                                  Если он не знает протокол, он пропускает всё в сторону внутреннего хоста, полагая, что случайности IP адреса достаточно.

                                                  Теперь пусть внутри какой-то слабозащищённый сервис (ну дырка в нём), и слушает на Any (IN6ADDR_ANY или как оно там будет зваться). Коннект на него должен приняться — ограничения-то нет. Значит, злоумышленник, получив откуда-то временный IP, может сразу его атаковать, пока этот IP не освобождён.

                                                  Чтобы этого не было, надо, получается, разделить Any на как минимум два подварианта: «совсем Any» и «Any для постоянных адресов», с умным выбором между ними. Только я что-то нигде такого в тех рекомендациях, включая RFC, не видел.

                                                  Эта проблема вообще хотя бы озвучена в обсуждении SLAAC?
                                                    0

                                                    Я хочу обратить внимание многоуважаемой общественности на один, очевидный из всего обсуждения этой статьи факт: IPv6 штука сложная, не очевидная, безопасная настройка которой до сих пор вызывает множество вопросов, на которые нет простого гайда for dummies с ответами… При этом на дворе 2020-й год, IPv6 исполнилось 25 лет. По-моему на этом тему можно закрывать и расходиться, кина не будет.

                                                      –1
                                                      IPv6 штука сложная, не очевидная, безопасная настройка которой до сих пор вызывает множество вопросов

                                                      Да ладно?
                                                      0. Получил статический v4 у провайдера.
                                                      1. получил учетку к туннелю и префикс на tunnelbroker.net
                                                      2. включил в роутере 6in4
                                                      3. настроил туннель
                                                      4. поднял radvd
                                                      5. ?????
                                                      6. PROFIT!

                                                      Всё, дальше работает SLAAC. Втыкаем в вифи или по проводу любой девайс — он автоматом получает глобально маршрутизируемый адрес.
                                                      Что здесь сложного?
                                                      Что здесь небезопасного?

                                                      Вот вам гайд в несколько пунктов для чайников — чем вы недовольны?

                                                      На этом тему можно закрывать и расходиться, кина не будет.

                                                      Конечно-конечно, лучше ж сидеть за NAT, и маяться костылями типа STUN, TURN, uPnP.

                                                      Что за люди пошли — даешь им простой рецепт раздачи глобальных адресов, прямые коннекты между девайсами — а им плохо.
                                                        +2
                                                        Что здесь небезопасного?

                                                        Это вот сейчас шутка юмора такая была, да? Вы как-то забыли в своём гайде примерно всё, что касается как раз именно безопасности — я не увидел слова файрвол, не увидел как надёжно разграничить доступ снаружи к локальным ресурсам, не увидел ответа на все те вопросы, которые встречаются в обсуждении этой статьи (включая вопрос netch80, в ветке которого мы сейчас разговариваем).


                                                        даешь им простой рецепт раздачи глобальных адресов, прямые коннекты между девайсами — а им плохо.

                                                        Ну да, плохо. Потому что мне нафиг не нужны прямые коннекты из инета к девайсам в моей локалке — за исключением очень небольшого числа разрешённых.

                                                          –2
                                                          Какая шутка? Я действительно не усматриваю практической опасности в том, что у меня все девайсы глобально адресуемы. А гипотетические сценарии про хакера и солонку меня мало волнуют.

                                                          Вам дается подсеть на 64 бита. Если атакующий не знает конкретного адреса и порта на нем — ему придется очень долго сканировать сеть. Сильно дольше, чем v4 на /8 и даже на /16.
                                                          Адреса для исходящих сокетов регулярно ротируются, у меня на каждом хосте как минимум 1 а то и 2 исходящих адреса, меняющиеся постоянно.
                                                          То есть вероятность успешно попасть в какой-нибудь уязвимый сервис — примерно как в муху.
                                                          Это уже само по себе безопасно.

                                                          И вы забываете про то, что v4 сам по себе тоже не определяет файрволлы и другие меры безопасности, хотя сам по себе менее безопасен и менее удобен. Всегда когда мы говорим v4 — подразумеваем NAT. И DHCP. v4 плохо конфигурируем и отвратителен в удобстве развертывания на фоне v6-ного RADVD и SLAAC.

                                                          А безопасность — это уже совсем другой аспект. Не нужны прямые коннекты — возьмите и настройте файрвол на роутере. iptables умеете же? 6tables то же самое. NAT же — это не защита, это не firewall.
                                                            +3
                                                            Я действительно не усматриваю практической опасности в том, что у меня все девайсы глобально адресуемы.

                                                            Ну вот в этом и проблема. Я опасность в этом вполне усматриваю. Потому что считать IP-адрес устройства, с которого оно будет рассылать в инет тьму пакетов (которые легко перехватываются как на уровне провайдеров, так и воруются с тех сервисов, на которые стучится устройство) как секретный токен — я категорически против. Секреты не рассылают непрерывным потоком в окружающий мир в открытом виде.


                                                            Всегда когда мы говорим v4 — подразумеваем NAT. И DHCP.

                                                            Когда мы говорим v4 — подразумеваем, что любая домохозяйка ставит себе роутер, который прикрывает её локалку от злобных хакеров в этих ваших интернетах. А для не домохозяек, а вполне квалифицированных админов и разработчиков, которым нужно открыть снаружи доступ к определённым сервисам в локалке, мы подразумеваем, что в инете полно простых инструкций по настройке файрвола, что по умолчанию обычно всё закрыто на роутере и надо включать проброс портов, и в целом кто угодно может справиться с этой задачей имея квалификацию на порядок ниже моей. А вот как справиться ровно с той же задачей в случае IPv6 до сих пор до конца неясно ни мне, ни многим не менее квалифицированным инженерам в этом обсуждении. И это — факт. Нам — неясно. Хотя мы интересуемся, хотим и пытаемся разобраться, делали несколько подходов в эту сторону, и т.д. и т.п. Поймите уже наконец: то, что нам всем это сложно — это ФАКТ. То, что нет простых инструкций, как это решается — это ФАКТ. Не потому, что я так сказал, а потому, что это написано в куче комментариев в этом обсуждении.


                                                            А безопасность — это уже совсем другой аспект.

                                                            Не другой, а основной. Я без проблем могу настроить IPv6, проблема только в том, что я не могу настроить его с уровнем безопасности эквивалентным моим текущим настройкам для IPv4 не потратив на это несколько недель, которых у меня на это просто нет.


                                                            Не нужны прямые коннекты — возьмите и настройте файрвол на роутере. iptables умеете же? 6tables то же самое. NAT же — это не защита, это не firewall.

                                                            Согласен насчёт NAT. А насчёт "возьмите и настройте" — проблема именно тут. IPv6 сложный. IP-адреса меняются динамически, выдаются множеством способов, у одного хоста их одновременно кучка выданных по-разному, что и как можно блокировать в ICMPv6 вообще неясно, насколько безопасно всё это не блокировать тоже неясно, к чему может получить доступ или что переконфигурировать в сети случайно залетевший пакет — неясно… И, снова это повторю, нет простых инструкций как всё это решать: как построить максимально закрытый файрвол, учитывающий все возможные фичи IPv6, как в нём открывать точечный доступ к отдельным сервисам в локалке, как в нём открывать точечный доступ к динамическим сервисам в локалке (те самые игры), etc.


                                                            Единственное решение этой проблемы, которое я пока услышал — каждый хост должен файрволить себя самостоятельно, открывая только те порты, которые считает необходимым. Это звучит разумно, но только на первый взгляд. На второй выясняется, что у нас банально нет возможности заставить каждую кофеварку адекватно защищать себя файрволом, что часть ресурсов должна быть доступна — но только из локалки… и в результате мы всё-равно возвращаемся к тому, что единственный рабочий вариант — это настроить файрвол на шлюзе между инетом и локалкой. А как его настраивать, чтобы было не менее безопасно чем в v4… ответа пока нет.

                                                              +1
                                                              не потратив на это несколько недель, которых у меня на это просто нет.
                                                              Такой набор правил полностью соответствует NAT:
                                                              ip6tables -P FORWARD DROP
                                                              ip6tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
                                                              ip6tables -A FORWARD -m conntrack --ctstate NEW -i $LAN -j ACCEPT
                                                              Порты "пробрасываются" только на неизменный IPv6-адрес и плевать сколько их у системы. А правильным решением для IPv6 является фильтрация всех входящих пакетов на порты 0-49151. Остальные порты предназначены для открытия соединений и естественно должны фильтровать TCP-стеком или программой.

                                                              что и как можно блокировать в ICMPv6

                                                              #пакеты из локалки, их фильтрация чревата полной потерей связи.
                                                              ip6tables -A INPUT -s fe80::/10 -p ipv6-icmp -j ACCEPT
                                                              #без этих пакетов иногда будут проблемы, но вполне допустимо ставить лимиты
                                                              ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT
                                                              ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT
                                                              ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT
                                                              ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT

                                                                0
                                                                > А правильным решением для IPv6 является фильтрация всех входящих пакетов на порты 0-49151. Остальные порты предназначены для открытия соединений и естественно должны фильтровать TCP-стеком или программой.

                                                                1. Остальные порты не предназначены, согласно IANA, для динамической аллокации, но вполне предназначены для статической (программа явно запросила конкретный номер).

                                                                2. Эта конкретная рекомендация IANA очень плохо соблюдается. Например, на Linux умолчательный диапазон уже много лет как [32768..60999], и менять его они не собираются. Вы собрались зарезать всю работу под Linux?

                                                                Или вот я смотрю на свой Linksys SPA-942, у него диапазон портов для медии — 32768..49999. Нужно перестроить все подобные устройства?

                                                                Что-то ваша теория, мягко говоря, не выдержит первой встречи с тяжёлым предметом, который в вас кинут пользователи за попытку введения такой полиси…
                                                                  0

                                                                  Т.е. то, что Вы полностью заблокировали передачу ICMPv6 между локалкой и инетом — это норм и ничему мешать работать не будет?


                                                                  Ещё остался открытым вопрос как открывать отдельные ресурсы в локалке снаружи, учитывая что IPv6 этих ресурсов меняется и неясно, как его определять.

                                                                    0
                                                                    Неправильно выразился. Не локалки, а с link-local адресов, действительных только в рамках широковещательного домена. Ну можно попробовать пропускать только RA, NDP, MLD и те без которых сеть будет глючить(packet to big и т.д.). Но особого смысла в этом нет. Ожидаете ли Вы, что провайдер зашлёт Вам червя через дыру в IPv6-стеке? В отличии от IPv4 соседей в Вашем соединении с провайдером быть не должно, так как каждому клиенту нужно выдать отдельную сеть.
                                                                    Адрес основанный на МАК не меняется вообще. Меняются только временные, а на них ничего открывать не нужно и даже вредно. Стандартная NAT подобная политика им подойдёт.
                                                                      0
                                                                      Ожидаете ли Вы, что провайдер зашлёт Вам червя через дыру в IPv6-стеке?

                                                                      Честно? Ну, многие не ждали, что провайдеры будут вытворять то, что они прямо сейчас вытворяют. Я не готов строить безопасность сети на предположениях о том, чего сделает или не сделает провайдер. Тем более, что провайдер (в терминах прямого линка) не один — у меня и провайдеров два, и кучка VPN в разные компании поднята…


                                                                      Меняются только временные, а на них ничего открывать не нужно и даже вредно.

                                                                      Как я уже тут писал, попробуйте объяснить это всем тем сервисам и устройствам, которые по умолчанию уже слушают на :: и 0.0.0.0.


                                                                      Поэтому давайте вернёмся к исходному вопросу: как именно нужно настроить файрвол для IPv6 так, чтобы уровень безопасности был не ниже текущего?


                                                                      • Сеть должна быть полностью работоспособна, разумеется.
                                                                      • Из инета должен быть доступ только к тем сервисам в локальной сети, к которым он открыт на файрволе.
                                                                      • Из локалки должен быть полный доступ в инет.
                                                                      • Перенастройка "более безопасным способом" устройств и сервисов в локалке — не вариант, проконтролировать на каких интерфейсах слушает каждая умная лампочка и перенастроить её — нереальная задача, если мы говорим о массовом внедрении.
                                                                      • Требуемый уровень доверия провайдеру — нулевой, как и сейчас.
                                                                      • Ну и по мелочи всякое, защита от спуфинга (если она нужна в IPv6), поддержка протоколов вроде ftp/irc, fail2ban (что, таки банить подсетями /64?), etc.

                                                                      Ещё лично мне актуален вопрос как без NAT в IPv6 делается multihoming — те самые два вышеупомянутых провайдера — они же не просто так, а для резервирования, и оно должно продолжать работать. Что происходит с исходящим IPv6 машины в локалке когда пакет наружу уходит через резервного провайдера когда основной лежит? Точнее, как на этот IPv6 придёт ответ?

                                                                        0
                                                                        Мы вроде обсуждаем брандмауэр в роутере? Соответственно речь об открытии портов в брандмауэре только для постоянных адресов. Временными пусть занимается conntrack и никто не достучится до программы висящей на [::]. Защита будет не хуже чем у NAT.
                                                                        Требуемый уровень доверия провайдеру — нулевой, как и сейчас.
                                                                        ARP и DHCP от провайдера принимаете? Значит не нулевой. С тем же успехом можете доверять ICMPv6(fe80::/10 по крайней мере).
                                                                        Ну и по мелочи всякое, защита от спуфинга (если она нужна в IPv6),

                                                                        А как Вы защищаетесь с IPv4?
                                                                        поддержка протоколов вроде ftp/irc
                                                                        В Linux соответствующие модули conntrack реализованы. И они в общем то общие для протоколов IPv4 и IPv6.
                                                                        fail2ban (что, таки банить подсетями /64?)
                                                                        Да.
                                                                        Ещё лично мне актуален вопрос как без NAT в IPv6 делается multihoming
                                                                        В домашних условиях, никак. Но и NAT для IPv6 в общем то есть. И обычный и stateless 1 в 1.
                                                                          0
                                                                          ARP и DHCP от провайдера принимаете?

                                                                          ARP — возможно, по крайней мере я ничего там не перенастраивал. А что, это создаёт какую-то угрозу?
                                                                          DHCP — нет, все настройки статические. Точнее, по одному провайдеру статические, а второй через 4G-модем, так что модем-то принимает DHCP, но вот у меня локальный интерфейс в сторону модема настроен статически на 192.168.x.x.


                                                                          А как Вы защищаетесь с IPv4?

                                                                          Ручками выполняю работу rp_filter через iptables. Причина — с включенным rp_filter не работал OpenVPN.


                                                                          В домашних условиях, никак.

                                                                          О-па. Что так? Я как-то наивно полагал, что уж с этим-то проблем не будет, это-ж фича, а с фичами в IPv6 всё скорее излишне, нежели нехватка.

                                                                            0
                                                                            Доступ в сеть с гарантией доступности %99,999… это фича для бизнеса за много денег, а не для любителей видео с котиками. По дешману можно только VPN поднять и ходить через него. Так же в принципе узлы могут оптимизировать маршрут через MIPv6, но адекватной реализации оного почему то нет даже в Linux не говоря уже про тупые лампочки.
                                                                              0

                                                                              Ну почему же "для бизнеса" и "за много денег", с чего Вы так решили?


                                                                              У меня один канал 100Mbps за $5.6/mo и второй 4G за $3.6/mo. Настройку multihoming я лет 10 назад описывал на хабре (https://habr.com/ru/post/100919/), сейчас всё немного изменилось — но скорее упростилось, чем наоборот.


                                                                              Я фрилансер уже лет 20, для меня критично "не пропадать" в процессе работы, иначе заказчики начинают нервничать. Так что UPS который держит несколько часов и второй канал — это обязательное требование. Аккумулятор для UPS на 100ah стоит порядка $200 (гелевый, для квартиры) и его хватает лет на 5-8, что даёт ещё $3/mo.


                                                                              И вот скажите, что из всего этого так дорого или сложно, что делает это доступным только "для бизнеса" и "за много денег"?

                                                                      0
                                                                      Ещё остался открытым вопрос как открывать отдельные ресурсы в локалке снаружи, учитывая что IPv6 этих ресурсов меняется и неясно, как его определять.

                                                                      Если вы предоставляете сервис, проще всего серверу выдать статический IP. Автоконфигурация всё-таки предназначена для клиентов.

                                                                    +1
                                                                    Поймите уже наконец: то, что нам всем это сложно — это ФАКТ.

                                                                    Я с этим не спорю. Вы недостаточно знакомы с протоколом, он кажется сложным, непонятным и даже, возможно, страшным. Это не решить иначе, чем образованием.


                                                                    То, что нет простых инструкций, как это решается — это ФАКТ.

                                                                    Вот это уже не очень правда.


                                                                    Есть миллионы клиентов, и они работают. Есть те, кто эти внедрения обеспечил. Есть вендоры, которые сделали сетевое оборудование, включая CPE, имеющее разумные настройки по умолчанию. Я уже приводил в пример свой маршрутизатор. Причём, я его не выбирал специально, он в комплекте с контрактом шёл. Есть инструкции для домашних пользователей, они как раз простые. Есть тренинги для специалистов, например, тренинг RIPE для LIR, они сложнее. Есть немало книг, в том числе и бесплатных. Повторюсь, образование — лучший способ борьбы с воспринимаемой сложностью и неуверенностью.


                                                                    Ну, конечно, есть и те, кто распространяет FUD. Можно обсуждать, почему они это делают, но это из области психологии, а не сетевых технологий, а я в психологии не разбираюсь. Некоторые распространяют FUD грубо, некоторые — тоньше. Про них даже доклады делают: https://www.youtube.com/watch?v=GK6vl5z-8NY.


                                                                    Единственное решение этой проблемы, которое я пока услышал — каждый хост должен файрволить себя самостоятельно, открывая только те порты, которые считает необходимым.

                                                                    Нет. Типовое решение проблемы сейчас в SOHO — файрвол на CPE, по умолчанию пускающий всё изнутри наружу и не пускающий ничего, кроме связанного с уже установленными соединениями, снаружи внутрь.

                                                                      +1
                                                                      Потому что считать IP-адрес устройства, с которого оно будет рассылать в инет тьму пакетов (которые легко перехватываются как на уровне провайдеров, так и воруются с тех сервисов, на которые стучится устройство) как секретный токен — я категорически против

                                                                      Откуда вы это взяли? Никаких секретов. Просто по исходящим наблюдающий не может вывести постоянный адрес, на котором сидят слушатели. Ну засветился исходящий. Ну прилетел в эфемерный порт tcp-syn слева. Так он будет отброшен самой операционкой или прикладным слоем, потому что соответствующий сокет не открывал такое исходящее соединение.

                                                                      Когда мы говорим v4 — подразумеваем, что любая домохозяйка ставит себе роутер, который прикрывает её локалку от злобных хакеров в этих ваших интернетах.

                                                                      Когда говорим v6 — тот же роутер, только более высокого ценового класса. от 5000 рублей. Ну и надо помнить, что хакерам, ориентированным на домохозяек — пофиг v4 у нее или v6. Они оперируют социнженерией и фишингом — уровнями 8 и 7 OSI.

                                                                      А насчёт «возьмите и настройте» — проблема именно тут. IPv6 сложный. IP-адреса меняются динамически, выдаются множеством способов, у одного хоста их одновременно кучка выданных по-разному, что и как можно блокировать в ICMPv6 вообще неясно, насколько безопасно всё это не блокировать тоже неясно, к чему может получить доступ или что переконфигурировать в сети случайно залетевший пакет — неясно…

                                                                      В случае если у вас /64 — у вас RADVD на роутере и SLAAC. Это тупо «воткнул и не надо настраивать» со стороны клиентского узла. Альтернатива — статика. Да, есть DHCP6, но вы его встретите редко. Динамически меняются только исходящие адреса. А основной, на который можно достучаться у узла будет один и тот же.

                                                                      enp31s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
                                                                              inet 192.168.0.47  netmask 255.255.255.0  broadcast 192.168.0.255
                                                                              inet6 2001:470:1f0b:560:fd65:5cd5:765d:8513  prefixlen 64  scopeid 0x0<global>
                                                                              inet6 2001:470:1f0b:560:ccd:9da6:2b9e:2663  prefixlen 64  scopeid 0x0<global>
                                                                      

                                                                      сабнет — 2001:470:1f0b:560, постоянный — 2001:470:1f0b:560:ccd:9da6:2b9e:2663, он сформировался узлом самым первым.

                                                                      нет простых инструкций как всё это решать: как построить максимально закрытый файрвол, учитывающий все возможные фичи IPv6, как в нём открывать точечный доступ к отдельным сервисам в локалке, как в нём открывать точечный доступ к динамическим сервисам в локалке (те самые игры), etc.

                                                                      Так же как в v4 — вам даже написали выше. Дропаете все по умолчанию, что не разрешено явно в полиси, и что не инициировано изнутри. На уровне роутера.
                                                                      Я, правда, не понимаю прикладного смысла такой политики, но up to you.
                                                                        0
                                                                        Просто по исходящим наблюдающий не может вывести постоянный адрес, на котором сидят слушатели.

                                                                        А ничего, что большая часть существующих сервисов по умолчанию норовит слушать на :: и 0.0.0.0? Да, можно тыкать в них, говорить что они не правы, что каждый надо конфигурировать ручками на конкретный IP… но на практике полно обратного, и не все устройства в локалке в принципе возможно перенастроить. На практике вариант внедрения, который подразумевает необходимость проверки на каком адресе слушают все сервисы на каждом устройстве в локалке, обречён на отказ от внедрения.

                                                                          0
                                                                          А ничего, что большая часть существующих сервисов по умолчанию норовит слушать на :: и 0.0.0.0?

                                                                          абсолютно ничего. вы как-то параноидально предполагаете, что конечный или транзитный узлы будут слать пробы. много вы таких видели?
                                                              0
                                                              Пусть протокол определяет, что часть соединений будет входящими — локальный хост открыл сокет и передал его координаты куда-то, и ждёт ответа. Есть протоколы, где это важно (и мне рядом тут пытались проесть мозг какой-то игрушкой с фиксированным портом).

                                                              Хост хочет входящих сообщений, он открывает входящий файрвол — или локальный, или, если мы говорим про типовой SOHO сетап, на CPE через, например, UPnP. Хост делает исходящие соединения — он не открывает входящий файрвол.


                                                              Нужно ли слушать на temporary адресах, или нет, хороший вопрос. Он стоит обсуждения; можно, например, сделать это в IETF v6ops, если ранее это не обсуждалось.


                                                              Эта проблема вообще хотя бы озвучена в обсуждении SLAAC?

                                                              Эта и другие проблемы обнаружения v6 адресов озвучены в RFC7707.

                                                                0
                                                                > Хост хочет входящих сообщений, он открывает входящий файрвол — или локальный, или, если мы говорим про типовой SOHO сетап, на CPE через, например, UPnP.

                                                                Серьёзно? Учить все приложения, которые хотят хотя бы получить голосовой поток, UPnP? И обязательно держать такое на раутерах? Тогда, раз им нужна такая функциональность, это лишает 90% разрекламированных преимуществ по сравнению с NAT. Только трансляцию адресов не надо делать, всё остальное осталось так же. Ну и ещё вместо испытанных методов прохождения NAT (STUN, TURN) учить ещё один новый подход через UPnP.

                                                                > Эта и другие проблемы обнаружения v6 адресов озвучены в RFC7707.

                                                                Аж 4 года назад. Нормального решения за это время не предложили. Что ж, уже 1/4 прогресса сделано. Такими темпами решение будет где-то к 2032?
                                                                  0
                                                                  Учить все приложения, которые хотят хотя бы получить голосовой поток, UPnP?

                                                                  Во-первых, да, можно научить приложение, научили же костылям в виде STUN. Во-вторых, можно не учить приложение, а обеспечить поддержку на уровне операционной системы, как это уже сделано в Windows. А поддержка UpnP в SOHO CPE уже есть практически повсеместно. В третьих, можно пользоваться локальным файрволом.


                                                                  Тогда, раз им нужна такая функциональность, это лишает 90% разрекламированных преимуществ по сравнению с NAT.

                                                                  Это пример так называемого вранья. Связанность никуда не исчезает от появления файрвола.


                                                                  Такими темпами решение будет где-то к 2032?

                                                                  Это очень пафосно, но решение уже есть и работает.

                                            0
                                            1. Провайдер выдал /56 (хороший, добрый провайдер).

                                            Статика или DHCP-PD?
                                            2. Как этот же шлюз передаст информацию о выданной сети на раутер отдела, который будет выдавать уже /64 на отдел.

                                            DHCP-PD
                                            3. Что будет, если провайдер сменит этот адрес: как он пришлёт нотификацию, как она пробежится вниз до каждого конкретного компа/телефона/etc, заставляя их сменить адрес.

                                            Кстати интересный вопрос, надо будет проверить на досуге, но скорее всего большая часть производителей не рассчитывала на такой вариант.
                                            4. Как эта смена адреса будет отражена в DNS, поддерживаемом этими раутерами/шлюзами, а также в других средствах вроде Active Directory, если им это нужно.

                                            Тут увы я бессилен, с виндовой инфраструктурой к счастью не приходилось работать. Хотя сдаётся мне что для компании получать от провайдера динамику — признак плохого тона. 99% проблем решится договорённостью с провайдером на статику.
                                            Варианты с домашним устройством дороже 100$ или SOHO дороже 300$ не принимаются. Варианты, где оповещение вниз вплоть до каждого аппарата (компа, телефона, принтера, умного дверного замка...) не раздаётся, и он тормозит часами, прежде чем перезапросить адрес — тоже.

                                            Не знаю как в в длинка/тплинках/etc, в микротике (что забавно он попадает и до 100$ и больше 300$, ибо ось одна на всех) можно настроить время делегирования префикса, опять же нужно проверить на практике, есть у меня большая уверенность что микротик разошлёт всем в сети новый префикс.
                                              0
                                              > DHCP-PD

                                              Это реально работает, что корневой DHCP сервер передаёт подчинённому, а тот — пинает уже своих листовых подчинённых?

                                              > Кстати интересный вопрос, надо будет проверить на досуге, но скорее всего большая часть производителей не рассчитывала на такой вариант.

                                              Вот как раз я слышал про фиаско поиска такой возможности. А это значит, что динамика тут не работает.

                                              > можно настроить время делегирования префикса

                                              Нужно не время делегирования, а прямой пинок всем, а то и с повторами.

                                              И это я ещё не поднял тему пропинать всех внутри OS (что, если, как сейчас чуть менее, чем все, держат всякие websocket?)
                                                0
                                                Нужно не время делегирования, а прямой пинок всем, а то и с повторами.

                                                А какой протокол так делает?

                                                  0
                                                  См. соседний ответ.
                                      +5
                                      Именно так. Имел аналогичный опыт в настройке микротика, с попыткой прогнать всё это через туннельного брокера. Я совершенно не понимаю комментаторов, которые говорят что «настраивается в 2 клика», рассуждая с точки зрения обывателя

                                      Немного нытья, почему я выпилил нафиг IPv6 из своей небольшой сетки:
                                      1. Совершенно нечитабельные и не запоминаемые адреса. Зайти на удалённую машину вбивая IPv6 руками? Нет, спасибо. Продиктовать его кому-то по телефону? Селестия упаси.
                                      Гораздо проще настроить локальный DNS, но делать это для каждого ресурса совершенно нет желания.
                                      2. Непонятность принципов работы. Я использовал туннельного брокера для получения глобальной подсети, и надеялся что при небольших усилиях смогу получать доступ к определённым ресурсам внутренней сети извне.
                                      Однако реальность была другого мнения. Машины сами назначают себе случайные адреса, маршрутизатор раздаёт адреса, но они не работают извне, raspberry pi вообще отказалась адекватно взаимодействовать с IPv6, выдавая ошибку при попытке обновления.
                                      3. Общая сложность наворотов технологий. Как настроить фаерволл, шоб не накосячить? Как настроить маршрутизацию с внешними сетями? Какие это вообще даёт преимущество лично мне, как «SOHO администратору»?

                                      Я не пытаюсь кого то убедить что IPv6 это плохо, просто рассказываю своё видение как «не специалиста по сетевым технологиям» а как «немного шарящего в сетях чувака»
                                        +1
                                        Я совершенно не понимаю комментаторов, которые говорят что «настраивается в 2 клика», рассуждая с точки зрения обывателя

                                        Ну начнём
                                        1. Совершенно нечитабельные и не запоминаемые адреса. Зайти на удалённую машину вбивая IPv6 руками? Нет, спасибо. Продиктовать его кому-то по телефону? Селестия упаси.

                                        Ну такая себе претензия, DynDNS никто не отменял, думаю в ближайшее время появится такой функционал у большинства девайсов.
                                        2. Непонятность принципов работы. Я использовал туннельного брокера для получения глобальной подсети, и надеялся что при небольших усилиях смогу получать доступ к определённым ресурсам внутренней сети извне.
                                        Однако реальность была другого мнения. Машины сами назначают себе случайные адреса, маршрутизатор раздаёт адреса, но они не работают извне, raspberry pi вообще отказалась адекватно взаимодействовать с IPv6, выдавая ошибку при попытке обновления.

                                        Адреса у вас скорее всего раздались по SLAAC, при таком варианте устройство получает 2 адреса, один постоянный на основе MAC адреса (EUI-64), второй сгенерированный рандомно и сменяемый с некоторым интервалом.
                                        Про «не работали извне», либо у вас некорректно настроен файрвол на маршрутизаторе, либо на хосте. Либо и там и там.
                                        3. Общая сложность наворотов технологий. Как настроить фаерволл, шоб не накосячить?

                                        Да так-же как в ипв4. Разрешить ICMP и входящий трафик для ESTABLISHED/RELATED соединений. Ну и по желанию открыть полный доступ к хостам имеющим свой файрвол, либо для каждого хоста прописывать правила для портов/протоколов на роутере.
                                        просто рассказываю своё видение как «не специалиста по сетевым технологиям» а как «немного шарящего в сетях чувака»

                                        Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.
                                        Собственно говоря настройка файрвола на IPv4 и IPv6 ничем не отличается, просто у вас никогда небыло своей хотя бы /24 белой в IPv4 которая маршрутизируется глобально. Скорее всего вы всю жизнь считали что NAT это файрвол и он защищает всю вашу сеть, что в корне неверно
                                          +2
                                          Настроить банальную маршрутизацию — это НЕ админские задачи, максимум — уровень эникейщика. С IPv4 проблем в этом плане никогда не было, как и с фаерволлом для него.

                                          Согласитесь, чтобы установить роутер в квартиру и сделать «шоб работало» — это уровень домохозяек, но никак не эникейщиков.
                                          В данном случае, мы перепрыгиваем с уровня домохозяйки на уровень полноценного админа, для выполнения довольно банальной задачи.
                                          Мне кажется, это совершенно не приемлимо как в плане безопасности, так и для юзабилити системы в целом
                                            0
                                            Настроить банальную маршрутизацию — это НЕ админские задачи, максимум — уровень эникейщика. С IPv4 проблем в этом плане никогда не было, как и с фаерволлом для него.

                                            Банальную это прописать шлюз? В таком случае естественно это не админские задачи, вот только про это я ничего и не писал, с чего вы начали переводить стрелки?
                                            Согласитесь, чтобы установить роутер в квартиру и сделать «шоб работало» — это уровень домохозяек, но никак не эникейщиков.

                                            Установить роутер и включить получение адреса по DHCP одинаково легко для домохозяек как для ipv4, так и для ipv6. Выше спрашивали про более сложные конфигурации, выходящие за пределы «домашнего» использования.
                                            +2
                                            > Ну такая себе претензия, DynDNS никто не отменял, думаю в ближайшее время появится такой функционал у большинства девайсов.

                                            IPv6 — 26 лет. Новое поколение выросло. Где функциональность?

                                            Но DNS — это тут не ответ. Как только начинаются реальные проблемы «только где же этот кто-то и куда он мог залезть?» — начинается поиск на уровне IP адресов. И вот тут-то оно и стукнет. Запомнить среднему админу даже пару десятков IP адресов не проблема. А v6?

                                            > Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.

                                            Ну я админом разных уровней, вплоть до CTO провайдера, был 10 лет, так что представляю себе.
                                            Да, проблем не так много по их чисто количеству — длинные адреса, дублирование адресных пространств, сложность одновременной поддержки DHCPv4 и RAv6 (если кому-то нужно), дублирование в DNS (и необходимость управления логики резолвинга), шлюзы адресаций, всё назвал? Но каждая сама по себе бьёт достаточно серьёзно.
                                              0
                                              IPv6 — 26 лет. Новое поколение выросло. Где функциональность?

                                              А кто его за последние 26 лет торопился внедрять и тестировать в массах? По вашему IPv4 на старте не имел проблем и там всё сразу было?
                                              Но DNS — это тут не ответ. Как только начинаются реальные проблемы «только где же этот кто-то и куда он мог залезть?» — начинается поиск на уровне IP адресов. И вот тут-то оно и стукнет. Запомнить среднему админу даже пару десятков IP адресов не проблема. А v6?

                                              У админа пара триллионов серверов в сети? Запомнить пару десятков адресов точно так-же просто. Если у вас проблемы с запоминанием — это не проблема протокола.
                                              Все проблемы что вы перечислены чисто надуманные и относятся к разряду «я привык на ipv4 и нафиг мне ваш ipv6, чего вдруг я должен что-то ещё изучать и понимать для внедрения?». Хотя там все новшества изучаются за один вечер неспешно.
                                              Нужно дождаться массового внедрения (хотя бы 50% мирового трафика) и поддержки у 80% производителей софта/железа, тогда уже можно будет говорить о реальных проблемах, а не об этих детских придирках.
                                              Лично у меня пока никаких проблем не возникает с внедрением IPv6 (кроме тугих провайдеров не желающих разбираться).
                                                0
                                                > А кто его за последние 26 лет торопился внедрять и тестировать в массах? По вашему IPv4 на старте не имел проблем и там всё сразу было?

                                                Проблема с миграцией адресов в сети по сигналу от провайдера — не требует какого-то особого «тестирования». Она понимается любым, кто хотя бы 5 минут спокойно посидит подумает над проблематикой и захочет решать осмысленно, а не затыканием дырки — и, кстати, неоднократно озвучивалась ещё в 90-е. Но ни вендоры, ни IETF оказались не заинтересованы в минимальном предвидении хотя бы на полшага вперёд.

                                                > Все проблемы что вы перечислены чисто надуманные

                                                Ни капельки. Даже проблема размера адреса это следствие известного правила «7±2»: v4 адрес ещё влезает в объём запоминаемого одной порцией, v6 — уже надо специально дробить на части и применять особые мнемотехники. Это, да, не юзерам (большинству) головная боль, это админам.
                                                Если вы лично от этого не страдаете — считаем, вам повезло.

                                                > Хотя там все новшества изучаются за один вечер неспешно.

                                                «Изучить новшества» да, можно за один вечер. Но от этого до реальной практики — километровая пропасть.

                                                > а не об этих детских придирках.

                                                Вот эти «детские придирки» и начали реально выстреливать на вопросе того же использования NAT.
                                                  0
                                                  Она понимается любым, кто хотя бы 5 минут спокойно посидит подумает над проблематикой и захочет решать осмысленно, а не затыканием дырки — и, кстати, неоднократно озвучивалась ещё в 90-е. Но ни вендоры, ни IETF оказались не заинтересованы в минимальном предвидении хотя бы на полшага вперёд.

                                                  Если вендоры и IETF не приняли это за проблему то тут два варианта
                                                  1) Это действительно не проблема
                                                  2) Это проблема касается крайне малого процента людей и видимо вызвана изначально неправильной структурой сети.
                                                  Вот эти «детские придирки» и начали реально выстреливать на вопросе того же использования NAT.

                                                  Понятно, я походу общаюсь с толстейшим троллем который даже понимать не хочет зачем IPv6 был создан. А одна из причин его появления это полный отказ от NAT, который вообще появился как костыль на половине жизненного пути IPv4
                                                    +2
                                                    > Понятно, я походу общаюсь с толстейшим троллем который даже понимать не хочет зачем IPv6 был создан.

                                                    Вы общаетесь с тем, кто 1) наблюдал ещё очень ранние шаги и хайп по поводу будущих перспектив IPv6, 2) в отличие от (похоже на то) большинства присутствующих, читал не только отдельные финальные RFC, но ещё и обсуждения и мотивации, а также плотно наблюдал несколько попыток радостного внедрения, с их последствиями.

                                                    Эмоции мне ваши пофиг, так что про тролля можете не фантазировать. А вот ответы на возникшие вопросы, неожиданные интересные мысли — очень даже, но, видимо, их тут уже не будет.

                                                    > А одна из причин его появления это полный отказ от NAT

                                                    Верно — в детских фантазиях его первых авторов так и было бы. Но это было ещё в том интернете, где не было ни спама, ни хакеров в нынешнем количестве, и где вообще защищаться ни от чего не было нужно (а червь Морриса пробежал и был прочно забыт, как курьёз), и даже «два Bay» ещё не взрывались. Для нынешнего мира все эти наивные мечтания не годятся в принципе.

                                                    > Это проблема касается крайне малого процента людей

                                                    Верно, те, кто сейчас может наткнуться на такую проблему — вытребывают статические адреса. Но это пока не началось реально широкое распространение за пределы мобильщиков и прочих чисто-end-user групп плюс высоких корпоратов.

                                                    > и видимо вызвана изначально неправильной структурой сети.

                                                    Да-да, плавали, знаем. «У вас кривые руки» на любое отклонение от генеральной линии партии, 640KB хватит всем, а пони розовые и летают. Заранее прошу: если нет конструктивных ответов — не увеличивайте локальную энтропию.
                                                      0
                                                      Скрытый текст
                                                      Вы общаетесь с тем

                                                      я правильно понимаю, то с модератором RU.UNIX.PROG?


                                                      Но это было ещё в том интернете, где не было ни спама, ни хакеров в нынешнем количестве, и где вообще защищаться ни от чего не было нужно

                                                      только причём тут NAT, это уже раз 20 обсуждалось вроде бы в комментариях к этому посту, что это решается firewall'ом (частью которого может являться NAT; а может и не являться).


                                                      но NAT нужен, кто же спорит.
                                                      например, когда мне нужно дать доступ из какой-то сети со своими адресами к интернету, и нет желания/возможности договориться с провайдером о маршрутизации адресов этой сети.

                                                        +2
                                                        Скрытый ответ
                                                        > модератором RU.UNIX.PROG
                                                        Да.
                                                        Только что толку, если последний активный тред в ней был 2 года назад, а предпоследний — летом 15-го.
                                                        Ну, могу постить в неё копии заметок из блога, поможет?


                                                        > только причём тут NAT, это уже раз 20 обсуждалось вроде бы в комментариях к этому посту

                                                        И я дважды отвечал на это, что никакой файрволл без NAT не даст сокрытия внутренней структуры сети и корреляции между её участниками, и что это может быть реально критично для многих.
                                                        Остальные 18, или около того, я уже не комментировал, но от этого идея выставить ну не голую попу, а попу под стеклом, всё в тот же Интернет — лучше не становится.

                                                        > но NAT нужен, кто же спорит.

                                                        И не только в том случае, что вы вспомнили.
                                                        Он должен поддерживаться и быть штатно доступным.
                                                        Случай, что вы описали, тоже показателен.
                                                          0
                                                          Скрытый текст
                                                          Ну, могу постить в неё копии заметок из блога, поможет?

                                                          нет, конечно.
                                                          fido мёртв, кто же с этим спорит.
                                                          но именно профессиональные эхи мне жалко.


                                                          P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
                                                          нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )

                                                            0
                                                            > но именно профессиональные эхи мне жалко.

                                                            RU.UNIX.BSD на удивление живая. Но там ветераны :)
                                                            Для RU.UNIX.PROG таких не нашлось, а следующее поколение думает уже на другом уровне и другими категориями — это типа тех, кто только Linux, но с nodejs в контейнере. Им та тематика тупо не нужна.

                                                            > P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
                                                            нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )

                                                            Вопросов не задают. А сгружать весь stackoverflow в него как-то некошерно.
                                        +2
                                        Неужели NAT такой весь из себя злой и ужасный? Мне кажется у него есть очень большой плюс в качестве барьера от внешних угроз внутренним сетям. Что IPv6 может предложить в этом плане? Плоская всемирная сеть хорошая идея для идеального мира. В реальности концепция приватных сетей находит большое применение.
                                          +4
                                          NAT это просто сломанная связанность между хостами. С таким же успехом можно просто перерезать провода и сказать что это ещё более безопасно (и с этим тоже не поспорить). Для безопасности всю жизнь предполагалось и предполагается использовать firewall. Правило блокирующее внешние подключения к хостам локальной сети наверное в большинстве firewall-ов занимает одну строку.
                                            +3
                                            В том-то и дело, что блокировать всё подряд — легко. А если всё-таки некоторые доступы нужны? А у нас всё подряд автоматически раздаёт себе адреса, а то и здоровенные диапазоны, пингует всё вокруг по ICMPv6, мультикастом и т.д.?

                                            Я умом понимаю все те плюсы, которые перечислены. Но с точки зрения обеспечения безопасности и настройки фаерволла, который делает нечто большее, чем блокирует входящие подключения — глаза пока ещё боятся, если честно.
                                              +2
                                              А чем настройка разрешения доступа на firewall будет отличаться от настройки прокидывания портов на NAT? И там и там по одной строчке правил, грубо говоря. NAT никогда не избавлял от firewall-а и необходимости его настройки.
                                                +9
                                                Кажется, что основной плюс NAT — то, что его «из коробки» тяжело приготовить небезопасно. Если домашняя сеть сидит за NAT, то производитель роутера не может легко и непринуждённо решить, что «а все входящие запросы мы направляем вот этой конкретной машине» и выставить её тем самым голым фронтом в интернет, проброс портов — это всё же осознанное действие, направленное на конкретные машины и конкретные порты. В то же время с v6 простое и в целом естественное решение для производителя роутера — направлять все входящие запросы по соответствующим айпи и тем самым да, создать проблемы с безопасностью. Действительно, если роутер из коробки будет иметь правило «все входящие рубить на роутере», а для внешнего доступа надо будет руками открывать конкретный порт к конкретной машине, то это ничем особо не будет отличаться от NAT с точки зрения безопасности, но у меня как-то нет уверенности, что все производители домашних роутеров будут вести себя именно так.
                                                  0
                                                  В то же время с v6 простое и в целом естественное решение для производителя роутера — направлять все входящие запросы по соответствующим айпи и тем самым да, создать проблемы с безопасностью.

                                                  Самое естественное решение — дропать по умолчанию все соединения извне внутрь. Собственно, так производители SOHO маршрутизаторов и поступают.

                                                    0

                                                    Ну т.е. с одной стороны декларируется (автором статьи, как минимум) "настоящий" Интернет, а с другой стороны мы прикрываемся магией conntrack, который должен определить какой UDP/ICMP/другой левый не-TCP-протокол пакет относится к мифическому "соединению", а какой нет? И для корректной работы которого хотя бы с некоторыми известными ему протоколами нужно ещё не забыть собрать и подгрузить модули-helper-ы.

                                                      0
                                                      На мой взгляд обычному пользователю в роутере проще тыкнуть что к этим 2 компам(т.к. у каждого есть свой внешний ip) будет доступ по ftp. Чем заморачиваться, что входящие запросы на порт 20 и 21 ты переадресовывай на порт 20 и 21 на компьютер А, в запросы на порты 22 и 23 на порты 20 и 21 на комп Б, а потом ещё надо SSH прокинуть, а порт 22 ты уже заюзал, «ой ай аяяйай», а потом ещё на клиентах порты менять…
                                                        0
                                                        Так 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 — тут уже второстепенное.
                                                        0
                                                        Ну т.е. с одной стороны декларируется (автором статьи, как минимум) "настоящий" Интернет, а с другой стороны мы прикрываемся магией conntrack

                                                        Сдесь была дискуссия о том, что NAT — не инструмент безопасности. Межсетевой экран — инструмент безопасности. Межсетевой экран можно выключить, если хосты сами будут заниматься фильтрацией трафика. NAT выключить нельзя. Вот в этом разница.


                                                        Положим, есть Маша и Петя, живущие вместе и любящие он-лайн игры. Для он-лайн игры нужно открыть какой-то конкретный порт на вход, туда будет литься трафик. Как такая схема реализуется с NAT?

                                                          0
                                                          > Для он-лайн игры нужно открыть какой-то конкретный порт на вход, туда будет литься трафик. Как такая схема реализуется с 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 в полный рост: если там файрволлы с обеих сторон и их нельзя изнутри убедить «впусти мне входящие и дай свой адрес» — связи не получится.
                                                            0
                                                            С этого порта изнутри открывается исходящее соединение, по которому будет вливаться поток.

                                                            Как это будет работать, если Маша и Петя играют одновременно и им одновременно нужен один и тот же порт?

                                                              0
                                                              В каком смысле «один и тот же порт»?
                                                              Если вы имеете в виду соединение с разных внутренних адресов на один и тот же удалённый адрес, то 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, чтобы не плавать настолько в азах.
                                                              Если вопрос в чём-то другом — сформулируйте так, чтобы его можно было понять.
                                                                0

                                                                Нет, Маша и Петя должны получать трафик на порт 5000 одновременно.

                                                                  0
                                                                  Повторю:

                                                                  >> Если вопрос в чём-то другом — сформулируйте так, чтобы его можно было понять.

                                                                  О каком порте 5000 на каком из хостов идёт речь? Пожалуйста, формулируйте сразу так, чтобы не надо было вытягивать подробности клещами.
                                                                    0

                                                                    Повторюсь:


                                                                    Маша и Петя, живущие вместе и любят он-лайн игры. Они хотят играть одновременно. Для он-лайн игры нужно открыть какой-то конкретный порт на вход (например, 5000), туда будет литься трафик извне. То есть, этот порт должен извне быть 5000 потому, что другие игроки будут туда отправлять трафик. Этот порт внутри тоже будет 5000 потому, что их игра слушает на этом порту.


                                                                    Как это сделать с NAT?

                                                                      0
                                                                      Вы всё ещё не можете чётко сформулировать задачу, но, насколько я смог расшифровать эту постановку… как говорится, вы или крестик снимите, или трусы наденьте.

                                                                      Если у онлайн-игры сервер _снаружи_ локалки Маши и Пети, то ситуации типа «игра слушает на этом конкретном, заданном жёстко самой игрой, порту» не бывает. Клиентская сторона никогда не фиксирует у себя конкретный порт, она полагается на аллокацию операционной системой динамического номера порта, и или открывает одно соединение с этого порта, или, если ей нужны дополнительные соединения, передаёт уже полученный порт другой стороне или серверу. Времена, когда фиксировали клиентские порты, закончились вместе с первыми опытами жизни FTP в гетерогенной среде (и не только из-за NAT), то есть это не позже середины 90-х. Сейчас просто нет таких требований.

                                                                      (Исключение: есть игры, которые для сетевого режима используют один и тот же порт для всех участников и бродкастят сообщения. Но это работает только в пределах одного L2 сегмента, не масштабируется на большее количество, и я не видел такого со времён первой халвы: кажется, последний, что такое умел, был Duke3D. А, может, ещё раньше закончилось, память уже теряет такие подробности.)

                                                                      Если кто-то из Маши и Пети поднял у себя в локалке _сервер_ игры, то у них будет один сервер. Именно для этого сервера строится явное правило статической трансляции внутрь: все входящие соединения на порт 5000 перебрасываются на указанный внутренний адрес на порт 5000. Эта возможность присутствует даже на мелких домашних раутерах, начиная со знаменитого DI-604, и тем более на любых более продвинутых средствах. Для внутреннего получателя его IP будет внутренним, но IP другой стороны — мировым (если это не в его локалке). Исходящие пакеты от него будут транслироваться с заменой адреса отправителя на установленный настройкой внешний адрес.

                                                                      Второй участник (предположим, что сервер у Маши — тогда это Петя) может подключаться к серверу Маши или по внутреннему адресу, или по внешнему — это на большинстве мелких раутеров тоже работает.

                                                                      Если Маша и Петя хотят каждый у себя поднять по серверу… да, в этом случае им надо будет прописать разные порты в конфигурации статического NAT — и это ничем не будет отличаться от ситуации, например, выделенного сервера в ДЦ с одиночным IP и двумя процессами сервера игры на разных портах.

                                                                      Если я всё ещё не угадал… ну пока у меня есть настроение — можете ещё покрутить, но лучше вы всё-таки научитесь формулировать так, чтобы было понятно с первого раза. Достаточный набор терминов для этого или присутствует в базе IP (хост, порт), или мной уже несколько раз упомянут в описании NAT (как внутренний, внешний и удалённый адреса).
                                                                        0

                                                                        Нет, это не сервер. Это многопользовательские игры, в которых для уменьшения RTT клиенты могут общаться друг с другом напрямую.


                                                                        Такой длинный ответ вместо простого "нет".


                                                                        Ясно, спасибо.

                                                                          +1
                                                                          > Нет, это не сервер. Это многопользовательские игры, в которых для уменьшения RTT клиенты могут общаться друг с другом напрямую.

                                                                          «Это» это где? В том, что вы хотели получить? Ну тогда это случай варианта 1 из моего описания, с некоторой дополнительной службой, которая оповещает участников об адресах друг друга, но дальше они взаимодействуют напрямую. И при этом ни хосты, ни порты не фиксируются, а определяются через эту службу имён.

                                                                          > Такой длинный ответ вместо простого «нет».

                                                                          Если ответ сократить до одного слова, то это «да». Но вы его не поняли.

                                                                          > Ясно, спасибо.

                                                                          Таки не за что. У меня не сработал /dev/telepathy, а вы не захотели ни объяснить, ни понять. Что ж, с таким я бессилен. Другие, надеюсь, захотят.
                                                                            0

                                                                            И всё таки ответ "нет".
                                                                            Пример. MMORPG, у которой сервер работает только как сервер авторизации, остальная связность работает как огромная mesh-сеть, где теоретически каждый может быть связан с каждым, на практике образуются ячейки связанных между собой игроков. Каждый из компов игроков — это тоже сервер по сути. И их может быть десятки тысяч. Если у кого-то сетевые проблемы, то ответ техподдержки категоричен и вынесен в FAQ — получите выделенный белый "адрес" и откройте порт XXXX на входящие соединения. Как, нас не волнует.
                                                                            И вот как раз с территории бывшего уже, я так понимаю, СНГ, больше всего стонов "мой провайдер белые адреса принципиально не выдает, что мне делать?" И стандартный ответ, "поздравляем, похоже вы зря потратили на игру своё бабло".

                                                                              +2
                                                                              Понятно. То есть со всего огромного игрового мира нашлись какие-то шизанутые ламеры-ретрограды, которым принципиален конкретный номер порта… да, в таком случае чистая возможность получить больше адресов становится полезным.
                                                                              (Но, поднявшись над конкретной проблемой, это выглядит примерно такой же дикостью, как если бы они потребовали держать связь по UUCP поверх диалапа и Netware на узлах.)
                                                0
                                                А потом следить за актуальностью софта на каждом хосте, чтобы его не взломали (к примеру, какие-нибудь дешевые камеры)? Вы утрируете, говоря, что NAT «это просто сломанная связность» — для большого количества кейсов это удобный механизм как с точки зрения безопасности, так и удобства настройки.
                                                  0
                                                  Не спорю что сломанная связанность может быть удобна в каких-то случаях. Но это остаётся сломанной связанностью.
                                                    0
                                                    Это вы назвали эту связность «сломанной». Можно назвать ее, например, «непрямой», или «усложненной». Сломанная — это если бы вообще не работала. Несимметричные маршруты, неоптимальные маршруты, низкие MTU и пр. — вы тоже назовете «сломанной связностью»?
                                                      0
                                                      Можно назвать полудуплексной. В одну сторону соединяться можно, в другую нет.
                                                        +2
                                                        Тогда она формально симплексная, что значит — в одну сторону. Полудуплексная — это когда стороны чередуются :)

                                                        Про ценность такой односторонности уже написал рядом.
                                                        Но, кроме того, NAT позволяет скрыть: количество хостов внутри сети, их группировку по сетям; группировку запросов по их источникам (до хоста); связность между запросами во времени (приходят с одного хоста или с разных). Для какого-нибудь фейсбука это, безусловно, зло — он хочет отслеживать каждого юзера отдельно. Но для клиента, которому реально надо хоть немного параноить, это безусловное благо. Потому NAT будет сохраняться и для IPv6, независимо от доступности адресов — и я бы его рекомендовал всем, по этим же причинам.
                                                          0
                                                          И проблема трекинга уже сейчас решается выдачей по 2 адреса через SLAAC:
                                                          — «белого» для входящих соединений
                                                          — «серого» периодически реролящегося для исходящих соединений.
                                                            0
                                                            > «серого» периодически реролящегося для исходящих соединений.

                                                            То есть те соединения, которым нужно долговременное существование, будут постоянно обрываться и клиентская система должна будет их пересоздавать? Вы серьёзно?
                                                              0
                                                              Нет не обрываются. Временные адреса при наличии привязки к ним хоть одного сокета, будут жить вечно. Но в таком случае существует риск, что из за какого то приложения, система захапает тысячи адресов.
                                                                0
                                                                > Но в таком случае существует риск, что из за какого то приложения, система захапает тысячи адресов.

                                                                Или из-за многих разных :)
                                                                Ответ понятен, спасибо. Как решение в принципе это может работать, да. Но откровенно выглядит как «на какое только извращение люди не пойдут, чтобы только не использовать уже проверенные годами технологии». :crash:
                                                                  0
                                                                  Или, в случае v4, затрэшит табличку трансляции.
                                                                    0

                                                                    Windows 10. Хром и открытые на фейсбук закладки. А если есть одновременно и IPv6, и IPv4, то винда по умолчанию всегда использует IPv6. Через сутки количество временных адресов на интерфейсе переваливает за сотню. Именно из работы этого механизма в сочетании с забавным механизмом доставки push-сообщений.
                                                                    Вообще, противники IPv6 в чем-то правы, граблей по нем раскидано немеряно, и, хотя жить они в общем не мешают, по крайней мере обычному пользователю, которому всё равно, что там работает транспортом, но сетевикам про эти нюансы лучше знать.

                                                                    0
                                                                    Подробности в RFC.
                                                                    От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма. А то, что соединения постоянно обрываются, — так это вы сами придумали.
                                                                      0
                                                                      > А то, что соединения постоянно обрываются, — так это вы сами придумали.

                                                                      Ну вы сами сказали про 2 адреса, а не произвольное количество :) Единственный вывод. Если недоговариваете — будьте готовы к подобному. RFC почитаю на досуге, спасибо.

                                                                      > От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма.

                                                                      Для v4 это тоже уже много лет как норма. Вопрос в том, как между ними распределять роли.
                                                                      Я так полагаю, за счёт чего-то определяется, что на один адрес соединения вешаются по умолчанию, а на второй — только явным указанием в bind()? Если да — можете не отвечать, найду в тех же RFC. Но если нет — то прямо работать не будет.
                                                        0
                                                        Что за смех? Миллионы домохозяек будут сидеть и править iptables? Nat в нынешних реалиях это скорее благо, нежели зло. Можно сидеть на уязвимом во все дыры тп-линке и не париться.
                                                        NAT это просто сломанная связанность между хостами

                                                        И да, что конкретно ломает домохозяйкам (подавляющему большинству пользователей сети)?
                                                          +4
                                                          > NAT это просто сломанная связанность между хостами.

                                                          Односторонне ограниченная, а не сломанная. Про перерезанный провод — спишем на полемический задор.

                                                          > Для безопасности всю жизнь предполагалось и предполагается использовать firewall.

                                                          Это вы рассматриваете единственный аспект безопасности — отсутствие возможности прямого несанкционированного доступа извне.
                                                          Почему вы игнорируете, например, необходимость сокрытия внутренней структуры, количества хостов, группировки размещений сервисов, связи между запросами разных клиентов?

                                                          Кроме безопасности: как вы будете отражать факт смены адресов провайдером так, чтобы это прошло прозрачно для пользователей? Минимум потребностей я описал тут, причём не уверен, что не пропустил ничего важного.
                                                          +3

                                                          NAT никак не изолирует внутреннюю сеть от подключения извне. https://habr.com/ru/post/402187/#comment_18100189


                                                          От внешних угроз защищает фаервол.

                                                            +1
                                                            Не совсем так. Вот смотрите, есть сеть1 и сеть2, есть роутер видящий обе эти сети. Сети никак не связаны. Что в данном случае защищает сеть1 от сети2? Никаким фаерволом там не пахнет. Теперь добавляем между сетями NAT — теперь у нас есть частичная связь, например сеть1 может отправлять запросы в сеть2 и получать ответ, но входящие соединения из сети2 в сеть1 не попадут. Сеть1 всё так же частично защищена от сети2, однако никакого фаервола мы не добавляли! Что в этом случае защищает сеть1 от сети2? Да то же самое что и в первом случае — неполная связанность сетей. Да, сам по себе NAT никого не защищает, скорее наоборот, поскольку он даёт частичную связанность, а не убирает остальные связи. Но и говорить что защищает фаервол — неверно. А поскольку именно NAT даёт возможность использовать частично связанные сети, то в быту и говорят, что защищает NAT.
                                                              +1
                                                              Насколько я могу понять, там по ссылке естественный способ обхода такого рода «защиты». Если атакующий находится в сети 2, то он может указать адрес (из сети 2) роутера сети 1 в качестве шлюза, после чего обратиться к адресу из сети 1 напрямую — и NAT сам по себе, без дополнительных настроек (которые, впрочем, зачастую активны по умолчанию), позволит ему это сделать.
                                                                +1
                                                                но входящие соединения из сети2 в сеть1 не попадут.

                                                                Попадут. Если сеть2 знает адрес конкретного компьютера из сети1 и отправит запрос к этому адресу через роутер, то роутер его прекрасно перенаправит по своим маршрутам в сеть1 без всяких там NAT, независимо от его наличия или отсутствия.


                                                                Я пожертвовал своей сетью и перед написанием комментария провёл эксперимент, подключив к своему роутеру вместо интернет-провайдера один из компьютеров, который имитировал сеть2. И он прекрасно получал доступ к сети1 (домашней сети за роутером) в обход NAT, пока я на роутере не врубил фаервол.

                                                                  0
                                                                  прекрасно получал доступ к сети1 в обход NAT

                                                                  Можно по подробней с айпишниками про этот фантастический кейс?
                                                                  Как можно через NAT достучатся даже зная внутренний айпишник (например на 192.168.1.10), без проброса портов?
                                                                  Для TCP это в принципе невозможно, для UDP есть возможность, но только когда сам 192.168.1.10 полез по UDP через NAT.
                                                                  Если же 192.168.1.10 только ожидает подключения, как через NAT можно к нему достучаться?
                                                                    0

                                                                    они про подключение по l2 к wan-порту роутера

                                                                      +1
                                                                      Как можно через NAT достучатся даже зная внутренний айпишник (например на 192.168.1.10), без проброса портов?

                                                                      Очень просто: отправить роутеру IP-пакет, в получателе указав нужный адрес (192.168.1.10). Роутер просто его отроутит по прописанным в нём маршрутам и всё. NAT'у здесь просто неоткуда взяться — он действует, только если отправлять пакеты непосредственно на адрес роутера, причём адрес принадлежащий сети2 (то есть не 192.168.1.1, а какой там интернет-провайдер выдаст роутеру)


                                                                      Для TCP это в принципе невозможно

                                                                      Это работает для любых протоколов на базе IP, в том числе для TCP. Я проверял это, открывая http-сайтик, запущенный на своём компьютере в сети1, и на компьютере из сети2 он успешно открылся в обход всех NAT.

                                                                  +2
                                                                  В той статье есть небольшое передергивание. NAT сам по себе не изолирует, а вот NAT вместе с маршрутизацией провайдера — идеальный фаервол. Если ты напрямую подключен к роутеру, то да, можно маршрутизировать пакеты в сеть за NAT-ом, а если между злоумышленником и тобой есть хоть один маршрутизатор — то всё, внешней угрозы не получится.
                                                                    0

                                                                    Да, но это если доверять провайдеру и не считать его внешней угрозой

                                                                    0
                                                                    А теперь объясните, каким образом злоумышленнику попасть в подсеть WAN интерфейса роутера, чтобы обойти NAT?

                                                                    От внешних угроз защищает фаервол.
                                                                    Если немного пофилософствовать, то в контексте обсуждения глобальной адресации/маршрутизации первично то, что у внутренних хостов нет реальных IP адресов, поэтому и реализован NAT (это вторично). И безопасность — это следствие самого факта серой адресации в локальной сети, а не NAT. А кто там именно в вашей коробке занимается отбрасываением пакетом — натер, роутер, файрвол или полисер — это уже не имеет отношения к глобальной адресации/маршрутизации
                                                                      +1

                                                                      Вариант, что интернет-провайдер является или может стать злоумышленником, не рассматривается принципиально?

                                                                        +1
                                                                        Речь про глобальный интернет. Защищает не нат, а адресация и невозможность маршрутизации в глобальном адресном пространстве. Провайдер в данном контексте это локальная сеть и его не рассматриваем.
                                                                          +1
                                                                          А почему провайдера не рассматриваем? Ростелеком вон уже сегодня не брезгует рекламу в http подставлять, а что им придет в голову завтра?
                                                                          Да и кулхацкера Васю из соседнего подъезда со счетов сбрасывать наверно не стоит.
                                                                          Так что все что не под вашим контролем — потенциально враждебно.
                                                                      +1
                                                                      > NAT никак не изолирует внутреннюю сеть от подключения извне.

                                                                      В общем случае (включая вырожденные виды) — не изолирует. Типичный — изолирует от любых не инициированных изнутри соединений, кроме явно прописанных в конфигурации. (Сразу оговорюсь: см. конец сообщения про тот случай, который выдаётся за фатальную проблему.)

                                                                      NAT устанавливает ассоциацию внешнего адреса внутреннему. У большинства их множество внутренних адресов больше множества внешних адресов, доступных для назначения NAT'ом — этого уже достаточно, чтобы произвольный входящий пакет не имел внутреннего адресата, если в NAT не назначена ассоциация для этого. Исключением являются те вырожденные NAT, для которых конструктивно установлено такое соответствие 1:1. Я ещё ни разу не видел такого вживую применённого, и сомневаюсь, что увижу.

                                                                      Symmetric NAT (в терминах STUN RFC), кроме того, не позволяет проникнуть на внутренний адрес запросу ни с какого удалённого адреса, кроме того, для которого этот внешний адрес был назначен. Для Cone типа такое возможно — на время жизни соответствующей ассоциации. Но Cone применяется в основном на домашних раутерах и крайне нетипичен даже для small office сегмента.

                                                                      Обсуждение по ссылке абсолютно неконструктивно, главный флеймер этого треда откровенно уводит разговор в сторону, а оппоненты оказались не в состоянии возразить по сути.

                                                                      > От внешних угроз защищает фаервол.

                                                                      Само правило работы NAT «впускаем только по наличию ассоциации» тут уже является таким элементов файрволла. Если в устройстве нет явных ляпов дизайна, то дополнительный файрволл для этого и не нужен.

                                                                      Наличие ingress filter при этом я считаю элементом обязательной конструкции. Проблема обсуждения по ссылке — и ваших примеров — в том, что зацикливание на возможности «а давайте отправим напрямую на внутренний адрес через хак» уводит от обсуждения принципиальной ценности NAT для большинства случаев, включая крякеров из Интернета (что на порядки типичнее взлома через соседа по локалке, который может подделать целевой MAC).
                                                                      0
                                                                      в ipv6 можно просто фаирвол использовать, вместо «защитного» ната, запретить подключение снаружи вовнутрь
                                                                      правда это создает необходимость в механизме похожем на upnp :) а его нету
                                                                      нет в жизни счастья
                                                                        0
                                                                        нат все таки не про входящие пакеты, а про входящие сессии, те мы опять же вернемся на уровень сессий
                                                                        что иногда для всяких там юдп весьма нетривиальная задача без таблиц нат :-)
                                                                          0
                                                                          UPnP не привязан к IPv4, и должен работать поверх IPv6. Вы, наверное, имели ввиду конкретно NAT Traversal, но если нет NAT, то не нужен Traversal. Нужно только прописать правило firewall c правильным адресом машины, откуда пришел UPnP запрос, я думаю, маршрутизаторы этому быстро научатся, если еще не умеют.
                                                                            0
                                                                            Правильно! Даешь UPnPv6, чтобы все эти полу-умные камеры и дверные замки радостно торчали голой *опой в недобный интернет в обход стандартного правила файрвола.
                                                                            +4

                                                                            NAT — не файервол.
                                                                            NAT — не файервол.
                                                                            NAT — не файервол.

                                                                            NAT — не файервол.
                                                                            Нет, NAT не обеспечивает большей безопасности по сравнению с прямым соединением.

                                                                              0
                                                                              Допустим файрвол отключён. Как в ipv4 при включённом NAT осуществить сканирование хвостов в локальной сети за ним из вне?
                                                                                +1

                                                                                Вы изначально предполагаете добропорядочность внешней сети. Попробуйте представить, что вся сеть за роутером с NAT подконтрольна злоумышленнику. Результаты вас огорчат.
                                                                                А я, к примеру, не могу себе представить, почему я должен доверять инфраструктуре своего провайдера.

                                                                                  +2
                                                                                  Ещё меньше я доверяю владельцам внешних ресурсов и транзитных узлов, которые при ipv6 видят напрямую мое устройство, которое при наличии NAT маскируется внешним роутером.
                                                                                  Хотелось бы все таки узнать, как NAT не защищает (он же не файрвол) и позволяет злоумышленнику отсканировать моё устройство за ним?
                                                                                    0

                                                                                    Я, находясь во внешней по отношении к вашему роутеру сети, шлю ему пакеты с src своим, dst — перебираю 192.168.0.0/16, 10.0.0.0/8 и 172.16.0.0/12
                                                                                    Ваш роутер совершенно честно передает пакеты внутрь вашей сети, он же не файервол, правда? Внутреннее устройство отвечает на мои запросы и через роутер (он же не файрвол, да?) отправляет их во внешнюю сеть. Всё, мне доступны все ваши внутренние ресурсы. Как я это делаю? Да как угодно. Ломаю комп ваших соседей и маршрутизатор вашего провайдера. Но в большинстве домосетей всё гораздо проще, фомкой открываю ящик с коммутатором у вас подъезде и просто включаюсь к вам в разрыв. Или рву кабель, если он проложен по стенке в коридоре. Да у меня просто уйма разных методик, как это сделать.

                                                                                      +1

                                                                                      Итак, чтобы не взломать, а просто хотя бы найти хост за NAT-ом, нужно что-то одно из:


                                                                                      1. Взломать другой хост за NAT-ом.
                                                                                      2. Пробраться незамеченным в помещение, соединенное кабелем с атакуемой сетью, со специальным инструментом.
                                                                                      3. Взломать маршрутизатор интернет-провайдера.

                                                                                      Это достаточно высокий уровень безопасности. Меня такой вполне устраивает.

                                                                                        0

                                                                                        Не пугайте страуса, пол бетонный (с)
                                                                                        Ваш этот "достаточно высокий уровень безопасности" имеет неопределенную величину, от нуля до бесконечности(нет, не правда, гораздо меньше).
                                                                                        Но я ничего не собираюсь доказывать. Я как был убежден, что должно быть защищено каждое устройство в сети, даже локальной и уже защищенной, так и буду дальше считать, что оно, это устройство, всегда находится во враждебном окружении. А если каждое устройство в локальной сети защищено файерволом, на котором запрещено всё, что не нужно для правильного функционирования этого устройства, политиками безопасности запрещены и не используются пароли, подверженные брутфорсу, а где возможно, так пароли и вообще не используются, а версии софта не имеют известных уязвимостей, то мне всё равно, есть ли возможность проникнуть ко мне во внутреннюю сеть. Это просто только один из многих заборов.

                                                                                          +4
                                                                                          Если вы непрерывно следите за всеми обновлениями безопасности и уязвимостями на всех телевизорах/камерах/умных замках и прочей мелочи, то это не значит, что все остальные тоже хотят тратить на это свое время.
                                                                                            0

                                                                                            Хотел бы я посмотреть на твою домашнюю сеть. У меня есть подозрения, что кто-то здесь не до конца честен.

                                                                                      +3

                                                                                      Всё это так, Вы абсолютно правы. Но это в теории. А на практике большинство домашних пользователей сейчас защищает в основном комбинация их NAT плюс добропорядочность (по крайней мере в данном отношении) их провайдера. При переходе на IPv6 они этой "защиты" лишатся… и самое плохое, что никто их об этом не предупредит, не научит правильно настраивать файрвол "для IPv6", и даже не выдаст роутер с изначально безопасно настроенным файрволом.

                                                                                        –3
                                                                                        Ну это уже вопрос простейшей образованности. Про брэндмауеры в Windows регулярно все говорят в статьях/лекциях на темы простейшей безопасности при использовании Интернета.
                                                                                          +9

                                                                                          Простейшей образованности??? Мне кажется, Вы сильно оторвались от реальности. Нет ничего плохого в том, чтобы чем-то сильно увлекаться, писать такие статьи, и агитировать за свою точку зрения в дискуссии, НО — берега терять при этом всё-таки не стоит.


                                                                                          Я считаю, что лично у меня эта "простейшая образованность" имеется: я не сетевой инженер, но я разработчик со стажем в 30+ лет и админю линух немногим меньше (с 1994), когда-то даже сделал собственный дистрибутив и поддерживал его несколько лет, сейчас на Gentoo. У меня дома кучка VLAN-ов, VPN-ов, два ISP — порядка 10-20 сетевых интерфейсов не считая докерных. И достаточно сложные правила iptables, чтобы всё это работало, и работало безопасно. Как по-вашему, тянет это на "простейшую образованность"?


                                                                                          Так вот. Лично я к IPv6 присматриваюсь очень давно. Несколько раз пытался погрузиться в него всерьёз. Но каждый раз это заканчивалось тем, что моя "простейшая образованность" и серьёзное отношение к безопасности домашней сети (и сетей проектов, которые я в той или иной мере админил), приводили к простому выводу: НАФИГ этот IPv6. Причин для этого несколько:


                                                                                          • Поддержка IPv6 не заменяет необходимость продолжать поддерживать IPv4 ещё очень долгое время, таким образом времени и внимания на настройку тратить придётся заметно больше в любом случае.
                                                                                          • IPv6 значительно сложнее IPv4, безопасная настройка файрвола для IPv6 из-за этого требует отдельных правил, и тупо использовать одни и те же правила для IPv4 и IPv6 не получится (если интересует качественный результат). Более того, в связи с этой сложностью я тогда даже не смог найти чётких рекомендаций по безопасной настройке файрвола для IPv6 — все, какие мне попадались, упускали из виду какие-то элементы (которые Вы называете "фичами" IPv6, а я "потенциальными дырами").
                                                                                          • В целом подключение IPv6 параллельно с IPv4 заметно увеличивает поверхность атаки (что в те годы, когда я активно смотрел в сторону IPv6, было частично связано ещё и с сыростью реализации IPv6-стека в ядре).

                                                                                          Резюмируя, IPv6 для абсолютного большинства — это сильное ослабление безопасности (относительно текущего уровня для IPv4), и значительное увеличение сложности настройки и поддержки сетевой инфраструктуры (как минимум просто из-за необходимости продолжать поддерживать IPv4, даже если не учитывать сложность самого IPv6).


                                                                                          Лично я в принципе включил в ядре поддержку IPv6 буквально месяц-два назад (выяснилось, что без этого у телеграма не работают звонки), и при этом тут же выключил её через sysctl. Да, я понимаю, что рано или поздно, скорее всего, мне придётся включить и настроить IPv6. Может быть. Поэтому и интересуюсь статьями вроде этой. Но пока что настройка IPv6 не даст мне ничего, кроме проблем, и ни одной причины этим заниматься я пока не вижу.

                                                                                            0
                                                                                            Замечание про простейшую образованность касалось только того, что пользователь сам дурак если не помнит и не заботится о правилах firewall-а. Это как винить кого угодно в том, что вылетел из окна автомобиля при столкновении — пристёгиваться надо всегда.
                                                                                              0
                                                                                              Снова повторюсь, прочитав полностью ваш комментарий: простейшая образованность касалось только того, что я считаю что человек обязан самостоятельно думать о безопасности своей: ремень безопасности, нескользящие ботинки (а не надежда что асфальт замой будет чист), презервативы, firewall-ы.

                                                                                              Работая с IPv4 и IPv6 я наоборот увидел что с IPv6 значительно проще работать, да и в самом протоколе его link-local-ы и прочие полезности очень упрощают жизнь. Да даже просто банальное огромное количество адресов — очень удобно, не нужно ютиться. Но да, соглашусь что если это в купе с IPv4 делается (dual stack), то это увеличивает повернхность атаки и теперь нужно буквально с двумя стэками работать сетевыми. Но так всегда: переходный период, когда лошади и конные повозки существуют совместно с автомобилями, означает что какое-то время будет сложнее, чем оставаться на лошадях или жить сразу полностью с автомобилями.
                                                                                                +4

                                                                                                Так и я о том же. Моей образованности как раз хватило, чтобы понять, что IPv6 мне пока лучше всего выключить вообще. Именно потому, что я примерно представляю себе сложность настройки IPv6 чтобы получить эквивалент моим текущим настройкам для IPv4, и понимаю, что в конечном итоге потратив на это недели две всё, что я получу взамен — ухудшение безопасности за счёт увеличения поверхности атаки, и всё. Никаких "плюшек" от IPv6 я не получу, просто потому, что у меня нет потребности открывать доступ снаружи в свою локалку, нет потребности увеличивать связность между текущими сетями, нет даже потребности (пока) подключаться к IPv6-only сайтам.


                                                                                                И, будем откровенны, у большинства обычных пользователей интернета образованность в этой теме сильно отстаёт от моей. И даже если они искренне попытаются настроить себе файрвол для IPv6 (ха-ха-ха! вот прям сейчас они бросят свои дела и займутся этим… они вообще даже слов таких не знают, в основной массе) — вряд ли у них это получится сделать достаточно качественно. Скорее всего этот файрвол в их исполнении будет больше напоминать закрытые ворота посреди чистого поля.

                                                                                                  0
                                                                                                  К вашей образованности у меня претензий нет и я уверен у меня есть чему у вас поучиться. Просто аргумент о том, что пользователям навредят потому что они не включают firewall — не серьёзный аргумент (для меня).

                                                                                                  Ну у кого какой опыт и выводы. Ничего не бывает что одинаково бы всем нравилось или бы все соглашались с чем-то. У меня прямо противоположный опыт: я получаю массу экономии времени, удобства, отсутствия раздражения (потому что удобно).

                                                                                                  Большинству пользователей я уверен что достаточно иметь firewall разрешающий исходящие соединения, запрещающий входящие (ну плюс ICMPv6 и другие мелочи). Это можно производителям ОС и делать как preset, мне кажется, ибо он удовлетворит 99.(9)% людей, как удовлетворяет NAT без firewall.
                                                                                                    0

                                                                                                    Да, наверняка можно сделать такой preset. Проблема в том, что сначала 20 лет провайдерам было сложно/дорого поменять своё оборудование, а теперь прикиньте, сколько лет займёт поменять домашние роутеры всех пользователей по всему миру — потому что в текущих роутерах таких preset-ов нет (впрочем, тут я могу ошибаться, но скорее всего — нет, либо те, что есть, сделаны чисто формально и не выдерживают никакой критики — просто потому, что производители никогда не заботятся о таких вещах пока их конкретно не прижмут).

                                                                                                      0
                                                                                                      Соглашусь что домашние маршрутизаторы не выдерживают никакой критики в вопросах безопасности. Но я имел в виду firewall на конечных устройствах (компьютер с Windows/GNU/BSD/whatever, iOS+Android).
                                                                                              +2

                                                                                              Если под брандмауэром Windows вы имеете в виду поделие, которое управляется при помощи wf.msc, то я вас уверяю, что оно не работает даже для IPv4. Чтобы просто браузер поставить, нужно включать в нем правило вида Разрешить любой трафик любой программе на любой адрес, иначе ничего не скачается.

                                                                                                0
                                                                                                Так исходящие соединения по умолчанию и так разрешены, ничего не нужно включать.

                                                                                                А о входящих брандмауэр честно предупреждает и спрашивает, разрешить этому приложению или нет.
                                                                                              0
                                                                                              Вы поняли мои мысли. Я уверен, что приватная (локальная) сеть должна существовать, и должен быть механизм сохранения данной приватности. С другой стороны демоны локальной сети должны в ней и оставаться. Думается с развитием применения ipv6 очень сильно изменится подход к настройке файрволов
                                                                                                0

                                                                                                Вы вообще уверены в том, что у большинства домашних пользователей этот NAT вообще существует? Многие просто включают кабель от провайдера в свой нотбук и даже не подозревают о вашей надежде, что NAT их защитит.

                                                                                                  +2

                                                                                                  Может кто-то так и делает, но у очень многих сейчас дома намного больше одного устройства — помимо ноута есть умные телевизоры, телефоны, планшеты, нередко второй компьютер… так что чаще всего этот кабель воткнут в WiFi роутер (нередко предоставленный и настроенный провайдером).

                                                                                                    0

                                                                                                    У меня сын некоторое время работал в саппорте интернет-провайдера, у него совсем другие сведения. Умные телевизоры, планшеты, два компьютера…
                                                                                                    Вы очень преувеличиваете средний уровень обычного домашнего пользователя.
                                                                                                    Больше двух третей абонентов обычных домосетей — обычные одиночные компы или нотбуки. И да, огромное количество пользователей даже не догадываются о том, что через WiFi роутер можно подключить несколько потребителей интернета к одному кабелю. Из статистики моего сына одним из самых популярных вопросов пользователей является "у меня уже есть ваш кабель, сколько стоит провести ещё один такой? А разветвители для интернета бывают?"
                                                                                                    А ещё дешевые тарифные планы у мобильных операторов сделали ненужными подключения по WiFi для смартфонов. А зачем?
                                                                                                    И ещё один аргумент. Вы видели, как выглядит радиоэфир на частоте 2.4ГГц в центре микрорайона из пяти 30-этажных жилых домов? И как оно "надежно" после этого работает? Обычный пользователь, поигравшись пару недель в "танчики" по вайфаю и сломав вокруг все ломающиеся предметы, звонит в техподдержку и рассерженно орет "ваш интернет нихрена не работает!", и, получив совет от саппорта попробовать включить кабель в порт компа напрямую, обнаруживает, что интернет таки стабильно работает, после чего исполняется чувства праведного негодования по поводу мошенников, которые ему этот вайфай предлагали.

                                                                                                      +3
                                                                                                      У меня сын некоторое время работал в саппорте интернет-провайдера, у него совсем другие сведения

                                                                                                      Вы видели, как выглядит радиоэфир на частоте 2.4ГГц в центре микрорайона из пяти 30-этажных жилых домов?

                                                                                                      вы сами себе противоречите, откуда же берутся десятки wifi сетей в любой многоэтажке, если NAT'ом (читай домашними роутерами) никто не пользуется? )))

                                                                                                        0
                                                                                                        вы сами себе противоречите, откуда же берутся десятки wifi сетей в любой многоэтажке, если NAT'ом (читай домашними роутерами) никто не пользуется? )))

                                                                                                        Провайдеры впаривают роутеры с wifi, настраивают, к примеру, ноутбук — и все.
                                                                                                        А на телефоне зачем wifi? Ведь это нужно где-то еще пароль взять, а он записан на бумажке, которая потерялась.
                                                                                                          +1
                                                                                                          Провайдеры впаривают роутеры с wifi, настраивают, к примеру, ноутбук — и все.
                                                                                                          Ну так и при чем здесь тогда «многие просто включают кабель от провайдера в свой нотбук», если этот самый ноутбук подключен к сети провайдера через его же роутер с NAT? Мне кажется, что сейчас подключить Интернет без роутера провайдера — квест, который «большинство домашних пользователей» не пройдет.
                                                                                                          Лично я вот понятия не имею, как подключить GPON МГТС без роутера этого самого МГТС. В последний раз, когда читал — вроде, левые устройства они не дают подключать. Но это не точно.
                                                                                                            0
                                                                                                            Это совершенно точно. GPON это не стандартизированная технология и если производитель не сказал, что данная конкретная модель ONT совместима с данной конкретной головной станцией. То стоит предполагать, что это не так и она сломает связь всему сегменту. Так же в их ONT прошит индивидуальный ключ авторизации и они его Вам естественно не дадут.
                                                                                                          0

                                                                                                          Не противоречу. Просто когда в зоне досягаемости любого устройства 3000 квартир, даже 25% пользующихся вайфаем — это просто офигительно много. А 5 домов стоящих напротив друг друга по кругу так, что можно прочитать название компании на пакете молока, которые стоит на столе в доме напротив, похоже позволяют на переотражении от соседних домах видеть всех. Вот абсолютно всех.

                                                                                                            0

                                                                                                            ну это вы крайний случай таки рассматриваете.
                                                                                                            в обычной отдельностоящей девятиэтажке увидеть 20 сетей ­— обычное дело. и в пятиэтажке 10 тоже. из чего я делаю вывод, что почти у всех, у кого подключен интернет, есть wifi-роутер (неудивительно, провайдеры сегодня предлагают поставить свой роутер пратически бесплатно)

                                                                                                              0

                                                                                                              Очевидно у меня в округе какие-то другие провайдеры. Которые выдают просто шнурок Ethernet в квартиру. А роутер у них стоит… ну в Ашане он ровно столько же стоит. Не могу сказать "дорого", но и покупать его будет только тот, кто точно знает, зачем он ему нужен, и почему ему не нужны для других целей эти $25.

                                                                                                                0
                                                                                                                Очевидно у меня в округе какие-то другие провайдеры. Которые выдают просто шнурок Ethernet в квартиру

                                                                                                                очевидно


                                                                                                                "простому пользователю" куда проще заплатить 10 рублей в месяц и не задумываться. да многие даже и не знают, что в ноутбук или телевизор можно воткнуть сетевой кабель (а стационарного компьютера не имеют вовсе).

                                                                                                                  0

                                                                                                                  Везет. Вот реально завидую. Аренда за 10руб. в месяц. Я бы тоже взял бы не задумываясь. У моего текущего провайдера есть IPv6 прямо из шнурка. С одной сетью /64 и /48 по запросу. Собственно, из-за них я к нему и перешел. Но вот аренды оборудования — вообще никакой.

                                                                                                                    0

                                                                                                                    странно, у нас, кажется, все провайдеры предоставляют роутер в аренду.
                                                                                                                    если смотреть на крупных (покрывающих весь город), то 2 из 3 готовы за дать роутер 10р в месяц.

                                                                                                                    0

                                                                                                                    Я вот недавно у своего провайдера узнавал. Вроде бы как цена аренды рутера 1 руб/мес. Но на самом дешевом тарифном плане (моем) такой опции нет. Чтобы арендовать рутер, мне пришлось бы перейти на тарифный план с такой же скоростью, но на 100 рублей абонплаты дороже. Т.е. получается что цена аренды составила бы 101 рубль, а не 1

                                                                                                      +1

                                                                                                      Большинство домашних пользователей как получали маршрутизатор от провайдера с управлением через TR-069, так и будут получать.

                                                                                                        0

                                                                                                        На практике абсолютно такой же уровень защиты (нет, на самом деле даже больше) дает одно единственное правило в файерволе на роутере — "разрешить соединения только со стороны LAN. И такой пункт есть в распоследних дешевых SOHO роутерах. И да, обычно он по умолчанию включен. NAT — он не для защиты, это просто костыль.

                                                                                                      0
                                                                                                      Попробую описать текстом. Представьте, что мы с вами в одной провайдерской сети 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. Если у вас отключен фаерволл, то я смогу обратиться к хостам внутри вашей домашней сети.
                                                                                                        +2
                                                                                                        Итого, случай опасности при «файрволл отключён» сводится к опасности только в особой конфигурации, в которой:

                                                                                                        1. WAN стороны жертвы и атакующего находятся в одном broadcast-сегменте формата «типичный Ethernet». Не выполняется в случае хакера из чуть более дальнего интернета.

                                                                                                        2. Это именно broadcast-сегмент с прямым бесконтрольным взаимодействием между сторонами. Не выполняется уже, например, на DOCSIS-сетях, где головные станции пропускают трафик через свой доступ и раутинг, и прямое взаимодействие между клиентами сегмента по их MAC невозможно. Кроме того, некоторые свичи позволяют организовать то же на Ethernet. Не выполняется при подключении каждого клиента персональным VLAN'ом.

                                                                                                        Ну да, формально можно засчитать один гол за счёт такого эффекта. Но:
                                                                                                        1) Практическая ценность его только в весьма частных условиях
                                                                                                        2) Простейший ingress filtering на входе его останавливает, и надо быть совсем зелёным админом, чтобы не поставить такое правило.

                                                                                                        Более того, формально, поскольку пакеты проходят в обход NAT, проблема тут не в NAT, а в раутере сбоку от него;) а может, его и нет? NAT ведь не означает раутинг вне NAT механизмов. Нет, что-то гол сомнительный :)

                                                                                                        А ещё варианты будут?
                                                                                                  +3
                                                                                                  Да, возможностей больше. Но ведь палка о двух концах — в IPv6 гораздо труднее разобраться, особенно человеку, для которого администрирование сетей — не профессиональная деятельность. Даже в IPv4 хватает нетривиальных вещей, а в IPv6 их на порядок больше. Поэтому зачастую и делается выбор в пользу «вот оно работает и более-менее понятно» а не «надо потратить годик на обучение, зато потом я смогу настроить IPv6 и иметь кучу возможностей, из которых я дай бог 1% использую».
                                                                                                    0

                                                                                                    Когда такое пишут, мне интересно становится, какой именно аспект работы IPv6 делает его «гораздо» более сложным. Вот у вас лично — понимание каких принципов работы IPv6 вызвало сложности?

                                                                                                      0

                                                                                                      Я хоть и "айтишник", v4 знаю на уровне "эникея", имею проблемы с пониманием работы v6. В частности, не понимаю как работает SLAAC, не понимаю почему все орут что нат нужен и позволяет скрыть колво хостов в сети, хотя для обычного пинга в /64 нужно прогнать около 2к экзабайт трафика (при размере всего пакета в 124байт).
                                                                                                      Так же есть проблемы с запоминанием адресов. Да, знаю, это проблемы людей, а не протокола, но все же…
                                                                                                      Ну а так же мне не ясна работа SLAAC, в плане выдачи доп адресов (выше писали об этом), зачем и как оно работает…
                                                                                                      Это нужно изучить, но, большенство комментаторов не хотят этим заниматься, мол, есть v4, работает — не трожь!


                                                                                                      p/s/
                                                                                                      у меня примерно 20% трафика бегает через v6 (туннель до HE), а еще на работе в ближайшем времени сделаем v6 :3

                                                                                                        +1
                                                                                                        SLAAC прост как пробка. Роутер периодически и по запросу рассылает общий конфиг сети(prefix,lifetime,mtu,gateway,...), а дальше клиенты сами разбирают адреса и делают проверку на кофликт. При выборе адреса используется очень простой алгоритм буквально склеивающий префикс и mac-адрес. Но этот адрес как cookie, позволяет отслеживать его перемещение между сетями независимо от используемых протоколов и программ. Также позволяет злоумышленнику извлечь mac-адрес и через wi-fi(при наличии) найти устройство в реале. Поэтому для исходящих соединений используются временные адреса.
                                                                                                          0

                                                                                                          Уоу, спасибо за то, что напомнили про WiFi. Знаю про EUI64, но не задумывался о том, что можно в реале найти (очень конечно маловероятно, будет из разряда "Я ТВОЙ МАК ВЫЧЕСЛЮ"), но все же.
                                                                                                          Так же спасибо за пояснение про принцип работы SLAAC!

                                                                                                            +1
                                                                                                            Нынче у бизнеса мода собирать максимум информации обо всех клиентах для таргетированной рекламы и сливать эту информацию агрегаторам. Если магазинчик у дома сольёт mac в базу, то вычисление станет плёвым делом.
                                                                                                          +2
                                                                                                          В частности, не понимаю как работает SLAAC

                                                                                                          ok, давайте попробуем разобраться — сначала очень высокоуровнево, а потом, если у вас будут вопросы, можно углубиться в меру моих знаний в этой области и способности прочитать RFC.


                                                                                                          1. Хост обнаруживает интерфейс, требующий конфигурации. Этот интерфейс должен уметь мультикаст.
                                                                                                          2. Хост настраивает link local адрес. В RFC есть генерализация про EUI-64, но для базового понимания это не очень важно. Можно считать, что адрес в случае Ethernet настраивается на основе MAC адреса, изменённого по специальному алгоритму и заданного префикса FE80::/10. 48-битный MAC адрес превращается в 64 битный и записывается во вторую половину IPv6 адреса.
                                                                                                          3. Прежде, чем начать использовать этот адрес, нужно убедиться, что он уникален в пределах этого линка. Для этого используется специальный алгоритм, описанный в RFC4862. Упрощая, хост отправляет на этот адрес пакеты Neighbor Solicitation и если она в ответ не получит Neighbor Advertisement, значит, адрес уникальный. Собственно, для этой части необходим мультикаст. Если адрес не уникальный (то есть, на одном линке оказалась как минимум ещё один хост с таким же MAC адресом), то процесс останавливается.
                                                                                                          4. Если адрес уникален, он присваивается интерфейсу и теперь у хоста есть адрес link local.
                                                                                                          5. Затем, хост ждёт информации от маршрутизатора в виде пакетов Router Advertisement. Если она ждать не может (что и происходит в реальности), она отправит пакеты Router Solicitation на мультикаст адрес all-routers. Маршрутизатор, получивший такой пакет, отправит внеочередной Router Advertisement.
                                                                                                          6. В пакете Router Advertisement есть бит, указывающий, нужно ли делать SLAAC, или будет DHCPv6. Если работает SLAAC, в пакете будет информация о глобальном префиксе (префиксах) назначеных этому линку. Может так же быть информация о DNS сервере и списке доменов для поиска. К слову, Router Advertisement есть время жизни, так что на линке можно сменить префикс налету.
                                                                                                          7. Получив информацию о префиксе, хост а заполняет вторую половину адреса — и есть разные алгоритмы, как именно это делать, для простоты будем считать, что она выбирает случайное 64 битное целое.
                                                                                                          8. Кандидат проверяется на уникальность. В отличие от выбора link-local, тут можно повторить, если адрес окажется не уникальным.
                                                                                                          9. Глобальный адрес (адреса) назначается интерфейсу. Если хост использует RA для настройки рекурсивного DNS, то настраивается и рекурсивный DNS.
                                                                                                          10. Можно работать.

                                                                                                          Ну а так же мне не ясна работа SLAAC, в плане выдачи доп адресов (выше писали об этом), зачем и как оно работает…

                                                                                                          На шаге шесть выше изначально предполагалось, что вторая половина адреса будет генерироваться так же, как на шаге 2 — на основе MAC адреса. Но потом беспокойство о том, что серверы (и транзит) будут идентифицировать компьютер, даже если он перешёл в другой префикс (потому, что вторая половина адреса не изменяется) и это решили переделать. Поэтому для исходящих соединений периодически (раз в сутки, например) генерируются случайные адреса. Поскольку если TCP соединение установлено, то адрес нельзя немедленно выкинуть, то после генерации нового адреса старые не исчезают немедленно и на интерфейсе может оказаться новый и, потенциально, несколько старых адресов. Кроме того, для серверных компонент может быть необходим стабильный адрес и он тоже будет на интерфейсе.

                                                                                                            0

                                                                                                            Огромное спасибо за такой развернутый ответ! Стало гораздо понятнее!

                                                                                                      +2
                                                                                                      Автор забыл рассказать о том, насколько ипв6 привязан к мультикасту.
                                                                                                      Плюшки, безусловно, крутые — но для корректной работы ипв6 придётся менять не только л3, но и всю коммутацию. В противном случае все линк-локал фишки будут работать в широковещательном режиме.
                                                                                                        0
                                                                                                        Не IPv6, а NDP и подобного уровня протоколы. Это отмечено в абзаце про требования, которые можно назвать и недостатками.
                                                                                                        +7

                                                                                                        Ещё лет 7 назад помню, как один друг, занятый сетевыми технологиями в академической и, одновременно, провайдерской среде утверждал, что переход на IPv6 — дело решённое и через пять лет все будут относиться к нему как к основному, забыв "старый" IPv4 как страшный сон.


                                                                                                        Тем не менее, "воз и ныне там" и всё строится по IPv4, IPv6 же интересует лишь энтузиастов и любителей радикально решить их же проблемы, специфичные для четвёрки. Плюс некоторые технологические компании.


                                                                                                        Абсолютное и подавляющее большинство пользуется интернетом для потребления контента или для решения конкретной задачи, когда "удобно" — это браузер, клиент или API, "красиво и эффективно" на сетевом уровне — увы, нет, это попросту невостребовано.


                                                                                                        Бизнес прекрасно понимает, что решить "костылями" и NAT — в разы дешевле и быстрее, чем переводить software/hardware на IPv6, поэтому и поныне IPv4 остаётся абсолютно доминирующим, а рост IPv6 трафика в основном чисто техническая заслуга отдельных контент-сервисов.


                                                                                                        Рискну высказать непопулярное мнение, но поймите меня корректно:


                                                                                                        • Я никоим образом не против IPv6, это отличная концепция и, если она действительно станет новым промышленным стандартом — то это отлично, рано или поздно IPv4 придётся менять, обновлять или заменять целиком — это бесспорно;
                                                                                                        • Однако, настройка и вообще "запоминание" IPv6 адресов и сетей — это боль;
                                                                                                        • Заниматься сменой и/или перенастройкой оборудования — это боль, потому что "и сейчас всё работает", пусть и не через красивые технологии;
                                                                                                        • Большинство софта, железа и в целом решений уже согасилось со всеми этими костылями и слоями абстраций;
                                                                                                        • Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.

                                                                                                        А что про NAT и абстракции — контейнеризация и бурное развитие SDN — это всё позволяет не обращать внимание на IPv6 вообще, для связности с "внешним миром" достаточно будет и одного адреса.

                                                                                                          0
                                                                                                          Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.


                                                                                                          Ага. При этом как раз то что упоминается в статье как достоинство
                                                                                                          У конечного пользователя появляется Интернет, а не удалённый доступ до ряда служб корпораций типа Facebook, ВКонтакте, WhatsApp, YouTube и т.д.!
                                                                                                          — оно как раз этим самым службам корпораций нафиг и не сдалось. Идеал корпораций — чтобы пользователь фб не знал ничего кроме фб и за пределы его экосистемы носу не казал, а для этого v4 за глаза и зауши достаточно.
                                                                                                            0
                                                                                                            оно как раз этим самым службам корпораций нафиг и не сдалось

                                                                                                            но почему же тогда эти самые корпорации так пропагандируют IPv6? Почему и у Google, и у Facebook сервисы отвечают по IPv6?

                                                                                                              0

                                                                                                              Скорее всего потому, что трекать юзера надёжно по уникальному IPv6 (а то и по всей /64, чтобы трекать все его девайсы как единое целое), без всяких кук — мечта для таких корпораций.

                                                                                                                0

                                                                                                                Как раз RFC4941, который Privacy Extensions for Stateless Address Autoconfiguration in IPv6, позволяет каждому устройству в IPv6 сети выбирать любой адрес из 4 миллиардов и делать это в любой момент по своему разумению. Windows 10, как самая популярная пользовательская ОС, умеет это делать из коробки. И делает это по умолчанию. Так что трекинг по IPv6 — плохая идея. Гораздо хуже, чем трекинг по адресу IPv4.

                                                                                                                  +1

                                                                                                                  Вы в своём ответе проигнорировали эту часть сознательно?


                                                                                                                  а то и по всей /64, чтобы трекать все его девайсы как единое целое
                                                                                                                    0

                                                                                                                    Это же IPv6, здесь нет бродкастов. Вообще нет. Нельзя обратиться к /64 как к единому целому. Нет никаких признаков внутри /64, одно там внутри устройство, или 4 миллиарда. Ну вот есть у меня дома /64 на всех домашних (пять компов, пять телефонов, два телевизора и планшет) Что трекать? Какой смысл в таком трекинге? Мне от 22 до 61 года, с полом я не определилось, иногда мужской, иногда женский, меня интересуют игры, гитары, электроника, красивые шмотки, подводное плавание, IT, кулинарные рецепты и схема разборки двигателя Skoda Octavia. Угу, вот трекинг по /64

                                                                                                                      +2

                                                                                                                      2-3 человека и сейчас могут пользоваться одним компом с одним набором кук. Тем не менее, это не сильно мешает их различать — разные наборы посещаемых сайтов, разные группы интересов, разное время работы, … Но куки можно удалить или вообще заблокировать соответствующими плагинами, а вот свою подсеть /64 скрыть/изменить намного сложнее.

                                                                                                                  +1

                                                                                                                  Так что сейчас — один внешний IP, что в IPv6 — общий префикс, какая разница. Гуглу сложно отличить телефон от десктопа? Несложно.


                                                                                                                  И кроме того, зачем тогда они строят IPv6-only датацентры?

                                                                                                                  0
                                                                                                                  Потому, что альтернатива CG-NAT, а значит меньше информации о пользователе. Представьте, что пользователь вошёл в интернет через открытую Wi-Fi точку. Гугл точно узнает где она находится, благодаря гугломобилям. А если она будет за CG-NAT, то он сможет определить в лучшем случае город. К тому же IPv6 продвигают гики, а таковых у IT-компаний полно.
                                                                                                                    +1

                                                                                                                    CG-NAT — крайне плохая альтернатива. Достаточно одного спамера в сети, чтобы заблокировали всех, кто за этим NAT-ом сидит. Под спамером я понимаю не только и даже не столько обычного спамера по SMTP протоколу. Просто неимоверное количество сервисов блокирует доступ на уровне IP. И мне совсем не улыбается лишиться доступа к своим любимым фоточкам котиков, потому что в соседнем доме мамкин кулхацер решил развлечься.