Pull to refresh
14
-0.8
Сергей Федотов @FSA

Пользователь

Send message

IPv4 будет в Китае ещё жив :)

Что значит «будет жив»?

Если от IPv4 откажутся государственные сайты, означает ли это, что IPv6 победил?

Если большинство провайдеров будет предоставлять как минимум дуалстэк, можно ли считать это победой IPv6?

Если провайдеры массово перейдут на IPv6 для построения своей сети, чтобы упростить её, а для доступа к ресурсам IPv4 поставят NAT64, это победа?

Если я сейчас дам ссылку на провайдеров, которые используют MAP-T у себя на сети, то будет ли это считаться досрочной победой?

Это значит, что по всему миру большинство пользуется IPv4, а вы говорите "легаси".

Я не говорил такого об IPv4. Я говорил об устройствах, которые не умеют работать с IPv4. Вот для них и нужны островки IPv4. У меня, например, есть два Zigbee шлюза от Xiaomi и Aqara. По функциям они идентичны и ни один не умеет работать с IPv6. Но всё меняется, когда на Aqara ставится альтернативная прошивка. Я теперь прекрасно работаю с ним по IPv6. Допускаю, что у других есть и IP-камеры и другие устройства, поддержка которых прекращена, а поддержка ими IPv6 не была добавлена. Я об этом говорил!!!

Вот давайте мы зеркально откажемся: я от IPv6, вы от IPv4 и посмотрим, чья реальность сильнее.

Будете смеяться, но я сейчас оказался в ситуации, что у меня дома не работает IPv4 адресация. Немного задерживается зарплата и Ростелеком отключил мне за неуплату IPv4. И не сразу замечаешь, что с интернетом что-то не так, потому что Youtube продолжает работать как ни в чём не бывало. Многие сайты открываются без проблем. Ну, например, можно продолжать пользоваться сервисами Yandex. Большую часть вопросов с ресурсами IPv4 я снимаю с помощью внешнего NAT64. В обычном режиме он у меня свой на маршрутизаторе и устройства внутри моей домашней сети могут работать исключительно на IPv6. Я даже специально ради эксперимента перевёл стационарный компьютер исключительно на IPv6. И у меня там не возникает никаких проблем. Так что прежде чем я написал свои комментарии я уже попробовал жить в мире IPv6.

Вот давайте мы зеркально откажемся: я от IPv6, вы от IPv4 и посмотрим, чья реальность сильнее.

Про отказ от IPv6 - смешно :-D У нас почти вся страна сидит исключительно на IPv4. Провайдеров минимум, кто IPv6 предоставляет. Официально предоставляет ещё меньше. Странно думать, что в таких условиях кто-то что-то будет предоставлять исключительно на IPv6.

Готов заключить пари на $100: и через десять лет, всё ещё можно будет ходить в сеть исключительно через IPv4 и что-то будет ломаться на исключительно IPv6 :)

Я не азартный человек. И к такому пари много вопросов. Например, по какой стране будем оценивать? Китай активно внедряет IPv6 и в 2030 планирует отказаться от IPv4. В Индии процент подключений с IPv6 больше 60%. Европейские провайдеры переводят свою инфраструктуру исключительно на IPv6. Чехия вообще заявила, что прекратит предоставление государственных услуг по IPv4 6 июня 2032 года. И, в то же время, в РФ вряд ли что-то будет меняться, потому что в условиях санкций не до развития сети. Мне не ясны критерии, по которым будет считаться, что я победил в этом споре.

Отказ от IPv4 невозможен, просто примите это как факт, как реальность данную нам в ощущениях.

А что мешает отказаться от него? Что сломается? Да, единственная причина - легаси устройства. Но для них можно островок IPv4 поднять и пользоваться дальше. Нет в IPv4 чего-то такого, что нельзя сделать в IPv6!!!

Все современные мобильные устройства прекрасно работают с IPv6. Все системы семейства *nix работают с IPv6 без ограничений. И там даже есть костыль для того, чтобы не имея IPv4 адреса на сетевом интерфейсе заставить работать программы, которые плюют на всё и пытаются подключиться именно по IPv4 адресу (например, торренты, потому что пир на IPv4). Даже в Windows обещают добавить подобный костыль. А уж с IPv6 WIndows прекрасно работает со времён Windows 7. На Windows XP не проверял, возможно там есть проблемы. Но, извините, эту систему уже официально списали много лет назад!!! Да там и интернетом уже нельзя нормально пользоваться.

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

