LLTR Часть 0: Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима?

[click0]

Для восстановление сети из неуправляемых коммутаторов после грозы потребуется очень много времени и ресурсов! (с) forum.nag.ru

[RamusAkaRami]

До середины прочитал и у меня чуть не взорвался мозг, особенно в выборе unicast src и dst или просто конец рабочего дня о себе дает знать.
Программный сканер-то написали уже? Который бы рисовал гипотетическую топологию?

[ZiroKyl]

Программный сканер-то написали уже?

Да, про него в следующих частях.
Следующая часть («Часть 1») выйдет скоро. Надеюсь, что успею ее обработать (сверстать, ...) менее чем за 1 неделю.

До середины прочитал и у меня чуть не взорвался мозг,… или просто конец рабочего дня о себе дает знать.

Перед публикацией статьи я давал прочитать ее нескольким людям, и одному из них было трудно воспринять всю информацию за один раз. Тогда я ему посоветовал «забить» на текст и посмотреть на схемы (предварительно прочитав в тексте про обозначения). Это ему помогло.

P.S. Я и сам представляю (в голове) все это графически (в виде схем, анимаций, ...).

[koot]

Прочитал вашу тему про vhd хотел бы использовать ее у себя на работе можете актуализировать статью и или выложить что нового наработанно по данной теме

[ZiroKyl]

Ничего нового за это время не появилось (все и так работает). Несколько раз обновлял bat'ники. В статье все ссылки указывают на последнюю версию.

P.S. важно понимать, что это только часть защиты, остальную часть я нигде не описывал (часть из нее в принципе не могу описать), но если это все реализовать, то вполне можно использовать такую систему для хакерских конкурсов (поиск по «hacker vs laptop»).

[ZiroKyl]

4 koot

P.S. важно понимать, что это только часть защиты, остальную часть я нигде не описывал

Но одно из основных правил очень простое:
— все, что можно изменить — нельзя выполнить
и наоборот:
— все, что можно выполнить — нельзя изменить.

Стандартными средствами первое решается с помощью ACL в NTFS и политик.
Второе — с помощью dVHD и ACL в NTFS.

Под «все, что можно изменить» подразумеваются файлы пользователя, хранящиеся на отдельном разделе (вне VHD).

Если пользователю все-таки понадобится выполнить один из своих файлов, то для этого я создал symbolic link / junction point (на разделе в VHD), ведущей к директории с файлами пользователя. Важно, чтобы это была не корневая директория, иначе будет трудно корректно настроить наследование прав доступа (ACL в NTFS).

[ZiroKyl]

А также, если ранее не "замораживали системы" (не использовали immutable/non-persistent хранилища для виртуальных машин, или Aufs/UnionFS, или EWF, или Deep Freeze/Shadow Defender/Comodo Time Machine/…), то столкнетесь с одной проблемой, решение которой заключается в заморозке времени системы (восстановление даты после перезагрузки).

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

Поясню: в таких "планировщиках заданий" задания выглядят примерно так: если с момента предыдущего запуска задания прошло больше двух недель, то "запустить задание" (заданием может быть, например, оптимизация кеша {очистка, перестройка}). А т.к. запись о моменте предыдущего запуска хранится на VHD (перезагрузка системы приводит систему в исходное состояние), то спустя 2 недели после заморозки, задание начнет выполняться после каждой перезагрузки (планировщик обновляет дату последнего запуска задания, но после перезагрузки дата возвращается назад, и планировщик опять запускает задание ...).

[Busla]

Интересно!
Но в основе идеи лежат «идеальные» свичи. В то время как реальные коммутаторы доступа имеют производительность того же порядка, что и скорость аплинка.

[ZiroKyl]

Во время создания LLTR (лето 2015) моя реальность выглядела много мрачнее:

• в основном D-Link DES-1016 (A / B / D) – точной модели уже не помню
• парочка D-Link DGS-1005D/RU
• и это ZyXEL ES-116S ...

Повествование я хотел строить в направлении от абстракций (Часть 0) к реальным условиям (Часть 7), тем самым полностью описав процесс создания LLTR (таким, каким этот процесс был в реальности).

