Блог сетевого инженера. Новости телеком, IT и околоIT.
iputils, так смутивший автора, сейчас одинаковые по поведению tracepath -6 и tracepath6, к которым можно добавлять опцию -p, чтобы конкретизировать порт на который отправится первый пакет и который будет увеличиваться на один с каждым новым пакетом. -p 33434 - сделает его похожим на классический traceroute, также это решит возможные проблемы с файрволлами, которые тихо фильтруют UDP порты за рамками возможных значений классического traceroute, поэтому эту опцию лучше использовать.
Для привычного traceroute, в моём CentOS Stream отдельный пакет, не стоящий по умолчанию, и в нём поведение traceroute -6 и traceroute6 тоже одинаково. Если хотите определённости - обновляйтесь и не смешивайте одинаковые утилиты из разных источников.IPv6, где проблему можно сделать потому что каждый обладает очень большим адресным пространством. В IPv4 - массовый и легитимный анонс всего своего адресного пространства в префиксах по /24 может привести даже к более плачевным результатам, потому что размер BGP таблицы маршрутизации уже очень большой и лишние 100К могут сделать дело намного эффективнее, чем лишние 500К в IPv6. Сейчас префиксов /24 в IPv4 таблице чуть меньше 60%, а /48 в IPv6 чуть больше 45% так что есть что деагрегировать. Смотрим за статистикой @FullViewBGPbot или @bgp_table_bot и не забываем поставить лимиты и триггеры там где это необходимо.static route ещё и NAT. Не знаю как у вас с твиттером, поэтому картинкой, стащил отсюда.IP. Поэтому сетевым инженерам стоит относиться к IP адресу и к любой собираемой технической информации как к персональным данным клиента/абонента, утечка которых не сильно отличается от утечки паспортных данных и ничем хорошим не кончится. Вас взломают, это дело времени, готовьтесь к этому.
А вот с точки зрения нашего государства у вас нет конфиденциальности в Интернете, сессии с вашим IP регистрируются и хранятся, а с приходом закона Яровой ещё и куча метаданных сверху. Интернет по паспорту уже давно с нами.IP адресом - то можете быть уверенным что освободив его, запросы на него будут приходить ещё очень и очень долго. Как, например, у Dataplane, новость "DNS Query Anomalies". Они конечно написали куда надо и даже заверили что никак этой ситуацией не воспользовались, но на такое поведение полагаться нельзя. Напротив, стоит предполагать что каждый утраченный вами ресурс будет использован, как минимум для сбора чувствительной для вас информации. Не теряйте свои ресурсы, а освободившиеся попридержите и помониторьте что на них прилетает.