P.S. Отправил это сообщение и понял, что оно ушло с моего компьютера на сайт habr.com по IPv6 протоколу. Но, поскольку на habr.com не поддерживается IPv6, то этот запрос ушёл туда через внешний шлюз NAT64. Вот такая суровая реальность.

Да не такой уж и большой объём знаний там нужен. Те, кто разбираются в IPv4 легко поймут как работает IPv6. А кто слабо разбирается, тому вообще особо разбираться не надо будет, ибо в IPv6 автоматизация есть и все эти вбивания, аналогичные 192.168.1.1 даром не нужны.
А вот отказ от IPv4 позволяет отказаться от разных костылей, которые помогали решить нехватку IP адресов и решать проблемы, вызванные этими решениями...

  1. Уже есть провайдеры, которые предоставляют IPv6. Значит у них есть оборудование, которое способно работать только с IPv6. Это вполне решаемая задача на относительно современном оборудовании (10-15 летнем точно).

  2. Построить домашнюю или корпоративную сеть на IPv6 проще простого, если конечно вы не используете технику из нулевых годов. Есть проблемы с софтом, но они все решаемые, если вендор не бросил поддержку железки. А если на железку можно поставить альтернативную прошивку на базе, например, OpenWRT, то у вас вообще не будет проблем с IPv6. Я в 2016 году покупал самый дешёвый маршрутизатор Asus. Там уже вполне поддержка IPv6 была на уровне, достаточном, чтобы раздать этот самый IPv6 в твоей локалке. И я даже раздавал их в 2016 году через туннель. От провайдера он тоже сможет раздать. А больше он ни на что и не годится, ибо железо очень слабое.

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

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

Только провайдеров пинать надо. В Новосибирске никто из доступных мне провайдеров не предоставляет IPv6. Есть Дом.ру, который предоставляет, но он не везде доступен. Но по факту оказалось, что на Ростелекоме очень даже есть IPv6. Да ещё и не просто есть, а в большинстве регионов присутствия. Но они совершенно не хотят им заниматься! Официально его НЕТ и поддержка никак не поможет, если есть проблемы. Но при этом он почти полноценно работает если не считать кривых маршрутов (пинг из Новосибирска в Новосибирск через Москву, больше 50 мс) и некоторых проблем в единичных регионах.

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

Из сотовых только у МТС и Мегафон, но у них и тарифы дороже раза в 2, чем у конкурентов. Yota приняли пожелание (по сути послали), Tele2 даже не планируют. Билайном не интересовался. У Мотива тоже вряд ли есть, но нужно проверять.

Годы идут, а пользоваться IPv6 всё ещё проблемно. И так наверное продлится ещё столько же лет, сколько уже внедряется IPv6 (уже в разы дольше, чем IPv4 существовал на момент появления IPv6).

Вы совершенно неправы. IPv6 способен полностью заменить IPv4. Сдерживающим фактором является именно засилие IPv4 в сети. Настройке IPv6 не все уделяют достаточного внимания и, например, я на сервер в Новосибирске хожу из Новосибирска с Ростелекома через Москву (вполне вероятно у них там ТСПУ). Но если сеть настроена корректно, то и IPv6 работает ничуть не хуже, а возможно и лучше, чем IPv4.

Свой вклад вносят и провайдеры хостинга. Совершенно недавно на мой запрос о том, что есть некоторые проблемы с потерями пакетов IPv6 долго поддержка не отвечала, а потом сказали, что они первые кого атаковали по IPv6 и, типа, всё наладится позже. Ок. Мне не критично, подожду. Тем более веб-сервер вполне себе удовлетворительно отвечает и справляется. А позже получаю совет использовать IPv4, чтобы всё стабильно было. Т.е. они совершенно не заморачиваются решением проблем в со своей сетью, а IPv6 у них для галочки.

Если у вас есть внешний NAT64, то можно пользоваться всем интернетом исключительно через IPv6 и практически не испытывать никаких проблем. А те проблемы немногочисленные, связаны не с протоколом IPv6, а с ресурсами на IPv4, поскольку в таком варианте не работает без дополнительного костыля обращение к IPv4 адресу напрямую. Но и это лечится через clatd на linux, а в Windows 11 обещали его добавить в ближайшее время. Но никто не заставляет вас использовать только IPv6. К тому же этот костыль можно на машрутизаторе, если у вашего провайдера сеть только на IPv6.