В этой «нулевой» части всего лишь было «немного» теории с "идеальными условиями":

… все соединения дуплексные, и скорость всех соединений одинаковая.

, и встроенным в текст «расширителем кошелка Миллера» (пригодится для следующих частей ;)
В следующих частях я выложу «нюансы» (но конкретно эти условия сохранятся).

И да, для описанной конфигурацией коммутаторов доступа (с портом, скорость которого превышает суммарную скорость основных портов):

коммутаторы доступа имеют производительность того же порядка, что и скорость аплинка

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

[ZiroKyl]

… но оптимальная цепочка пиров все же будет построена, и «полная скорость сети» будет достигнута.

Более корректный ответ: в этих условиях можно не получить оптимальную цепочку — придется делать перебор вариантов. Однако предварительное «сканирование» (LLTR) сети позволит (в некоторых случаях) сократить количество перебираемых вариантов.

Но я не зацикливался на подобных случаях (все равно количество перебираемых вариантов будет велико), оставаясь в пределах оговоренных ограничений:

… все соединения дуплексные, и скорость всех соединений одинаковая.

+ точность результатов сканирования может уменьшить активность сторонних узлов сети в момент сканирования. Это придется учитывать и подстраиваться, что приведет к усложнению алгоритма работы (выбор параметров сканирования, последовательности сканирования, обработка полученных данных).

Поэтому «не все сразу» — при создании модели (Часть 1) добавится еще одно ограничение — отсутствие посторонней активности в сети.

[ZiroKyl]

Нужна помощь: следующая часть будет посвящена разработке, но единственный хаб связанный с сетью в потоке разработка называется Mesh-сети (есть еще близкие хабы: Twisted, «Разработка систем связи» и «Системы обмена сообщениями»).
Нужно выбрать наиболее подходящий хаб для статьи. Точнее наоборот — чтобы статья подходила для читателей этого хаба.

Прототип (модель) протокола будет создаваться в OMNeT++, в котором также моделируют и Mesh-сети. Однако в моей статье не будет ни слова про Mesh-сети.
Код в ней будет написан на C++, но эта статья не про язык/стандарт C++.
В ней будет немного реверс-инжиниринга, но это не основная тема статьи.

Варианты:

• разместить в Администрирование → Сетевые технологии (но статья не относится к администрированию)
• разместить в Разработка → Mesh-сети (и в начале статьи извиниться перед его [хаба] читателями)
• попросить создать новый хаб, например, Разработка → Сетевые протоколы (но если бы каждый создавал хаб для своей статьи, то получился бы хаос)

В общем, идеального варианта нет.

_{P.S. было бы здорово, если хабы из Администрирования имели зеркальную копию в Разработке, ведь то, что администрируют изначально было кем-то разработано.}

[ZiroKyl]

Неделя пролетела незаметно … Вышла новая часть!

Она большая, очень большая. Если «Часть 0» (эта часть) занимала 20 страниц, то «Часть 1» занимает 138 страниц (вместе с содержимым спойлеров). Сейчас некоторые сайты показывают время чтения статьи (например: «6-12 мин.»), ну что же, если бы на Хабре было такое поле, то в нем было бы написано «4-6 дн.» … хорошо, что такого поля нет.
И, т.к. это tutorial, а они обычно предполагают воспроизведение действий читателями, то в конце добавил опрос, чтобы узнать, сколько людей дошли до конца, и пора ли публиковать следующую часть.

Заодно обновил UserCSS (только с ним я могу читать такие «объемные» тексты).
Изменений несколько, и все они связаны с <code>.

---

Первое изменение можно назвать "Anti quotes-hell".
Допустим, есть фрагмент кода, который читатель может скопировать и использовать (вставить в командную строку, код программы, …) (эффект лучше заметен, если для основного текста и для inline-<code> используется один и тот же размер шрифта):

• foo + bar + 19
• -foo=bar
• foo + bar & baz + zzz

Где здесь код, и где текст? Точнее где здесь границы кода?

Чтобы границы были лучше видны, я заключаю блоки кода в кавычки:

