Комментарии 10
Возможно я упускаю что-то фундаментальное, но...
Если я подключен компьютером к порту свитча/роутера и свитч/роутер в своей таблице mac адресов сопоставляет меня с конкретным своим портом, то как переключение режима работы интерфейса на компьютере (на компьютере же, не на роутере, как я понял из статьи) поможет, если на этот тот физический порт, куда я подключен, свитч/роутер будет отправлять только мои пакеты и бродкасты?
Или тут рассматривается подключение к hub (OSI L1), а не к switch (OSI L2/L3)?
Так как от автора статьи ответа, скорее всего, не будет, то отвечаю сам себе. Скорее всего в статье подразумевается беспроводное подключение и режим "monitor mode" в Kali Linux. В таком случае да, wifi адаптер будет слышать все пакеты в этом broadcast домене.
Ну может автор предполагает еще и arp спуфинг применить )
Поражает ширина умений некоего мифичкеского "devops инженера". Теперь: "DevOps инженеру необходимо разбираться в сетях не хуже специализированного нетворк инженера". Остается добавить умение играть на скрипке, приуспеть в паурлифтинге, да и в боксе было бы неплохо. Что еще придумают авторы курсов? :)
На мой взгляд базовое уменение пользоваться wireshark/tcpdump необходимо как senior dev, так и линуксовому ops'y общего профиля. Мне в роли разработчика далеко не раз приходилось втыкаться wireshark'ом чтобы отловить проблемы с кодировками, компрессией, несброшенными буфферами, некорректным проксированием и т. п.
Иногда бывает полезно воткнуться удаленно, но это уже обычно не для dev'а: wireshark -k -i <(ssh $REMOTE "tcpdump -s 0 -U -n -w - -i $INTERFACE [filters..]")
Умение смотреть трафик в wireshark, это не совсем то чем занимается сетевой инженер. Вот там всякие железки L2-L3, всякие маршрутизации, vlanы и т.д. (кучи протоколов, особенностей, облачных реализаций и т.п.) врятли снились даже синьору dev, да и зачем? Что для devops, так это сетевое взаимодействие, сетевые распределенные fs, и т.п. Синьор dev много знает про работу например Ceph, и почему из нее плохо читать чанками? В том то и дело...
Да это понятно, что dev иметь представление о сети полезно, но большая часть того чем занимается сетевой инженер -- совсем не его песочница. Здесь же статья была уровня недотуториал по шарку..
Что же до ceph, если senior dev с ней взаимодействует (даже просто читает/пишет с/на смонтированный iscsi), то знать ограничения крайне желательно. Иначе будут fsync'ать после каждого байта (или 512) или выжрут все iops'ы когда в этом не было необходимости. Также как представлять что у разных хранилищ бывает сильно разный размер блока, знать характерные задержки для того io с которыми взаимодействует (и когда это знание станет важным). Как, в общем, с любой смежной областью с которой он имеет дело. Иначе разве это senior, если он живёт в парадигме monkey see -- monkey do?
Запустить tcpdump это не что-то узкоспециализированное. Это один из базовых инструментов диагностики. Банально посмотреть как/куда приходит/уходит трафик. Условный devops/build/sre/etc инженер если не будет знать базовые вещи про сети может словить гигансткое количество проблем в своей работе, при этом быть источником этих самых проблем.
Захват сетевого трафика в Kali Linux