Ещё одним сдерживающим фактором является то, что поддержку IPv6 в своих устройствах часто многие производители делают формальную. Т.е. да, устройство может работать с IPv6 адресами. Но построить на нём что-то сложнее сети, которая раздаёт сеть /64 невозможно. Например, такие CPE под брендом Ростелеком. У них даже нет встроенного файервола для IPv6, либо он включен по умолчанию и никак не настраивается (увы этого я не успел проверить, а сейчас использую нормальный маршрутизатор). Но это небольшая проблема. Если я получаю на нём свою сеть /56, то я совершенно не могу раздать выданные мне 256 сетей кому-то ещё. Одну сеть /64 он раздаёт через LAN интерфейсы. А остальные 255 сетей висят мёртвым грузом и никак не используются. Но всё меняется, если поставить нормальный маршрутизатор с полноценной поддержкой IPv6.

Резюмируя. Каких-то явных проблем у IPv6 протокола нет. Он способен полностью заменить IPv4 и работает не хуже, а возможно, даже и лучше, за счёт более эффективного распределения адресного пространства по территории планеты и более простой обработки пакетов на промежуточных узлах. Но откуда проблемы? Саботаж по внедрению протокола и недостаточное уделение внимания настройкам своих сетей для работы с IPv6.

Вишенка на торте. Google - чемпион по внедрению IPv6. Если заходить на www.google.com или открывать ссылки в их почте Gmail по IPv6, то придётся периодически столкнуться с капчей и доказывать, что ты человек, а не робот.

ravdv - это ничто иное как Router Advertisement Daemon, т.е. демон, который обеспечивает рассылку анонсов маршрутизатора. Это нужно только в сетях, где вам необходимо автоматическое конфигурирование клиентов. Если вы используете Wireguard, то он вообще, в силу своей простоты, никак с этим работать не может. OpenVPN обычно раздаёт адреса из указанного ему диапазона. Т.е. для него radvd не нужен. Может быть их как-то и можно скрестить, но и без него всё работает.

В нашем случае нужно не анонсами маршрутизатора заниматься, а обеспечивать пересылку на себя пакетов с помощью механизма поиска соседей, раз провайдер не смаршрутизировал их на вашу машину. А для этого нужен именно NDP proxy. ndppd - один из вариантов реализации.

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

Бить особо не собираюсь. К тому же мы находимся в ситуации, когда инструментами чиним сеть, которую кто-то сломал. Поэтому я не против NAT. Но при использовании IPv6 нужно учитывать одну вещь. Нельзя просто так взять и назначить клиентам адрес из диапазона fd00::/7 и ждать что у всех всё заработает. Некоторые клиенты не будут пользоваться IPv6 по той причине, что сеть fd00::/7 не маршрутизируется в интернете, а значит использовать адрес из этого диапазона для исходящего соединения на публичный адрес бессмысленно. Поэтому к вашему NAT теперь придётся ещё и прикрутить какую-то фиктивную адресацию с GUA адресами, чтобы у клиентов всё заработало. В такой ситуации вообще непонятно зачем нам использовать NAT, если мы и так будем выдавать GUA адреса клиентам. Разве что NAT нужен, чтобы сокрыть реальный адрес клиента... Короче, тут NAT не для функционирования сети нужен, поэтому я такое вполне допускаю.

Мол, если мы получаем от хостера префикс, то надо и каждому клиенту раздавать индивидуальные адреса из этого префикса, и тому подобное. После настройки, как правило, ничего не работает, потому что у хостеров обычно не-routed префиксы и нужно использовать что-то типа radvd.

radvd тут совершенно ни при чём. radvd рассылает анонсы машрутизатора в сеть, которые нужны для автоматического конфигурирования IPv6. Для того же Wireguard он совершенно бесполезен.

Проблема тут в другом. Провайдерский маршрутизатор при запросах извне на вашу адресацию посылает вашему серверу запрос - «кто там у нас владеет этим адресом?». Если вы не присвоили этот адрес вашей машине на интерфейс, который смотрит в сторону провайдера, то ваша машина отвечать не будет. У неё же нет этого адреса. Нам нужно заставить нашу машину отвечать на запросы поиска соседей. Этим занимается ndppd. Он проксирует запросы поиска соседей туда, куда мы скажем, или вообще просто будет отвечать безусловно, что да, это мой адрес и шли мне все пакеты для этого адреса. А ещё NDP proxy можно настроить через sysctl, но я глубоко в тему не вникал.

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

Добавил замечание в текст. Спасибо за подсказку.