• “foo + bar +” 19
• “-foo=bar ”
• “foo + bar” & “baz + zzz”

Но как это будет выглядеть, если сам блок кода содержит кавычки в начале и конце (например, чтобы показать, что число надо задавать в виде строки):

• “"8"”
• “"foo" + "bar"”
• “"6" + "9" == "69"”

Слишком много кавычек. При большой концентрации кавычек в тексте они перестают помогать и начинают отвлекать. Получается рябь/мусор из кавычек.

Поэтому я (как читатель) предпочитаю подсвечивать фон и границы блоков кода. У меня это настроено в стилях браузера (UserCSS).

Поэтому я (как писатель) предпочитаю, вместо задания визуального представления (использования кавычек) в разметке — разделять разметку и оформление (подсвечивание фона и границ блоков кода). То есть писать так:

• foo + bar + 19
• -foo=bar
• foo + bar & baz + zzz

И как раз здесь возникает проблема, если начальные стили сайта (AuthorCSS) не задавали фон/границу для внутристрочных блоков кода, и заходит читатель, который в своем UserCSS не задает оформление внутристрочных блоков кода.

Поэтому мне (как писателю) приходится добавлять кавычки (получая в итоге «quotes-hell»), и (как читателю) использовать UserJS, который убирает обрамляющие блоки кода кавычки.

---

Второе изменение убирает фон у внутристрочных блоков кода.
Если сравнить два представления одного и того же текста: одно — оригинальное (без UserCSS; без затенения фона у <code>), другое — измененное (с UserCSS), то в измененном варианте <code> начинают акцентировать на себя внимание. Но автор текста не хотел делать акцент на всех <code>! Для создания акцента он использует <strong> (и <em>).

Решение проблемы: убрать затемнение фона, но оставить чуть заметный border.
Кстати, после этого изменения, кажется что <code> дополнительно подсвечены изнутри, т.е. кажется, что их фон ярче, чем фон обычного текста.

И что самое приятное — теперь мы можем при помощи затемнения фона создавать акцент на выборочных <code> с использованием разметки: <strong><code>...</code></strong>!

Похоже, в GitHub при создании help.github.com задумались об этом, и пришли к тому же выводу. И дополнительно добавили изменение цвета border для случая <a><code>...</code></a> — я попробовал добавить это в UserCSS, и оказалось, что при большой концентрации code-ссылок в абзаце — они начинают отвлекать.

Еще один нюанс (если не устали читать этот поток мыслей)

Иногда авторы используют внутристрочные блоки кода (<code>) для разметки многострочных фрагментов (либо для вывода не кода моноширинным шрифтом), вместо использования <source> или <pre>. При этом код начинает выглядеть как «многострочная колбаска»…

В этом случае поможет «анти-колбасочный стиль»: с border-top-style: none; и border-bottom-style: none;. С ним и границы кода видны, и нет «колбасок». Но в своем UserCSS я не использую его — мне нравится полный вариант border.

P.S. для разметки не кода подходит тег <samp>.
P.P.S. мне вначале показалось, что на help.github.com тоже используется <samp> для вывода «терминала», но оказалось, что там просто использовали <pre class="command-line">.

---

[ZiroKyl]

Похоже, через Yandex многие ищут «OMNeT++ учебник на русском» (запрос подсказки для "OMNeT++"):

(
    GET /suggest-opera?part=OMNeT%2B%2B&n=5 HTTP/1.1
    Host: suggest.yandex.ru
    Accept-Language: ru
)(
    ["omnet++",["omnet++","omnet++ учебник на русском", ...]]
)

В Google тоже есть похожие запросы:

(
    GET /complete/search?q=OMNeT%2B%2B&client=opera&hl=ru HTTP/1.1
    Host: clients1.google.com
    Accept-Language: ru
)(
    ["OMNeT++",[4x...,"omnet++ на русском","omnet++ installation guide",...]]
)

Вполне подходящие название для «Часть 1»: это tutorial (учебник), он про OMNeT++, и он написан кириллицей :-)
Да будет так: "OMNeT++ учебник на русском".