Comments 459
Всё очень вкусно и весело, но сложность настройки, особенно на маршрутизаторах, намного выше чем для v4.
Для обычного человека с SOHO роутером, если производитель сразу хорошо сделал, никаких проблем нет и SLAAC — это может быть и круто, всё само раздалось, у устройств в сети белый внешний адрес появился.
Но недавно пытался настроить IPv6 на RouterOS и, несмотря на то, что провайдер поддерживает и в openwrt завелось всё сразу, микротик либо не выдаёт клиентам адреса, либо себе, либо не пускает трафик наружу через себя.
А все материалы сводятся к тому же, что у вас написано: настройте SLAAC, это стильно, модно и молодёжно. Но при этом стек технологий вокруг IPv6 крайне сложный, и если ты не зароешься в RFC на долгие дни, то разобраться весьма проблематично.
Но недавно пытался настроить IPv6 на RouterOS и, несмотря на то, что провайдер поддерживает и в openwrt завелось всё сразу, микротик либо не выдаёт клиентам адреса, либо себе, либо не пускает трафик наружу через себя.
SLAAC на ROS настраивается в 2 клика, просто кто-то всё ещё считает что ROS для домохозяек и всё должно предельно просто настраиваться.
И всё тоже самое, с точностью до вариаций перевода пишут в ответах на форумах микротика, на реддите, на stackexchange.
Что всё настроить тривиально, просто автор не разобрался. Но никто не говорит, как это сделать в два клика, чтобы при этом работало.
SLAAC настраивается в добавлении адреса.
Если у вас статика — вешаете /64 адрес на интерфейс и ставите advertise=yes, если получаете по DHCP-PD — вешаете адрес ::1/64 (например, так то любой какой захотите), указываете пул адресов из которого брать и так-же включаете advertise. Допом в IPv6 — ND можете покастомизировать что микрот будет отдавать в SLAAC.
Если же вы из отряда тех кто хочет префикс отличный от /64 заставить работать с SLAAC — вам путь в RFC где определено что SLAAC должен работать только для /64.
Если же вы из отряда тех кто хочет префикс отличный от /64 заставить работать с SLAAC
ну вот у меня дома есть динамическая подсеть /64 от провайдера.
есть wifi-сеть.
есть проводная сеть (даже не одна на самом деле, поделены vlan'ами)
есть сети для виртуалок.
и какой мне толк от сети /64 провайдера, если я не могу её нарезать?!?
Да, SLAAC на меньших размерах не будет работать.
хорошо, и как будет выглядеть подключение к сети с телефона без SLAAC?
Только вопросы: а зачем вам её нарезать? У 99.9% пользователей не возникнет такой надобности (SLAAC удовлетворяет их). И чтобы вопросов «как нарезать» не возникало, дают рекомендации выдавать /56 или даже /48 сети конечным пользователям. Насколько видел статистику, большинство провайдеров выдавало /56 или больше.
не мониторю ситуацию, но по состяюнию на год назад из трёх провайдеров в моём доме ipv6 предлагал только один, у него /64
Да, только вот есть явно больные на всю голову провайдеры, которые даже /64 выдавать жлобятся, а выдают /128. и когда просишь у них /56 смотрят на тебя, как на идиота. Хотя, с другой стороны, это ещё более-менее вменяемые провайдеры, совсем невменяемые говорят, что у "нас IPv6 нет и не планируется".
Мне не мешало отдавать и /64 сеть SLAAC-у и одновременно нарезать её для хостов на одном и том же маршрутизаторе.
а можно детали?
большинство провайдеров выдавало /56 или больше
гугл привёл на:
https://version6.ru/isp
список провадйеров, предоставляющих ipv6, небольшой, почти у всех /64.
плюс там же список "Провайдеры, ранее предоставлявшие IPv6" размером чуть ли не с половину основного.
А тот же ДомРу об этом в курсе? /64 и больше не дадим и вообще объясните какие у вас ошибки. И вообще /64 это стандартный размер.
попросите у провайдера /48, я не думаю что он разорится от этого
имея опыт общения с провайдерами — даже пробовать не буду.
речь идёт о массовой услуге, вся вариативность ограничивается тем, какие "галочки" есть в личном кабинете и у девочек из колцентра. для vip-клиентов (юриков) могут быть варианты, но не для платящих 400р в месяц физиков.
«После пятнадцатого отрывания провода злобной уборщицей умоляешь провайдера перевести тебя на ppp. Провайдер добрый, посылает на [censored] только первые 82 раза, потом соглашается.» ©
OK, хочу послушать конкретные рецепты, как это выглядит — с именами производителей и моделей, которые это уже сделали (после 26 лет разработки IPv6). А именно для следующего юзкейса:
1. Провайдер выдал /56 (хороший, добрый провайдер). Как это происходит на протокольном уровне, и что надо нажать/написать у устройства, пригодного для раутера фирмочки на 20 человек.
2. Как этот же шлюз передаст информацию о выданной сети на раутер отдела, который будет выдавать уже /64 на отдел.
3. Что будет, если провайдер сменит этот адрес: как он пришлёт нотификацию, как она пробежится вниз до каждого конкретного компа/телефона/etc, заставляя их сменить адрес.
4. Как эта смена адреса будет отражена в DNS, поддерживаемом этими раутерами/шлюзами, а также в других средствах вроде Active Directory, если им это нужно.
Упрощённый вариант — домашняя сеть, получено /56 или /64 от провайдера, точно так же раздаётся на уже одну локальную сеть (простым аппаратом с WiFi рогами ценой до 100$).
Варианты с домашним устройством дороже 100$ или SOHO дороже 300$ не принимаются. Варианты, где оповещение вниз вплоть до каждого аппарата (компа, телефона, принтера, умного дверного замка...) не раздаётся, и он тормозит часами, прежде чем перезапросить адрес — тоже.
Если такого варианта нет, он чудовищно дорог или требует больше, чем включить 2 галочки с понятными названиями на вебе раутера — все рассказы про SLAAC и прочие страшные слова это «в пользу бедных».
Вот я и прошу назвать модель, а также параметры (какие времена он позволяет задать, в первую очередь, для router advertisement). Как клиентские терминалы на это реагирует. Как оно отражается в DNS. Что это в принципе возможно и по каким словам — я знаю. Интересует именно практика на своём опыте.
> Почитайте про PD. И не думайте, что эта проблема не была осознана и решена.
Читал. Осознана — по крайней мере теми, кто способен осознать — спора нет. Решение — 1) таки вопрос о точных моделях. 2) Что с DNS? Это из коробки где-то есть? Заниматься сексом по скрещиванию какого-нибудь dhcpd с dnsmasq я-то смогу, а как быть админу мелкой конторы?
> Иерархический PD тоже в принципе возможен, но я не уверен, что в «фирмочке на 20 человек он нужен». Такое, пожалуй, двумя кликами не настроить. Иерархические сети требуют больше усилий в настройке.
Пусть не 20, а 50. Всё равно — уровень сложности настройки?
OK. 600 секунд это настолько много, что слово «чудовищно» недостаточно, это ещё хуже. В идеале это всё должно реагировать за полсекунды, а на смену адреса эти самые RA должны лететь не ожидая таймаута и пачкой в несколько штук для дублирования. А для надёжности корпоративного уровня оно ещё должно заглянуть в lease DB и пинать каждого, кто не переключился.
> Я без понятия. У меня маршрутизатор не умеет динамически апдейтить DNS для локальной зоны — что для v4, что для v6. Я не в курсе, какие SOHO маршрутизаторы такое умеют.
Значит, пишу: этого ещё нет ;(
> Мне кажется, вы хотите скрестить ужа с ежом: сначала говорите про SOHO маршрутизаторы и минимальную настройку в два клика, а потом сразу — про Active Directory.
Нет, это вопрос по разным уровням, от минимума до близкого к максимуму. Но AD вполне возможен и на 50 сотрудников.
В общем, пока с практической доступностью этих возможностей явно не плохо, а очень плохо :(
Протокол — не делает. А вот NAT — устраняет необходимость зависеть от внешних адресов в принципе.
Внутренняя сеть строится на site-local или ULA адресах, на границе — NAT. Проблемы известны, на некоторые я традиционно вою волком (как SIP media transport), но если выбирать, что лучше — знание внешними хакерами структуры внутренней сети или проблемы с отдельными сервисами — я выберу второе.
> Я ещё раз повторюсь, определите задачу. Если задача про SOHO маршрутизатор, обслуживающий два VLAN и меньше сотни клиентов — это одно. Если задача про AD и сотни клиентов с дополнительными маршрутизаторами внутри сети — другое.
В том и дело, что разницы здесь нет. Есть задача, универсальная на все случаи: если мы не используем постоянные внутренние адреса, а строим на внешних адресах — то имеем грабли, которые надо решать (и список этих граблей я привёл). Home или корпорация с AD — объём проблем тот же, меняются только те сетевые средства, которые надо лечить.
Тут, однако, надо заметить, что можно пытаться выставлять на каждый внутренний хост одновременно site-local/ULA и внешний адрес, во внутренний DNS выставлять внутренние адреса, и надеяться на маршрутизацию. Наверно, можно, но я ещё не видел dhcpd с выдачей нескольких адресов одновременно. Если это будет — можно будет обсудить грабли такого решения (но срочное оповещение при переключении таки всё равно будет полезно).
> Так в IPv4 она тоже не даёт.
В IPv4 частные адреса внутри — норма, и нет апологетов тотального отказа от них, которые на формулировки проблем начинают рассказывать, что сегодня потребности в колбасе нет.
Это теория или практика?
И как быть с возможными потерями в сети?
> Вы всё-таки в традициях 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, то на этом можно собрать много информации для будущих диверсий.
Пусть протокол определяет, что часть соединений будет входящими — локальный хост открыл сокет и передал его координаты куда-то, и ждёт ответа. Есть протоколы, где это важно (и мне рядом тут пытались проесть мозг какой-то игрушкой с фиксированным портом).
Если внешний файрволл существует и знает протокол… ok, считаем, проблем нет, кроме того, что он должен знать все протоколы (нереально).
Если он не знает протокол — соединения не будет.
Если он не знает протокол, он пропускает всё в сторону внутреннего хоста, полагая, что случайности IP адреса достаточно.
Теперь пусть внутри какой-то слабозащищённый сервис (ну дырка в нём), и слушает на Any (IN6ADDR_ANY или как оно там будет зваться). Коннект на него должен приняться — ограничения-то нет. Значит, злоумышленник, получив откуда-то временный IP, может сразу его атаковать, пока этот IP не освобождён.
Чтобы этого не было, надо, получается, разделить Any на как минимум два подварианта: «совсем Any» и «Any для постоянных адресов», с умным выбором между ними. Только я что-то нигде такого в тех рекомендациях, включая RFC, не видел.
Эта проблема вообще хотя бы озвучена в обсуждении SLAAC?
Я хочу обратить внимание многоуважаемой общественности на один, очевидный из всего обсуждения этой статьи факт: IPv6 штука сложная, не очевидная, безопасная настройка которой до сих пор вызывает множество вопросов, на которые нет простого гайда for dummies с ответами… При этом на дворе 2020-й год, IPv6 исполнилось 25 лет. По-моему на этом тему можно закрывать и расходиться, кина не будет.
IPv6 штука сложная, не очевидная, безопасная настройка которой до сих пор вызывает множество вопросов
Да ладно?
0. Получил статический v4 у провайдера.
1. получил учетку к туннелю и префикс на tunnelbroker.net
2. включил в роутере 6in4
3. настроил туннель
4. поднял radvd
5. ?????
6. PROFIT!
Всё, дальше работает SLAAC. Втыкаем в вифи или по проводу любой девайс — он автоматом получает глобально маршрутизируемый адрес.
Что здесь сложного?
Что здесь небезопасного?
Вот вам гайд в несколько пунктов для чайников — чем вы недовольны?
На этом тему можно закрывать и расходиться, кина не будет.
Конечно-конечно, лучше ж сидеть за NAT, и маяться костылями типа STUN, TURN, uPnP.
Что за люди пошли — даешь им простой рецепт раздачи глобальных адресов, прямые коннекты между девайсами — а им плохо.
Что здесь небезопасного?
Это вот сейчас шутка юмора такая была, да? Вы как-то забыли в своём гайде примерно всё, что касается как раз именно безопасности — я не увидел слова файрвол, не увидел как надёжно разграничить доступ снаружи к локальным ресурсам, не увидел ответа на все те вопросы, которые встречаются в обсуждении этой статьи (включая вопрос netch80, в ветке которого мы сейчас разговариваем).
даешь им простой рецепт раздачи глобальных адресов, прямые коннекты между девайсами — а им плохо.
Ну да, плохо. Потому что мне нафиг не нужны прямые коннекты из инета к девайсам в моей локалке — за исключением очень небольшого числа разрешённых.
Вам дается подсеть на 64 бита. Если атакующий не знает конкретного адреса и порта на нем — ему придется очень долго сканировать сеть. Сильно дольше, чем v4 на /8 и даже на /16.
Адреса для исходящих сокетов регулярно ротируются, у меня на каждом хосте как минимум 1 а то и 2 исходящих адреса, меняющиеся постоянно.
То есть вероятность успешно попасть в какой-нибудь уязвимый сервис — примерно как в муху.
Это уже само по себе безопасно.
И вы забываете про то, что v4 сам по себе тоже не определяет файрволлы и другие меры безопасности, хотя сам по себе менее безопасен и менее удобен. Всегда когда мы говорим v4 — подразумеваем NAT. И DHCP. v4 плохо конфигурируем и отвратителен в удобстве развертывания на фоне v6-ного RADVD и SLAAC.
А безопасность — это уже совсем другой аспект. Не нужны прямые коннекты — возьмите и настройте файрвол на роутере. iptables умеете же? 6tables то же самое. NAT же — это не защита, это не firewall.
Я действительно не усматриваю практической опасности в том, что у меня все девайсы глобально адресуемы.
Ну вот в этом и проблема. Я опасность в этом вполне усматриваю. Потому что считать IP-адрес устройства, с которого оно будет рассылать в инет тьму пакетов (которые легко перехватываются как на уровне провайдеров, так и воруются с тех сервисов, на которые стучится устройство) как секретный токен — я категорически против. Секреты не рассылают непрерывным потоком в окружающий мир в открытом виде.
Всегда когда мы говорим v4 — подразумеваем NAT. И DHCP.
Когда мы говорим v4 — подразумеваем, что любая домохозяйка ставит себе роутер, который прикрывает её локалку от злобных хакеров в этих ваших интернетах. А для не домохозяек, а вполне квалифицированных админов и разработчиков, которым нужно открыть снаружи доступ к определённым сервисам в локалке, мы подразумеваем, что в инете полно простых инструкций по настройке файрвола, что по умолчанию обычно всё закрыто на роутере и надо включать проброс портов, и в целом кто угодно может справиться с этой задачей имея квалификацию на порядок ниже моей. А вот как справиться ровно с той же задачей в случае IPv6 до сих пор до конца неясно ни мне, ни многим не менее квалифицированным инженерам в этом обсуждении. И это — факт. Нам — неясно. Хотя мы интересуемся, хотим и пытаемся разобраться, делали несколько подходов в эту сторону, и т.д. и т.п. Поймите уже наконец: то, что нам всем это сложно — это ФАКТ. То, что нет простых инструкций, как это решается — это ФАКТ. Не потому, что я так сказал, а потому, что это написано в куче комментариев в этом обсуждении.
А безопасность — это уже совсем другой аспект.
Не другой, а основной. Я без проблем могу настроить IPv6, проблема только в том, что я не могу настроить его с уровнем безопасности эквивалентным моим текущим настройкам для IPv4 не потратив на это несколько недель, которых у меня на это просто нет.
Не нужны прямые коннекты — возьмите и настройте файрвол на роутере. iptables умеете же? 6tables то же самое. NAT же — это не защита, это не firewall.
Согласен насчёт NAT. А насчёт "возьмите и настройте" — проблема именно тут. IPv6 сложный. IP-адреса меняются динамически, выдаются множеством способов, у одного хоста их одновременно кучка выданных по-разному, что и как можно блокировать в ICMPv6 вообще неясно, насколько безопасно всё это не блокировать тоже неясно, к чему может получить доступ или что переконфигурировать в сети случайно залетевший пакет — неясно… И, снова это повторю, нет простых инструкций как всё это решать: как построить максимально закрытый файрвол, учитывающий все возможные фичи IPv6, как в нём открывать точечный доступ к отдельным сервисам в локалке, как в нём открывать точечный доступ к динамическим сервисам в локалке (те самые игры), etc.
Единственное решение этой проблемы, которое я пока услышал — каждый хост должен файрволить себя самостоятельно, открывая только те порты, которые считает необходимым. Это звучит разумно, но только на первый взгляд. На второй выясняется, что у нас банально нет возможности заставить каждую кофеварку адекватно защищать себя файрволом, что часть ресурсов должна быть доступна — но только из локалки… и в результате мы всё-равно возвращаемся к тому, что единственный рабочий вариант — это настроить файрвол на шлюзе между инетом и локалкой. А как его настраивать, чтобы было не менее безопасно чем в v4… ответа пока нет.
не потратив на это несколько недель, которых у меня на это просто нет.Такой набор правил полностью соответствует 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 ACCEPT1. Остальные порты не предназначены, согласно IANA, для динамической аллокации, но вполне предназначены для статической (программа явно запросила конкретный номер).
2. Эта конкретная рекомендация IANA очень плохо соблюдается. Например, на Linux умолчательный диапазон уже много лет как [32768..60999], и менять его они не собираются. Вы собрались зарезать всю работу под Linux?
Или вот я смотрю на свой Linksys SPA-942, у него диапазон портов для медии — 32768..49999. Нужно перестроить все подобные устройства?
Что-то ваша теория, мягко говоря, не выдержит первой встречи с тяжёлым предметом, который в вас кинут пользователи за попытку введения такой полиси…
Т.е. то, что Вы полностью заблокировали передачу ICMPv6 между локалкой и инетом — это норм и ничему мешать работать не будет?
Ещё остался открытым вопрос как открывать отдельные ресурсы в локалке снаружи, учитывая что IPv6 этих ресурсов меняется и неясно, как его определять.
Адрес основанный на МАК не меняется вообще. Меняются только временные, а на них ничего открывать не нужно и даже вредно. Стандартная NAT подобная политика им подойдёт.
Ожидаете ли Вы, что провайдер зашлёт Вам червя через дыру в IPv6-стеке?
Честно? Ну, многие не ждали, что провайдеры будут вытворять то, что они прямо сейчас вытворяют. Я не готов строить безопасность сети на предположениях о том, чего сделает или не сделает провайдер. Тем более, что провайдер (в терминах прямого линка) не один — у меня и провайдеров два, и кучка VPN в разные компании поднята…
Меняются только временные, а на них ничего открывать не нужно и даже вредно.
Как я уже тут писал, попробуйте объяснить это всем тем сервисам и устройствам, которые по умолчанию уже слушают на :: и 0.0.0.0.
Поэтому давайте вернёмся к исходному вопросу: как именно нужно настроить файрвол для IPv6 так, чтобы уровень безопасности был не ниже текущего?
- Сеть должна быть полностью работоспособна, разумеется.
- Из инета должен быть доступ только к тем сервисам в локальной сети, к которым он открыт на файрволе.
- Из локалки должен быть полный доступ в инет.
- Перенастройка "более безопасным способом" устройств и сервисов в локалке — не вариант, проконтролировать на каких интерфейсах слушает каждая умная лампочка и перенастроить её — нереальная задача, если мы говорим о массовом внедрении.
- Требуемый уровень доверия провайдеру — нулевой, как и сейчас.
- Ну и по мелочи всякое, защита от спуфинга (если она нужна в IPv6), поддержка протоколов вроде ftp/irc, fail2ban (что, таки банить подсетями /64?), etc.
Ещё лично мне актуален вопрос как без NAT в IPv6 делается multihoming — те самые два вышеупомянутых провайдера — они же не просто так, а для резервирования, и оно должно продолжать работать. Что происходит с исходящим IPv6 машины в локалке когда пакет наружу уходит через резервного провайдера когда основной лежит? Точнее, как на этот IPv6 придёт ответ?
Требуемый уровень доверия провайдеру — нулевой, как и сейчас.ARP и DHCP от провайдера принимаете? Значит не нулевой. С тем же успехом можете доверять ICMPv6(fe80::/10 по крайней мере).
Ну и по мелочи всякое, защита от спуфинга (если она нужна в IPv6),
А как Вы защищаетесь с IPv4?
поддержка протоколов вроде ftp/ircВ Linux соответствующие модули conntrack реализованы. И они в общем то общие для протоколов IPv4 и IPv6.
fail2ban (что, таки банить подсетями /64?)Да.
Ещё лично мне актуален вопрос как без NAT в IPv6 делается multihomingВ домашних условиях, никак. Но и NAT для IPv6 в общем то есть. И обычный и stateless 1 в 1.
ARP и DHCP от провайдера принимаете?
ARP — возможно, по крайней мере я ничего там не перенастраивал. А что, это создаёт какую-то угрозу?
DHCP — нет, все настройки статические. Точнее, по одному провайдеру статические, а второй через 4G-модем, так что модем-то принимает DHCP, но вот у меня локальный интерфейс в сторону модема настроен статически на 192.168.x.x.
А как Вы защищаетесь с IPv4?
Ручками выполняю работу rp_filter через iptables. Причина — с включенным rp_filter не работал OpenVPN.
В домашних условиях, никак.
О-па. Что так? Я как-то наивно полагал, что уж с этим-то проблем не будет, это-ж фича, а с фичами в IPv6 всё скорее излишне, нежели нехватка.
Ну почему же "для бизнеса" и "за много денег", с чего Вы так решили?
У меня один канал 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.
И вот скажите, что из всего этого так дорого или сложно, что делает это доступным только "для бизнеса" и "за много денег"?
Потому что считать 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? Да, можно тыкать в них, говорить что они не правы, что каждый надо конфигурировать ручками на конкретный IP… но на практике полно обратного, и не все устройства в локалке в принципе возможно перенастроить. На практике вариант внедрения, который подразумевает необходимость проверки на каком адресе слушают все сервисы на каждом устройстве в локалке, обречён на отказ от внедрения.
Серьёзно? Учить все приложения, которые хотят хотя бы получить голосовой поток, UPnP? И обязательно держать такое на раутерах? Тогда, раз им нужна такая функциональность, это лишает 90% разрекламированных преимуществ по сравнению с NAT. Только трансляцию адресов не надо делать, всё остальное осталось так же. Ну и ещё вместо испытанных методов прохождения NAT (STUN, TURN) учить ещё один новый подход через UPnP.
> Эта и другие проблемы обнаружения v6 адресов озвучены в RFC7707.
Аж 4 года назад. Нормального решения за это время не предложили. Что ж, уже 1/4 прогресса сделано. Такими темпами решение будет где-то к 2032?
1. Провайдер выдал /56 (хороший, добрый провайдер).
Статика или DHCP-PD?
2. Как этот же шлюз передаст информацию о выданной сети на раутер отдела, который будет выдавать уже /64 на отдел.
DHCP-PD
3. Что будет, если провайдер сменит этот адрес: как он пришлёт нотификацию, как она пробежится вниз до каждого конкретного компа/телефона/etc, заставляя их сменить адрес.
Кстати интересный вопрос, надо будет проверить на досуге, но скорее всего большая часть производителей не рассчитывала на такой вариант.
4. Как эта смена адреса будет отражена в DNS, поддерживаемом этими раутерами/шлюзами, а также в других средствах вроде Active Directory, если им это нужно.
Тут увы я бессилен, с виндовой инфраструктурой к счастью не приходилось работать. Хотя сдаётся мне что для компании получать от провайдера динамику — признак плохого тона. 99% проблем решится договорённостью с провайдером на статику.
Варианты с домашним устройством дороже 100$ или SOHO дороже 300$ не принимаются. Варианты, где оповещение вниз вплоть до каждого аппарата (компа, телефона, принтера, умного дверного замка...) не раздаётся, и он тормозит часами, прежде чем перезапросить адрес — тоже.
Не знаю как в в длинка/тплинках/etc, в микротике (что забавно он попадает и до 100$ и больше 300$, ибо ось одна на всех) можно настроить время делегирования префикса, опять же нужно проверить на практике, есть у меня большая уверенность что микротик разошлёт всем в сети новый префикс.
Это реально работает, что корневой DHCP сервер передаёт подчинённому, а тот — пинает уже своих листовых подчинённых?
> Кстати интересный вопрос, надо будет проверить на досуге, но скорее всего большая часть производителей не рассчитывала на такой вариант.
Вот как раз я слышал про фиаско поиска такой возможности. А это значит, что динамика тут не работает.
> можно настроить время делегирования префикса
Нужно не время делегирования, а прямой пинок всем, а то и с повторами.
И это я ещё не поднял тему пропинать всех внутри OS (что, если, как сейчас чуть менее, чем все, держат всякие websocket?)
Немного нытья, почему я выпилил нафиг IPv6 из своей небольшой сетки:
1. Совершенно нечитабельные и не запоминаемые адреса. Зайти на удалённую машину вбивая IPv6 руками? Нет, спасибо. Продиктовать его кому-то по телефону? Селестия упаси.
Гораздо проще настроить локальный DNS, но делать это для каждого ресурса совершенно нет желания.
2. Непонятность принципов работы. Я использовал туннельного брокера для получения глобальной подсети, и надеялся что при небольших усилиях смогу получать доступ к определённым ресурсам внутренней сети извне.
Однако реальность была другого мнения. Машины сами назначают себе случайные адреса, маршрутизатор раздаёт адреса, но они не работают извне, raspberry pi вообще отказалась адекватно взаимодействовать с IPv6, выдавая ошибку при попытке обновления.
3. Общая сложность наворотов технологий. Как настроить фаерволл, шоб не накосячить? Как настроить маршрутизацию с внешними сетями? Какие это вообще даёт преимущество лично мне, как «SOHO администратору»?
Я не пытаюсь кого то убедить что IPv6 это плохо, просто рассказываю своё видение как «не специалиста по сетевым технологиям» а как «немного шарящего в сетях чувака»
Я совершенно не понимаю комментаторов, которые говорят что «настраивается в 2 клика», рассуждая с точки зрения обывателя
Ну начнём
1. Совершенно нечитабельные и не запоминаемые адреса. Зайти на удалённую машину вбивая IPv6 руками? Нет, спасибо. Продиктовать его кому-то по телефону? Селестия упаси.
Ну такая себе претензия, DynDNS никто не отменял, думаю в ближайшее время появится такой функционал у большинства девайсов.
2. Непонятность принципов работы. Я использовал туннельного брокера для получения глобальной подсети, и надеялся что при небольших усилиях смогу получать доступ к определённым ресурсам внутренней сети извне.
Однако реальность была другого мнения. Машины сами назначают себе случайные адреса, маршрутизатор раздаёт адреса, но они не работают извне, raspberry pi вообще отказалась адекватно взаимодействовать с IPv6, выдавая ошибку при попытке обновления.
Адреса у вас скорее всего раздались по SLAAC, при таком варианте устройство получает 2 адреса, один постоянный на основе MAC адреса (EUI-64), второй сгенерированный рандомно и сменяемый с некоторым интервалом.
Про «не работали извне», либо у вас некорректно настроен файрвол на маршрутизаторе, либо на хосте. Либо и там и там.
3. Общая сложность наворотов технологий. Как настроить фаерволл, шоб не накосячить?
Да так-же как в ипв4. Разрешить ICMP и входящий трафик для ESTABLISHED/RELATED соединений. Ну и по желанию открыть полный доступ к хостам имеющим свой файрвол, либо для каждого хоста прописывать правила для портов/протоколов на роутере.
просто рассказываю своё видение как «не специалиста по сетевым технологиям» а как «немного шарящего в сетях чувака»
Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.
Собственно говоря настройка файрвола на IPv4 и IPv6 ничем не отличается, просто у вас никогда небыло своей хотя бы /24 белой в IPv4 которая маршрутизируется глобально. Скорее всего вы всю жизнь считали что NAT это файрвол и он защищает всю вашу сеть, что в корне неверно
Согласитесь, чтобы установить роутер в квартиру и сделать «шоб работало» — это уровень домохозяек, но никак не эникейщиков.
В данном случае, мы перепрыгиваем с уровня домохозяйки на уровень полноценного админа, для выполнения довольно банальной задачи.
Мне кажется, это совершенно не приемлимо как в плане безопасности, так и для юзабилити системы в целом
Настроить банальную маршрутизацию — это НЕ админские задачи, максимум — уровень эникейщика. С IPv4 проблем в этом плане никогда не было, как и с фаерволлом для него.
Банальную это прописать шлюз? В таком случае естественно это не админские задачи, вот только про это я ничего и не писал, с чего вы начали переводить стрелки?
Согласитесь, чтобы установить роутер в квартиру и сделать «шоб работало» — это уровень домохозяек, но никак не эникейщиков.
Установить роутер и включить получение адреса по DHCP одинаково легко для домохозяек как для ipv4, так и для ipv6. Выше спрашивали про более сложные конфигурации, выходящие за пределы «домашнего» использования.
IPv6 — 26 лет. Новое поколение выросло. Где функциональность?
Но DNS — это тут не ответ. Как только начинаются реальные проблемы «только где же этот кто-то и куда он мог залезть?» — начинается поиск на уровне IP адресов. И вот тут-то оно и стукнет. Запомнить среднему админу даже пару десятков IP адресов не проблема. А v6?
> Почему-то каждый такой «не специалист, немного шарящий» пытается прикинуться хомячком, а зарится на вполне себе админские задачи, которые хомячкам не интересны и не нужны.
Ну я админом разных уровней, вплоть до CTO провайдера, был 10 лет, так что представляю себе.
Да, проблем не так много по их чисто количеству — длинные адреса, дублирование адресных пространств, сложность одновременной поддержки DHCPv4 и RAv6 (если кому-то нужно), дублирование в DNS (и необходимость управления логики резолвинга), шлюзы адресаций, всё назвал? Но каждая сама по себе бьёт достаточно серьёзно.
IPv6 — 26 лет. Новое поколение выросло. Где функциональность?
А кто его за последние 26 лет торопился внедрять и тестировать в массах? По вашему IPv4 на старте не имел проблем и там всё сразу было?
Но DNS — это тут не ответ. Как только начинаются реальные проблемы «только где же этот кто-то и куда он мог залезть?» — начинается поиск на уровне IP адресов. И вот тут-то оно и стукнет. Запомнить среднему админу даже пару десятков IP адресов не проблема. А v6?
У админа пара триллионов серверов в сети? Запомнить пару десятков адресов точно так-же просто. Если у вас проблемы с запоминанием — это не проблема протокола.
Все проблемы что вы перечислены чисто надуманные и относятся к разряду «я привык на ipv4 и нафиг мне ваш ipv6, чего вдруг я должен что-то ещё изучать и понимать для внедрения?». Хотя там все новшества изучаются за один вечер неспешно.
Нужно дождаться массового внедрения (хотя бы 50% мирового трафика) и поддержки у 80% производителей софта/железа, тогда уже можно будет говорить о реальных проблемах, а не об этих детских придирках.
Лично у меня пока никаких проблем не возникает с внедрением IPv6 (кроме тугих провайдеров не желающих разбираться).
Проблема с миграцией адресов в сети по сигналу от провайдера — не требует какого-то особого «тестирования». Она понимается любым, кто хотя бы 5 минут спокойно посидит подумает над проблематикой и захочет решать осмысленно, а не затыканием дырки — и, кстати, неоднократно озвучивалась ещё в 90-е. Но ни вендоры, ни IETF оказались не заинтересованы в минимальном предвидении хотя бы на полшага вперёд.
> Все проблемы что вы перечислены чисто надуманные
Ни капельки. Даже проблема размера адреса это следствие известного правила «7±2»: v4 адрес ещё влезает в объём запоминаемого одной порцией, v6 — уже надо специально дробить на части и применять особые мнемотехники. Это, да, не юзерам (большинству) головная боль, это админам.
Если вы лично от этого не страдаете — считаем, вам повезло.
> Хотя там все новшества изучаются за один вечер неспешно.
«Изучить новшества» да, можно за один вечер. Но от этого до реальной практики — километровая пропасть.
> а не об этих детских придирках.
Вот эти «детские придирки» и начали реально выстреливать на вопросе того же использования NAT.
Она понимается любым, кто хотя бы 5 минут спокойно посидит подумает над проблематикой и захочет решать осмысленно, а не затыканием дырки — и, кстати, неоднократно озвучивалась ещё в 90-е. Но ни вендоры, ни IETF оказались не заинтересованы в минимальном предвидении хотя бы на полшага вперёд.
Если вендоры и IETF не приняли это за проблему то тут два варианта
1) Это действительно не проблема
2) Это проблема касается крайне малого процента людей и видимо вызвана изначально неправильной структурой сети.
Вот эти «детские придирки» и начали реально выстреливать на вопросе того же использования NAT.
Понятно, я походу общаюсь с толстейшим троллем который даже понимать не хочет зачем IPv6 был создан. А одна из причин его появления это полный отказ от NAT, который вообще появился как костыль на половине жизненного пути IPv4
Вы общаетесь с тем, кто 1) наблюдал ещё очень ранние шаги и хайп по поводу будущих перспектив IPv6, 2) в отличие от (похоже на то) большинства присутствующих, читал не только отдельные финальные RFC, но ещё и обсуждения и мотивации, а также плотно наблюдал несколько попыток радостного внедрения, с их последствиями.
Эмоции мне ваши пофиг, так что про тролля можете не фантазировать. А вот ответы на возникшие вопросы, неожиданные интересные мысли — очень даже, но, видимо, их тут уже не будет.
> А одна из причин его появления это полный отказ от NAT
Верно — в детских фантазиях его первых авторов так и было бы. Но это было ещё в том интернете, где не было ни спама, ни хакеров в нынешнем количестве, и где вообще защищаться ни от чего не было нужно (а червь Морриса пробежал и был прочно забыт, как курьёз), и даже «два Bay» ещё не взрывались. Для нынешнего мира все эти наивные мечтания не годятся в принципе.
> Это проблема касается крайне малого процента людей
Верно, те, кто сейчас может наткнуться на такую проблему — вытребывают статические адреса. Но это пока не началось реально широкое распространение за пределы мобильщиков и прочих чисто-end-user групп плюс высоких корпоратов.
> и видимо вызвана изначально неправильной структурой сети.
Да-да, плавали, знаем. «У вас кривые руки» на любое отклонение от генеральной линии партии, 640KB хватит всем, а пони розовые и летают. Заранее прошу: если нет конструктивных ответов — не увеличивайте локальную энтропию.
Вы общаетесь с тем
я правильно понимаю, то с модератором RU.UNIX.PROG?
Но это было ещё в том интернете, где не было ни спама, ни хакеров в нынешнем количестве, и где вообще защищаться ни от чего не было нужно
только причём тут NAT, это уже раз 20 обсуждалось вроде бы в комментариях к этому посту, что это решается firewall'ом (частью которого может являться NAT; а может и не являться).
но NAT нужен, кто же спорит.
например, когда мне нужно дать доступ из какой-то сети со своими адресами к интернету, и нет желания/возможности договориться с провайдером о маршрутизации адресов этой сети.
Да.
Только что толку, если последний активный тред в ней был 2 года назад, а предпоследний — летом 15-го.
Ну, могу постить в неё копии заметок из блога, поможет?
> только причём тут NAT, это уже раз 20 обсуждалось вроде бы в комментариях к этому посту
И я дважды отвечал на это, что никакой файрволл без NAT не даст сокрытия внутренней структуры сети и корреляции между её участниками, и что это может быть реально критично для многих.
Остальные 18, или около того, я уже не комментировал, но от этого идея выставить ну не голую попу, а попу под стеклом, всё в тот же Интернет — лучше не становится.
> но NAT нужен, кто же спорит.
И не только в том случае, что вы вспомнили.
Он должен поддерживаться и быть штатно доступным.
Случай, что вы описали, тоже показателен.
Ну, могу постить в неё копии заметок из блога, поможет?
нет, конечно.
fido мёртв, кто же с этим спорит.
но именно профессиональные эхи мне жалко.
P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )
RU.UNIX.BSD на удивление живая. Но там ветераны :)
Для RU.UNIX.PROG таких не нашлось, а следующее поколение думает уже на другом уровне и другими категориями — это типа тех, кто только Linux, но с nodejs в контейнере. Им та тематика тупо не нужна.
> P.S. а в FAQ заглядывал в последний раз в этом году, кажется.
нет желания поддерживать? или всё, что хотелось сказать, уже сказано? )
Вопросов не задают. А сгружать весь stackoverflow в него как-то некошерно.
Я умом понимаю все те плюсы, которые перечислены. Но с точки зрения обеспечения безопасности и настройки фаерволла, который делает нечто большее, чем блокирует входящие подключения — глаза пока ещё боятся, если честно.
Ну т.е. с одной стороны декларируется (автором статьи, как минимум) "настоящий" Интернет, а с другой стороны мы прикрываемся магией conntrack, который должен определить какой UDP/ICMP/другой левый не-TCP-протокол пакет относится к мифическому "соединению", а какой нет? И для корректной работы которого хотя бы с некоторыми известными ему протоколами нужно ещё не забыть собрать и подгрузить модули-helper-ы.
С 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 — тут уже второстепенное.
Я пропущу про жизнь Маши и Пети вместе (непонятно, они за одним 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 в полный рост: если там файрволлы с обеих сторон и их нельзя изнутри убедить «впусти мне входящие и дай свой адрес» — связи не получится.
Если вы имеете в виду соединение с разных внутренних адресов на один и тот же удалённый адрес, то 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, чтобы не плавать настолько в азах.
Если вопрос в чём-то другом — сформулируйте так, чтобы его можно было понять.
>> Если вопрос в чём-то другом — сформулируйте так, чтобы его можно было понять.
О каком порте 5000 на каком из хостов идёт речь? Пожалуйста, формулируйте сразу так, чтобы не надо было вытягивать подробности клещами.
Если у онлайн-игры сервер _снаружи_ локалки Маши и Пети, то ситуации типа «игра слушает на этом конкретном, заданном жёстко самой игрой, порту» не бывает. Клиентская сторона никогда не фиксирует у себя конкретный порт, она полагается на аллокацию операционной системой динамического номера порта, и или открывает одно соединение с этого порта, или, если ей нужны дополнительные соединения, передаёт уже полученный порт другой стороне или серверу. Времена, когда фиксировали клиентские порты, закончились вместе с первыми опытами жизни FTP в гетерогенной среде (и не только из-за NAT), то есть это не позже середины 90-х. Сейчас просто нет таких требований.
(Исключение: есть игры, которые для сетевого режима используют один и тот же порт для всех участников и бродкастят сообщения. Но это работает только в пределах одного L2 сегмента, не масштабируется на большее количество, и я не видел такого со времён первой халвы: кажется, последний, что такое умел, был Duke3D. А, может, ещё раньше закончилось, память уже теряет такие подробности.)
Если кто-то из Маши и Пети поднял у себя в локалке _сервер_ игры, то у них будет один сервер. Именно для этого сервера строится явное правило статической трансляции внутрь: все входящие соединения на порт 5000 перебрасываются на указанный внутренний адрес на порт 5000. Эта возможность присутствует даже на мелких домашних раутерах, начиная со знаменитого DI-604, и тем более на любых более продвинутых средствах. Для внутреннего получателя его IP будет внутренним, но IP другой стороны — мировым (если это не в его локалке). Исходящие пакеты от него будут транслироваться с заменой адреса отправителя на установленный настройкой внешний адрес.
Второй участник (предположим, что сервер у Маши — тогда это Петя) может подключаться к серверу Маши или по внутреннему адресу, или по внешнему — это на большинстве мелких раутеров тоже работает.
Если Маша и Петя хотят каждый у себя поднять по серверу… да, в этом случае им надо будет прописать разные порты в конфигурации статического NAT — и это ничем не будет отличаться от ситуации, например, выделенного сервера в ДЦ с одиночным IP и двумя процессами сервера игры на разных портах.
Если я всё ещё не угадал… ну пока у меня есть настроение — можете ещё покрутить, но лучше вы всё-таки научитесь формулировать так, чтобы было понятно с первого раза. Достаточный набор терминов для этого или присутствует в базе IP (хост, порт), или мной уже несколько раз упомянут в описании NAT (как внутренний, внешний и удалённый адреса).
«Это» это где? В том, что вы хотели получить? Ну тогда это случай варианта 1 из моего описания, с некоторой дополнительной службой, которая оповещает участников об адресах друг друга, но дальше они взаимодействуют напрямую. И при этом ни хосты, ни порты не фиксируются, а определяются через эту службу имён.
> Такой длинный ответ вместо простого «нет».
Если ответ сократить до одного слова, то это «да». Но вы его не поняли.
> Ясно, спасибо.
Таки не за что. У меня не сработал /dev/telepathy, а вы не захотели ни объяснить, ни понять. Что ж, с таким я бессилен. Другие, надеюсь, захотят.
И всё таки ответ "нет".
Пример. MMORPG, у которой сервер работает только как сервер авторизации, остальная связность работает как огромная mesh-сеть, где теоретически каждый может быть связан с каждым, на практике образуются ячейки связанных между собой игроков. Каждый из компов игроков — это тоже сервер по сути. И их может быть десятки тысяч. Если у кого-то сетевые проблемы, то ответ техподдержки категоричен и вынесен в FAQ — получите выделенный белый "адрес" и откройте порт XXXX на входящие соединения. Как, нас не волнует.
И вот как раз с территории бывшего уже, я так понимаю, СНГ, больше всего стонов "мой провайдер белые адреса принципиально не выдает, что мне делать?" И стандартный ответ, "поздравляем, похоже вы зря потратили на игру своё бабло".
(Но, поднявшись над конкретной проблемой, это выглядит примерно такой же дикостью, как если бы они потребовали держать связь по UUCP поверх диалапа и Netware на узлах.)
Про ценность такой односторонности уже написал рядом.
Но, кроме того, NAT позволяет скрыть: количество хостов внутри сети, их группировку по сетям; группировку запросов по их источникам (до хоста); связность между запросами во времени (приходят с одного хоста или с разных). Для какого-нибудь фейсбука это, безусловно, зло — он хочет отслеживать каждого юзера отдельно. Но для клиента, которому реально надо хоть немного параноить, это безусловное благо. Потому NAT будет сохраняться и для IPv6, независимо от доступности адресов — и я бы его рекомендовал всем, по этим же причинам.
— «белого» для входящих соединений
— «серого» периодически реролящегося для исходящих соединений.
То есть те соединения, которым нужно долговременное существование, будут постоянно обрываться и клиентская система должна будет их пересоздавать? Вы серьёзно?
Или из-за многих разных :)
Ответ понятен, спасибо. Как решение в принципе это может работать, да. Но откровенно выглядит как «на какое только извращение люди не пойдут, чтобы только не использовать уже проверенные годами технологии». :crash:
Windows 10. Хром и открытые на фейсбук закладки. А если есть одновременно и IPv6, и IPv4, то винда по умолчанию всегда использует IPv6. Через сутки количество временных адресов на интерфейсе переваливает за сотню. Именно из работы этого механизма в сочетании с забавным механизмом доставки push-сообщений.
Вообще, противники IPv6 в чем-то правы, граблей по нем раскидано немеряно, и, хотя жить они в общем не мешают, по крайней мере обычному пользователю, которому всё равно, что там работает транспортом, но сетевикам про эти нюансы лучше знать.
От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма. А то, что соединения постоянно обрываются, — так это вы сами придумали.
Ну вы сами сказали про 2 адреса, а не произвольное количество :) Единственный вывод. Если недоговариваете — будьте готовы к подобному. RFC почитаю на досуге, спасибо.
> От себя замечу, что иметь более одного (и даже более двух) v6 ip-шника на интерфейсе — это норма.
Для v4 это тоже уже много лет как норма. Вопрос в том, как между ними распределять роли.
Я так полагаю, за счёт чего-то определяется, что на один адрес соединения вешаются по умолчанию, а на второй — только явным указанием в bind()? Если да — можете не отвечать, найду в тех же RFC. Но если нет — то прямо работать не будет.
NAT это просто сломанная связанность между хостами
И да, что конкретно ломает домохозяйкам (подавляющему большинству пользователей сети)?
Односторонне ограниченная, а не сломанная. Про перерезанный провод — спишем на полемический задор.
> Для безопасности всю жизнь предполагалось и предполагается использовать firewall.
Это вы рассматриваете единственный аспект безопасности — отсутствие возможности прямого несанкционированного доступа извне.
Почему вы игнорируете, например, необходимость сокрытия внутренней структуры, количества хостов, группировки размещений сервисов, связи между запросами разных клиентов?
Кроме безопасности: как вы будете отражать факт смены адресов провайдером так, чтобы это прошло прозрачно для пользователей? Минимум потребностей я описал тут, причём не уверен, что не пропустил ничего важного.
NAT никак не изолирует внутреннюю сеть от подключения извне. https://habr.com/ru/post/402187/#comment_18100189
От внешних угроз защищает фаервол.
но входящие соединения из сети2 в сеть1 не попадут.
Попадут. Если сеть2 знает адрес конкретного компьютера из сети1 и отправит запрос к этому адресу через роутер, то роутер его прекрасно перенаправит по своим маршрутам в сеть1 без всяких там NAT, независимо от его наличия или отсутствия.
Я пожертвовал своей сетью и перед написанием комментария провёл эксперимент, подключив к своему роутеру вместо интернет-провайдера один из компьютеров, который имитировал сеть2. И он прекрасно получал доступ к сети1 (домашней сети за роутером) в обход NAT, пока я на роутере не врубил фаервол.
прекрасно получал доступ к сети1 в обход NAT
Можно по подробней с айпишниками про этот фантастический кейс?
Как можно через NAT достучатся даже зная внутренний айпишник (например на 192.168.1.10), без проброса портов?
Для TCP это в принципе невозможно, для UDP есть возможность, но только когда сам 192.168.1.10 полез по UDP через NAT.
Если же 192.168.1.10 только ожидает подключения, как через NAT можно к нему достучаться?
они про подключение по l2 к wan-порту роутера
Как можно через NAT достучатся даже зная внутренний айпишник (например на 192.168.1.10), без проброса портов?
Очень просто: отправить роутеру IP-пакет, в получателе указав нужный адрес (192.168.1.10). Роутер просто его отроутит по прописанным в нём маршрутам и всё. NAT'у здесь просто неоткуда взяться — он действует, только если отправлять пакеты непосредственно на адрес роутера, причём адрес принадлежащий сети2 (то есть не 192.168.1.1, а какой там интернет-провайдер выдаст роутеру)
Для TCP это в принципе невозможно
Это работает для любых протоколов на базе IP, в том числе для TCP. Я проверял это, открывая http-сайтик, запущенный на своём компьютере в сети1, и на компьютере из сети2 он успешно открылся в обход всех NAT.
От внешних угроз защищает фаервол.Если немного пофилософствовать, то в контексте обсуждения глобальной адресации/маршрутизации первично то, что у внутренних хостов нет реальных IP адресов, поэтому и реализован NAT (это вторично). И безопасность — это следствие самого факта серой адресации в локальной сети, а не NAT. А кто там именно в вашей коробке занимается отбрасываением пакетом — натер, роутер, файрвол или полисер — это уже не имеет отношения к глобальной адресации/маршрутизации
Вариант, что интернет-провайдер является или может стать злоумышленником, не рассматривается принципиально?
В общем случае (включая вырожденные виды) — не изолирует. Типичный — изолирует от любых не инициированных изнутри соединений, кроме явно прописанных в конфигурации. (Сразу оговорюсь: см. конец сообщения про тот случай, который выдаётся за фатальную проблему.)
NAT устанавливает ассоциацию внешнего адреса внутреннему. У большинства их множество внутренних адресов больше множества внешних адресов, доступных для назначения NAT'ом — этого уже достаточно, чтобы произвольный входящий пакет не имел внутреннего адресата, если в NAT не назначена ассоциация для этого. Исключением являются те вырожденные NAT, для которых конструктивно установлено такое соответствие 1:1. Я ещё ни разу не видел такого вживую применённого, и сомневаюсь, что увижу.
Symmetric NAT (в терминах STUN RFC), кроме того, не позволяет проникнуть на внутренний адрес запросу ни с какого удалённого адреса, кроме того, для которого этот внешний адрес был назначен. Для Cone типа такое возможно — на время жизни соответствующей ассоциации. Но Cone применяется в основном на домашних раутерах и крайне нетипичен даже для small office сегмента.
Обсуждение по ссылке абсолютно неконструктивно, главный флеймер этого треда откровенно уводит разговор в сторону, а оппоненты оказались не в состоянии возразить по сути.
> От внешних угроз защищает фаервол.
Само правило работы NAT «впускаем только по наличию ассоциации» тут уже является таким элементов файрволла. Если в устройстве нет явных ляпов дизайна, то дополнительный файрволл для этого и не нужен.
Наличие ingress filter при этом я считаю элементом обязательной конструкции. Проблема обсуждения по ссылке — и ваших примеров — в том, что зацикливание на возможности «а давайте отправим напрямую на внутренний адрес через хак» уводит от обсуждения принципиальной ценности NAT для большинства случаев, включая крякеров из Интернета (что на порядки типичнее взлома через соседа по локалке, который может подделать целевой MAC).
правда это создает необходимость в механизме похожем на upnp :) а его нету
нет в жизни счастья
что иногда для всяких там юдп весьма нетривиальная задача без таблиц нат :-)
NAT — не файервол.
NAT — не файервол.
NAT — не файервол.
…
NAT — не файервол.
Нет, NAT не обеспечивает большей безопасности по сравнению с прямым соединением.
Вы изначально предполагаете добропорядочность внешней сети. Попробуйте представить, что вся сеть за роутером с NAT подконтрольна злоумышленнику. Результаты вас огорчат.
А я, к примеру, не могу себе представить, почему я должен доверять инфраструктуре своего провайдера.
Хотелось бы все таки узнать, как NAT не защищает (он же не файрвол) и позволяет злоумышленнику отсканировать моё устройство за ним?
Я, находясь во внешней по отношении к вашему роутеру сети, шлю ему пакеты с src своим, dst — перебираю 192.168.0.0/16, 10.0.0.0/8 и 172.16.0.0/12
Ваш роутер совершенно честно передает пакеты внутрь вашей сети, он же не файервол, правда? Внутреннее устройство отвечает на мои запросы и через роутер (он же не файрвол, да?) отправляет их во внешнюю сеть. Всё, мне доступны все ваши внутренние ресурсы. Как я это делаю? Да как угодно. Ломаю комп ваших соседей и маршрутизатор вашего провайдера. Но в большинстве домосетей всё гораздо проще, фомкой открываю ящик с коммутатором у вас подъезде и просто включаюсь к вам в разрыв. Или рву кабель, если он проложен по стенке в коридоре. Да у меня просто уйма разных методик, как это сделать.
Итак, чтобы не взломать, а просто хотя бы найти хост за NAT-ом, нужно что-то одно из:
- Взломать другой хост за NAT-ом.
- Пробраться незамеченным в помещение, соединенное кабелем с атакуемой сетью, со специальным инструментом.
- Взломать маршрутизатор интернет-провайдера.
Это достаточно высокий уровень безопасности. Меня такой вполне устраивает.
Не пугайте страуса, пол бетонный (с)
Ваш этот "достаточно высокий уровень безопасности" имеет неопределенную величину, от нуля до бесконечности(нет, не правда, гораздо меньше).
Но я ничего не собираюсь доказывать. Я как был убежден, что должно быть защищено каждое устройство в сети, даже локальной и уже защищенной, так и буду дальше считать, что оно, это устройство, всегда находится во враждебном окружении. А если каждое устройство в локальной сети защищено файерволом, на котором запрещено всё, что не нужно для правильного функционирования этого устройства, политиками безопасности запрещены и не используются пароли, подверженные брутфорсу, а где возможно, так пароли и вообще не используются, а версии софта не имеют известных уязвимостей, то мне всё равно, есть ли возможность проникнуть ко мне во внутреннюю сеть. Это просто только один из многих заборов.
Хотел бы я посмотреть на твою домашнюю сеть. У меня есть подозрения, что кто-то здесь не до конца честен.
Всё это так, Вы абсолютно правы. Но это в теории. А на практике большинство домашних пользователей сейчас защищает в основном комбинация их NAT плюс добропорядочность (по крайней мере в данном отношении) их провайдера. При переходе на IPv6 они этой "защиты" лишатся… и самое плохое, что никто их об этом не предупредит, не научит правильно настраивать файрвол "для IPv6", и даже не выдаст роутер с изначально безопасно настроенным файрволом.
Простейшей образованности??? Мне кажется, Вы сильно оторвались от реальности. Нет ничего плохого в том, чтобы чем-то сильно увлекаться, писать такие статьи, и агитировать за свою точку зрения в дискуссии, НО — берега терять при этом всё-таки не стоит.
Я считаю, что лично у меня эта "простейшая образованность" имеется: я не сетевой инженер, но я разработчик со стажем в 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 не даст мне ничего, кроме проблем, и ни одной причины этим заниматься я пока не вижу.
Работая с IPv4 и IPv6 я наоборот увидел что с IPv6 значительно проще работать, да и в самом протоколе его link-local-ы и прочие полезности очень упрощают жизнь. Да даже просто банальное огромное количество адресов — очень удобно, не нужно ютиться. Но да, соглашусь что если это в купе с IPv4 делается (dual stack), то это увеличивает повернхность атаки и теперь нужно буквально с двумя стэками работать сетевыми. Но так всегда: переходный период, когда лошади и конные повозки существуют совместно с автомобилями, означает что какое-то время будет сложнее, чем оставаться на лошадях или жить сразу полностью с автомобилями.
Так и я о том же. Моей образованности как раз хватило, чтобы понять, что IPv6 мне пока лучше всего выключить вообще. Именно потому, что я примерно представляю себе сложность настройки IPv6 чтобы получить эквивалент моим текущим настройкам для IPv4, и понимаю, что в конечном итоге потратив на это недели две всё, что я получу взамен — ухудшение безопасности за счёт увеличения поверхности атаки, и всё. Никаких "плюшек" от IPv6 я не получу, просто потому, что у меня нет потребности открывать доступ снаружи в свою локалку, нет потребности увеличивать связность между текущими сетями, нет даже потребности (пока) подключаться к IPv6-only сайтам.
И, будем откровенны, у большинства обычных пользователей интернета образованность в этой теме сильно отстаёт от моей. И даже если они искренне попытаются настроить себе файрвол для IPv6 (ха-ха-ха! вот прям сейчас они бросят свои дела и займутся этим… они вообще даже слов таких не знают, в основной массе) — вряд ли у них это получится сделать достаточно качественно. Скорее всего этот файрвол в их исполнении будет больше напоминать закрытые ворота посреди чистого поля.
Ну у кого какой опыт и выводы. Ничего не бывает что одинаково бы всем нравилось или бы все соглашались с чем-то. У меня прямо противоположный опыт: я получаю массу экономии времени, удобства, отсутствия раздражения (потому что удобно).
Большинству пользователей я уверен что достаточно иметь firewall разрешающий исходящие соединения, запрещающий входящие (ну плюс ICMPv6 и другие мелочи). Это можно производителям ОС и делать как preset, мне кажется, ибо он удовлетворит 99.(9)% людей, как удовлетворяет NAT без firewall.
Да, наверняка можно сделать такой preset. Проблема в том, что сначала 20 лет провайдерам было сложно/дорого поменять своё оборудование, а теперь прикиньте, сколько лет займёт поменять домашние роутеры всех пользователей по всему миру — потому что в текущих роутерах таких preset-ов нет (впрочем, тут я могу ошибаться, но скорее всего — нет, либо те, что есть, сделаны чисто формально и не выдерживают никакой критики — просто потому, что производители никогда не заботятся о таких вещах пока их конкретно не прижмут).
Если под брандмауэром Windows вы имеете в виду поделие, которое управляется при помощи wf.msc, то я вас уверяю, что оно не работает даже для IPv4. Чтобы просто браузер поставить, нужно включать в нем правило вида Разрешить любой трафик любой программе на любой адрес, иначе ничего не скачается.
Вы вообще уверены в том, что у большинства домашних пользователей этот NAT вообще существует? Многие просто включают кабель от провайдера в свой нотбук и даже не подозревают о вашей надежде, что NAT их защитит.
Может кто-то так и делает, но у очень многих сейчас дома намного больше одного устройства — помимо ноута есть умные телевизоры, телефоны, планшеты, нередко второй компьютер… так что чаще всего этот кабель воткнут в WiFi роутер (нередко предоставленный и настроенный провайдером).
У меня сын некоторое время работал в саппорте интернет-провайдера, у него совсем другие сведения. Умные телевизоры, планшеты, два компьютера…
Вы очень преувеличиваете средний уровень обычного домашнего пользователя.
Больше двух третей абонентов обычных домосетей — обычные одиночные компы или нотбуки. И да, огромное количество пользователей даже не догадываются о том, что через WiFi роутер можно подключить несколько потребителей интернета к одному кабелю. Из статистики моего сына одним из самых популярных вопросов пользователей является "у меня уже есть ваш кабель, сколько стоит провести ещё один такой? А разветвители для интернета бывают?"
А ещё дешевые тарифные планы у мобильных операторов сделали ненужными подключения по WiFi для смартфонов. А зачем?
И ещё один аргумент. Вы видели, как выглядит радиоэфир на частоте 2.4ГГц в центре микрорайона из пяти 30-этажных жилых домов? И как оно "надежно" после этого работает? Обычный пользователь, поигравшись пару недель в "танчики" по вайфаю и сломав вокруг все ломающиеся предметы, звонит в техподдержку и рассерженно орет "ваш интернет нихрена не работает!", и, получив совет от саппорта попробовать включить кабель в порт компа напрямую, обнаруживает, что интернет таки стабильно работает, после чего исполняется чувства праведного негодования по поводу мошенников, которые ему этот вайфай предлагали.
У меня сын некоторое время работал в саппорте интернет-провайдера, у него совсем другие сведения
Вы видели, как выглядит радиоэфир на частоте 2.4ГГц в центре микрорайона из пяти 30-этажных жилых домов?
вы сами себе противоречите, откуда же берутся десятки wifi сетей в любой многоэтажке, если NAT'ом (читай домашними роутерами) никто не пользуется? )))
вы сами себе противоречите, откуда же берутся десятки wifi сетей в любой многоэтажке, если NAT'ом (читай домашними роутерами) никто не пользуется? )))
Провайдеры впаривают роутеры с wifi, настраивают, к примеру, ноутбук — и все.
А на телефоне зачем wifi? Ведь это нужно где-то еще пароль взять, а он записан на бумажке, которая потерялась.
Провайдеры впаривают роутеры с wifi, настраивают, к примеру, ноутбук — и все.Ну так и при чем здесь тогда «многие просто включают кабель от провайдера в свой нотбук», если этот самый ноутбук подключен к сети провайдера через его же роутер с NAT? Мне кажется, что сейчас подключить Интернет без роутера провайдера — квест, который «большинство домашних пользователей» не пройдет.
Лично я вот понятия не имею, как подключить GPON МГТС без роутера этого самого МГТС. В последний раз, когда читал — вроде, левые устройства они не дают подключать. Но это не точно.
Не противоречу. Просто когда в зоне досягаемости любого устройства 3000 квартир, даже 25% пользующихся вайфаем — это просто офигительно много. А 5 домов стоящих напротив друг друга по кругу так, что можно прочитать название компании на пакете молока, которые стоит на столе в доме напротив, похоже позволяют на переотражении от соседних домах видеть всех. Вот абсолютно всех.
ну это вы крайний случай таки рассматриваете.
в обычной отдельностоящей девятиэтажке увидеть 20 сетей — обычное дело. и в пятиэтажке 10 тоже. из чего я делаю вывод, что почти у всех, у кого подключен интернет, есть wifi-роутер (неудивительно, провайдеры сегодня предлагают поставить свой роутер пратически бесплатно)
Очевидно у меня в округе какие-то другие провайдеры. Которые выдают просто шнурок Ethernet в квартиру. А роутер у них стоит… ну в Ашане он ровно столько же стоит. Не могу сказать "дорого", но и покупать его будет только тот, кто точно знает, зачем он ему нужен, и почему ему не нужны для других целей эти $25.
Очевидно у меня в округе какие-то другие провайдеры. Которые выдают просто шнурок Ethernet в квартиру
"простому пользователю" куда проще заплатить 10 рублей в месяц и не задумываться. да многие даже и не знают, что в ноутбук или телевизор можно воткнуть сетевой кабель (а стационарного компьютера не имеют вовсе).
Везет. Вот реально завидую. Аренда за 10руб. в месяц. Я бы тоже взял бы не задумываясь. У моего текущего провайдера есть IPv6 прямо из шнурка. С одной сетью /64 и /48 по запросу. Собственно, из-за них я к нему и перешел. Но вот аренды оборудования — вообще никакой.
Я вот недавно у своего провайдера узнавал. Вроде бы как цена аренды рутера 1 руб/мес. Но на самом дешевом тарифном плане (моем) такой опции нет. Чтобы арендовать рутер, мне пришлось бы перейти на тарифный план с такой же скоростью, но на 100 рублей абонплаты дороже. Т.е. получается что цена аренды составила бы 101 рубль, а не 1
На практике абсолютно такой же уровень защиты (нет, на самом деле даже больше) дает одно единственное правило в файерволе на роутере — "разрешить соединения только со стороны LAN. И такой пункт есть в распоследних дешевых SOHO роутерах. И да, обычно он по умолчанию включен. NAT — он не для защиты, это просто костыль.
За вашим роутером находится ваша домашняя сеть 192.168.0.0/24.
На своей стороне я прописываю маршрут в сеть 192.168.0.0/24 через 10.10.10.2. Если у вас отключен фаерволл, то я смогу обратиться к хостам внутри вашей домашней сети.
1. WAN стороны жертвы и атакующего находятся в одном broadcast-сегменте формата «типичный Ethernet». Не выполняется в случае хакера из чуть более дальнего интернета.
2. Это именно broadcast-сегмент с прямым бесконтрольным взаимодействием между сторонами. Не выполняется уже, например, на DOCSIS-сетях, где головные станции пропускают трафик через свой доступ и раутинг, и прямое взаимодействие между клиентами сегмента по их MAC невозможно. Кроме того, некоторые свичи позволяют организовать то же на Ethernet. Не выполняется при подключении каждого клиента персональным VLAN'ом.
Ну да, формально можно засчитать один гол за счёт такого эффекта. Но:
1) Практическая ценность его только в весьма частных условиях
2) Простейший ingress filtering на входе его останавливает, и надо быть совсем зелёным админом, чтобы не поставить такое правило.
Более того, формально, поскольку пакеты проходят в обход NAT, проблема тут не в NAT, а в раутере сбоку от него;) а может, его и нет? NAT ведь не означает раутинг вне NAT механизмов. Нет, что-то гол сомнительный :)
А ещё варианты будут?
Я хоть и "айтишник", v4 знаю на уровне "эникея", имею проблемы с пониманием работы v6. В частности, не понимаю как работает SLAAC, не понимаю почему все орут что нат нужен и позволяет скрыть колво хостов в сети, хотя для обычного пинга в /64 нужно прогнать около 2к экзабайт трафика (при размере всего пакета в 124байт).
Так же есть проблемы с запоминанием адресов. Да, знаю, это проблемы людей, а не протокола, но все же…
Ну а так же мне не ясна работа SLAAC, в плане выдачи доп адресов (выше писали об этом), зачем и как оно работает…
Это нужно изучить, но, большенство комментаторов не хотят этим заниматься, мол, есть v4, работает — не трожь!
p/s/
у меня примерно 20% трафика бегает через v6 (туннель до HE), а еще на работе в ближайшем времени сделаем v6 :3
Плюшки, безусловно, крутые — но для корректной работы ипв6 придётся менять не только л3, но и всю коммутацию. В противном случае все линк-локал фишки будут работать в широковещательном режиме.
Ещё лет 7 назад помню, как один друг, занятый сетевыми технологиями в академической и, одновременно, провайдерской среде утверждал, что переход на IPv6 — дело решённое и через пять лет все будут относиться к нему как к основному, забыв "старый" IPv4 как страшный сон.
Тем не менее, "воз и ныне там" и всё строится по IPv4, IPv6 же интересует лишь энтузиастов и любителей радикально решить их же проблемы, специфичные для четвёрки. Плюс некоторые технологические компании.
Абсолютное и подавляющее большинство пользуется интернетом для потребления контента или для решения конкретной задачи, когда "удобно" — это браузер, клиент или API, "красиво и эффективно" на сетевом уровне — увы, нет, это попросту невостребовано.
Бизнес прекрасно понимает, что решить "костылями" и NAT — в разы дешевле и быстрее, чем переводить software/hardware на IPv6, поэтому и поныне IPv4 остаётся абсолютно доминирующим, а рост IPv6 трафика в основном чисто техническая заслуга отдельных контент-сервисов.
Рискну высказать непопулярное мнение, но поймите меня корректно:
- Я никоим образом не против IPv6, это отличная концепция и, если она действительно станет новым промышленным стандартом — то это отлично, рано или поздно IPv4 придётся менять, обновлять или заменять целиком — это бесспорно;
- Однако, настройка и вообще "запоминание" IPv6 адресов и сетей — это боль;
- Заниматься сменой и/или перенастройкой оборудования — это боль, потому что "и сейчас всё работает", пусть и не через красивые технологии;
- Большинство софта, железа и в целом решений уже согасилось со всеми этими костылями и слоями абстраций;
- Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.
А что про NAT и абстракции — контейнеризация и бурное развитие SDN — это всё позволяет не обращать внимание на IPv6 вообще, для связности с "внешним миром" достаточно будет и одного адреса.
Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.
Ага. При этом как раз то что упоминается в статье как достоинство
У конечного пользователя появляется Интернет, а не удалённый доступ до ряда служб корпораций типа Facebook, ВКонтакте, WhatsApp, YouTube и т.д.!— оно как раз этим самым службам корпораций нафиг и не сдалось. Идеал корпораций — чтобы пользователь фб не знал ничего кроме фб и за пределы его экосистемы носу не казал, а для этого v4 за глаза и зауши достаточно.
Скорее всего потому, что трекать юзера надёжно по уникальному IPv6 (а то и по всей /64, чтобы трекать все его девайсы как единое целое), без всяких кук — мечта для таких корпораций.
Как раз RFC4941, который Privacy Extensions for Stateless Address Autoconfiguration in IPv6, позволяет каждому устройству в IPv6 сети выбирать любой адрес из 4 миллиардов и делать это в любой момент по своему разумению. Windows 10, как самая популярная пользовательская ОС, умеет это делать из коробки. И делает это по умолчанию. Так что трекинг по IPv6 — плохая идея. Гораздо хуже, чем трекинг по адресу IPv4.
Вы в своём ответе проигнорировали эту часть сознательно?
а то и по всей /64, чтобы трекать все его девайсы как единое целое
Это же IPv6, здесь нет бродкастов. Вообще нет. Нельзя обратиться к /64 как к единому целому. Нет никаких признаков внутри /64, одно там внутри устройство, или 4 миллиарда. Ну вот есть у меня дома /64 на всех домашних (пять компов, пять телефонов, два телевизора и планшет) Что трекать? Какой смысл в таком трекинге? Мне от 22 до 61 года, с полом я не определилось, иногда мужской, иногда женский, меня интересуют игры, гитары, электроника, красивые шмотки, подводное плавание, IT, кулинарные рецепты и схема разборки двигателя Skoda Octavia. Угу, вот трекинг по /64
2-3 человека и сейчас могут пользоваться одним компом с одним набором кук. Тем не менее, это не сильно мешает их различать — разные наборы посещаемых сайтов, разные группы интересов, разное время работы, … Но куки можно удалить или вообще заблокировать соответствующими плагинами, а вот свою подсеть /64 скрыть/изменить намного сложнее.
CG-NAT — крайне плохая альтернатива. Достаточно одного спамера в сети, чтобы заблокировали всех, кто за этим NAT-ом сидит. Под спамером я понимаю не только и даже не столько обычного спамера по SMTP протоколу. Просто неимоверное количество сервисов блокирует доступ на уровне IP. И мне совсем не улыбается лишиться доступа к своим любимым фоточкам котиков, потому что в соседнем доме мамкин кулхацер решил развлечься.
Динамическая адресация ломает правила ipsec, а значит и Mobile IPv6. Будет неприятно если Ваш смартфон автоматически настроивший Mobile IPv6 адрес через домашний Wi-Fi, в полночь потеряет с ним связь. И сломает подключение в совершенно другой сети.
В IPv6 процесс смены адреса по RA несколько отличается от IPv4.
Можно жить некоторое время со старым и новым адресом одновременно, причем старый будет использоваться ровно столько, сколько на нем будут открыты соединения. Новые — будут использовать новый полученный адрес.
В IPv6 процесс смены адреса по RA несколько отличается от IPv4.
Можно жить некоторое время со старым и новым адресом одновременно, причем старый будет использоваться ровно столько, сколько на нем будут открыты соединения.
то есть роутер отслеживает, что старый адрес ещё используется, и только потом удаляет запись в таблице маршрутизации?
Отслеживает, что выдавал этот адрес, и тестирует, что он ещё жив. По NDP NUD. Но на самом деле это уже костыль над SLAAC. Сначала мы делаем stateless протокол, а потом костылями подпираем то, что от него отваливается. IPv6 он такой, да. Хотя, DHCP же вроде тоже есть, так что можно сделать один в один, как в IPv4.
Пока не возникнет выгодный, коммерчески эффективный продукт, требующий IPv6 — он будет минорным, потому что ОК, Ютуб и картинки с котами работают и сейчас, что требуется большинству.
Уже сейчас есть, к примеру, VPS IPv6 only c привлекательными скидками. Хочешь IPv4 адрес — добавь $5 в месяц к стоимости. Очень даже стимулирует.
Я думаю, причина очень простая: практически не осталось оборудования, которое НЕ поддерживает IPv6, поэтому чем потом массово апгрейдится на него, нарываясь на всевозможные грабли, куда проще поддерживать IPv6 в рабочем состоянии по мере роста и развития сетей.
А переходить на IPv6 придется, так как операторы домашнего интернета видят свое развитие в предложении дополнительных цифровых услуг своим клиентам, чтобы от канала, который все менее рентабелен, перейти к сервисам. А для этого нужен доступ к устройствам, которые клиенты в том числе берут и будут брать в аренду (всякие приставки, роботы, изделия IoT, и т.д.). Все NAT-ы являются большой помехой в этом деле.
Бизнес прекрасно понимает, что решить «костылями» и NAT — в разы дешевле и быстрее, чем переводить software/hardware на IPv6, поэтому и поныне IPv4 остаётся абсолютно доминирующим, а рост IPv6 трафика в основном чисто техническая заслуга отдельных контент-сервисов.
Дешевле как раз без NAT — у сотовых CGNAT требует немалых инвестиций, к примеру.
Если происходит внедрение, как, например, у МТС — то дальше все работает хорошо и стабильно, абоненты даже не знают, что у них ipv6.
В целом сейчас доля ipv6 трафика — 30% (для тех, кто перешел на ipv6).
Странно, почему habr не переедет на ipv6 :)
Роскомнадзору вы что делать при этом прикажете? Как быть? Вы модуль «ревизор» видали? Тама столько памяти нет сколько этих адресов)))
Дак пусть
З.Ы. У меня, кстати, в России v6 есть. И он будет, просто до какого-то времени будут закрывать глаза на то, что v6 не заблокировать качественно. Ну не умеет железо. Яровая вон тоже три года хотела трафик хранить. До того как выяснилось, что это требует от мирового производства HDD только на Россию и работать.
ящики сорм — это одно, реестр блокировок — другое.
блокировать "плохие" сайты обязан провайдер самостоятельно, от государства только список сайтов и проверки (и штрафы, если плохо блокирует).
P.S. сейчас проверил rutracker.org через ipv6 с "правильным" dns — заблокирован, как и ожидалось
Умеют только самые новые и самые дорогие. Которые надо КУПИТЬ ЗА СВОИ ДЕНЬГИ, ростелеком купит, мелкий провайдер из задрищенска…
В 18 году модуль ревизор точно не умел проверять в6 адреса, ну и сама идея вести реестр запрещенных в6 аресов выглядит настолько идиотской, что проще отказаться от в6
МГТС как раз раздаёт. Динамический правда, и только /64, но всё же раздаёт.
https://version6.ru/isp/mgts
О да! я давеча пару недель вволю налюбился поднимая ipv6 на впсе хецнера :)
А расскажите пожалуйста — зачем вы налюбились, когда он там по умолчанию поднят и настроен?
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 159.69.14.230 netmask 255.255.255.255 broadcast 159.69.14.230
inet6 fe80::9400:ff:fe0a:f139 prefixlen 64 scopeid 0x20<link>
inet6 2a01:4f8:1c1c:2f3d::1 prefixlen 64 scopeid 0x0<global>
ether 96:00:00:0a:f1:39 txqueuelen 1000 (Ethernet)
RX packets 2083718 bytes 1276850142 (1.2 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1391024 bytes 1220778556 (1.2 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Просто работает. Из коробки.
Дома на роутере (Asus средней цены, гигабитный двухдиапазонник) настроен 6in4 от HE в SLAAC, всем девайсам опять же выдаются глобальные v6-адреса.
Ну, т.е. если в сети есть роутер с v6 аплинком и RADVD — ничего не надо делать, кроме как воткнуть кабель.
Роутер Хуавей от МГТС GPON да, сам генерит и выдает IPV6 внутри — но какой в этом смысл если тот же провайдер НЕ работает (читай никак не выпускает из своих сетей) весь IPV6 траффик…
А ваш Хуавей не умеет в 6in4 аплинк до Hurricane Electric, например? Мой — умеет, так и живу. HE выдал мне /64, которую раздает роутер в локалке. Все работает как задумано — есть автоконфигурация адресов, есть подсеть /64, есть глобальная связность.
Касаемо Хецнера — да, интерфейс поднимается, только надо еще net.ipv6.conf.default.forwarding=1
Зачем? Вы роутите несколько v6 сетей? Потому как эта опция нужна для того, чтобы разрешить форвардинг v6-трафика между интерфейсами. А достукиваться до сервера это не мешает.
# sysctl net.ipv6.conf.default.forwarding
net.ipv6.conf.default.forwarding = 0
~$ ping -6 2a01:4f8:1c1c:2f3d::1
PING 2a01:4f8:1c1c:2f3d::1(2a01:4f8:1c1c:2f3d::1) 56 data bytes
64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=1 ttl=54 time=40.7 ms
64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=2 ttl=54 time=40.8 ms
64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=3 ttl=54 time=40.8 ms
64 bytes from 2a01:4f8:1c1c:2f3d::1: icmp_seq=4 ttl=54 time=40.9 ms
^C
--- 2a01:4f8:1c1c:2f3d::1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 40.683/40.810/40.908/0.217 ms
~$ ssh root@2a01:4f8:1c1c:2f3d::1
The authenticity of host '2a01:4f8:1c1c:2f3d::1 (2a01:4f8:1c1c:2f3d::1)' can't be established.
ECDSA key fingerprint is SHA256:aSlaF63wCFy0cX50wXacfHxm0NHDdj26wX0YdN8Glic.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '2a01:4f8:1c1c:2f3d::1' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 18.04 LTS (GNU/Linux 4.15.0-22-generic x86_64)
зато сканирующих ботов в той черной дыре ооочень много, для интереса гляньте raw логи — будете неприятно удивлены..
Ну, пока скан не вызывает отказ в обслуживании — пофигу, честно говоря, тем более, у меня там не web-сервер, а прокси к телеге. nginx кстати по дефолту настраивается слушать все v4 и v6 адреса.
поисковики больше и чаще заходить не стали,
С чего бы им больше заходить? Для них единица измерения — доменное имя, а не адрес.
зато сканирующих ботов в той черной дыре ооочень много, для интереса гляньте raw логи — будете неприятно удивлены..
Ой ли?
"Пустой" среднемесячный трафик трафик на интерфейсе, доступном из инета по IPv4 100-160kbit/s
по IPv6 — 2-4kbit/s
И вот не надо про "неуловимого Джо" — в условиях гигантского адресного пространства сканирование становится сильно дорогим. Оно не исчезло полностью, особо упоротые сканят и весь IPv6, я видел примеры в логах. Но это реально сильно дороже по затратам. Можно конечно сказать, "вот будет у каждого пользователя по терабиту, будут и IPv6 сканить", но вы представляете себе, что будет в сетях IPv4, если у всех будет терабит?
Как раз для embedded IPv6 в работе сильно проще. Памяти может надо чуть больше, но код — меньше.
Спецам хорошо, домохозяйки ничего не поймут.
Здравствуйте, новые ботнеты.
Вы меня сильно удивляете.
Вы пишите:
ни одна из массово используемых ОС не сможет эффективно коммутировать или маршрутизировать трафик на такой скорости.
Конечно, можем в софте. И 10G, и 20G, и даже 40G — вполне возможно. Вот в районе 100+ уже проблемы.
У меня 2 Mpps на OVS прекрасно переваривается, на серверах нескольколетней давности. Без dpdk. Вы даёте ссылку на статью 2015 года, а на дворе 2020.
DPDK и множество полуаппаратных акселераторов OVS'а — это вполне важно и нужно. Но оно начинает играть важную роль на цифрах, которые существенно выше, чем 1Mpps.
10-20G современный сервер может обработать в любом варианте. Хоть мелкими пакетами, хоть крупными.
Мой поинт был, что "медленность" современных компьютеров в обработке сетевого трафика — это такое тонкое передёргивание вендоров сетевого железа. Да, никакой сервер не переварит 100Mpps. Но редко какой сервер окажется в ситуации, что ему надо столько переваривать.
поэтому смотрел что есть и как работает на бытовом железе
в общем где то на 40 (реже 80) все упирается где то во внутренние шины. какие именно PCI/Mem/CPU не проверял, но general servers/OSes работают без мега шаманства до 40ка, дальше все
Я согласен что мало кому придётся переваривать много pps-ов. Изначально вся эта тема в статье поднята исключительно от того, что раньше каналы связи были такие медленные, что компьютер нельзя было нагрузить ими, грубо говоря. Количество перерастает в качество — сильно быстрые сети, качественно требуют существенно более простых протоколов, чтобы облегчить жизнь компьютерам, которым уже много много pps так легко не переварить.
Killer-feature: link-local адреса
Для большой организации не нужно тратить время и силы на разрезание на подсети какой-нибудь 10/8 сети, раздавая из неё адреса для маршрутизаторов, следя чтобы не пересеклось ничего.
если мне нужны изолированные локальные сети, то я могу сделать их пересекающимися и в ipv4, непересекающиеся нужны только для единого адресного пространства.
Везде надо привыкать к тому, что стоит использовать глобальные префиксы сетей. Это очень удобно!
Исчезает NAT (всё ломающий костыль, абсолютное зло): теперь можно использовать гораздо более эффективные протоколы для различных задач.
вот у меня дома два интернет-провайдера, в офисе три. как это будет работать без nat? получать as и поднимать bgp? в офисе ещё можно попробовать, но дома-то?!?
хотя и в офисе проблемы, вполне нормальная ситуация, когда в каком-то филиале падает интернет, на несколько дней ставится 4g-модем и всё работает. что будет в случае использования глобальных префиксов?
P.S. главное, пока полно софта (и оборудования), поддерживающего только ipv4. то есть от внедрения ipv6 никакие проблемы ipv4 никуда не денутся, только добавится ещё возня с ipv6.
В чём проблема с вашим multi-homing-ом? В чём проблема с BGP? NAT не вариант в принципе: за ним не работает куча протоколов и нет связанности между хостами.
Я давно не встречал софта не поддерживающий IPv6.
чём проблема с вашим multi-homing-ом?
какие адреса должны быть в локалке?
В чём проблема с BGP?
я же написал уже, повторюсь: о нём нужно договариваться отдельно. далеко не все провайдеры готовы (особенно если речь о каком-нибудь мелком офисе на 3 человека, который платит тысячу в месяц).
"воткнул 4g-модем и всё заработало", "договорился с первым попавшимся провайдером и через пару дней появился проводной интернет" — вообще нереально.
NAT не вариант в принципе: за ним не работает куча протоколов
и кто вам поверит, когда у каждого дома стоит wifi-роутер с nat?
и нет связанности между хостами
+vpn
Я давно не встречал софта не поддерживающий IPv6.
вот только сегодня смотрел прогу для управления холодильной камерой. никакого ipv6 не увидел.
У всех этих людей дома с WiFi-роутером есть Интернет? Я им не верю. Удалённый доступ за NAT-ом вовне — есть. Интернетом я это не могу назвать.
VPN? Вы серьёзно? Начали с IPv6 с сплошными белыми адресами, закончили NAT+VPN как возможное решение?
Ну… прога для управления камерой может и не умеет. Будем считать что отсталость софта для холодильных камер тормозит внедрение IPv6.
Я для начала не пойму что именно вам нужно с вашим multihoming-ом
мне нужно чтобы браузер на компьтере открывал хабр, чтобы контакт на телефоне жены работал и т.д., и т.п.
ещё нужно, чтобы при отказе одного провайдера трафик автоматически переходил на другого. ну и желательно, чтобы на некоторые сети можно было выставить приоритетным какого-то провайдера (связность между местными провайдерами оставляет желать лучшего, маршрут через m9 — далеко не самый плохой вариант).
это мы считаем, что светлое будущее уже наступило и второй провайдер тоже стал предоставлять ipv6
примерно то же самое в корпоративной сети, только там гораздо больше пользователей/устройств, которым нужен доступ только к локальным ресурсам.
понятно, что это можно сделать с site-local адресами, но вы-то в статье говорите, что это зло
VPN? Вы серьёзно? Начали с IPv6 с сплошными белыми адресами, закончили NAT+VPN как возможное решение?
вы что-то путаете, я не начинал со сплошных белых адресов, я вообще не вижу зачем они мне нужны в корпоративной сети.
мне нужно, чтобы пользователь в офисе из другого города мог запустить 1с, открыть файлы с сетевого ресурса, чтобы в случае проблем техподдержка смогла подключиться к его компьютеру по vnc/ssh/чему-то ещё, …
Зло это NAT :-). Site-local имеет право на существование (я у себя и дома его использую для транспорта IPsec туннелей), но нужно *очень* хорошо задуматься нужен ли он. Что будет плохого в том, что вы в локальной сети с 1С и прочими будете использовать глобальные адреса? Вы же в любом случае firewall-ом и так будете обеспечивать безопасность и невозможность подключения к ним из вне (или, скорее всего, напишете IPsec security policy говорящий что из вне только с ESP шифрованием). Так какой смысл в site-local? Так как site-local часто будет каким-нибудь fc::/64 (или /7), то есть отнюдь не нулевая вероятность что у кого-нибудь дома такое же используется, а он захочет подключиться туннелем к сети предприятия (удалённая работа). Смысла не использовать имеющиеся глобальные адреса просто нет, как минимум они дают гарантирю что не пересекутся с инфраструктурой кого-нибудь другого.
Если вам нужна невозможность подключения извне — для этого есть firewall.
Что будет плохого в том, что вы в локальной сети с 1С и прочими будете использовать глобальные адреса?
Я вроде несколько раз отвечал на этот вопрос. Чей будет адрес? Провайдера? У меня их в центральном офисе больше одного. Свой? Тогда мне нужно озаботиться as и bgp. Не то, что это было так уж плохо, но мы сейчас приходим к тому, что во всех периферийных точках тоже должны быть резервные каналы (хотя бы в виде 4g-модема). Поднимать по as на каждую точку с несколькими пользователям? (а у меня их несколько сотен)
а не получится, что завтра я ушёл от этого провайдера — и он те адреса отдал кому-то ещё
да вроде бы получить PI блок несложно.
только вот я не вижу потребности в переходе на ipv6 в корпоративной сети, а dual stack… не, подождём ещё лет пять, а потом ещё раз вернёмся к этому вопроcу.
source based routing policies
Они должны настраиваться на конечном устройстве или на маршрутизаторе? Если всё же на маршрутизаторе, то как он сообщит обратно конечному устройству, что адрес, который оно только что попыталось использовать для исходящего соединения, принадлежит ляснувшемуся провайдеру и надо повторить попытку с использованием адреса другого провайдера?
У меня есть работодатель, у которого в корпоративной сети только IPv6. Они решили, что поддерживать такое проще и дешевле, чем городить зоопарк из частных сетей, vpn, nat и целенаправленно к этому шли пару лет. Как там результаты, к примеру, по финансам и трудовым ресурсам — я не знаю, но доступ к внутренней инфраструктуре снаружи сильно упростился. И нет, не стал от этого более небезопасным, IPsec, все дела, всё на месте. Админить такое — чистое удовольствие. И да, поскольку теперь дома IPv6 у меня must have, то я все свои домашние сервисы перевел в IPv6 only. Это реально очень удобно. Понятно, что исчезновением лично меня с моим десятком хоббийных сайтов из IPv4 пространства никто этого не заметил, да и те несчастные, кто попытавшись открыть напрямую ссылку из поиска гугла никуда попасть не могут, но всегда могут "открыть сохраненную страницу", но рано или поздно эта тенденция таки станет массовой.
но доступ к внутренней инфраструктуре снаружи сильно упростился
я правильно понимаю, это "сильно упростился" — это ipv6-туннель (большинство же провайдеров не предоставлят нативного ipv6) + ipsec? это правда проще, чем l2tp или openvpn с конфигом в несколько строчек?
IPsec далёк от идеала, не спорю. Но… при всех своих недостатках, для меня он однозначно лучший выбор чем OpenVPN, который худший выбор, особенно с наличием WireGuard. И я уж лучше SSH-TUN туннель бы поднял, но не OpenVPN. Но эта тема не касается IPv6 :-). OpenVPN можно и поверх IPv6 использовать наверняка.
Я помахал ручкой одному провайдеру, который сказал "IPv6 нет и не предвидится" и подключился к другому, у которого /64 из коробки и можно бесплатно просто по письму получить ещё /56
И обхожусь без ipv6-туннелей. (Хотя вот прямо сейчас я не дома и тут у меня да, ipv6 туннель)
И да, это проще и понятнее, чем l2tp. Потому что разделено на две назависимые сущности — туннель и шифрование.
Некоторые well-known multicast адреса позволяют легко узнать какие компьютеры вообще есть в сети (broadcast домене Ethernet-а)
в ipv4 не так?
попробовал
PING 10.0.0.255 (10.0.0.255) 56(84) bytes of data.
64 bytes from 10.0.0.43: icmp_seq=1 ttl=255 time=0.189 ms
64 bytes from 10.0.0.46: icmp_seq=1 ttl=255 time=0.206 ms (DUP!)
64 bytes from 10.0.0.45: icmp_seq=1 ttl=255 time=0.223 ms (DUP!)
64 bytes from 10.0.0.44: icmp_seq=1 ttl=255 time=0.224 ms (DUP!)
64 bytes from 10.0.0.24: icmp_seq=1 ttl=255 time=0.337 ms (DUP!)
64 bytes from 10.0.0.247: icmp_seq=1 ttl=100 time=1.54 ms (DUP!)
64 bytes from 10.0.0.16: icmp_seq=1 ttl=64 time=2.88 ms (DUP!)
64 bytes from 10.0.0.249: icmp_seq=1 ttl=100 time=5.16 ms (DUP!)
64 bytes from 10.0.0.248: icmp_seq=1 ttl=100 time=7.35 ms (DUP!)А в чём смысл выдавать каждому пользователю /64? Нет, я допускаю, что это может заметно разгрузить таблицы маршрутизации на роутерах, но если не фокусироваться на ограниченных возможностях роутеров — зачем это нужно? По сути ведь это просто бессмысленное уничтожение громадного количества адресов — ведь у абсолютного большинства пользователей, даже после выдачи IP каждой лампочке в доме и каждому контейнеру докера, будет реально использоваться несколько сотен адресов максимум. Хотите выдать с диким запасом, чтобы хватило навсегда — ну выдайте /112, это 64K адресов каждому. А при выдаче всем /64 мы, по сути, минимум 48 бит адресного пространства выкидываем в мусор… что возвращает нас к изначальному вопросу: для чего это нужно?
На самом деле у меня такой же вопрос: разве это не слишком ли расточительно. Ну коммитеты посчитали что вроде нет, должно хватить даже так, даже выдавая /56 или /48 конечным пользователям. Но, на данный момент все адреса выдаются только из 2000::/3 — используется 1/8 всего возможного пространства. Если же умные коммитеты обосрались с рассчётами и прикидыванием, то у нас есть ещё 7 попыток, где могут быть в корне совершенно другие политики выдачи.
Отличная новость! Т.е. люди, которые потенциально таки совершили эту ошибку, из 128 бит умудрились оставить нам всего 7 попыток сделать правильно?
Я бы не стал считать что эти люди потенциально совершили ошибку. Точнее так: потенциально абсолютно все совершают ошибки изобретая любой протокол, правила, алгоритмы и прочее. Но эти хотя бы задумываются о запасном плане, чтобы не пришлось, как с IPv4, полностью менять все маршрутизаторы и софт.
Потери при выдаче /64 будут не /48 бит, а все 60-62, ведь у многих буквально несколько устройств всего-лишь подключено. Но не стоит забывать что и подходы работы в IPv6 сетях надо менять и не ютиться на одном IP-адресе. Лично я вот не редко выношу некоторые службы на отдельные IP, чтобы персонально к этим IP применять IPsec политики. Это просто удобно. Возможно массово это никто и не будет использовать, а возможно нам и этого будет не хватать — никто не знает что будет в будущем.
/64 хосту позволяет использовать RFC 4941 — Privacy Extensions for Stateless Address
И все скрипты, которые обходят весь интернет для поиска открытых ssh портов превращаются в тыкву, потому что теперь каждый хост в IPv6 — это как весь интернет в IPv4(нет, в реальности гораздо больше)
Честно говоря, я ждал этого аргумента. Риторический вопрос: не кажется ли Вам, что прятать порт ssh таким образом — это дикий overkill? Я уже молчу о том, что многие в IPv6 всё-равно поставят адреса вроде …::1 чтобы ленивее было набирать/запоминать/различать, что можно перевесить ssh на нестандартный порт, и, главное, что если защита периметра строится на том, что порт ssh не найдут, то у меня для Вас плохие новости…
Речь про другое. Речь скорее про компы обыкновенных пользователей, у которых проблемы с безопасностью из-за их безалаберности. Не нравится вам 22-й порт, окей, пусть это будет 3389. Суть от этого не меняется. в IPv4 сети сканером одного порта полностью обходится весь интернет за несколько часов. В IPv6 на это уйдут месяцы, даже если сканить только уже распределенные сети, не трогая зарезервированные и неиспользуемые. Это в общем случае не безопасность "меня никогда не найдут", а значительное увеличение стоимости атаки. Поэтому отпадет огромное количество мамкиных кулхацкеров, поскольку вероятность получить результат за приемлемое время сильно падает. А ещё это не такой стремительный рост ботнетов, это тоже пассивная безопасность, потому что ботнеты на сотни тысяч пораженных устройств позволяют легко делать то, что меньшим количеством просто не делается.
Есть способы сильно эти "месяцы" сократить, не без своих ограничений, но, тем не менее. И увеличение стоимости атаки получается уже не столь значительным, как нам бы хотелось. Вот, быстро погуглил, и сразу попался список подходов (скорее всего далеко не окончательный):
- When nodes are allocated sequential IIDs addresses such as ::1, ::2, ::3, ::4, …
- When nodes have their IPv6 address in DNS zones that can be queried
- When nodes respond to an ICMPv6 echo-request sent to the all-nodes link-local multicast (FF02::1)
- When nodes respond to an invalid extension header sent to the all-nodes link-local multicast (FF02::1)
- When nodes respond to an MLD query send to the all-nodes link-local multicast (FF02::1)
- When nodes send an ICMPv6 type 135 Neighbor Solicitation (NS) for a rogue default router sending an ICMPv6 type 134 Router Advertisement (RA)
- Using other methods of leveraging IPv4 to learn the IPv6 address of the dual-protocol node
- If all the nodes on the network use SLAAC and EUI-64 with the same Ethernet NIC OUI. In this case, the first 24 bits of the IID will all be the same, the next 16 bits of the IID are FFFE, followed by the unique 24 bits of the node’s MAC address. Scanning 2^24 IPv6 addresses might take only a few days.
Ни один из методов не работает на обычной Windows 10, получившей IPv6 адрес по SLAAC. В которой пользователь даже не знает, что надо что-то там настраивать. Купил в магазине нотбук и пользуется. Напоминаю, если что, это и есть порядка 95% всех хостов в интернете. А сервера, что сервера, у серверов должны быть админы. Так что мой тезис скорее подтверждается, чем был опровергнут.
Метания с DHCP (а сделаем два протокола — RA и DHCPv6), NAT (абсолютное зло, а добавим IPv6-to-IPv6 NPT), диапазонами (fec0:/fc00:: или ::ipv4/::ffff:ipv4), EUI из MAC/рандомно, меняющаяся длина префикс (6 vs 8) прекрасно демонстрируют компетенции авторов IPv6.
— Удаленный доступ: NAT + маршрутизация провайдера надежно закрывает абонентские терминалы, на которых некоторые пользователи так любят отключать межсетевые экраны. IPv6 автоматом несет коллапс ИБ.
— NAT иногда нужен вовсе не для экономии адресов, а для эмуляции окружения сегментов сетей. И заменить его нечем. И, да, читаем про IPv6-to-IPv6 NPT.
— IPSec/ESP вполне себе работает и в IPv4/NAT. Но, всё же OpenVPN, Wireguard, SSH/TLS проще и в настройке и как протоколы (а значит и потенциально менее уязвимы).
— «минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.
— Идея использовать глобальный префикс прекрасна, если помнить, что провайдер, которому этот префикс принадлежит может и поменяться. Вместе с префиксом.
— Я честно не смог найти мнемонику между 2a02:6b8::2:242 и ya.ru — и назвать четыре числа простому пользователю, не смыслящему в этих ваших сетях и английском, сильно проще чем многосимвольную щестнадцатиричную «штуку».
— Насчет иерархии IPv6 адресов. Старые сетевые инженеры помнят, зачем в древних cisco нужно включать бесклассовую маршрутизацию и почему в 80-х от неё отказались. Думаю, со временем откажемся и здесь.
— link-local были прекрасно сделаны в Windows и без IPv6, показывая, что переделывать сетевые протоколы ради автоматически настраивающихся сетей не требуется.
— well-known multicast адреса в IPv4 назвались широковещательным пингом — и его похоронили ради безопастности. Удивительно, что теперь это преподносится как преимущество.
— Магия SLAAC уходит, когда мы вспоминаем про обычные роутеры с 192.168.1.1/24 и DHCP — ведь для простого пользователя ничего не меняется.
— Магия anycast уходит, когда выясняется, что в отличии от существующего сейчас Anycast, здесь эти адреса нельзя использовать в качестве адресов отправителей.
— В IPv6 вообще то НЕ фиксированные заголовки из-за extension headers. И агитация IPv6, в которой их якобы отсутствие преподносится преимуществом хороший пример переусложненности протокола.
— Flow Label сложно сказать насколько жизнеспособно, пакеты не фрагментируются до нечитаемости заголовков TCP/UDP/SCTP и я не уверен, что он когда-либо будет применен в живых системах из-за потенциальных проблем с безопасностью при балансировке нагрузки.
— Multicast NDP работает в Ethernet сетях так же как и ARP/DHCP. Вот если у вас X.25, тогда да, нагрузка на сеть будет меньше (RFC 4861).
— NDP NUD в общем-то действительно плюс. Одна из базовых причин продвижения Google своего QUIC вместо связки IP/TCP/TLS.
Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства. Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско. А потом в целях безопасности, что бы не светить MAC, заменим это случайным числом — действительно, в заголовке каждого пакета, два 8 байтных случайных числа, вместо полезных данных. Действительно IPv6 — «эффективный» и «продуманный» протокол.
Ну и главный минус IPv6 — это заведомо заложенная несовместимость с IPv4, какие-то работоспособные варианты Dual Stack стали появляться лет через 10-15, после выхода протокола — и это очень сильно тормозило его внедрение. Удивительно, как имея IPv4 — далеко не идеальный и не беспроблемный протокол, десять лет его эксплуатации в живых сетях и решения проявившихся проблем можно было создать IPv6.
«минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.
У меня дома /56. Пожаловаться на провайдера?
Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско.
В чем фиаско-то? Ну дублирует.
Насчет /64 я ошибся — комментарий слишком длинный вышел, а аспектов связанных с IPv6 много. Имелось в виду сужающееся пространство — изначально, конечным пользователям планировали давать /48. Потом начали сокращать — у вас /56, у кого-то до /64. Меньше в текущих реалях уже нельзя.
Насчет дублирования — эти байты лишние. Если их убрать из заголовка, то на работоспособности протокола это не скажется. Но из-за них длина адреса сокращается вдвое и каждый пакет (от 300 до 1500 байт) содержит лишние 16 байт — меньше пропускная способность сетей, больше энергопотребление и т.д…
Как я понимаю, разработчики ipv6 учли тот факт, что предсказать будущее трудно, поэтому чрезмерная оптимизация (ну не нужно же!) завтра может стать болью. Вот вы считаете, что не нужны эти биты, а кто-то в комитете сказал, что он считает, что нужны, и привел конкретный кейз, и у остальных, наверное, не нашлось доводов убедить, что этот кейз нерелевантен. Именно потому, что все, кто чрезмерно уверены, чаще ошибаются.
IPX был куда лучше для локальных сетей, чем TCP/IP, но совершенно не работал в глобальном пространстве. Помню, как мы долго плевались, когда переходили с IPX на TCP/IP в офисе в начале 90-х, и переходили только потому, что нужно было с компов выходить в интернет. IPX не проиграл, он просто автоматом вышел из игры, но стал популярен с нуля и выигрывал у tcp/ip почти 15 лет при том, что tcp/ip существовал с начала 80-х как официальный стандарт. Ровно так же автоматом уйдёт ipv4, потому что в мире IOT он не релевантен.
в мире IOT он не релевантен
С миром IoT всё сложно, на самом-то деле. Он ещё не наступил, и пока неясно, наступит ли. У него уже проявилось две большие проблемы, у которых пока что решения нет: во-первых китайские умные лампочки и прочие вибраторы/радионяни с "закладками" стучащие домой (а потом с серверов компании всё это утекает в паблик), и во-вторых "окирпичивание" умных устройств если что-то случается с серверами компании-производителя.
Первая проблема больше волнует незначительный процент населения обеспокоенного приватностью и безопасностью, и их беспокойство вполне могут проигнорировать "во имя великого IoT" (хотя тут я уже не уверен — пока это касалось лампочек всё так и было, но вот случившиеся утечки через вибраторы и радионяни подняли намного бо́льший шум). Но вот вторая касается всех и каждого — никто не хочет платить кучу денег за более дорогое "умное" устройство, срок жизни и работоспособность которого (напр. после автоматического некорректного обновления) никто не может гарантировать.
Эти проблемы, конечно, решаемые. Но это решение сильно удорожит продукт, и вполне может сделать большую часть IoT нерентабельным.
Я разговаривал с операторами — они видят в обеих проблемах возможности. Они могут взять на себя и вопросы безопасности и вопросы обслуживания устройств, плюс локализация в широком смысле этого слова. Собственно, многие уже выстраивают соответствующую инфраструктуру.
Никакие «лампочки» никуда попадать не будут и до них будет не достучаться.
Ну а физики должны страдать, они же хотят все нахаляву :)
Он не может заменить из-за инертности мышления людей, и банально из-за того, что Интернет, как таковой, мало кому нужен. Деньги приносят конечные пользователи. А им нужен удалённый доступ к ряду сервисов.
>— Удаленный доступ: NAT + маршрутизация провайдера надежно закрывает абонентские терминалы, на которых некоторые пользователи так любят отключать межсетевые экраны. IPv6 автоматом несет коллапс ИБ.
Отсутствие Интернета (возможность общения хостов между собоу) означает повышенную безопасность. Да, я это от многих уже слышал и считаю маразмом. Отключите кабель — будет ещё безопаснее. Потому что пользователи и без firewall-а умудрятся что-нибудь сделать небезопасное.
>— NAT иногда нужен вовсе не для экономии адресов, а для эмуляции окружения сегментов сетей. И заменить его нечем. И, да, читаем про IPv6-to-IPv6 NPT.
Не нужно смешивать людей придумывавших IPv6/NDP/etc с всегда-найдётся-человеками которые придумают нечто странное. В RFC много всякого странного и ненужного.
>— IPSec/ESP вполне себе работает и в IPv4/NAT.
С костылями в виде NATT. А если оба за NAT-ом, то тут как всегда…
>Но, всё же OpenVPN, Wireguard, SSH/TLS проще и в настройке и как протоколы (а значит и потенциально менее уязвимы).
Зависит от IKE демонов. Настройка strongSwan — одно удовольствие и возвращаться к OpenVPN никогда. TLS — только версия 1.3 выглядит достойно с криптографической точки зрения. Среди всех вышеназванных протоколов (кроме ультрасовременного WireGuard) — только IPsec за свою историю не имел криптографических проблем. Даже первые версии ESP и IKE имеют отличный уровень безопасности.
>— «минимум /64 сеть» — обман из 90-х, когда оверинженериг создателей IPv6 не ограничивался реальностью. Сейчас конечному пользователю такую сеть уже почти никто не выдаст.
Это явно не соответствует правде. Нигде не встречал чтобы выдавали меньше.
>— Идея использовать глобальный префикс прекрасна, если помнить, что провайдер, которому этот префикс принадлежит может и поменяться. Вместе с префиксом.
Да, и все NDP/MIPv6 и прочие заточены под то, что всё может меняться. В SLAAC-е даже lifetime-ы есть из серии часов для префикса/адреса.
>— Я честно не смог найти мнемонику между 2a02:6b8::2:242 и ya.ru — и назвать четыре числа простому пользователю, не смыслящему в этих ваших сетях и английском, сильно проще чем многосимвольную щестнадцатиричную «штуку».
Тут мнемоники нет. Это просто короткий и запоминающийся адрес. Нет, безусловно с «8.8.8.8»/«8.8.4.4» ничто не может соревноваться, но на практике адреса всё-равно достаточно короткие и легко запоминающиеся.
>— Насчет иерархии IPv6 адресов. Старые сетевые инженеры помнят, зачем в древних cisco нужно включать бесклассовую маршрутизацию и почему в 80-х от неё отказались. Думаю, со временем откажемся и здесь.
Помнят, потому что классовая адресация крайне нерационально использовала пространство адресов и чтобы моментально не произошёл коллапс от нехватки всего IPv4 пространства — придумали CIDR. Только причём тут иерархия и классовость/безклассовость? В IPv4 мире нарезали на маленькие кусочки и маршрутизировали хаотично, потому что кому как и где уж выдали.
>— link-local были прекрасно сделаны в Windows и без IPv6, показывая, что переделывать сетевые протоколы ради автоматически настраивающихся сетей не требуется.
Про Windows не знаю. Но вот вне Windows как-то не прижилось.
>— well-known multicast адреса в IPv4 назвались широковещательным пингом — и его похоронили ради безопастности. Удивительно, что теперь это преподносится как преимущество.
Удивительно, но в IPv4 мире любят даже ICMP полностью блокировать, уничтожая возможность делать PMTUD, считая что у кого не native-1500-bytes-MTU — нищеброд и сам виноват.
>— Магия SLAAC уходит, когда мы вспоминаем про обычные роутеры с 192.168.1.1/24 и DHCP — ведь для простого пользователя ничего не меняется.
Не понял причём тут какой-то 192.168.1.1, SLAAC и DHCP.
>— Магия anycast уходит, когда выясняется, что в отличии от существующего сейчас Anycast, здесь эти адреса нельзя использовать в качестве адресов отправителей.
Это явно не соответствует действительности. Я даже не знаю откуда такое вы взяли или увидели.
>— В IPv6 вообще то НЕ фиксированные заголовки из-за extension headers. И агитация IPv6, в которой их якобы отсутствие преподносится преимуществом хороший пример переусложненности протокола.
Решения о маршрутизации принимаются на основе фиксированного заголовка. Почти все расширенные маршрутизатор в общем-то может игнорировать. Полная картина — не фиксирована. Для маршрутизаторов — фиксирована.
>— Flow Label сложно сказать насколько жизнеспособно, пакеты не фрагментируются до нечитаемости заголовков TCP/UDP/SCTP и я не уверен, что он когда-либо будет применен в живых системах из-за потенциальных проблем с безопасностью при балансировке нагрузки.
Действительно flow label на практике ещё не понятно насколько полезен. Но вредит он максимум только наличием 20 лишних бит — попытка не пытка.
>— Multicast NDP работает в Ethernet сетях так же как и ARP/DHCP. Вот если у вас X.25, тогда да, нагрузка на сеть будет меньше (RFC 4861).
Не всегда так, но да, он может превратиться в broadcast.
>Плюс 128 битные адреса, которые на самом деле 64 битные, поскольку последние 8 байт генерирует EUI из MAC адреса устройства.
На самом деле они 128 битные, посколько никто вас не обязывает использовать только этот один автоматический EUI64 адрес. Вы можете сгенерировать ещё 1<<64-XXX адресов. То что современные приложения учаться «ужиматься» на куче портов на одном единственном IP адресе — да, факт. IPv6 это другой мир, где для *более* эффективной работы стоит применять другие подходы. В самом адресе уже можно зашивать «порты», экономя на более простых транспортных заголовках, например.
>Половина адреса сетевого уровня дублирует адрес уровня канального — это полное фиаско.
Ну не половина, а 48-бит. И IP не предполагает использование исключительно поверх Ethernet/WiFi сетей. Канальный уровень может быть любым. И в идеале он должен быть point-to-point без ненужного (для IPv6 мира) overhead-а от адресов канального уровня.
>А потом в целях безопасности, что бы не светить MAC, заменим это случайным числом — действительно, в заголовке каждого пакета, два 8 байтных случайных числа, вместо полезных данных. Действительно IPv6 — «эффективный» и «продуманный» протокол.
Проблемы и мысли людей делающих подобное не стоит мешать с теми, кто продумывал IPv6 протокол. Если я ногами кручу руль автомобиля, демонстрируя неудобные сидения для такого действа, то вряд ли стоит винить создателей автомобиля что они это не продумали. Вы уже второй раз странные и не лучшие идеи прикрепляете к создателям IPv6.
>Ну и главный минус IPv6 — это заведомо заложенная несовместимость с IPv4
Не всегда стоит нести совместимость с чем-то предыдущим. О лошадях и конных повозках, благо, сейчас не задумываются при проектировании автомагистралей.
Удивительно, но в IPv4 мире любят даже ICMP полностью блокировать
И сразу же
Проблемы и мысли людей делающих подобное не стоит мешать с теми, кто продумывал IPv6 протокол. Если я ногами кручу руль автомобиля, демонстрируя неудобные сидения для такого действа, то вряд ли стоит винить создателей автомобиля что они это не продумали. Вы уже второй раз странные и не лучшие идеи прикрепляете к создателям IPv6.
Спасибо за отличный пример двойных стандартов
Он не может заменить из-за инертности мышления людей,
Это не так — за это же время сменились целые эпохи в других областях, и инерция мышления этому не помешала.
и банально из-за того, что Интернет, как таковой, мало кому нужен.
А вот это правда — и она блокирует большую часть аргументов из статьи, просто потому, что большинство этих аргументов актуальны только для сетевых инженеров.
Отсутствие Интернета (возможность общения хостов между собоу) означает повышенную безопасность. Да, я это от многих уже слышал и считаю маразмом.
Всё так. Любой файрвол по своей сути эту связность ломает, это его работа — блокировать небезопасные связи. А Интернет большинству не нужен, как мы уже выяснили. (А кому нужен — мне, например — тот давно получил у провайдера белый IP.)
Не нужно смешивать людей придумывавших IPv6/NDP/etc с всегда-найдётся-человеками которые придумают нечто странное.
Вот, кстати, хороший вопрос: а как без этого "странного" в IPv6 предполагается обходить блокировки и вообще маскировать свой адрес от слежки? Ну, то самое, для чего сегодня поднимается VPN, на котором NAT?
Зависит от IKE демонов. Настройка strongSwan — одно удовольствие … (кроме ультрасовременного WireGuard)
Но зачем же исключать WireGuard? Он как раз хорошо показывает, как на самом деле просто всё это должно настраиваться, и настройку strongSwan на его фоне воспринимать удовольствием… ну, немного отдаёт мазохизмом. От большой любви к IPv6, конечно же, можно на это закрыть глаза, но если смотреть объективно…
2a02:6b8::2:242 … на практике адреса всё-равно достаточно короткие и легко запоминающиеся.
А это уже отдаёт Стокгольмским синдромом. На всякий случай уточню: нет, этот адрес не короткий, и нет, не легко запоминающийся.
Удивительно, но в IPv4 мире любят даже ICMP полностью блокировать
Ничего удивительного, просто он создавал проблемы с безопасностью когда-то, а потом все тупо копировали уже не очень актуальные правила файрвола со stackoverflow. В этом смысле ICMPv6 скорее всего будет ещё более проблемным, потому что он более сложный и нагруженный функционалом, так что с безопасностью у него может быть заметно хуже. Собственно, быстрый поиск это элементарно доказывает: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=icmpv6
Это так, так как видно что помешала. Это не единственная причина. Стоимость оборудования (особенно в 90-х и 2000-х, когда оно не держало IPv6), ненужность провайдерам и конечным пользователям, и т.д…
>А кому нужен — мне, например — тот давно получил у провайдера белый IP.
Как и я всю жизнь был за статическим IP. Но таких то людей крайне мало.
>в IPv6 предполагается обходить блокировки и вообще маскировать свой адрес от слежки? Ну, то самое, для чего сегодня поднимается VPN, на котором NAT?
VPN-ы которые я поднимал и которыми пользовался — были без NAT. Вопрос блокировок, анонимизации и прочего, мягко говоря, выходит за рамки эффективной сети передачи данных (IP). Можете посмотреть моё выступления на тему анонимизации :-): www.youtube.com/watch?v=FJ68Kha78Lo
Анонимизация и эффективность работы — даже не вспомню чтобы были не на разных чашах весов.
>Но зачем же исключать WireGuard? Он как раз хорошо показывает, как на самом деле просто всё это должно настраиваться, и настройку strongSwan на его фоне воспринимать удовольствием… ну, немного отдаёт мазохизмом. От большой любви к IPv6, конечно же, можно на это закрыть глаза, но если смотреть объективно…
1) Исключаю потому что он появился *совсем* недавно. Грубо говоря, год назад мы бы о нём не заикнулись. А так да: он хорош. 2) IPsec это не VPN. IPsec может использоваться для VPN, но он может даже для обеспечения безопасности per-socket использоваться. WireGuard это только VPN.
>2a02:6b8::2:242 … На всякий случай уточню: нет, этот адрес не короткий, и нет, не легко запоминающийся.
На всякий случай напомню, что он достаточно короткий для запоминания, в отличии от мифа о том, что все адреса всегда длинные (128 бит!) типа 2a03:5a00:17:123:50c2:1bff:fea8:dd3.
>В этом смысле ICMPv6 скорее всего будет ещё более проблемным
Любая новая и более сложная технология (решающая больше задач) (и софт) потенциально такой будет, очевидно. Автомобили тоже требовали десятилетий опыта, отладки, и высокой квалификации для обслуживания и создания, в отличии от лошадей которых только приручить и впрячь в повозки. Это всё очевидно. Хочется железобетонной надёжности, то можно использовать (MS-)DOS.
Автомобили, в отличие от лошадей, давали явные преимущества всем и каждому. А IPv6, как Вы сами верно заметили в начале комментария, это "ненужность провайдерам и конечным пользователям". Стоимость оборудования за это время изменилась, а вот насчёт ненужности — всё по-прежнему актуально, даже не смотря на то, что IPv4 совсем-совсем кончились.
Они все имеют IPv6 просто потому, что ISP им его выдаёт по умолчанию, их OS его поддерживает по умолчанию, и трафик возникает потому, что ютуб им по умолчанию выдаёт AAAA запись.
Сами пользователи в Интернете и IPv6 по-прежнему не нуждаются, ничего про него не знают, и не подозревают о том, что вся эта выдача им IPv6 "по умолчанию" ослабляет их безопасность.
Я к тому, что объёмы трафика тут не показатель. Показателем свершившегося внедрения IPv6 станет исключительно точка, в которой у обычных пользователей не получится по IPv4 заходить на часть нужных им и достаточно популярных сайтов. А такого может ещё лет 20 не случиться.
Сейчас сложнее найти ресурсы которые бы не были доступны по IPv6
взял alexa top 50, скормил dig -t aaaa, оказалось 12 сайтов из списка имеют ipv6 адреса
ВК когда-то имел IPv6, но через некоторое время его отключили. По заверениям поддержки, из-за спамеров. (В чём связь между спамерами и IPv6, объяснять отказались)
Он не может заменить из-за инертности мышления людей
Ближайший аналог — 2G/3G/4G. Инертность мышления не мешала переходу.
Отсутствие Интернета означает повышенную безопасность. Отключите кабель — будет ещё безопаснее
Вообще да, с отключенным кабелем действительно будет ещё безопаснее. Отсутствие полной симметричной связанности мешает лично вам, но для большинства потребителей интернета — эта плюс.
В RFC много всякого странного и ненужного.
NAT нужен. И для IPv6 тоже. Не что бы у пользователей отбирать белые адреса и давать серые, а для управления сетями, отладки, эмуляции сетевого окружения и т.д. Благодаря NAT, можно полностью переделать сегмент сети, с заменой сервисов в ней, протестировать всё это, в том числе на части живых пользователей и выкатить в прод незаметно для пользователей одной командой в консоли маршрутизатора. И в таких задачах у NAT замены нет.
А если оба за NAT-ом, то тут как всегда
Да, как всегда, когда жадность потребителей мешает оплатить белый адрес. А производителей железа внедрить протокол без дефицита адресов.
Зависит от IKE демонов
Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.
Да, и все NDP/MIPv6 и прочие заточены под то, что всё может меняться.
Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.
Это просто короткий и запоминающийся адрес.
Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6. И возможности сокращения, демонстрируемые в статья плохо релевантны адресациям в реальных сетях — я на свой ближайшей сервер зашел, там префикс 2a03:b0c0:3:d0::27b:e009, это ну никак не «достаточно короткие и легко запоминающиеся».
классовая адресация крайне нерационально использовала пространство
В IPv6 я вижу повтор этой истории.
Про Windows не знаю. Но вот вне Windows как-то не прижилось.
Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.
любят даже ICMP полностью блокировать
Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.
Не понял причём тут какой-то 192.168.1.1, SLAAC и DHCP.
Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.
Это явно не соответствует действительности. Я даже не знаю откуда такое вы взяли или увидели.
RFC3513. Но ОК, новый RFC4291 это ограничение снял.
Решения о маршрутизации принимаются на основе фиксированного заголовка
Сейчас, в IPv4 это работает так же.
На самом деле они 128 битные
Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.
Ну не половина, а 48-бит
Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.
в идеале он должен быть point-to-point без ненужного overhead-а от адресов канального уровня.
Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.
Проблемы и мысли людей делающих подобное не стоит мешать с теми, кто продумывал IPv6 протокол.
Это то, во что IPv6 эволюционировал. Текущее положение дел. Исправление и свидетельство ошибок тех, кто придумывал IPv6. Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.
Не всегда стоит нести совместимость с чем-то предыдущим.
Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.
Они не так отличаются по сути работы своей.
>Вообще да, с отключенным кабелем действительно будет ещё безопаснее. Отсутствие полной симметричной связанности мешает лично вам, но для большинства потребителей интернета — эта плюс.
Не стоит их называть потребителями Интернета. Это потребители удалённых сервисов. Поднять IPsec между компьютерами они не смогут — какой же тут Интернет?
>NAT нужен
Единственное для чего он был нужен — как-то выжить в условиях нехватки IP адресов. На этом всём.
>Благодаря NAT, можно полностью переделать сегмент сети, с заменой сервисов в ней, протестировать всё это, в том числе на части живых пользователей и выкатить в прод незаметно для пользователей одной командой в консоли маршрутизатора. И в таких задачах у NAT замены нет.
Это решается маршрутизацией.
>Да. С этим хорошо в последних Linux. А вот варианты Windows-Linux-Cisco-Android и IPSec вызывают сильное неприятие всё этой радости. Изначальный IPSec имел не особо набор не особо стойких алгоритмов типа DES и кучу CVE в его разных реализациях.
Microsoft всегда в своём духе.
>Я писал, что ваша идея из статьи использовать вместо site-local глобальные префиксы, которые сменятся при смене провайдера — не очень практичная.
Ваша идея использовать site-local адреса, без очень веских на то причин (они могут быть, не спорю, просто не верю что часто), гарантированно вызовет геморрой при коллизии сетей объединённых VPN-ом.
>Он сложней 4-х трехзначных цифр. И сложность человеку работать с адресами — объективная проблема IPv6.
Это ваше субъективное мнение. Наверное мозг людей по разному устроен. Но мне абсолютно несвязанные 4 десятичных числа не просто запомнить, вот честно, правда.
>В IPv6 я вижу повтор этой истории.
Где-то есть опасения что адресов уже начало не хватать?
>Это живой пример, что link-local не завязаны на сетевой протокол. Можно было сделать отдельный, независящей от IPv4 и IPv6 протокол и внедрить в разных ОС.
Ну вот за столько десятков лет IPv4 так ничего подобного и не сделали чтобы везде было и работало. IPv6 сделал.
>Это результат эволюции и всевозможных атак из 90-х. Поэтому и странно видеть, как ICMPv6 пытается повторить похожий путь.
Мне то странно видеть что вы её кладёте на этот путь. По вашей логике вообще не нужно ничего нового изобретать и писать новый софт. Нет, я тоже в целом приверженец идеи «работает — не трожь» и противник «движения ради движения» (кто-то считает прогрессом ради прогресса), но всему есть разумные пределы применимости. Видеохостинг изначально можно поднять на одном сервере с хранением видео файлов на ФС как есть. Но с ростом популярности такого сервера, придётся делать системы как в ivi.ru, где работают сотни программистов и сетевых инженеров. IPv4 уже не удовлетворяет потребностям.
>Для обывателя SLAAC не привносит ничего нового — он не заметить разницы.
Обывателю достаточно оставить с дюжину сайтов типа YouTube, VK, FB, и т.д., а всё остальное отрубить — я уверен что 99% не заметят разницы тоже. Обыватели меня не интересуют.
>Решения о маршрутизации принимаются на основе фиксированного заголовка
>Сейчас, в IPv4 это работает так же.
Только заголовок обрабатывается сложнее (разная длина, плюс пересчёт checksum на каждом hop). А так да: в IPv6 аналогично, просто проще.
>Уже нет. Это сломает маршрутизацию. Железо из Tier 1 ради оптимизаций все, что ниже /64 маршрутизировать не будет ибо не реализовано. SOHO сегмент не может из-за совместимости с RA/DHCPv6 и текущими реализациями стеков. Адреса, как бы теоретически, 128-битные, но только маршрутизировать из них больше 64 уже не выйдет.
Вы придумываете. Когда у меня был /64, то я дробил на маленькие сети, между разными устройствами (FreeBSD машины). Про Tier1 ничего не скажу, но ok, там поверю что ради оптимизации они не смотрят на 64-бит. Там это крайний случай.
>Я может запамятовал, но на вскидку из 48 бит MAC генерировалось 64 нижней части. Ну или уже не так помню и тяжко лезть в RFC искать.
48 бит становятся 64 битами, да. Просто энтропии в этом адресе всё-равно 48 бит. Плюс два байта константы вставляются.
>Штуки вроде NDP говорят об обратном. Выдавать по local-link IPv6 каждому порту коммутатора в ЦОДах тоже никто вроде не предлагает. А Ethernet/WiFi преобладают безальтернативно и рассчитывать IPv6 под другой канальный уровень странно. Поэтому идеи о ptp как оправдание такой схемы адресации выглядят странно.
NDP как-раз говорит о том, что он адреса канального уровня явно может и не быть — поэтому поля переносящие *внутри* ICMPv6 link-layer адрес: опциональны. На самом деле отличная apenwarr.ca/log/20170810 статья как-раз и предлагает делать на каждом порте коммутатора IPv6 сеть сразу же. По сути же оно так уже и есть: у нас точка-точка соединения чисто физически.
>Это то, во что IPv6 эволюционировал.
IPv6 это RFC описывающие IPv6. Плюс NDP. Плюс ещё несколько. Не нужно приплетать странные (дурные) RFC ко всей кучи и считать что их или кто-то обязан реализовывать или хотя бы даже прислушиваться. Эти дурные вещи никто никуда не тащит, в здравом уме.
>Я не понимаю, почему вы думаете, что пришли какие-то левые люди и начали штамповать похабные RFC ломающие замысел первоначальных авторов.
Ну… потому что вот прям буквально так и думаю, действительно. Я программист и прекрасно знаю что можно делать костыли побыстрее, решая сиюминутные задачи. А можно хорошо что-то продумывать, просто сложнее и дольше внедрять потом придётся. Сколько коммитетов/разработчиков — столько и подходов может быть. Все они профессионалы, бесспорно, но я сам, будучи разработчиком, не со всеми разработчиками согласен в решениях. Текущая статья: полная солидарность с разработчиками IPv6/NDP/MIPv6/и т.д…
>Цена должна быть оправдана. ~24 года с создания IPv6, ~40 с создания IPv4. И протокол никак не рассчитанный под современную сеть менять не хотят. У нас в компании думали внедрять IPv6 ещё лет 7 назад, с регистрацией своих префиксов и т.д., но из-за отсутствия совместимости Dual Stack в те времена отставили IPv4. И всё, внедрение не состоялось.
Ну а в США больше половины трафика это IPv6 *уже*. Можно и дальше бесконечно вспоминать старые времена как оно не получилось. 7 лет назад SLAAC-RDNSS мало кто поддерживал, сводя на нет его как возможную замену DHCP. Я IPv6 пользуюсь уже 10+ лет, но только сейчас вот написал про него статью, только сейчас считаю что пора.
Они не так отличаются по сути работы своей.
Между ними лежит пропасть сильно большая, чем между IPv4 и IPv6.
Единственное для чего он был нужен — как-то выжить в условиях нехватки IP адресов. На этом всём.
То, что лично вам NAT чем-то мешает не делает его автоматически не нужным. Я уже дважды писал для чего он требуется. И насчет всех этих идей про «выживание при нехватке IP адресов» – изначально NAT работал 1 к 1. А серые IP (нынешний NAT) назывались PAT и появились сильно позже. Поэтому NAT ортоганален нехватке адресов и вообще не для нее создан был.
Это решается маршрутизацией.
Для некоторых конфигураций, тот же результат можно получить через маршрутизацию. Но, только вы вообще представляете себе какую конфигурацию нужно наворотить для полноценной Anycast маршрутизации эквивалентной NAT-у? Я вот на вскидку знаю пару человек, которые за пол дня смогут сделать тоже самое, что за пару минут делается 2-3 строчками через NAT. И уж молчу про дополнительное оборудование и ценник на него.
Ваша идея использовать site-local адреса, без очень веских на то причин (они могут быть, не спорю, просто не верю что часто), гарантированно вызовет геморрой при коллизии сетей объединённых VPN-ом.
Что неожиданно легко решается NAT-ом. Зато ваша идея убьет сеть при смене провайдера.
Это ваше субъективное мнение. Наверное мозг людей по разному устроен. Но мне абсолютно несвязанные 4 десятичных числа не просто запомнить, вот честно, правда.
Тоже цифры, также несвязанные, только шестнадцатеричные и больше.
Ну вот за столько десятков лет IPv4 так ничего подобного и не сделали чтобы везде было и работало. IPv6 сделал.
Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.
Мне то странно видеть что вы её кладёте на этот путь. По вашей логике вообще не нужно ничего нового изобретать и писать новый софт.
Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP. Просто лет через 10 будут блочить уже ICMPv6 и всё.
Обыватели меня не интересуют.
Но у вас популистская статья, для обывателей. Не техническое сравнение, не примеры ваших кейсов и настроек — а ведь по комментариям видно, что у вас хорошо заработала связка IPv6 + IPSec для развертывания своих AutoConf сетей поверх интернета. Опиши вы её часть народа ломанулась бы повторять – вот вам и способствование внедрению IPv6.
Только заголовок обрабатывается сложнее (разная длина, плюс пересчёт checksum на каждом hop). А так да: в IPv6 аналогично, просто проще.
Я просто не знаю откуда вы это взяли…. Какая разница какая длина, если смещение адресов от начала пакета одинаковое? Для маршрутизации IPv4 лучше IPv6 из-за более коротких адресов для простых маршрутизаторов, а IPv6 лучше IPv4 из-за пока сильно менее раздутого числа маршрутов для Full View маршрутизаторов.
Вы придумываете.
Проблема не во FreeBSD, а в «альтернативных» стеках. Всякий IoT, роутеры, IP камеры и т.д., одно такое устройство, в котором одаренный программист не выполнил RFC (а у IPSec их здоровая куча) и всё – ваша дробленая сеть со сложной маршрутизацией с этим устройством работать не будет. А во всех этих девайсах лютый треш бывает.
На самом деле отличная apenwarr.ca/log/20170810 статья как-раз и предлагает делать на каждом порте коммутатора IPv6 сеть сразу же.
Статья ИМХО весьма противоречивая. Такое интересный идеализм игнорирующий и физическое устройство коммутаторов и смысл SDN-на и местами здравый смысл. Но реально слишком много — там целую статью писать можно в ответ.
IPv6 это RFC описывающие IPv6. Плюс NDP. Плюс ещё несколько. Не нужно приплетать странные (дурные) RFC ко всей кучи и считать что их или кто-то обязан реализовывать или хотя бы даже прислушиваться. Эти дурные вещи никто никуда не тащит, в здравом уме.
Зачем это куда-то тащить? И Windows и Linux исполняют RFC 7217, а до этого RFC 4941, которые как вы наивно думаете являются «странными (дурными)».
Ну… потому что вот прям буквально так и думаю, действительно.
Но я же говорю не об каких-то абстрактных материях – это то, что реализовано в операционных системах ещё со времен Windows XP. Да и как-бы конгломерат RFC описывающих IPv6 – эта здоровая куча из десятков взаимосвязанных документов, по несколько на все эти SLAAC, RA, DHCPv6, Address Architecture и т.д.
Из ваших комментариев становятся понятны и проблемы, с которыми вы столкнулись из-за серых адресов и как IPv6 хорошо лег на конкретно ваши задачи. Но я хочу заметить, что вы упорно пытаетесь экстраполировать свой сугубо положительный опыт на все кейсы. Однако, как правило, есть вторая сторона и плюсы уравновешиваются какими-то минусами. И я уверен, что если бы вы в статье сконцентрировались не столько на положительных (для вас) сторонах IPv6, сколько на условиях когда они проявляются и были бы менее категоричны в сторону NAT — статья бы выиграла.
Ваше субъективное мнение.
>То, что лично вам NAT чем-то мешает не делает его автоматически не нужным.
Штука которая делает неработоспособными любой протокол про который её явно не обучили? Какой бы костыль не был, но лучше без костылей.
>Что неожиданно легко решается NAT-ом.
Все ваши доводы по поводу NAT-а для меня выглядят абсолютно безумно нерациональностью. Вы представляете тяжеловесность NAT-а? Ну, в принципе что это за технология, как устроена? Очевидно что да. С таким же успехом, можно предлагать всё делать на прикладном уровне. Ну например HAProxy/nginx-ы разбирающие и балансирующие (или что там понадобится) HTTP запросы. Бывают места где без этого просто никак. А есть места где это сделать и просто, только крайне не эффективно с точки зрения ресурсов компьютеров. NAT относится к последнему. Просто все описанные вами usecase-ы, как их на лету подключать/отключать, меня конфигурацию и прочее — вовсю и по полной делается в ivi.ru, где я когда-то работал (не над сетями): о NAT-ах речи просто не может идти, когда трафик в сотни гигабит несколько лет назад был. Вопрос не в том что можно или нет решить эти задачи NAT-ом, а эффективно ли это или нет. Большинству людей просто поставить NAT на домашнем маршрутизаторе, чем писать правила firewall-а. Молоток предназначен для забивания гвоздей, а ещё им можно двери подпирать — это не значит что им стоит подпирать двери, если конечно он всё-равно при этом постоянно и для забивания гвоздей используется. В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.
>Microsoft сделал. На Linux серверах такой проблемы вообще нет. Даже для Linux клиентов есть свои аналоги вроде zeroconf & etc.
Только из коробки эти zeroconf мало в каких дистрибутивах идут.
>Но я же и возмущаюсь, тем, что ICMPv6 здесь не привнес ничего нового, а повторил сделанное и в дальнейшем отвергнутое в IPv4/ICMP.
Ну, тут я и остановлюсь пожалуй, ибо в RFC NDP (одного только NDP!), раз в моей статье этого не видно, не одна страница сравнения с IPv4 и сколько он нового привнёс. Если не замечать и всего остального в таком же масштабе…
И чем это отличается от того, что вы будете иметь без NAT?
Пусть у вас внутренняя сеть на мировых адресах, выданных из провайдерского /48, и вам протокол по каким-то причинам предлагает у клиента открыть порт и принимать на него соединения извне. Вы будете пускать всех, кто знает IP конкретного клиента? Спасибо, админ, предложивший такое, будет уволен за глупость и нулевые знания в области безопасности. Значит, файрволл по какому-то условию (клиент его оповестил, что есть внутри порт, или изнутри начали стучаться)? Тогда нет разницы с тем, что в случае NAT: за счёт граничного файрволла — протокол не работает.
Покажите мне, как вы будете решать эту проблему в случае вашего тотального IPv6 и без открытия внутренней сети всем мировым ветрам на вход. Покажете надёжный метод — ok, можно будет поверить, что это лучше NAT. Пока что сколько я ни спрашивал апологетов IPv6, мне никто на это не смог ответить.
На практике же в результате вместо, например, SIP — для которого задача пропустить медиапоток за NAT требует костылей вроде промежуточных прокси, STUN-серверов, ICE и т.п. — используют IAX2, у которого всё бегает по одной UDP ассоциации. Вместо FTP, с проблемами активного режима, массово используют HTTP. И так далее. И с таким уже нет разницы, NAT или не NAT, главное, что диверсанты снаружи внутрь не проходят.
> Все ваши доводы по поводу NAT-а для меня выглядят абсолютно безумно нерациональностью. Вы представляете тяжеловесность NAT-а? Ну, в принципе что это за технология, как устроена? Очевидно что да. С таким же успехом, можно предлагать всё делать на прикладном уровне.
Подробности в студию — как это по-вашему делается «на прикладном уровне». Один метод — завернуть всё в одно соединение (ассоциацию) я уже описал. Есть другие предложения?
> В IPv6 мире, считайте, исчезла задача забивания гвоздей — молотку не место.
Всё те же проблемы в том же виде.
Из этой поста, злоупотребляющем полужирным выделением и словами-лозунгами, создается впечателение, что молоток здесь именно как ipv6
а IPv6 лучше IPv4 из-за пока сильно менее раздутого числа маршрутов для Full View маршрутизаторов.
вы ошибаетесь, записей уже не меньше (то есть сам fw уже заметно толще). а если и правда каждая фирма будет брать себе as, то вообще коллапс настанет.
Когда его задумывали, предполагалась при этом и замена MAC адресов напрямую IPv6 адресами с отменой ARP. Можно поискать — например, по публикациям Radia Perlman (много агитировала за упрощение L2/L3 взаимодействия). Но на Ethernet это не состоялось. Состоялось только на Infiniband — там 16-байтный адрес формируется из GUID адаптера (это как MAC, но 8-байтный) стандартным link-local IPv6 префиксом.
> Удивительно, как имея IPv4 — далеко не идеальный и не беспроблемный протокол, десять лет его эксплуатации в живых сетях и решения проявившихся проблем можно было создать IPv6.
А они не думали толком. IPv6 стабилизировался в базовых спецификациях ещё до того, как IPv4 CIDR начал массово распространяться. Но отменять поспешные решения никто уже не хотел.
В 1994-м (год окончательного принятия 128 бит) шли шатания в предложениях; было одновременно 64 и 128, причём 128 вначале состояли из двух разных уникальных адресов (!) — 64 на глобально уникальный и 64 на локально уникальный. Окончательным аргументом в пользу 128 стало письмо:
==={{{ <9407072035.aa15952@sundance.itd.nrl.navy.mil>
Yes, you said the magic words, «FIXED LENGTH.» I have espoused the virtues
of fixed length addresses before. My biggest beef with variable length
addresses is the issue of maintaining additional state or taking additional
time to parse an address whose length I don't know at the start.
[...]
> 8 byte fixed length address.
I have no problem with this, but this alienates many people. Also, there
seems to be a trend toward low percentage of allocated address space used.
(I offer NRL itself as an example, though not the worst, of such waste.)
If we could pull it off with 8 bytes, I'd be all behind it.
> 16 byte fixed length address.
This eliminates much alienation. Furthermore, wasted address space is not
a significant problem here.
[...]
My position can be best summarized as:
The SMALLEST possible fixed-length address. And that length
better have a good justification for why it cannot be smaller.
===}}}
Источник: ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/1994-07
Видимо, это было последней каплей — безо всякого обсуждения данного письма все резко переключились на единственный вариант драфта — со 128-битными адресами.
Думаю, большинство обычных людей не готовы к такой (свободе).
А почему нельзя? Говорят, что даже винду сейчас со встроенным файерволом можно выставлять, не пробовал. Линуксовых хостов с реальными ip и пустыми iptables есть у меня в достаточном количестве.
хотя, конечно, я понял про что вы, просто поёрничать захотелось.
мне в этом споре сторонников выхода локалки через nat и сторонников файервола на роутере вообще непонятен предмет спора. по сути это одно и то же же, в linux используются одни и те же таблицы conntrack, настраивается через тот же самый iptables (или что там сейчас модно? nftables?)
заметной разницы с точки зрения настройки, внутреннего устройства и безопасности всего этого ИМХО нет.
только nat таки нужен, так что и в ipv6-only сетях он иногда будет встречаться (и вы вроде бы уже согласились с этим).
NAT сам по себе не является security feature. Но существование NAT и самого понятия "локалка" в 2020 отрицать столь же бессмысленно, как отрицать сам IPv6. Является NAT вселенским злом или нет — не суть важно, важно другое: из-за NAT все уже привыкли к тому, что безопасность внутри локалки можно поддерживать на уровне сильно ниже того, который необходимо поддерживать для доступных извне узлов. И сегодня бессмысленно давать этому оценку — хорошо это или плохо, корректно такое отношение или нет — потому что факт в том, что устройства и сервисы в локалке зачастую абсолютно ничем не защищены — ни файрволами, ни аутентификацией (либо аутентификация там уровня admin:admin).
Открывать ко всем этим устройствам и сервисам прямой доступ из внешнего интернета в текущих реалиях — безумие (что подтверждается недавними громкими атаками, когда JS в браузере юзера использовался для сканирования и атаки сервисов в локалке или на localhost). Обеспечить перенастройку локальных сервисов под стандарты безопасности внешних — даже не знаю, реально ли это в принципе (в мелких компаниях нередко используется в т.ч. самописный софт, в котором аутентификацию никто даже не предусматривал, потому что он же "только для своих" — его переделывание, учитывая что разработчик уже много лет тут не работает, а исходники потеряли… в общем это может оказаться похлеще проблемы 2000 и перехода на 64-битные процы вместе взятых). И даже если это реально — кто этим всем будет заниматься, и будет ли кто-то заниматься в принципе? И сколько времени на это уйдёт? В каждой SOHO локалке? Там обычно просто нет достаточно квалифицированных спецов для этой работы, равно как и нет понимания необходимости в этих изменениях.
Даже в этом треде отписалось несколько человек, которые пытались у себя внедрять IPv6 по собственной инициативе, и потом от него отказались, в т.ч. из соображений безопасности. Угадайте, что случится, когда в SOHO массово заработает IPv6, и следом их пойдут массово взламывать? Первым делом все они отключат IPv6, потому что с одной стороны будет паника, а с другой нет другого быстрого и дешёвого способа вернуть старый уровень безопасности для локалок. И уговорить их снова его включить может оказаться не так просто, как в первый раз.
Угадайте, что случится, когда в SOHO массово заработает IPv6, и следом их пойдут массово взламывать? Первым делом все они отключат IPv6, потому что с одной стороны будет паника, а с другой нет другого быстрого и дешёвого способа вернуть старый уровень безопасности для локалок. И уговорить их снова его включить может оказаться не так просто, как в первый раз.
IPv6 уже массово заработал в SOHO. В практически любом месте в смартфоне в США по умолчанию будет включен IPv6. Более того, особо упоротые мобильные операторы грозятся в ближайшем будущем отключать IPv4 по умолчанию и включать его только по явному требованию пользователя. Аналогично дела обстоят и с кабельным доступом.
Я админю некоторое количество серверов в США и веб-серверов в том числе, и это крупная международная компания. Не IT. Вот, полез проверил, у них на сайте примерно 60% запросов — из IPv6.
Что-то это не вызывает никакой паники.
Паника будет, когда его начнут массово ломать. А взлом дело такое, он работает от цены — как только текущими методами станет слишком дорого ломать, так сразу и переключатся на альтернативные методы, включая активное использование IPv6. Те же дыры в процах существовали лет 15, если не больше, и никому до них не было дела — пока были более дешёвые способы ломать. Аналогично будет и с IPv6 — чем больше вокруг IPv6 и чем лучше защищены системы на IPv4 — тем выше шанс, что начнутся массовые атаки на IPv6. Просто это случится ещё не сегодня, и даже не завтра. Но через 3-4 года — запросто.
Я написал: переход на IPv6 прямо сейчас сильно снизит безопасность SOHO; плюс многие из тех, кто в состоянии безопасно настроить IPv4, не готовы выделить достаточно много времени чтобы сделать то же самое для IPv6, потому что это значительно сложнее.
Вы ответили: IPv6 можно настроить безопасно если иметь достаточную квалификацию.
Поговорили, в общем.
Как только гугл закончит свою бессмысленную войну за хороший https и против гадкого http, вполне может оказаться, что следующей причиной для изменения рейтингов выдачи сайтов будет наличие AAAA записи в DNS. А однажды — отсутствие A записи в DNS ;)
И тогда все те, что горой стоят против внедрения IPv6, молча козырнут и бегом начнут переводить все свои сервисы на IPv6. А пока всё и так работает — "работает? Ничего не трогай!" (с)
Единственное, что стоит делать — продолжать внедрять IPv6, у себя дома, у друзей и родственников, на работе. Возможно, стоит в качестве благотворительности обучать людей, но я не уверен, что на всю Москву или Питер надётся десяток человек, которые хотят учиться.
вот вы сами и констатировали, что никому этот ipv6 не нужен
ага. я насмотрелся уже на любителей бежать впереди паровоза, например провайдер построил сеть на atm, который "вот-вот победит", в результате сеть сейчас перестроена на ethernet, сколько денег было вбухано впустую — страшно представить.
и таких примеров несть числа — infiniband, itanium, rdram, …
да, я немного передёргиваю, ipv6 взлетит. когда-нибудь. но пока большинство провайдеров ip4-only — о чём говорить?
Еще на практике сразу же прилетают другие грабли — чтобы работал SLAAC надо емнип чтобы провайдер выдавал /48 минимум, а это далеко не все провайдеры делают. Т.е. из-за SLAAC получается что деление на подсети прибито гвоздями RFC. Так и получаются всякие уродливые костыли типа NAT66.
Еще не совсем понятно как правильно организовывать зоны RLOC — тут тоже есть разночтения(например в 6LoWPAN).
L-2: The IPv6 CE router MUST assign a separate /64 from its
delegated prefix(es) (and ULA prefix if configured to provide
ULA addressing) for each of its LAN interfaces.
WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating
router the size of the prefix it requires. If so, it MUST
ask for a prefix large enough to assign one /64 for each of
its interfaces, rounded up to the nearest nibble, and SHOULD
be configurable to ask for more.
Не понял, как SLAAC связан с NAT66
Из-за того, что провадер дает меньше /64(некоторые дают вообще один адрес или /16), на помощь приходят всякие костыли типа NAT66.
И причём тут RLOC — тоже не понял.
Это не по теме SLAAC, но некоторые стандарты, которые основаны на IPv6 RFC, по разному определяют Realm Local.
Не так давно считал плотность адресов ipv4 по бесплатному набору данных от ip2location.com.
Карта:
https://alliumnsk.netlify.com/images/gradientm.png
ipv4 адреса распределены сильно неравнмерно. В китае ~4 человек на 1 айпи4 адрес, а в Канаде ~2.5 адреса на человека
p.s. благодаря написанию этого комментария осознал ошибку у себя
можно глупый вопрос? А ipv6 как-нибудь решит проблему того, что траффик, скажем из Сибири до Японии идет не напрямую, а через Москву, Западную Европу (опциально США) и только потом в Японию?
А ipv6 как-нибудь решит проблему того, что траффик, скажем из Сибири до Японии идет не напрямую, а через Москву, Западную Европу (опциально США) и только потом в Японию?
Нет конечно. Это две ортогональных сущности, роутинг и адресация.
если у нас такие адреса 128 бит, то туда можно класть широту долготу и подсказку по роутингу
ну и собственно в статье написано, что ipv6 это не просто более длинный адрес, но и много других хороших фич, так что можно было подумать и машрутизация лучше тоже
Нет, вот не нужно смешивать адресацию, маршрутизацию и ещё и географические координаты. Вот вообще не нужно, даже руководствуясь благими намерениями. Потому что вот прямо сейчас у меня на компе адреса, принадлежащие польскому и американскому провайдеру. Гугл, к примеру, считает, что я в США нахожусь. Потому что маршрут ко мне именно так и выглядит. И я лично хочу, чтобы так и продолжалось и впредь.
Я почему-то воспринимаю ваш комментарий как то, что сетевые протоколы должны позволять вам указывать подложное местонахождение, но не позволять другим получать близкий к оптимальному рутинг. Почему один юзкейс важнее другого? И почему они несовместимы?
Если добавлять в длинный адрес поля, подсказыващие географическое положение, никто же не запретит вам точно так же указывать подложные координаты?
А давайте я напишу вот только не нужно смешивать сетевые протоколы и методы анонимности в сети. Вот вообще не нужно, даже руководствуясь благими намерениями.
Нет, я совсем про другое. Про то, что пути роутинга неисповедимы и маршрут между двумя соседними домами на одной улице запросто может проходить через Варшаву, Ганновер и Хельсинки. И это правильно, не надо это ломать. Даже из благих побуждений.
Из этого следует прямой вывод, что географические координаты в адресе — бессмысленны. Адрес, он для машин, а не для людей, а раз географические координаты в адресе машинам не нужны, то и толкать их туда не надо.
Про то, что пути роутинга неисповедимы
Кажется, где-то я уже это слышал… пути божьи неисповедимы, поэтому не следует пользоваться контрацепцией (вариант: делать прививки, и.т.д.)
Некоторые вещи, однако, весьма исповедимы, такие как ограниченная скорость распространения сигнала (скорость света в вакууме поделить на показатель преломления оптоволокна) и вытекающая отсюда латентность на дальних расстояниях. Также весьма исповедима лень некоторых людей, не желающих править таблицу маршрутизации (пока это не влияет на их доход) и изобретающих весьма сложные отговорки.
а раз географические координаты в адресе машинам не нужны, то и толкать их туда не надо.
Да мне без разницы, каким способом, просто я хочу, чтобы скажем, у меня пинг до Кореи был не 500 мс, а хотя бы 90.
(Автор статьи, кстати, предлагал пихать в адрес человеко-читаемые рюшечки, по сути дублирующие DNS)
Также весьма исповедима лень некоторых людей, не желающих править таблицу маршрутизации (пока это не влияет на их доход) и изобретающих весьма сложные отговорки.
Людям, которые пытаются порулить таблицами маршрутизации, надо бить по шаловливым ручкам. Разные там BGP не зря придуманы и десятки лет отлизывались.
А машинные алгоритмы при выборе маршрута как раз и оперируют той же задержкой сигнала, как одним из многих параметров. Но только одним из многих.
Да мне без разницы, каким способом, просто я хочу, чтобы скажем, у меня пинг до Кореи был не 500 мс, а хотя бы 90.
И как этому может помочь впендюривание географических координат в IP адрес?
Универсальный совет, хотите небольшой пинг до XYZ — езжайте жить поближе к XYZ и выберите правильного провайдера с нужной связностью. Мне, к примеру, пинг в 90мс до Кореи не светит принципиально, потому что это физически невозможно.
traceroute to ppomppu.co.kr (110.45.151.153), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 ae-35.a01.nycmny17.us.bb.gin.ntt.net (128.241.2.249) 2.161 ms 2.214 ms 2.217 ms
6 * * *
7 ae-3.r22.asbnva02.us.bb.gin.ntt.net (129.250.6.116) 7.875 ms 8.931 ms 7.908 ms
8 ae-5.r23.lsanca07.us.bb.gin.ntt.net (129.250.3.189) 79.181 ms 79.198 ms 79.103 ms
9 ae-5.r01.lsanca20.us.bb.gin.ntt.net (129.250.6.49) 72.243 ms 76.325 ms 73.715 ms
10 ae-1.a01.lsanca20.us.bb.gin.ntt.net (129.250.2.214) 72.316 ms 76.786 ms 77.942 ms
11 ae-0.lgu.lsanca20.us.bb.gin.ntt.net (168.143.229.202) 69.884 ms 69.874 ms 68.233 ms
12 1.213.145.25 (1.213.145.25) 184.072 ms 1.213.149.161 (1.213.149.161) 71.271 ms 67.078 ms
13 1.208.105.17 (1.208.105.17) 236.061 ms 1.208.104.89 (1.208.104.89) 232.588 ms 1.208.105.17 (1.208.105.17) 232.250 ms
14 * * *
15 1.208.167.94 (1.208.167.94) 228.812 ms 1.208.172.38 (1.208.172.38) 255.913 ms 1.213.152.194 (1.213.152.194) 247.512 ms
16 1.213.149.13 (1.213.149.13) 239.558 ms 1.213.150.250 (1.213.150.250) 245.855 ms 1.208.175.126 (1.208.175.126) 239.431 ms
17 117.52.240.50 (117.52.240.50) 231.977 ms 117.52.240.38 (117.52.240.38) 241.309 ms 228.226 ms
18 61-111-1-118.kidc.net (61.111.1.118) 237.097 ms * 117.52.240.34 (117.52.240.34) 241.652 ms
19 110.45.151.153 (110.45.151.153) 243.424 ms 245.889 ms *
20 * 110.45.151.153 (110.45.151.153) 237.823 ms 247.705 msИ ничего с этим не сделать
Мне, к примеру, пинг в 90мс до Кореи не светит принципиально, потому что это физически невозможно.
Понятия не имею, где вы живете. Для Москвы, где наибольшая плотность хабраюзеров, пинг 90 мс до Кореи физически возможен. В Новосибирске, где я живу, тем более.
Универсальный совет, хотите небольшой пинг до XYZ — езжайте жить поближе к XYZ
вы это серьезно? Зачем тогда этот энторет если можно взять лошадку и приехать к человеку лично?
выберите правильного провайдера с нужной связностью.
Мне теперь под каждый сайт подбирать провайдера? А перед провайдерами еще слой аки костыльный NAT ставить?
Вы привели пример traceroute из IPv4. Автор поста указывает, что в IPv6 адреса выдаются иерархически, поэтому таблицы маршрутизации получаются меньше и проще. В IPv4 же у одной страны масса несмежных диапазонов, адреса в цепочке traceroute похожи на хэши. Вот я и подумал — может в сети ipv6 быть пинги хоть немного ближе к физически возможным станут… разве это не одна из первоочередных задач сети? (а не обеспечивать сетевых инженеров зарплатой).
Для Москвы, где наибольшая плотность хабраюзеров, пинг 90 мс до Кореи физически возможен. В Новосибирске, где я живу, тем более.
Вы основываетесь на предположении, что существует прямой оптоволоконный кабель Москва-Сеул. Или Новосибирск-Сеул. Что цена на аренду канала в нем конкурентноспособна с остальными вариантами. Да что там цена, вообще просто есть возможность аренды, он не перегружен. Что Ваш провайдер прямо заинтересован в быстрой доставке контента из Южной Кореи своим потребителям и готов понести на это некоторые финансовые затраты. В таком идеальном мире да, до Новосибирска возможен пинг в 90мс. До Москвы — сильно сомневаюсь, на одной ретрансляции только больше потеряется. Это если не считать 50-60мс чистой задержки в стекле. Будет ближе к 200мс. Сорри, законы физики не обмануть.
от я и подумал — может в сети ipv6 быть пинги хоть немного ближе к физически возможным станут… разве это не одна из первоочередных задач сети?
Нет, это вообще никоим боком к версии IP не имеет. Физический и канальный уровень определяет всё и он никак не зависит от (желаемой) сетевой маршрутизации. А именно он будет определять задержки в канале. Есть прямой канал из X в Y, возможно на сетевом уровне будет принято решение использовать его. Нет прямого, из X в Y пакеты пойдут через Z. Из моего опыта пинги в IPv4 и в IPv6 примерно одинаковы, плюс-минус. Чуть меньше в IPv6 только из-за того, что там пока чуть меньше загрузка канала.
Вы основываетесь на предположении, что существует прямой оптоволоконный кабель Москва-Сеул.
отнюдь нет. Расстояние до Сеула через Владивосток, Хабаровск ненамного длинее прямого.
"зоконы физики" не определяют задержки на ретрансляцию, они могут быть сколь угодно малыми. То что может быть у провайдера клиенты хотят больше смотреть 4к видео на ютубе, чем пинг до Кореи, это не физика, это экономика. Но, простите, как говорил ОП, я хочу иметь интернет а не удаленный доступ до гугла и фейсбука.
Я всего лишь прошу чтобы пинг до Кореи у меня был в ТРИ раза хуже физически возможного, а не равным физическому пределу. А сейчас у меня до некоторых сайтов там пинг 450.
Из моего опыта пинги в IPv4 и в IPv6 примерно одинаковы, плюс-минус
в чьем юскейсе примерно одинаковы? Между Роттердамом и Франкфуртом наверное и так маршрутизация неплохая что в 4 что в 6. А у кого-то что-то в юзкейс как раз и не входит из-за плохого соединения. Как соединения поменяются, юзкейс тоже может поменяться.
отнюдь нет. Расстояние до Сеула через Владивосток, Хабаровск ненамного длинее прямого.
А кто Вам сказал, что существует канал Владивосток-Сеул или Хабаровск-Сеул, что он не загружен настолько, что в этом канале возникают потери и маршрутизация на автомате не начинает избегать этого канала?
в чьем юскейсе примерно одинаковы? Между Роттердамом и Франкфуртом наверное и так маршрутизация неплохая что в 4 что в 6. А у кого-то что-то в юзкейс как раз и не входит из-за плохого соединения.
Вы по прежнему основываетесь на предположении, что существует какие-то особые специальные физические каналы для Интернета. На практике цифра и голос делят одни и те же мощности и выделение нового канала передачи данных — это выделение очередного контейнера в SDH в магистральном канале. Да, может быть такое, что Ваш провайдер по IPv4 подписал один договор, и по IPv6 — другой, с другим поставщиком. Но вероятность этого исчезающе мала исключительно по экономическим причинам.
"зоконы физики" не определяют задержки на ретрансляцию, они могут быть сколь угодно малыми.
Это только Вам так кажется. В реальном, неиллюзорном мире все цифровые электронные устройства имеют вполне ощутимые задержки в обработке сигнала. Точно так же, эти же самые законы физики не дают построить компьютер с бесконечно большой производительностью. То, что частоты процессоров уперлись в потолок и практически не растут — это оно, физические ограничения.
Вы по прежнему основываетесь на предположении, что существует какие-то особые специальные физические каналы для Интернета. На практике цифра и голос делят одни и те же мощности и выделение нового канала передачи данных
вы в каком году живёте?
какой голос? его доля в магистральных каналах исчезающе мала.
и вот только вчера смотрел:
https://www.hetzner.com/unternehmen/rechenzentrum/
вы уверены, что линки в 600 и 400 гигабит по SDH идут?
В реальном, неиллюзорном мире все цифровые электронные устройства имеют вполне ощутимые задержки в обработке сигнала. Точно так же, эти же самые законы физики не дают построить компьютер с бесконечно большой производительностью.
имеют. только когда мы говорим о дополнительных задержках в сотни миллисекунд — дело всё-таки не в "задержках ретрансляции", а в буферизации, перегрузке каналов/шейпинге, китайском файерволе, …
ну и географически неоптимальные маршруты тоже вносят свою лепту, конечно.
до физических ограничений в большинстве случаев нам ещё пилить и пилить.
какой голос? его доля в магистральных каналах исчезающе мала.
Это ничего не меняет. Магистральщики — это отдельный вид разумных существ, с интернет-провайдерами они не скрещиваются ;)
вы уверены, что линки в 600 и 400 гигабит по SDH идут?
А Вы уверены, что это пропускная способность единичного канала, а не агрегированная из множества каналов STM-64? Или речь о том, что провайдерам SDH не виден, им виден MPLS, а что там в канале, они не знают и им всё равно?
Вы по прежнему основываетесь на предположении, что существует какие-то особые специальные физические каналы для Интернета.
Не основываюсь. Кроме того, 500 мс для общения голосом это чрезвычайно некомфортно тоже.
Какой такой закон физики(tm) ограничивает время рутинга пакета?
По моему скромному опыту, RTT в глобальной сети сильно больше зависит от длины пути в кабеле, чем от количества маршрутизитаторов, которые он проходит. Обработку заголовков можно сделать за микро-наносекунды, а вот миллисекунды на прохождение 9000 км сократить не удается.
Обработку заголовков можно сделать за микро-наносекунды
Она и происходит за наносекунды. Проблема в том, что эта операция происходит очень много раз. И набегают миллисекунды. Но хуже того, чтобы усилить сигнал в оптоволокне, нужно раз в 50-100км преобразовывать его в электрическую копию, восстанавливать форму сигнала и потом преобразовывать его в свет обратно. И вот тут всё происходит ну просто ужас как медленно по сравнению с остальными процессами. Придумайте, как сделать это быстрее хотя бы раза в два — в три, станете очень богатым человеком.
Кроме того, 500 мс для общения голосом это чрезвычайно некомфортно тоже.
Задержка голоса в 500мс вполне себе бывает в мобильных сетях. Особо не мешает. Разве что эхо раздражает.
Но вообще я не пойму, что лично Вы хотите? Чтобы Ваш провайдер проложил оптоволоконную магистраль прямо в Сеул? Каким образом это относится к обсуждению исходной темы?
EDFA усилители постепенно ухудшают форму сигнала, кроме того, каждый из них ухудшает сигнал/шум в усиливаемой полосе примерно на 2-3 дб. Поэтому кроме них в канал периодически ставят оптико- электрические усилители, это не коммутаторы, это просто ретрансляторы, поэтому задержки в них гораздо меньше. Но они всё равно есть. Поэтому даже если у вас 6000км оптоволоконного трансатлантического кабеля, у которого по дороге под водой 100% нет ни одного коммутатора, то задержка составляет не 30мс, как следовало было ожидать, а около 50, или около 100мс пинга. В любом случае мне понятны хотелки пользователей, чтобы из Новосибирска до корейских игровых серверов было 90мс пинга, мне непонятно, согласны ли они за это платить. Ведь это находится близко к теоретическим пределам в существующих сетях.
так тут говорят не просто "хочу 90мс", а "теоретически возможно 90мс, а на деле почти 500мс". было бы 150мс, может и не было бы жалоб?
Жалобы бы были, потому что предел играбельности — порядка 100мс. Всё, что больше, уже не позволяет конкурировать с локальными игроками. Но, поскольку "узок их круг, и страшно далеки они от народа" (с), то вряд ли провайдеры когда-либо обратят внимание на проблемы данной категории пользователей. Хотя как раз 150мс вместо 500 им достаточно просто получить, достаточно заплатить несколько миллионов рублей в год за собственный канал в Сеул, а не гонять всё через Москву.
Один из самых прямых известных мне маршрутов это ttk-Новосибирк > vk.com-Москва, петель нет, расстояние 2818 км. Теоретический минимальный ping 28мс, фактический 40мс. Из Омска меньше на 5мс, значит есть коммутаторы по пути и волокна проложены не по прямой. И всё же задержка только 30% выше теоретической.
Вы зря тут про 50-100 км написали. В обсуждаемом случае этих километров из-за кривой маршрутизации приходится примерно раз в 10 больше, чем могло бы быть. Никакая ловля блох оптимизация повторителей не даст желаемого RTT при следовании такому маршруту.
Чтобы Ваш провайдер проложил оптоволоконную магистраль прямо в Сеул?
я кажется написал что хотел 90 мс. Прямой канал Сеул-Новосибирск дал бы, как максимум, 50 мс, это огромный оверкилл.
Каким образом это относится к обсуждению исходной темы?
ну так ОП написал что маршрутизация в ipv6 должна быть лучше, потому то и потому, и потому что адреса выдаются иерархически, и ipv6 это не только 128 бит против 32 но и куча других плюшек.
Автор статьи, кстати, предлагал пихать в адрес человеко-читаемые рюшечки, по сути дублирующие DNS
Уже всё давно придумали до нас
Это всё просто замечательно, адреса типа ru/msk/south_butovo/gorchakova_st/43/app123 вообще прекрасно человекочитаемы и вполне себе содержат географические данные. Но. Сущая малость. Надо теперь научить машины(маршрутизатор, он тоже машина, только сильно заточенная на один специфический вид деятельности) разбирать такие адреса миллионами в секунду и на их основе строить маршрут доставки. Это такая малость, но портит абсолютно всё.
Strawman
Ну нет же. Вы, вместе с авторами NDN, пытаетесь в сущности, предназначенные исключительно для машинной обработки, вложить удобные человеку понятия, категории и смыслы. Безусловно, это можно сделать. Но это лишь усложнит машинную обработку и, внезапно, не принесет никакой выгоды человеку. Вы на практике не пользуетесь IP адресами, вы используете DNS имя, которое как раз и предназначено для удобного использования человеком. А маршрутизатору абсолютно всё равно, есть ли какой-то физический смысл в IP адресе, который он сейчас форвардит, ему достаточно одной записи в таблице маршрутизации, по которой он примет решение.
Широта и долгота вообще-то не очень человеко-читаемые единицы, тем более в сжатом виде, strawman же..
ему достаточно одной записи в таблице маршрутизации, по которой он примет решение.
И отправит траффик до Кореи через Европу — ну а что, достаточно же, дойдет. Может быть действительно там нехватка каналов, но что-то я думаю что костыльность нынешнего ipv4 заключается не только в несоотвествии числа адресов и хостов, но и алгоритм тоже неидеальный.
И отправит траффик до Кореи через Европу — ну а что, достаточно же, дойдет. Может быть действительно там нехватка каналов, но что-то я думаю что костыльность нынешнего ipv4 заключается не только в несоотвествии числа адресов и хостов, но и алгоритм тоже неидеальный.
И правильно сделает, что отправит через Европу, что бы Вы лично хотели больше, пинг 500мс и 100% доставка(ну ладно, почти 100%), или 90мс и потери в 10%? Чуда ведь не будет, какой протокол не придумай. Кроме того, нужно учитывать тот факт, что у любого провайдера на периферии самый толстый и надежный канал будет в Москву и СПб, потому что хотите Вы того, или нет, но 60-70% трафика будет именно туда. Будут ли вообще какие-то другие каналы вообще — тут вопрос, есть ли у провайдера деньги на дополнительные плюшки. Чаще всего их, денег, на все плюшки не хватает.
Широта и долгота вообще-то не очень человеко-читаемые единицы, тем более в сжатом виде, strawman же..
Не знаю, что такое широта и долгота в сжатом виде, но это сущности, придуманные человеком и для человека. В цифровых сетях они не имеют вообще никакого смысла. Не понимаю, почему они так для Вас важны.
пинг 500мс и 100% доставка(ну ладно, почти 100%), или 90мс и потери в 10%?
Так это ж от юзкейса зависит. При латетности 90 мс можно еще пакет заново запросить несколько раз. Если перезапросить потерянный пакет 2 раза, получится 0.1% потерь вместо 10%.
но это сущности, придуманные человеком и для человека
таким же образом можно сказать что двоичную систему придумал человек для человеков, работающих с машинами.
Не понимаю, почему они так для Вас важны.
затем, что Согласно теории относительности, никакой сигнал не может распространяться быстрее скорости света, следовательно, и если маршрут сильно кривой то будет высокая латентность.
Это не задача протокола. Это как ваш провайдер (или его апстрим, или апстрим апстрима, и т.д.) решит. Сам хожу до Кореи через США с Сахалина :D Именно по-этому поднят гейт в Токио, через который пускаю весь трафик в азию)
Вообще-то никто не мешает использовать NAT для IPv6. Это же только транспорт, ему все равно, какие технологии поверх него используются.
Угу. И однажды не получить доступ к очень нужному в данный момент ресурсу, который IPv6 only. А такие уже вот прямо сейчас есть. Мне лично транспорт как таковой неинтересен, мне ехать, а что там под капотом, всё равно. Но ведь жизнь заставила сесть и всё настроить. Так вот, заглянув под капот, я понял, что там в общем всё в порядке, ездить можно. Но тут уже сотни сообщений настрочили, что я ошибаюсь, и мне IPv6 не нужен и даже вреден. Ну ок.
Ну вот у меня есть ;) Ресурсы, которые позволяют мне зарабатывать деньги — это достаточно важные ресурсы?
Список в студию, плз.
Я на них деньги зарабатываю, NDA.
Я об этом выше уже писал. Внутренняя сеть компании — IPv6 only. Active Directory, IIS, ERP, MS SQL и Oracle, всё на доменных именах и IPv6. Nginx вот правда, с веб-сайтом компании, наружу торчит в IPv4. Вернее, в dual stack. В запросе к сетевикам, когда я хочу новую виртуалку задеплоить, вопрос про IPv6 вообще не стоит, а вот вопрос "нужно ли выделение IP4 адреса" имеется. И потом в списке из семи пунктов, почему нужно выделять IPv4 адрес, нужно выделить один или несколько пунктов. Первый пункт — "будет использоваться ПО, которое не поддерживает IPv6 и нет возможности это ПО не использовать". Последний — "требуется для разработки и тестирования". Тогда под виртуалку выделят отдельную железку, которая включена в отдельный влан из отдельного коммутатора. После чего мне нужно будет, по имеющемуся опыту, от двух недель до месяца ждать, пока вся эта корпоративная бюрократия предоставит мне к такой виртуалке удаленный доступ. А вот если она обычная, IPv6 only, то через пару дней максимум. Поэтому у меня никогда не возникает соблазна поставить галку "нужен IP4", ну его нафиг. Да и не было необходимости никогда.
Если я правильно понял MikFoxi (а если нет — он поправит), то речь шла вовсе не о внутренних ресурсах, а о популярных сайтах во внешнем инете.
А. В этом смысле да, не думаю, что это будет скоро, популярные сайты только на IPv6. Наиболее вероятный сценарий — гугл начнет снижать рейтинги показов сайтов в поиске за наличие IN A записи в DNS. И вот как только он об этом только объявит, начнется массовый отказ от IPv4 ;) А он вполне такое может запилить. Но, как я уже говорил, мне в общем всё равно, что, кто и как использует. Мне не шашечки, мне ехать. Будет IPv6 Ok, хорошо. Запилят какой-нибудь IPv2020 — ну да ладно, будем его использовать, когда надо. В начале 90-х я в одном министерстве убеждал типа именитых профессоров и к.т.н., великих технических специалистов, что X.25 это безусловно круто, но будущее за TCP/IP. Было весело видеть их унылые лица, да. А ещё раньше, в начале 80-х, я получил трояк за курс "теория СВЧ устройств", потому что сказал, что однажды технология производства полупроводников позволит работать в гигагерцовом диапазоне без всяких магнетронов и всей этой посеребренной канализации. Жаль, что препод не дожил до IEEE 802.11ac в коробочке, которая продается в каждом супермаркете.
Мое мнение:
Как клиенту инет провайдера, ipv6 мне не нужен и даже вреден (если внедрять по полной и пров будет раздавать подсеть чтоб каждому утюгу по выделенному ипу), потому что это нарушит безопасность моей локалки, да и куча устройств у меня которые не поддерживают ipv6.
Как админ сайтов — надобности в ipv6 мне нету, т.к. у всех посетителей всегда есть ipv4, сайты мои в РКН не забанены, чтоб иметь запасные ипы. Зато вред от ipv6 сайтам есть, изза того что их безлимит (благодаря утюгам, имеющим белый ipv6 и выход в интернет и которые уже взломаны), хоть поштучно, хоть подсетями учитывай, с них немерянно валится чернухи — ддосеры, брутфорсеры, поиск уязвимостей, создающих нагрузку и опасность серверу, тенденция эта постоянно растет и будет расти. Потому я даже сайтам которые за cloudflare отключаю ipv6, чтоб видеть меньше мусора в логах.
А популярные сайты, инста, фб, ютуб и т.п. которым как бы по статусу для солидности надо иметь ipv6 — их от этого парсить проще, дешево взять ipv6 проксей и качай сколько хочешь, с ipv4 проксей их парсить можно разориться.
Вы уже тратите администрирование сетей больше. Хотите чтобы все этой х… ней занимались? Оставьте только ipv6, коли вы такой евангелист и напишите мне через полгодика, сколько ресурсов из вас нужных вам не ответило.
Я правильно полагаю, что пока Хабр не включится в ipv6, вы мне не ответите?
Я правильно полагаю, что пока Хабр не включится в ipv6, вы мне не ответите?
Неправильно полагаете, поскольку давно изобретен NAT64
Вот в обратном направлении есть определенные проблемы, и без прокси-серверов уже не обойтись. Но да, не могу сказать, что там большие проблемы, просто надо помнить… о нюансах, скажем так.
Если все это выпустить в свободный интернет — это будут постоянные кражи персональных данных, взломы всего, и вообще это будет всемирный ботнет.
Ну так не выпускайте — настройка ipv6 firewall часто это просто 1 крыжик в веб-интерфейсе.
Он даже может быть уже включен по умолчанию.
В добавку к всем плюсам IPv6 добавлю что DNSSEC который имеет в мире распространение в 2% всех клиенских зон (3 уровня и выше) на мой взгляд тормозится именно из-за IPv4, ибо SlitDNS с DNSSEC эта та еще боль, которая попросту не нужна в случае использования прозрачной маршрутизации IPv6. Что бы его завести приходится вырубать DNSSEC валидацию для своих субдоменов, либо делать свои приватные DNS публичными и на них настраивать IP Scope
а он заряжен бумагой?
Бабушка поспорила с Сёмой, что он не съест 25 её пельменей на то, что он уберёт в квартире…
И вот Сёма доедает 24-й пельмень, а 25-го в тарелке нет…
Извините, не выдержал...
Например люди работающие в крупном сотовом операторе, и паре региогиональных провайдеров, на вопрос, а когда айпивишесть, сказали что никогда, поскольку оборудование сорм с оным не работает, и есть полунегласные директивы от руководства даже не смотреть в ту сторону, хотя самый главный препон, наличие легаси оборудовния уже практически преодолен, а через примерно лет пять будет преодолен полностью.
А так то да, половина маршрутизации это есть костыли направленные на устранение несоответствия числа хостов числу айпи адресов…
Предлагаю автору от теоретического описания плюсов ipv6 перейти к практической демонстрации как всё в действительности сейчас. Как все это выглядит для среднестатистического пользователя.
На примере среднего роутера типа упоминавшегося в ветке asus ac1200g+ показать что где включалось, настраивалось. Какой провайдер какой ipv6 выдал. Какие разные устройства подключаются к этому роутеру и как безопасно они себя чувствуют "вывалившись" в сеть. Какой фаервол на роутере, какие фаерволы на компе с виндой с линуксом, вайфай часах, каком нибудь увлажнителе с файфаем, принтере, телефоне на андроиде или иосе, каком нибудь шлюзе умного дома и лампочках с вайфаем, медиаплеере.
Как подключаются в эту схему старые устройства с ipv4 только.
А главное показать безопасность всего этого. Попробовать провести "проникновение". Проверить не светит ли в сеть какойнибудь домашний медиасервер с домашним видео или nfs шара или самба. Нужны ли и есть ли фаеволы на конечных пользовательских устройствах или достаточен файервол на обычном роутере и достаточен ли.
Вот тогда на реальном примере станет яснее хорош ли ipv6 и не пора ли его использовать.
Никак оно не должно выглядеть, плагэндплей.
-Какой провайдер какой ipv6 выдал
В РФ никакой не выдаст, version6.ru/isp, вы видели в списке роскомпозора в6 адреса? А какой выдаст там все это ограничится внутренней сетью без маршрутизации в интернет, на радость мамкиным хацкерам из этой сети.
-Нужны ли и есть ли фаеволы на конечных пользовательских устройствах
Файрвол? Какой файрвол? Астрологи объявили неделю снижения цен на дедики!
В РФ никакой не выдаст
МТС и Скайнэт выдают. Глобально маршрутизируемые.
МТС и Скайнэт выдают
мтс проводной не выдаёт. у нас, во всяком случае
хм, интересно… два телефона с ipv6 адресами могут связаться напрямую, минуя провайдера?
Что понимается под словами "напрямую, минуя провайдера"? Минуя маршрутизацию через оборудование мобильного оператора? Нет, и тут версия протокола или адресация не при чем. Канальный уровень, передача сигналов в сотовой сети так устроена, что это невозможно.
Понимается, что по вашему совету, юзеры взяли лошадок и едут навстречу друг другу. Пока они далеко, сигнал идет через провайдера. Как они оказались в прямой видимости, маршрутизация прозрачно меняется.
Вопрос в том, насколько это достижимо на практике
Как протокол сетевого уровня может исправить то, что невозможно сделать исходя из ограничений физического и канального уровней? Два приемопередатчика мобильных телефонов не умеют связываться между собой. Только с базовой станцией мобильного оператора. А вот там уже возможны варианты. Но сейчас, при текущих настройках, базовая станция отправляет полученные пакеты от пользователя сразу поближе к ядру сети, туда, где биллинг, аппаратура по закону Яровой, где пакет данных будет обмерен, проклассифицирован и копия которого будет сложена на три года ждать оперативных действий силовиков. А уж потом он вернется назад на эту же базовую станцию (может быть, пройдя при этом сотни и тысячи километров) и с неё будет отправлен другому телефону.
Это недостижимо по политическим причинам. Государство просто не допустит существование таких протоколов передачи данных. Ни у нас, ни в самых распрекрасных оплотах демократии. Но особенно у нас. Поэтому только так, любой чих — через мобильного оператора. И — в папочку.
Ну то есть связываться напрямую айпи6 не позволяет, и пинг не уменьшает…
(Т.е. буде потребуется прямое соединение, нужно будет на уровне приложения делать переключение протоколов. Примерно как сейчас с NAT'ом)
Что остается в сухом остатке?
Айпи6 лучше чем айпи4? Армяне лучше чем грузины? Чем же? Чем грузины...
Ну, лично я никогда и не ставил акценты в таком ключе, что кто-то из них лучше. Я лишь говорил о своем личном опыте, что однажды я обнаружил, что мне IPv6 необходим и я для этого сменил провайдера только потому, что старый не давал ни статики по IPv4, чтобы работал туннель до Hurricane Electric, ни собственного IPv6. Потом я съездил в штаты и с удивлением узнал, что у T-Mobile, а это, на секундочку, один из крупнейших мобильных операторов США, оказывается IPv6 доступен изначально, а вот IPv4 надо открывать дополнительным соглашением, но без этого соглашения и так интернет прекрасно работает. И что это никакой не как-бы экспериментальный протокол для гиков, а вполне себе коммерческое решение, широко используемое во всем мире. Доля IPv6 мировом трафике растет огромными темпами, даже в Китае и Индии, и только бывший совок плетется в хвосте. И вот тут мне становится немного непонятно, не происходит ли тут технологическое отставание нашей страны в базовых для информатизации вещах. А после вала сообщений здесь типа "наши деды всегда трутом и кресалом огонь добывали, зачем нам ваши зажигалки" я понял ещё одну вещь, что тут не только налицо само технологическое отставание, это как раз можно преодолеть. Налицо ещё и психологическое нежелание это отставание преодолевать, поскольку это выводит из зоны комфорта. Ну ок, я не собираюсь здесь проповедовать, мессия из меня никакой. Это скорее просто ещё один небольшой довод в копилку для того, чтобы завести трактор.
я так тоже могу перефразировать "наши деды еще гоняли сетевые пакеты в Японию через Голландию, зачем нам ваши прямые маршруты".
А вообще да, ретроградство случается. Я вот на фотофорумах его постоянно вижу и часто оно приправляется фразой "законы физики" о.о
даже в Китае и Индии, и только бывший совок плетется в хвосте.
для Индии как раз очень понятно: большое население, маленькое колчество выделенных ip4 адресов. (40 миллиона адресов это меньше даже чем у Австралии), они просто вынуждены. А Китай на карте доли ipv6 закрашен тем же красным, что и РФ.
Ну то есть связываться напрямую айпи6 не позволяет
Что значит «напрямую»?
При наличии у двух устройств глобально маршрутизируемых адресов и сетевой среды — позволяет.
буде потребуется прямое соединение, нужно будет на уровне приложения делать переключение протоколов.
Приложениям обычно вообще пофиг — v4 или v6, что нарезолвилось из DNS — на тот address family сокет и открывается.
"не позволяет" — я тут только транслирую мнение юзера Tolmy.
я уже писал что в этом вопросе "напрямую" значит "минуя провайдеров" когда устройства находятся близко. Если два устройства в прямой досягаемости будут гонять траффик через провайдера интернета — то это очень похоже как бы если они сидели за NAT'ом, а прелесть именно глобально маршрутизируемого адреса не очень-то и видна.
Нет. Прелесть глобально маршрутизируемого адреса в том, что если вы стучите на порт 5678 — вы можете быть уверены, что трафик идет именно приложению, слущающему порт 5678.
Никакого NAT, именно прямая связь в рамках межсетевой среды.
А device-to-device mesh — это вообще ортогональная тема, да еще и парой уровней OSI ниже.
Прелесть глобально маршрутизируемого адреса в том, что если вы стучите на порт 5678 — вы можете быть уверены, что трафик идет именно приложению, слущающему порт 5678.
Никакого NAT, именно прямая связь в рамках межсетевой среды
а какой тут use case?
вот есть у меня ip и порт некоего сервиса (моего или чужого — не важно). какое мне дело до того есть там nat или нет? может там вообще reverse proxy с nginx/haproxy/sslh/etc, какая разница, если оно выглядит как утка и крякает как утка?
Может быть сначала оно идет товарищу майору, а уже потом приложению на другом конце? Некоторым это не нравится больше, чем NAT.
Ну почему ж она ортогональная-то? Вот допустим сидят в одном опенспейсе Вася и Петя, обмениваются данными. Вдруг рутер умер/крысы перегрызли кабель и т.п… Соединения порвались. В чем "глобальность" маршрутизации тогда заключается, если приложения на планшетах Васи и Пети не могут более сообщаться? Таким же образом можно было бы считать ICQ UIN или имя на фейсбуке глобально маршрутизируемым.
В случае с ipv4 невозможность связи после обрыва была понятной — адресов не хватало, и приложение на планшете Васи не знало, что за такими-то циферками и номером порта скрывается хост который физически в радиусе 10 метров находится. ipv6 благодаря большому количеству адресов может назначить одинаковые адреса в "старой" умершей сети и во временной сетке между устройствами Пети и Васи.
Может быть сначала оно идет товарищу майору, а уже потом приложению на другом конце? Некоторым это не нравится больше, чем NAT.
Если вы не контролируете среду передачи — вы не контролируете утечки. А вы не контролируете в общем случае.
Вот допустим сидят в одном опенспейсе Вася и Петя, обмениваются данными. Вдруг рутер умер/крысы перегрызли кабель и т.п… Соединения порвались.
С чего они порвались то, если оба адреса в одном бродкаст домене, а умер роутер?
В чем «глобальность» маршрутизации
В том что отпадает разделение на приватные и маршрутизируемые адреса ввиду того, что /64 хватит всем в любой сети. Адресное пространство становится плоским и полносвязным.
Ну почему ж она ортогональная-то?
Потому что IP — это про адресацию и маршрутизацию. Потому что в отношении доставки данных он полагается на нижележащие слои OSI.
И говорить «может ли v6 обеспечить связность без провайдера» некорректно. Т.к. обеспечивать связность — это ответственность технологии уровнем ниже. Формально — у вас всегда есть провайдер.
С чего они порвались то, если оба адреса в одном бродкаст домене, а умер роутер?
ну я имел в виду ситуацию, когда рутер одновременно является точкой доступа wi-fi.
Потому что IP — это про адресацию и маршрутизацию. Потому что в отношении доставки данных он полагается на нижележащие слои OSI.
Что вы так к этой сферической в вакууме модели OSI привязались, вот она уж точно ортогональна моему вопросу. Вопрос про реальные реализации ipv6 на которые предлагается переходить. Мой первоначальный вопрос был могут ли два телефона с ipv6 адресами (андроид 9.0-телефоны подключенные к МТС) связаться напрямую если они находятся близко, чтобы не платить за траффик который идет через оператора сотовой связи.
Что вы так к этой сферической в вакууме модели OSI привязались
Да потому что среда решает.
Мой первоначальный вопрос был могут ли два телефона с ipv6 адресами (андроид 9.0-телефоны подключенные к МТС) связаться напрямую если они находятся близко, чтобы не платить за траффик который идет через оператора сотовой связи.
Нет, конечно. А вот при помощи Direct-а могут.
Да потому что среда решает.
модель OSI запрещает использовать одновременно два транспорта?
Нет, конечно. А вот при помощи Direct-а могут.
а что произойдет при этом с соединениями открытыми с глобальными ip6 адресами? они превратятся в тыкву?
модель OSI запрещает использовать одновременно два транспорта?
Нет конечно. Но вы формулируете априорно некорректно — смешиваете межсеть и доступ к среде: «позволят ли глобальные v6 адреса связываться напрямую в сотовой сети, минуя провайдера», тогда как это вообще не функция межсети.
а что произойдет при этом с соединениями открытыми с глобальными ip6 адресами? они превратятся в тыкву?
Нет конечно. Они как висели на интерфейсе сотового модема, так и останутся. а в директе вы получите link-local-ы с префиксом fe80/16, не глобальные, но позволяющие обменяться в одном директ-домене.
1) Выдают глобально маршрутизируемые
2) У меня свой роутер, настраивал сам
3) Рутрекер доступен по https
Я на дня выступление слушал, там человек про iOS странности в ipv6 рассказывал. Если резюмировать, то в ipv6 iOS голой жопой наружу, и весьма несложно ломается и ничего с этим не поделаешь, там ещё описывался факт подмены маршрутизатора для iOS. Ей можно широковещательным пульнуть, что её ip хотят и она новый попросит у маршрутизатора. Так что с ipv6 мальчики просто не сталкивались ещё с проблематикой, когда поведение смартфона в сети никак не откорректировать, остаётся с этим жить. Только с ipv6 придётся с этим жить в публичной сети. Кстати, кто знает, как в iOS настраивается фаервол?
Кто-нибудь! Расскажите этому мальчику о недостатках и нерешённых проблемах, которые ставят под вопрос целесообразность внедрения этой технологии. Ситуации с wi-fi, который везде и всюду уже достаточно, чтобы не продолжать.
В домашней сети с /64 на роутере — просто работает (SLAAC, RADVD).
А вы бы не тратили время на чтение комментариев, псевдоучёных, которые в основном зарабатывают рейтинг перед будущим работодателем, а почитали бы больше статей по проблематике использования ipv6. Или вас родители не научили кучку сначала нюхать, потом пробовать на зубок?
Тут пару тролей засело, и уже массу времени потратили люди на аргументацию, однако бесполезно. Предпочитаю намекнуть, а там уже каждый сам для себя решит: почитать или минуснуть. Пока, что получается собрать статистику по минусам. Адекватных людей сложней вычислить.
IPv6 хорош как раз тем, что убирает массу болячек v4 — дефицит адресного пространства, как следствие — необходимость в NAT, зависимость конфигурирования сети от DHCP. При наличии /64 на роутере и разрешенном SLAAC+RAD все просто работает автомагически — вставь провод и готово.
Выдача /64 из /56 или /48 тоже вполне регламентированная процедура.
Т.е. проблем с внедрением и использованием v6 нету. Есть проблема с ленивыми задницами в операторском бизнесе.
Пост очень длинный, поэтому я сделал короткий реферат, оставив только самое важное.
никогда
Интернет
эффективно и удобно
очень эффективно, продуманно и удобно!
просто и удобно!
очень удобно!
очень эффективно, продуманно и удобно!
продуманно!
Killer-feature
невероятно удобно!
легко
Killer-feature
эффективно и просто!
очень эффективным!
эффективно
очень удобно и продуманно!
просто и эффективно!
продуманно и эффективно!
продуманный
эффективно
OpenWRT 19.07.1, самая последняя версия. Raspberry Pi3.
Чистая свежезалитая прошивка.
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether b8:27:eb:b4:a6:b4 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fdb3:4c8a:6296::1/60 scope global
valid_lft forever preferred_lft forever
inet6 fe80::ba27:ebff:feb4:a6b4/64 scope link
valid_lft forever preferred_lft foreverВот не надо врать то. Всё на месте. Адрес из Local IPv6 unicast addresses (см rfc4193), это полный аналог 192.168.1.1
GL-AR750S прошивка 3.101
На устройствах на всех пропала конфигурация IPv6. Конечно же я обманываю. Балабол эдакий. И если с IPv6 маршрутизатор бы загружен по памяти до 80%, а сейчас без — 50% и это при том, что я и раньше его не пользовал, он в холостую стоял.
И на Mikrotik с IPv6 расход памяти ощутимо больше, при том, что я его не использовал, не гонял по нему трафик.
Так что на домашних роутерах весьма значительная экономия ресурсов. При всех недостатках в довесок, что здесь описали.
На сайте OpenWRT для GL-AR750S я не нашел никаких упоминаний о прошивке 3.101
Есть 19.07.01
В dmesg от её загрузки явственно видно
[ 21.734875] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 21.768425] br-lan: port 1(eth0.1) entered blocking state
[ 21.774015] br-lan: port 1(eth0.1) entered forwarding state
[ 21.780071] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.2: link becomes ready
[ 21.892225] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes readyИ? Будем извиняться?
Послушайте. Устройство у вас, или у меня?
: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether e4:95:11:11:11:11 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e695:1111:1111:1111/64 scope link
valid_lft forever preferred_lft forever
....
Далее мне было лениво перетирать мак-адреса и ip-адреса, поэтому я не стал вам все интерфейсы показывать. Но можете поверить мне на слово, там inet6 ни где не фигурирует, даже link-local который fe80::
Я не говорил, что его вырезали из ядра или из прошивки. Я сказал, что его отключили. На интерфейсах его нет, на устройства не раздаётся. Железяка из коробки загружена без твиков и прочей хрени — как есть.
А вы по каким-то сборкам, своим прикидкам делаете поспешные выводы. Я ж не за весь OpenWRT говорю. Я говорю про частность моего маршрутизатора, который кем-то там в китае собирается, прошивается. Это не моё личный колхоз, который я не осилил. Это то, что продаётся за деньги, как miktotik, и поддерживается как-то худо бедно. И вот это факт, как оно произошло на злобу дня. Я не специально этот день планировал, чтобы всех мордой макнуть.
Если кому и нужно извиняться, то в этой ситуации уж точно не мне. Но вы себя можете не утруждать, я не получаю удовольствие от чужих извинений, оставьте их при себе.
link/ether e4:95:11:11:11:11 brd ff:ff:ff:ff:ff:ff
inet6 fe80::e695:1111:1111:1111/64 scope link
Гы-гы-гы. Нет IPv6. Ну ок.
Вы внимательно читаете. Есть только локальные адреса. На двух интерфейсах. На этом конец. Устройства не получают ipv6. IPv6 не маршрутизируется. Это про голое поведение роутера. При обновлении прошивки в описании было сказано, что ipv6 отключён.
Прежде чем голо гыгыкать, разберитесь. А то ксилолита на интерфейсе локальный ipv6 и орёте от радости разоблачения, там дальше ещё атласы к интерфейсу идут беспроводные интерфейсы и всё уже даже без локального ipv6.
Если у Вашего провайдера нет IPv6, то у кого Ваш роутер получит IPv6? Естественно на интерфейсах не будет ничего, кроме link-local. Я не пойму, что вы хотите доказать? Что лично у Вас нет глобального IPv6? Так я этого и не утверждал никогда.
PS А прошивка у Вас старая, Вы в курсе? Новая раздает IPv6 ULA
;)
Думал, здесь я самый жирный троль, однако, похоже нет. Вам просто поспорить нравится? Факты вас не интересуют? Я правильно понимаю?
И это к аргументу про домохозяек, которым вот так обнови роутер, и кто ей конфигурацию на ipv4 перенастроит? А! Ну, да. IPv4 любая домохозяйка настроит. Главное, чтобы провайдер был не только IPv6. А так-то, да — технология обкатанная можно переходить домохозяйкам. Сейчас каждая знает, как свой IoT утюг откатить на старую прошивку без доступа к интернет — ipv6 же сломался.
б) пользуйтесь нормальными роутерами, например RT-AC57
MikroTik по вашему нормальный роутер? В простейших моделях для квартиры, там нет ipv6, и даже, если мне не изменяет память, не возможно включить.
Я не считаю свои роутеры ненормальными. 80% населения нашей страны, кто не IT специалист, вообще не смогут себе выбрать хоть сколь-нибудь нормальный роутер.
Между прочим производитель этого роутера, на собирал денег на это начинание у сообщества, взял популярный OpenWRT, который постоянно развивается, постоянно выпускают обновления.
Я не сомневаюсь, что если приложу свою руку, то легко себе верну ipv6 на своём маршрутизаторе. Просто у меня подход несколько иной к таким коробочкам. Я их покупаю, чтобы они функцию свою выполняли с минимальными отвлечениями на детали того, что там внутри вертится. И судя по модели вашего роутера, вы тоже его не на родной прошивке держите. А ели на родной, то как скоро под неё перестанут выпускать обновления производитель? Через год, как закончится гарантия первых моделей? Ваш нормальный роутер продаётся без спецификации по процессору и оперативной памяти. Простому обывателю нужно постараться найти эту информацию. Как можно говорить о том, на сколько он хорош? По количеству антеннок? У MikrtoTik'ов домашних вообще антеннок невидать. Получается, что MikroTik фуфло?
MikroTik по вашему нормальный роутер?
Нет. Это для тех, кто хотел циску, но денег не хватило. Нормальные роутеры из «пошел и купил» навскидку делают зухель и асус. если религия не позволяет, и руки из того места растут — pfSense или голый Debian/Ubuntu/CentOS вам. Там никто ничего не отключит и на стоковом железе оно все производительней MIPS-овых коробочек при прочих равных.
Я RT-AC57 брал исходя из трех причин, одна из которых — умение в v6 разными способами. Бонусом — 5 ГГц Wi-Fi и гигабитные порты. И проблем никаких я с ним не испытываю. А v6-сети (как структурированные, так и виртуализованные) я строил еще лет 12 назад.
Вот не пойму вашу позицию. IPv6 для вас не сложно, а mikrotik не нормальный роутер, из пошёл и купил asus хороший. Это вы говорите про роутеры в одной из моделей которых мне встречался вариант, когда люди на Новый год включили гостевые сети аж четыре штуки открытые, которые к тому же пускали на вебморду роутера, в которой стандартные заводские логин, пароль. Может сейчас в них нормально, но общий подход их я уяснил. В нормальном роутере из гостевой сети к вебморде попасть нельзя так просто.
Надеюсь у вас не такие критерии были в построении сетей, как в выборе роутера. Асусы ценны на рынке, только из-за возможности пахнуть туда openwrt.
Но, сомневаюсь, что они для каждого уникальную прошивку делали, поэтому, смею предположить, что тогда во всех роутерах asus была фича.
Вот zyxel не поражал меня подобными глупостями, смею предположить что это приемлемый для домохозяек вариант, но опять же, если их младшие модели взять они обладают славой отдалённой славой dir-300.
У mikrotik даже младшие балалайки закрывают нагрузку большинства семей. Вопрос только в пропускной способности портов. Но отказ в обслуживании нужно постараться сделать. IPv6 включённого по умолчанию нет, чтобы, когда провайдер включит его, домохозяйка не оказалась неожиданно жопой наружу с незащищённым ipv6. А ещё какая нибудь винда обнаружив на хвосте ipv6 будет нагружать хиленький роутер запросами, которые всё равно ни куда не уйдут на текущем ipv4 от провайдера. По моему, у вас проблему с пониманием простоты и безопасности.
В нормальном роутере из гостевой сети к вебморде попасть нельзя так просто
Не использую гостевые сети, так что ничего не могут сказать. Выдать гостю QR для подключения к домашней сети — не проблема, а если гость мутный — вот тебе другой QR, который ведет на torbox на базе распи — и езди из-под тора по всему интернету, чтоб в случае чего я не при делах.
У mikrotik даже младшие балалайки закрывают нагрузку большинства семей
А среднеценовые асусы не закрывают? О какой вообще нагрузке можно говорить применительно к домашней сети? Там помянутые DIR-300 справляются в большинстве случаев.
IPv6 включённого по умолчанию нет, чтобы, когда провайдер включит его, домохозяйка не оказалась неожиданно жопой наружу с незащищённым ipv6.
Так и в моем нет. Он включается и настраивается за 2 минуты.
неожиданно жопой наружу с незащищённым ipv6
И? Вероятность случайно быть поломанным снаружи обратно пропорциональна разрядности сети. Всю /64 долбить — да привет. А на вектора типа «зайди на сайт и скачай вредонос» это никак не влияет.
По моему, у вас проблему с пониманием простоты и безопасности.
Чойта? Вставь и работает. Даже дурацкий DHCP не нужен. Порты мапить не нужно. А небезопасность вы никак не аргументировали. То, что NAT не файрволл тут уже много раз упоминалось.
В простейших моделях для квартиры, там нет ipv6, и даже, если мне не изменяет память, не возможно включить.
v6 есть во всех моделях, необходимо добавить соответствующий пакет. ROs одинакова на всех железках.
Не насиловать население двойственностью, просто планомерно на уровне провайдеров, владельцев проводов и железок перестраивать инфраструктуру, а потому, когда всё будет обкатано ссаживать уже смертных с этого гиблого ipv4? Нет, давайте объявим готовность ipv6, предложим всем добровольно переходить на него, уверяя, что обратно дороги нет, чтобы люди хапали говна, решали проблемы, кто во что гаразд, по ходу выясненных косяков впихивать костыли. Мне одному кажется, что подход какой-то бесструктурный, или сейчас так модно всё делать, я сильно устарел, консерваторам не место в IT?
Или всё так и делается, просто местная пацанва решила приобщиться к такому большому прогрессу и с флагами впереди агитируют домохозяек сесть на кол и повернуться три раза по часовой стрелке?
Ну у меня только такие варианты. Я просто не вижу смысла усложнять себе жизнь новым не обкатанным. Зачем бизнесу в это вкладываться усложняя себе жизнь и раздувая бюджеты на IT сейчас? Когда можно подождать перестроения сетей на новый лад, а потом у себя внедрить уже по готовым инструкциям.
Даже обсуждение здесь показывает, что ipv6 в провайдерах не поселился. Я год назад уточнял за ipv6 у провайдеров Владивостока, Ростелеком во Владивостоке и в Волгограде конечному пользователю не даёт ipv6, отвечают что нет, и не планируется в ближайшем обозримом будущем. Так зачем мутить воду и предлагать людям сейчас городить костыли с ipv6 поверх ipv4 или уходить от провайдеров, которые не дают (а провинции в большинстве городов не дают)? Это чтобы показать свою не компетентность как инжинер? Я бы точно не стал бы такого человека ставить во главу IT отдела. Чтобы он за мой счёт занимался своими увлечениями и строил, строил, строил, что не актуально текущим реалиям? Может в Америках и Европах всё значительно лучше с сетями и с ipv6, но не так это приносится на новые земли.
А рассказы обывателей о сетях в простых компаниях той же Америки (не Google и Facebook, там ещё другие компании есть), складывается впечатление, что там местами куда печальней обстоят дела с сетями. Наслушались сказок про wi-fi сети на улицах, понаделали у себя, а съездить проверить забыли. А там нет. Ну нет там wi-fi в аэропорту, на вокзалах в парках… Ну по крайней мере гуляющие люди не находят его так просто, как у нас тут. Что-то я про стиляг аналогию вспомнил. А! Это же про IT должно быть, обычно же не применяют опыт из сторонних областей. То мод, а здесь IT. В IT моды нет. В IT блондинок нет, которым можно рассказать, что целюлит, это что-то ужасное, с чем срочно нужно бороться, что сиськи силиконом нужно надувать. Это IT, детка, здесь суровые бородатые дядьки!.. Или нет?.. ;)
Короче, хочу сказать, что это попахивает очередной киркоровской попсой. Технологии не для конечных целей, а чтобы на всём этом движении раскрутить маховик торговли. Вон китайцы даже своего интернета толкового не имеют, такой он у них говёный и безальтернативный. Зато весь мир снабжают сетевыми устройствами. А отсталая страна — мы. Потому что это всё хаваем, делаем какую-то движуху непонятную, а конечный результат — посмотреть котиков в интернете. Производств, как кот наплакал.
Если до этого комментария добрался очередной школьник начинающий в IT, знай — ipv6 это самое последнее, на что тебе стоит обратить внимание, чтобы начать карьеру, просто пропускай эту технологию. Хотя, я думаю, почитав все эти комментарии станет и без того понятно любому школьнику, что это какая-то мутная тема.
Ну, что тут скажешь. С этим мировым внедрением у меня складывается аналогия — пусть дом догорит, тогда тушить начнём — сказал пожарник. При этом бабы с вёдрами бегают и заливают избушку.
И последний вопрос остался. Если всё так хорошо с переходом на ipv6 и вопрос этот решён, почему не освобождаются ipv4? Или у сообщества есть сомнения, что при высвобождении ipv4 старая гвардия обрадуется и закрепится на этой «отмирающей» технологии?
Пока что я вижу дичавшую агитацию, а тенденции несколько иные.
Мне кажется, тут кто-то людей за нос водит.
Маркёр готовности технологии этой — количество публичный ресурсов доступных по новой технологии и количество посещений по этой новой технологии, и это всё по отношению к старой технологии.
Мы получим готовность. А приводить голую статистику пионеров, у кооо он включён на проводе — тогда и меня можно причислить к активным пользователям ipv6 у меня же на оборудовании где то на интерфейсах проскакивают локальные v6. Что и продемонстрировали местные эксперты, высказав по листингу суждение о наличие ipv6 в моей сети.
Сказочники!
Отдельно хочется упомянуть отлично продуманный Mobile IPv6.
Подскажите где гайд искать на тему
вот есть /64 в домашней сети (и больше нету).
есть /64 от мобильного оператора. Android 11 от Samsung.
есть микротик.
Что и как настраивать чтобы по адресу из домашней сети — был доступен смартфон
комментарий удален
IPv6 — прекрасный мир, стоящий скорого перехода на него