Чаще всего мне встречался вариант, когда дают доступ через пользователя root. Т.е. подключаться нужно ssh root@host. Далее после входа на сервер:

  1. Создаёте пользователя и добавляете его в группу sudo. Также полезно сразу указать пользователю оболочку /bin/bash

  2. Задаёте пароль для пользователя

  3. Загружаете свой ключ под вашим пользователем.

  4. Проверяете, что можете войти без пароля и можете переключиться на root через sudo.

  5. Ели всё нормально, запрещаете доступ к ssh от пользователя root и с использованием парольной аутентификации.

В случае проблем с доступом, можно воспользоваться панелью правления и доступом к консоли сервера (VNC и др.). Она же спасёт, если накосячите что-то с настройкой сети.

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

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

Исправил.

Да, действительно. Надо подробнее изучить вопрос. Однако указанный вами ключ в Ubuntu 22.04 LTS и Fedora 39 имеет значение no. В Ubuntu это задано прямо в sshd_config, а в Fedora в sshd_config.d (правда там используется старое имя параметра).

Если вы используете NAT в IPv6, то либо вы что-то неправильно делаете, либо с вашей сетью что-то не так.

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

Всё проще. Математический аппарат подсказывает нам, что нет смысла прослушивать записи с частотами дискретизации выше 40+ кГц. Перейдите на спектр ИКМ сигнала и вы увидите, что кроме полезного сигнала в нём есть составляющие, аналогичные амплитудно-модулированному сигналу на частотах кратных частоте дискретизации. Т.е. если мы фильтром обрежем всё что выше нашего уровня восприятия, то мы получим исходный сигнал без каких либо искажений. Искажения будет давать только шаг квантования.

Зачем же на студии повышать частоту дискретизации и количество уровней квантования? Потому что мы сможем вместо сложных аналоговых фильтров (а нужно обрезать резко после 20 кГц и при этом не искажать то, что до этих 20 кГц есть) можем применить цифровую обработку и более качестве обрезать лишнее. АЧХ среза будет куда более идеальна, чем то, что нам могут дать аналоговые фильтры. Дополнительные уровни квантования позволят нам без заметных искажений подтянуть уровень сигнала до нужного нам уровня. Ведь если нам нужно усилить сигнал в 2 раза, то мы половину уровней квантования в результирующем материале потеряем (конечно, вряд ли кто-то так сильно усиливает сигнал в студийных условиях, проще переписать нормально, но это хорошо отражает суть, зачем нам лишние уровни). Итого, мы за счёт избыточности вытягиваем нужный нам сигнал и уже в идеальном виде кодируем со стандартными параметрами для потребителей. В результате у нас есть отличный

и они выяснили, что есть уникумы, которые слышат вплоть до 22 кГц

Это скорее не из-за уникумов, а из-за неидеальности фильтров. Нужно обрезать очень хорошо до той частоты, которая ниже в 2 раза частоты оцифровка материала. Если этого не сделать, то мы можем получить лишние шумы. В спектре ИКМ сигнала от частоты дискретизации вверх и вниз идёт спектр нашего полезного сигнала, примерно как при АМ модуляции. И вот эта нижняя часть может залезть на наш полезный сигнал и добавить лишних звуков. Идеальных фильтров не бывает, вот и взяли запас в 2кГц на неидеальность фильтров, чтобы точно до частоты в половину частоты дискретизации ничего не добралось.

На Ростелекоме открылся. Но если проверить через curl, то работает только по IPv6. По IPv4: curl: (35) Recv failure: Соединение разорвано другой стороной

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

Если соединение основное падает, то происходит рассылка RA, что первый шлюз прекращает работу, а второй наоборот должен объявить, что он теперь шлюз по умолчанию. Схему с двумя маршрутизаторами кто-то делал. Возможно это были микротики.

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

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

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

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

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

Было бы интересно почитать серьёзный гайд на тему безопасной настройки IPv6 и сопровождения dual stack конфигурации. 

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

С другой стороны у нас есть устройства, которые предоставляются пользователям. Производители устройств должны сделать так, чтобы было максимально безопасно. Тут я уже писал комментарий про пароли на админку ADSL модемов. Вы просто не представляете сколько спама летело из Америки с адресов в 2000х, которые у провайдера были прописаны как adsl клиенты. В это же время у меня за 30 дней в ящике гугла в папке спам было больше 6000 писем. По спаму можно было проверять работает ящик или письма не приходят.

1
23 ...

Information

Rating
Does not participate
Location
Тавда, Свердловская обл., Россия
Date of birth
Registered
Activity