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

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

Может быть я утрирую и даже я сразу вспомню много настоящих и больших инженеров на высоких управленческих должностях. Однако, что в этих должностях больше? Является ли сохранённый инженерный навык исключением или правилом в этом случае? Принцип "Менеджер может управлять всем, так как это его работа", создал и развивает другую культуру профессии менеджера, в которой сложно оставаться технарём.

Большой учебник Bash или в виде вики. На том же сайте рядом лежит FAQ, для конкретных ответов на вопросы.

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

Маленькая утилитка для определения IP адресов и ASn по доменному имени - asnip. Фактически это обёртка к api.hackertarget.com. Иногда падает, но иногда работает и даже очень удобна в это время. Заменяет собой череду команд из nslookup и whois.
У меня почти такое же есть на TCL, но там поиск начинается с ASn и не используются внешние API. В общем, я подумал, что надо поиск по домену прикрутить и моя будет лучше :)
Задачи такого рода достаточно частые, потому что на уровне абонентов в основном только домены, а на уровне настроек ASn и сети, поэтому такой перевод нужен. Результаты работы утилиты попадают в файлы cidrs.txt и ips.txt.

И ещё одна обёртка на этот раз к geolite.maxmind.com - asnlookup. По названию ищет сети и может сразу отправить их на вход nmap, понятно для кого добавочка, но не приносящая никакой дополнительной пользы. Для работы нужен unzip именно в таком виде или придётся немного подправить код.

Это примеры повседневной автоматизации которая, я думаю, есть у многих если не у каждого админа, где нибудь в каталоге ~/random-scripts. Пишется за полчаса, если не слишком лень :) иногда дорабатывается, но часто так и остаётся в первом варианте потому что работает, а большего и не надо.

T8 и МФТИ хвалятся, что бьют все рекорды по дальности и скорости передачи сигнала в оптоволокне без промежуточных усилений. Цитата из публикации в IEEE Photonics Technology Letters (наверное там платно, поэтому только резюме) :

This letter demonstrates unrepeatered real-time transmission of 200 Gb/s (5 bit per symbol modulation format, 56.8 GBaud) signal over terrestrial 520 km single-span fiber link. This was achieved using ultra low-loss fibers with large effective area, ROPAs with dedicated fibers, and distributed Raman amplifiers with co- and counter-propagating pumps.

Какого размера должен быть пакетный буфер на маршрутизаторе? Статья про то, что чем меньше тем лучше, вплоть до нескольких десятков пакетов. Основной критерий оценки это полнота утилизации канала передачи, при этом, предполагается, что регулированием трафика занимается TCP с его механизмом предотвращения заторов. Большая часть статьи это обзорное повествование история вопроса со ссылками на другие работы, а вместо выводов ещё больше новых вопросов.

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

Найти компромисс и есть настоящая наука, высший пилотаж.

Google Stadia не использует IPv6 и кеши (почему написано в комментариях). Наверное, хорошо рассуждать о высоких материях находясь в 200км от двух датацентров Google. От меня 1000км только до ближайшей PoP, и ещё столько же до датацентра. Проекту слишком мало лет, чтобы там всё было, не всё сразу, если конечно не прикроют его.

Во всём виновата Windows, кто же ещё?, которая отправляет к администратору сетей, хотя надо отправить к администратору групповых политик. Но сетевой администратор не растерялся и сам всё починил, выступив в роли прокси.

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

Иногда нужен прицельный подход, а иногда широкий охват, а часто совместить это вместе. Бывает возникает ситуация что до тебя доходит очень узкая задача, что-то вроде: "Тащи виланы сюда, настрой порт в авто". Начинаешь подниматься выше по иерархии охватывая картину в целом и понимаешь, что и виланы-то тащить не надо, порт уже настроен, да и проблема решена два года назад в общем виде. Достаточно тип услуг другой назначить в уже существующей системе.

И это не только проблема больших компаний со сложной организацией, там где больше двух человек, да даже если один уже может случится так что общую картину нельзя охватить целиком. В предельном случае общая картина это набор островков которые между собой никак не пересекаются и это хороший вариант. Не очень хороший это когда между этими островками построено бесчисленное множество мостов возникающих каждый раз когда в задаче возникает ключевое слово, "сеть" - сетевики, даже если это электрическая сеть, "Windows" - к сисадминам, "sql" - к программистам.

