@schors
schors
18 Nov 2018

Когда в «выгрузке» появились IPv6-адреса, я думал, что история будет скучной. Но нет, она превращается в «Удивительные приключения IPv6 в выгрузке». Я уже писал, как пару дней блокировали IPv6 огромными подсетями:
https://t.me/usher2/531
https://www.facebook.com/us...sts/2206675212880002
https://vk.com/wall-167974248_345

Явную ошибку поправили. Но сегодня, один провайдер в чате https://t.me/version6 заметил, что его фильтр почему-то не знает об этом исправлении. Дело в том, что каждая запись в «выгрузке» имеет уникальный хэш, который изменяется при каждом изменении внутри записи (согласно памятке http://vigruzki.rkn.gov.ru/...operators_actual.pdf ). Так вот записи были исправлены с подсетей на отдельные IPv6-адреса, а хэш не поменялся. И фильтры, которые применяют изменения с учетом изменения этого хэша ничего не заметили.

Например, запись id=1181781 имеет хэш hash="9B3CC919D3A02CBDD95D0B1C0630041A" в выгрузках 2018-11-09 03:33:00 и 2018-11-18 01:31:00 (вот прямо сейчас), но в первой там две подсети IPv6 по /32, а во второй – два IPv6 адреса.

Конечно, от ошибок никто не застрахован. Но в такой серьёзной автоматизированной системе, от которой зависит доступ в сеть на 1/6 части суши, могли бы как-то поответственнее подходить к вопросу.

18 Nov 2018

Чтобы это было совсем по-русски, хэш по спецификации системы должен быть именно от содержимого записи. Но по традиции запись может меняться не меняя хэша.
ЛСДУ3 и ЙФЯУ9, короче.

18 Nov 2018

да это просто криворукость. вручную поменяли

#mbysf/2 в ответ на /1

Добавить пост

Вы можете выбрать до 10 файлов общим размером не более 10 МБ.
Для форматирования текста используется Markdown.