А если вы берёте и сохраняете у себя эти авторские материалы и не своим мозгом пользуетесь, а просто копируете то, что в этим материалах написано, немного видоизменяя и передавая ту же самую суть? Человеческий мозг сложнее устроен. Могут быть какие-то отклонения, какие-то новые догадки. Так вы можете выдать какую-то уникальную идею базируясь на своём опыте, который вы не помните дословно, как было в материале. ИИ же по большей части в том или ином виде хранит то, на чём обучался и используется именно в том виде.
Не знаю как менялись, но после ухода Google Adsense мой еле приносящий что-то сайт с РСЯ стал зарабатывать ещё меньше. Если раньше можно было надеяться хотя бы иногда окупать хостинг и домен, то сейчас дохода от РСЯ хватает максимум на оплату более дешёвого чем раньше хостинга. А на домен вообще не хватает. Но и это ещё не чистое сравнение, потому что в последнее время у меня начал приносить что-то мой блог. Он сейчас обгоняет тот сайт. Т. е. теперь доход идёт от двух сайтов, а он меньше, чем был от одного в Google Adsense. Если бы это были коммерческие проекты, я бы давно их закрыл. А раз хобби, поэтому тянут деньги из кармана, а РСЯ покрывает эти расходы лишь частично, меньше трети.
Если вы ещё не заметили, сейчас большинство продуктов так и делается. Это просто ужас какой-то, когда заходишь на сайт, а он грузится оооочень долго, браузер съедает оперативку. Если глянуть код, то диву даёшься что там наворочено. А внешне там выглядит всё довольно просто. Бизнес не хочет хороших решений, бизнесу нужны быстрые решения, которые приносят деньги. А там как-нибудь допилят (нет).
ИИ в целом позволяет экономить время на рутиных задачах. Может быть даже качество кода подрастёт, потому что у разработчиков будет больше времени подумать над общим улучшением программы. Думаю, что программисты не станут ненужными, просто специфика работы сменится. И количество вакансий уменьшится. Кто знает. Время покажет.
Вы пишите так словно DNS arpa запись имеет приоритет выше чем PREF64.
Нет. Я такого не имел в виду. Просто RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) вышел аж в ноябре 2013 года, а RFC 8781 (Discovering PREF64 in Router Advertisements) только в апреле 2020), поэтому старые реализации обнаружения префикса могут опираться на старый RFC. По-хорошему, старый способ нужно отключать по умолчанию и включать только вручную, только тем, кому оно действительно нужно. Но это лично моё мнение.
Как метод борьбы: просто переводить в фаерволе все исходящие DNS на локальные и возможно этого достаточно?
А что делать с DNSoverTLS и DNSoverHTTPS? Я вполне могу прописать в качестве DNS 2606:4700:4700::64 и включить DNSoverTLS и этот трафик не перенаправит. При этом система на моей машине согласно RFC 7050 будет думать, что у меня есть NAT64 по стандартному адресу 64:ff9b::/96, а его там может и не быть. Да и вообще тут просто огромный простор для целевых атак, ведь весь интернет IPv4 можно вписать в сеть IPv6 стандартного размера и ещё куча адресов останется. При этом жертва даже ничего не заподозрит, ведь будут работать стандартные механизмы системы, а значит выявить атаку будет практически невозможно.
Да. Это больше потенциальная опасность, а не реальная. Но если есть другой, более надёжный способ, то зачем сохранять этот.
где все вендоры обсудили все граничные кейсы и все поправили, в том числе старые реализации
Ну, вообще-то в Android и iOs это уже поправили. В MacOS, вроде, тоже. А на Linux и Windows из коробки этого нет и сейчас. Я вообще не представляю можно ли Windows использовать в режиме IPv6-only через WiFi или Ethernet подключение.
Я пишу вам с компьютера где все настроено как я описывал выше и сломанных приложений я пока что не нашёл.
Я тоже баловался на Fedora. Только у меня не было автоматического обнаружения префикса NAT64. Просто был настроен clatd, а NAT64 был на маршрутизаторе. Да, всё прекрасно работает при полностью отключенном вручную IPv4, даже торренты качаются с пиров IPv4 и Steam работает. Кстати, тут недавно обнаружил, что починили возможность запуска Steam в режиме без clat. Так что можно запускать игры, но при попытке что-то скачать из магазина просто выдаётся, что интернет недоступен. Для этого нужен clat.
В реализации CLAT от эппл AAAA записи синтезируется на клиенте
Да. Хороший вариант заставить синтезировать записи локальный резольвер. Но тогда теряется смысл домена ipv4only.arpa, ведь чтобы синтезировать нужную запись устройство должно узнать адресацию NAT64. И тут единственным рабочим вариантом оказывается PREF64 в RA.
Запись ipv4only.arpa потребовалась для старых айфонов (iOS 15)
Это просто более ранний RFC, но многие его критикуют и призывают не использовать. Я присоединяюсь к ним.
На счет безопасности, у меня нет квалифицированного комментария.
Тут есть потенциальная опасность в том, что если вы каким-то образом начнёте использовать недоверенный DNS, который может весь ваш IPv4 трафик направить на подставной NAT64 шлюз, ведь диапазон NAT64 не является чем-то фиксированным и можно использовать любые адреса, в том числе и GUA для публичных NAT64. Такое может провернуть, например, какой-то вирус. Может и администратор сети, но он вообще может перехватывать весь ваш трафик и у него нет в таком способе особой нужды. Конечно, ваш трафик и так будет по большей части зашифрован, но его как минимум злоумышленник может записать для последующей расшифровки. Будет неприятно, если какая-то чувствительная информация будет защищена ненадёжными алгоритмами шифрования.
DNS64 не обязателен в случае iOS macOS. Скорее от него больше вреда, т.к. он перепишет все записи и даже вреден для ipv6 mostly.
Это совершенно не так. DNS64 делает доступным большую часть сервисов IPv4. При этом никакой дополнительной нагрузки на клиента не создаётся. Он просто изначально отправляет все запросы на IPv6 адрес и ему без разницы что там дальше происходит, потому что ответ он получит, если NAT64 работает и сервис отвечает. Для устройства всё выглядит так, что он общается с IPv6 сервисом. CLAT же нужен именно для тех случаев, если программы напрямую обращаются к IPv4 адресам. В этом случае нужен виртуальный интерфейс с фейковым IPv4. Дальше это нужно дополнительно обрабатывать прямо на устройстве, чтобы пакет ушёл на NAT64.
Никакие записи DNS не переписываются. Записи типа AAAA добавляются к записям типа A, если для этих доменных имён нет AAAA. Ничего страшного в этом нет, кроме того, что это сломает DNSSEC для доменов, которые его используют, но не имеют AAAA записей. Например, так будет у банка ВТБ и Ростелекома... Впрочем, DNSSEC на rt.ru и так сломан без всяких DNS64... Интересно было бы узнать насколько часто вообще включают проверку DNSSEC компании.
Достаточно NAT64, PREF64, DHCP option 108 и dns записей для ipv4only.arpa типа А и АААА.
Тут вы всё в кучу смешали. ipv4only.apra и PREF64 - это два разных способа обнаружения NAT64 в данном конкретном сегменте сети и это два разных RFC. Обнаружение через DNS имеет потенциальные проблемы с безопасностью, а также не гарантирует того, что NAT64 будет обнаружен. Банально, если клиент прописал себе другой DNS. И может ложно сработать, если клиент прописал себе DNS64 от того же Cloudflare или Google. PREF64 в RA тоже не самая безопасная штука, но в RA приходит множество других критичных параметров, которым приходится доверять. Для ipv4only.arpa есть отдельный RFC, но я бы не стал его использовать как основной способ обнаружения, только как резервный вариант. А лучше бы вообще не использовал. DHCP option 108 нужна только в том случае, если ваша сеть выдаёт IPv4 адреса, которых у вас ограниченное количество. При помощью этой опции вы можете экономить пул адресов за счёт того, что его не будут занимать те, кто может работать в режиме IPv6-only, а это все мобильные устройства на Android и iOs, а также MacOS. Понятное дело, что если вы используете внутри сети 192.168.1.0/24, то вам скорее всего фиолетово все 200 устройств получат себе IPv4 адрес или только 50 из 200. А вот если вы выдаёте белые IPv4, то экономия пула оправдана.
symfonycasts/sass-bundle не поможет с scss? У меня тоже scss использовался, но я не сильно глубоко его использовал. Вероятно каких-то сложных вещей просто нет и меня это решение вполне устроило.
Сейчас вроде в Symfony рекомендуют использовать AssetMapper вместо Webpack Encore. Реально большая экономия времени на сборке. Но я пробовал его только на простых вещах.
Собственно, проверил. Установил пакет в Archlinux из extra-testing. В качестве маршрутизатора взял официальную сборку под свой маршрутизатор без каких-либо модификаций. Всё необходимое он получал от головного маршрутизатора, где были настроены свои DNS64 и NAT64, как и было описано в статье, поэтому устроил и базовый набор компонентов.
Опция действительно работает, но она не включена по умолчанию, что разумно, т. к. NetworkManager не использует clat (уже есть патчи и обсуждение внедрения), поэтому возможны проблемы при работе некоторых программ. При включенной опции реально идёт запрос 108 опции в DHCPv4, на который отвечает OpenWrt и указывает время, на которое нужно выключить DHCPv4 клиента. Компьютер не получает IPv4 адреса и работает только через IPv6.
Удивительно, что я решил написать подобную статью прямо в тоже самое время, когда вышел NetworkManager с таким революционным изменением! Стоит доработать статью?
Оказывается прямо перед публикацией этого материала вышла новая версия NetworkManager 1.52, которая теперь поддерживает RFC 8925 «IPv6-only preferred». Жду появления в дистрибутивах.
На микротике это все переноситься ровно в одну команду на доноре и на одну команду на рецепиенте.
Не надо сравнивать железки одного вендора и множество устройство, которые выпускает куча вендоров. Но даже в таких условиях мне удалось перенести конфигурацию без особых заморочек. И WiFi тоже возможно бы удалось перенести, но видимо из-за того, что железо для WiFi очень сильно отличалось (как минимум в одном был WiFi 5, в другом WiFi 6), вылезли некоторые косяки и проще было настроить WiFi с нуля.
Ну а подготовка собственной сборки вряд ли есть у микротика, когда на твоём устройстве только нужный софт установлен.
Это как сравнивать настройку iPhone и Android. О первого минимальное число вариантов, у второго есть огромный выбор совершенно разных устройств. Да. Переплачиваешь и не паришься... почти.
P.S. Кстати, по количеству портов мои железки тоже отличались, но при этом конфигурация перенеслась без проблем.
С FTTH всё плохо, если хотите обойтись одной железкой. Но есть рабочие варианты с двумя железками. Можно приобрести какой-нибудь маршрутизатор с SFP слотом. В него устанавливается GPON терминал. НО! Это дорого (из "бюджетного" - SNR-CPE-ME2-SFP б/ушный + SFP терминал, но это уже как минимум более 5 тысяч рублей). Это не очень надёжно. Нужно с провайдером согласовывать ключ подключения, либо использовать его с имеющегося терминала. Видел много жалоб, что SFP-PON терминалы сильно нагреваются. В целом вариант рабочий, но нужно быть готовым, что могут возникнуть проблемы. Самый рабочий вариант - перевести маршрутизатор от Ростелекома в режим моста, либо заменить его на то, что они называют PON-розеткой. Эта самая розетка по сути медиаконвертор из PON в Ehternet. Если у вас уже есть терминал в аренде, то менять его на "розетку" смысла не вижу, тем более можно позвонить в поддержку и попросить перевести его в режим моста. Желательно ещё попросить выключить WiFi, чтобы он эфир не забивал, потому что использовать его на GPON терминале уже не получится. Дальше подключаете свой маршрутизатор c OpenWRT через Ethernet и пользуетесь. Если есть доп. услуги, типа IPTV или телефонии, они остаются на GPON терминале.
Буквально месяц назад переносил настройки OpenWRT. Вполне себе возможно. Просто переносишь текстовые файлы и минимально их редактируешь. WiFi пришлось настраивать с нуля, потому что там совершенно другое железо. Ну и сборку для новой железки тоже пришлось делать под себя отдельно с учётом разных чипов в маршрутизаторах. Если нужно массово настраивать железки с похожим железом, то всё можно один раз подготовить, а потом всё клонировать. У меня довольно сложные настройки для локалки, если сравнивать со среднестатистическим маршрутизатором. Например, есть резервирование адресов по DHCP для IPv4 и IPv6, доменные имена, которые внутри сети только работают и ещё некоторые вещи. И всё успешно перенеслось.
В РФ да. Пару сотовых компаний выдают, да некоторые проводные операторы. Но РФ - не показатель. Там где реально припекает (Китай, Индия) IPv6 разворачивается ускоренными темпами. Да и Европа тоже не отстаёт. Парадокс, но у меня сейчас хостинг стоит дешевле, чем IPv4 для него. Есть ещё бесплатная VPS... Но за то, чтобы иметь к ней доступ только по IPv4 нужно платить 150 рублей в месяц.
Нет. Я никогда не менял когда просили. Обычно была причина. Один раз менял, потому что микросим понадобилась. Последний раз менял по причине того, что криво обрезал под наносим и надо было правильно вставлять, чтобы работала.. Была симка с логотипом Ростелекома в виде уха (а точно это было ухо?), поменяли на чёрную Tele2.
Ну тут они под замес попали. Владелец торговой марки отказал в продлении лицензии по известным причинам. Так что тут понятно зачем переименовывали. А вот путь, который проделал мой номер: Уралсвязьинформ GSM -> Ютел -> Ростелеком -> Tele2 -> t2. И это самая понятная замена товарного знака из всех предыдущих.
А если вы берёте и сохраняете у себя эти авторские материалы и не своим мозгом пользуетесь, а просто копируете то, что в этим материалах написано, немного видоизменяя и передавая ту же самую суть? Человеческий мозг сложнее устроен. Могут быть какие-то отклонения, какие-то новые догадки. Так вы можете выдать какую-то уникальную идею базируясь на своём опыте, который вы не помните дословно, как было в материале. ИИ же по большей части в том или ином виде хранит то, на чём обучался и используется именно в том виде.
Не знаю как менялись, но после ухода Google Adsense мой еле приносящий что-то сайт с РСЯ стал зарабатывать ещё меньше. Если раньше можно было надеяться хотя бы иногда окупать хостинг и домен, то сейчас дохода от РСЯ хватает максимум на оплату более дешёвого чем раньше хостинга. А на домен вообще не хватает. Но и это ещё не чистое сравнение, потому что в последнее время у меня начал приносить что-то мой блог. Он сейчас обгоняет тот сайт. Т. е. теперь доход идёт от двух сайтов, а он меньше, чем был от одного в Google Adsense. Если бы это были коммерческие проекты, я бы давно их закрыл. А раз хобби, поэтому тянут деньги из кармана, а РСЯ покрывает эти расходы лишь частично, меньше трети.
Если вы ещё не заметили, сейчас большинство продуктов так и делается. Это просто ужас какой-то, когда заходишь на сайт, а он грузится оооочень долго, браузер съедает оперативку. Если глянуть код, то диву даёшься что там наворочено. А внешне там выглядит всё довольно просто. Бизнес не хочет хороших решений, бизнесу нужны быстрые решения, которые приносят деньги. А там как-нибудь допилят (нет).
ИИ в целом позволяет экономить время на рутиных задачах. Может быть даже качество кода подрастёт, потому что у разработчиков будет больше времени подумать над общим улучшением программы. Думаю, что программисты не станут ненужными, просто специфика работы сменится. И количество вакансий уменьшится. Кто знает. Время покажет.
Нет. Я такого не имел в виду. Просто RFC 7050 (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) вышел аж в ноябре 2013 года, а RFC 8781 (Discovering PREF64 in Router Advertisements) только в апреле 2020), поэтому старые реализации обнаружения префикса могут опираться на старый RFC. По-хорошему, старый способ нужно отключать по умолчанию и включать только вручную, только тем, кому оно действительно нужно. Но это лично моё мнение.
А что делать с DNSoverTLS и DNSoverHTTPS? Я вполне могу прописать в качестве DNS 2606:4700:4700::64 и включить DNSoverTLS и этот трафик не перенаправит. При этом система на моей машине согласно RFC 7050 будет думать, что у меня есть NAT64 по стандартному адресу 64:ff9b::/96, а его там может и не быть. Да и вообще тут просто огромный простор для целевых атак, ведь весь интернет IPv4 можно вписать в сеть IPv6 стандартного размера и ещё куча адресов останется. При этом жертва даже ничего не заподозрит, ведь будут работать стандартные механизмы системы, а значит выявить атаку будет практически невозможно.
Да. Это больше потенциальная опасность, а не реальная. Но если есть другой, более надёжный способ, то зачем сохранять этот.
Ну, вообще-то в Android и iOs это уже поправили. В MacOS, вроде, тоже. А на Linux и Windows из коробки этого нет и сейчас. Я вообще не представляю можно ли Windows использовать в режиме IPv6-only через WiFi или Ethernet подключение.
Я тоже баловался на Fedora. Только у меня не было автоматического обнаружения префикса NAT64. Просто был настроен clatd, а NAT64 был на маршрутизаторе. Да, всё прекрасно работает при полностью отключенном вручную IPv4, даже торренты качаются с пиров IPv4 и Steam работает. Кстати, тут недавно обнаружил, что починили возможность запуска Steam в режиме без clat. Так что можно запускать игры, но при попытке что-то скачать из магазина просто выдаётся, что интернет недоступен. Для этого нужен clat.
Да. Хороший вариант заставить синтезировать записи локальный резольвер. Но тогда теряется смысл домена ipv4only.arpa, ведь чтобы синтезировать нужную запись устройство должно узнать адресацию NAT64. И тут единственным рабочим вариантом оказывается PREF64 в RA.
Это просто более ранний RFC, но многие его критикуют и призывают не использовать. Я присоединяюсь к ним.
Тут есть потенциальная опасность в том, что если вы каким-то образом начнёте использовать недоверенный DNS, который может весь ваш IPv4 трафик направить на подставной NAT64 шлюз, ведь диапазон NAT64 не является чем-то фиксированным и можно использовать любые адреса, в том числе и GUA для публичных NAT64. Такое может провернуть, например, какой-то вирус. Может и администратор сети, но он вообще может перехватывать весь ваш трафик и у него нет в таком способе особой нужды. Конечно, ваш трафик и так будет по большей части зашифрован, но его как минимум злоумышленник может записать для последующей расшифровки. Будет неприятно, если какая-то чувствительная информация будет защищена ненадёжными алгоритмами шифрования.
Это совершенно не так. DNS64 делает доступным большую часть сервисов IPv4. При этом никакой дополнительной нагрузки на клиента не создаётся. Он просто изначально отправляет все запросы на IPv6 адрес и ему без разницы что там дальше происходит, потому что ответ он получит, если NAT64 работает и сервис отвечает. Для устройства всё выглядит так, что он общается с IPv6 сервисом. CLAT же нужен именно для тех случаев, если программы напрямую обращаются к IPv4 адресам. В этом случае нужен виртуальный интерфейс с фейковым IPv4. Дальше это нужно дополнительно обрабатывать прямо на устройстве, чтобы пакет ушёл на NAT64.
Никакие записи DNS не переписываются. Записи типа AAAA добавляются к записям типа A, если для этих доменных имён нет AAAA. Ничего страшного в этом нет, кроме того, что это сломает DNSSEC для доменов, которые его используют, но не имеют AAAA записей. Например, так будет у банка ВТБ и Ростелекома... Впрочем, DNSSEC на rt.ru и так сломан без всяких DNS64... Интересно было бы узнать насколько часто вообще включают проверку DNSSEC компании.
Тут вы всё в кучу смешали. ipv4only.apra и PREF64 - это два разных способа обнаружения NAT64 в данном конкретном сегменте сети и это два разных RFC. Обнаружение через DNS имеет потенциальные проблемы с безопасностью, а также не гарантирует того, что NAT64 будет обнаружен. Банально, если клиент прописал себе другой DNS. И может ложно сработать, если клиент прописал себе DNS64 от того же Cloudflare или Google. PREF64 в RA тоже не самая безопасная штука, но в RA приходит множество других критичных параметров, которым приходится доверять. Для ipv4only.arpa есть отдельный RFC, но я бы не стал его использовать как основной способ обнаружения, только как резервный вариант. А лучше бы вообще не использовал.
DHCP option 108 нужна только в том случае, если ваша сеть выдаёт IPv4 адреса, которых у вас ограниченное количество. При помощью этой опции вы можете экономить пул адресов за счёт того, что его не будут занимать те, кто может работать в режиме IPv6-only, а это все мобильные устройства на Android и iOs, а также MacOS. Понятное дело, что если вы используете внутри сети 192.168.1.0/24, то вам скорее всего фиолетово все 200 устройств получат себе IPv4 адрес или только 50 из 200. А вот если вы выдаёте белые IPv4, то экономия пула оправдана.
symfonycasts/sass-bundleне поможет с scss? У меня тоже scss использовался, но я не сильно глубоко его использовал. Вероятно каких-то сложных вещей просто нет и меня это решение вполне устроило.Сейчас вроде в Symfony рекомендуют использовать AssetMapper вместо Webpack Encore. Реально большая экономия времени на сборке. Но я пробовал его только на простых вещах.
Собственно, проверил. Установил пакет в Archlinux из extra-testing. В качестве маршрутизатора взял официальную сборку под свой маршрутизатор без каких-либо модификаций. Всё необходимое он получал от головного маршрутизатора, где были настроены свои DNS64 и NAT64, как и было описано в статье, поэтому устроил и базовый набор компонентов.
Опция действительно работает, но она не включена по умолчанию, что разумно, т. к. NetworkManager не использует clat (уже есть патчи и обсуждение внедрения), поэтому возможны проблемы при работе некоторых программ. При включенной опции реально идёт запрос 108 опции в DHCPv4, на который отвечает OpenWrt и указывает время, на которое нужно выключить DHCPv4 клиента. Компьютер не получает IPv4 адреса и работает только через IPv6.
Удивительно, что я решил написать подобную статью прямо в тоже самое время, когда вышел NetworkManager с таким революционным изменением! Стоит доработать статью?
Оказывается прямо перед публикацией этого материала вышла новая версия NetworkManager 1.52, которая теперь поддерживает RFC 8925 «IPv6-only preferred». Жду появления в дистрибутивах.
Это на скриншоте из оригинальной статьи. Я никогда не работал с macOS. Вероятно, это её особенность, либо привычки автора оригинальной статьи.
Как бы хреново это не звучало, «Не повторяйте глупостей, записанных в конституции...».
Вопрос на засыпку. В OpenWRT 24.10 больше нет этих пакетов. Чем заменить?
Не надо сравнивать железки одного вендора и множество устройство, которые выпускает куча вендоров. Но даже в таких условиях мне удалось перенести конфигурацию без особых заморочек. И WiFi тоже возможно бы удалось перенести, но видимо из-за того, что железо для WiFi очень сильно отличалось (как минимум в одном был WiFi 5, в другом WiFi 6), вылезли некоторые косяки и проще было настроить WiFi с нуля.
Ну а подготовка собственной сборки вряд ли есть у микротика, когда на твоём устройстве только нужный софт установлен.
Это как сравнивать настройку iPhone и Android. О первого минимальное число вариантов, у второго есть огромный выбор совершенно разных устройств. Да. Переплачиваешь и не паришься... почти.
P.S. Кстати, по количеству портов мои железки тоже отличались, но при этом конфигурация перенеслась без проблем.
С FTTH всё плохо, если хотите обойтись одной железкой. Но есть рабочие варианты с двумя железками.
Можно приобрести какой-нибудь маршрутизатор с SFP слотом. В него устанавливается GPON терминал. НО! Это дорого (из "бюджетного" - SNR-CPE-ME2-SFP б/ушный + SFP терминал, но это уже как минимум более 5 тысяч рублей). Это не очень надёжно. Нужно с провайдером согласовывать ключ подключения, либо использовать его с имеющегося терминала. Видел много жалоб, что SFP-PON терминалы сильно нагреваются. В целом вариант рабочий, но нужно быть готовым, что могут возникнуть проблемы.
Самый рабочий вариант - перевести маршрутизатор от Ростелекома в режим моста, либо заменить его на то, что они называют PON-розеткой. Эта самая розетка по сути медиаконвертор из PON в Ehternet. Если у вас уже есть терминал в аренде, то менять его на "розетку" смысла не вижу, тем более можно позвонить в поддержку и попросить перевести его в режим моста. Желательно ещё попросить выключить WiFi, чтобы он эфир не забивал, потому что использовать его на GPON терминале уже не получится. Дальше подключаете свой маршрутизатор c OpenWRT через Ethernet и пользуетесь. Если есть доп. услуги, типа IPTV или телефонии, они остаются на GPON терминале.
Буквально месяц назад переносил настройки OpenWRT. Вполне себе возможно. Просто переносишь текстовые файлы и минимально их редактируешь. WiFi пришлось настраивать с нуля, потому что там совершенно другое железо. Ну и сборку для новой железки тоже пришлось делать под себя отдельно с учётом разных чипов в маршрутизаторах. Если нужно массово настраивать железки с похожим железом, то всё можно один раз подготовить, а потом всё клонировать.
У меня довольно сложные настройки для локалки, если сравнивать со среднестатистическим маршрутизатором. Например, есть резервирование адресов по DHCP для IPv4 и IPv6, доменные имена, которые внутри сети только работают и ещё некоторые вещи. И всё успешно перенеслось.
В РФ да. Пару сотовых компаний выдают, да некоторые проводные операторы. Но РФ - не показатель. Там где реально припекает (Китай, Индия) IPv6 разворачивается ускоренными темпами. Да и Европа тоже не отстаёт. Парадокс, но у меня сейчас хостинг стоит дешевле, чем IPv4 для него. Есть ещё бесплатная VPS... Но за то, чтобы иметь к ней доступ только по IPv4 нужно платить 150 рублей в месяц.
Нет. Я никогда не менял когда просили. Обычно была причина. Один раз менял, потому что микросим понадобилась. Последний раз менял по причине того, что криво обрезал под наносим и надо было правильно вставлять, чтобы работала.. Была симка с логотипом Ростелекома в виде уха (а точно это было ухо?), поменяли на чёрную Tele2.
Ну тут они под замес попали. Владелец торговой марки отказал в продлении лицензии по известным причинам. Так что тут понятно зачем переименовывали. А вот путь, который проделал мой номер: Уралсвязьинформ GSM -> Ютел -> Ростелеком -> Tele2 -> t2. И это самая понятная замена товарного знака из всех предыдущих.
Да. Сразу скидка постоянная в 40%, да ещё и безлимит на всё, а не только на Ютуб (потерял актуальность) и мессенджеры.