Так и живём, но в Windows и не только, можно всё же более понятные сообщения об ошибках делать.

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

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

Так вот, еду в автобусе смотрю "Мистер Робот" и вижу открытую диаграмму сети, на паузу нажать не успел, поэтому перемотал и посмотрел снова. Это был yEd, не знаю почему я не увидел его раньше, но теперь следующие несколько недель работаю только в нём. Явного отторжения пока не вызывает, чего не могу сказать например про Pencil, но на вкус и цвет. Функционал достаточно богатый, нужные иконки легко гуглятся. Поэтому, возможно, вопрос с диаграммами я скоро закрою.

​Интересная статистика от REG.RU. Для сравнения ~32000 адресов это сеть /17. Весь наш пул адресов это плюс ещё /18 (~16000), но мы провайдер и мы можем позволить себе NAT, без этого не хватит. При этом мы никогда не стремились накапливать адреса, всегда брали ровно столько сколько нам не хватало. То есть у нас "много" , если сравнивать с тем что приводится. Много ли это для хостеров вот в чём вопрос.

⌨️ И вот ещё, большое количество различных vim-like полезностей, собранных в одном месте https://vim.reversed.top/

#фидбечат #линк #vim

Хорошо и подробно про mtr, с примерами. Это вторая часть серии.

Сегодня пиринговый форум - цель моего раннего утреннего перелёта. Кто не дошёл, есть трансляция https://peering-forum.ru/live/

Много где засветилась новость про то что можно ломать VPN - на OpenNET достаточно понятно пишут, но много внимания уделили не сути, а режимам rp_filter и методам перебора. Можно читать оригинальный тред, там подробнее, но ровно про то же.

Что важно:
1. Зашифрованный трафик остаётся зашифрованным и его не расшифровывают
2. Используемый метод позволяет влиять на то что будет передаваться внутри туннеля
3. Это влияние можно использовать чтобы выяснить параметры соединения внутри туннеля, например, адресацию
4. Это можно использовать чтобы добавлять/подменять реальный трафик внутри туннеля, но вслепую. Ответ будет зашифрованным внутри туннеля и поэтому атака предполагает ещё и его перехват и анализ на основе статистики и сигнатур
5. Атака возможна потому что пакет обрабатывается одинаково в соответствии со своим адресом в не зависимости на какой из интерфейсов он пришёл

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

P.S. Там камни в огород systemd летят в связи с этим, но тут больше дело в том, чтобы знать свою систему и понимать как всё работает.

Скорость исполнения, против скорости разработки. Скорость выполнения посчитать легко и даже можно калории посчитать и там всё ясно с тем кто на коне. А вот со скоростью разработки и поддержки сложнее, иначе бы не было ни Ruby ни Java.

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

Как настроить серверы DHCP Kea в режиме высокой доступности, они даже лизы между собой синхронизируют. Пошаговая инструкция, иногда не хватает подробностей и раскрытия большего количества вариантов, но за этим можно к официальной документации сходить. Хорошее решение из коробки, без собственноручно написанной логики.

Пока пароли всё ещё в ходу - статья про то как сделать хороший пароль - всё дело в длине и уникальности:

1. Каждому ресурсу свой пароль
2. Если пароль содержит цифры, буквы и спец.символы это не значит что он хороший
3. Ответ на секретный вопрос для восстановления пароля сделайте другим не менее сложным паролем
4. Двухфакторная аутентификация
5. и менеджер паролей

Приводится несколько заблуждений, например, по поводу частоты смены паролей, в конце пару ссылок по теме, в том числе на чекер сложности паролей от Dropbox.

На нашем недавнем тепло-семейном сборе в Москве (кстати, спасибо всем, кто пришёл) узнал прекрасную историю про бурления масс вокруг мнения не безызвестного нам всем товарища Пепельняка. Иван человек простой и прямо говорит, что проблема не в BGP, а в руках и головах инженеров, которые им пользуются.
Ну и понеслось...
https://blog.ipspace.net/2019/12/bgp-and-car-safety.html