Pull to refresh
4
Сергей Попов@Pinkbyte

Системный администратор

1
Subscribers
Send message

i2p живее всех живых - скорость не радует, но "кто понял жизнь - тот не спешит" (c)

Tor с мостами Snowflake тоже вполне себя хорошо чувствует

Пф, тоже мне проблема:

src IP российский?

Dst IP зарубежный?

Извольте превышение оплатить.

Принадлежность адресов по GeoIP считать будут - и им будет насрать на то, что точность у этих баз иногда на уровне параши

Смените IP на подсеть которая в бане у РКН. И пойдете искать другого хостера.

>NAT64 и DNS64 должен предоставлять провайдер

Ага, каждый. Прям как и IPv6.

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

Я смотрю на текущую ситуацию, вижу что она никуда не движется уже с десяток лет и закономерно впадаю во фрустрацию. Ибо насуетить СЕБЕ IPv6 в домашнюю сеть - это не проблема. Вот с 2010(а то и раньше) - не проблема. Все пройдено - и miredo, и туннельные брокеры и даже 6to4 (который закопали, вот за него было обидно, да).

Только нативный IPv6 от провайдера я видел за все этовремя дважды: на мобильном LTE от Мегафона и экспериментально - в провайдере где я работаю :(

А я про то, что у нас уже почти 30 лет стукнуло с момента первого RFC. Я сомневаюсь что в телекоме в проде трудится оборудование 20+ лет (госуха - другой разговор, есть у меня пара серверов 2005 года выпуска работающие до сих пор).

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

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

Ну и ладно, давай еще 10 лет чтобы не осталось нового оборудования, которое не поддерживает IPv6 полностью (то есть статика, SLAAC, DHCPv6 для получения адреса - для конечных устройств и DHCPv6 prefix delegation - для роутеров)

Ой, а вот и настал 2026. Тем временем у нас есть китайские роутеры Tenda, которые не слышали про IPv6. Но это ладно, может это те самые аутсайдеры, им закон никогда не писан, вот крупняк весь прям четко все делает...

Аууууу! Android до сих пор не умеет DHCPv6 для получения IP(только SLAAC). В свежих версиях научили prefix delegation - но только для Tethering.

В результате имеем кучу девайсов c бэйджиком IPv6 certified, а что это значит - не узнаешь пока документацию не прочтешь

Так что как я уже сказал - я искренне хочу увидеть повсеместное внедрение IPv6 (не обязательео IPv6 only - Dual stack is fine too). Но с текущими темпами я боюсь до этого замечательного времени не дожить.

И да - на своем железе я могу настроить ULA, получить IPv6 от брокера или настроить Yggdrasil. Это все прекрасно и замечательно, но я говорю вовсе не об этом. Я говорю о глобальном маршрутизируемом IPv6-адресе выдаваемом каждым ISP абоненту by design.

Ты возможно меня неправильно понял и записал в хейтеры IPv6. Это не так. Я сам считаю что у IPv4 есть куча проблем, которые не решены, а подперты костылями (NAT).

А я просто устал, понимаешь? Я подобные статьи читаю с 2010 года. Одна из моих работ - в небольшом региональном провайдере, примерно с этого же года. И знаешь сколько я IPv6 видел в продакшене по работе? Не в своих домашних сетях, а прям реально а проде?

Ноль. Зеро. Пустое множество.

Можно долго рассказывать о преимуществах протокола. Можно рисовать графики и утверждать что вот в эту пятилетку он точно победит.

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

Просто я опасаюсь не дожить до этого прекрасного момента...

Итого - три технологии (NAT64, DNS64, CLAT), однокнопочных реализаций для которых в роутерах нет. Причем если для CLAT еще ладно - он относительно первых двух достаточно свежий, то вот с первыми двумя есть вопросики (что-то для NAT64 есть в OpenWRT из коробки, но вообще надо допиливать - потому что с тем же DNS64 предлагается возиться самому).

Безусловно, это всё возможно сделать и это не является какой-то прям неразрешимой проблемой.

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

Помнится до этого говорили что никто рубить куски Cloudflare и Fastly не будет, ибо очень много чего ляжет. А еще ранее была первая итерация борьбы с Telegram. Который забороть(тогда) не удалось, а вот осталлная инфраструктура знатно полежала...

Безусловно. Только он не поможет, когда белый адрес на роутер к абоненту не приходит вообще. Да, есть всякие UDP hole punching и DHT, но это не всегда работает со всеми типами NAT. В общем проблема есть и всякие IPv6-брокеры здравствуют до сих пор. Ну и Yggdrasil немножко спасает, да...

В OpenWRT можно писать правила для IPv6 для хост-части префикса - без указания самого префикса. Работать будет и при смене префикса, но только для клиентских девайсов на DHCPv6 или с отключенной рандомизацией в SLAAC. Ну и вяглядят такие правило конечно суперстранно - это да, это проблема

Wi-Fi так-то большей частью обратно совместим. Да, есть 802.11a, да, закопали WEP, но выходящие новые устройства обычно выходили не только с поддержкой свежего стандарта, но и пары(а то и более стандартов назад).

IPv6 же с IPv4 роднят только идея и три буквы в названии - внутри эти протоколы обратно несовместимы.

А еще могут быть несовместимы применяемые на сетях старого поколения технические решения.

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

Как всегда - 100500 тыщ денег, потому что "а куда вы со своим КИИ денетесь?"

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

А так в целом - да ради Бога. Делайте как вам и вашим пользователям удобно.

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

Вы что-то явно делаете не так если у вас теряются или меняются сигнатуры сервера к которому вы подключаетесь (при условии что сервер тот же самый).

Насколько я знаю автопринятие можно сделать в OpenSSH - комбинацией "автоодобрять неизвестные ключи" и назначением файла известных ключей как /dev/null. Учитывая что OpenSSH нынче даже в винду встроен - вполне себе вариант.

Защиты от MitM в такой схеме естественно нет

Aeza, Senko Digital, Timeweb

У последних дешево не будет, но зато у них репутация получше.

Два директора у Aeza - на киче за сотрудничество с наркошопами.

Техдир Senko Digital - украинец и знаменит русофобскими высказываниями в Steam - может кому-то это важно. К технической работе сервиса лично у меня претензий так-то нет, просто предупреждаю.

Selfhosted. Просто сейчас в маркетинговых материалах на сравнении тарифов пишут Free Tier при наличии. И лепят пометку Selfhosted - если оно поддерживается.

Я не в теме, но может клиент Mattermost такое умеет? Там правда засада будет с серверной стороны - у этих гавриков мало того что SSO нет в бесплатном плане нет(это допустим приемлимо), но они даже очистку базы от старых сообщений вынесли в Enterprise-подписку. Люди обходятся скриптами с Github-а.

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

1
23 ...

Information

Rating
4,963-rd
Location
Ростов-на-Дону, Ростовская обл., Россия
Registered
Activity

Specialization

Системный администратор, Сетевой инженер
Ведущий
Администрирование серверов
Администрирование сетей
Администрирование Linux
Системное администрирование
Маршрутизация
Администрирование оборудования Cisco
Виртуализация
Администрирование почтовых серверов
Docker