Лига Сисадминов

Продолжение IP over Ethernet. Часть 0.2 со ссылками на 0.1 и 0.

Итак поговорим о ethernet коммутаторах.

Сначала кратенько о том как было до них:

Для понимания функционирования любой эзернет сети нужно знать немного, но все-таки кое-что нужно:

1. Адресация. Если не упоминать ранние реализации, а начинать сразу с актуальных (ethernet v2), то у каждого устройства в сети (для удобства дальше все такие устройства буду называть хостами (host) как в tcp/ip независимо от контекста L2 или L3 пока речь будет идти о связанных с tcp/ip технологиях) должен существовать уникальный физический адрес - MAC, уникальность обеспечивается координацией IEEE производителей оборудования. Каждый MAC-адрес это 48 битный идентификатор, для удобства восприятия человеком обычно представленный шестнадцатиричными цифрами, объединенными в блоки:

00:0f:9f:c5:c3:c3 - разделенные двоеточиями на 8-мибитные блоки (байты или октеты) - один из наиболее популярных видов записи;

00-0f-9f-c5-c3-c3 - то же, но с дефисами, так, обычно, в длинках;

c04a.003c.044b - разделенные точками 16-тибитные блоки - принятый вид записи в Cisco IOS;

Первые 3 октета это префикс, соответствующий вендору, а следующие 3 октета - уникальный идентификатор, назначенный производителем.

Кроме идентификаторов хостов есть MAC адреса специального назначения. Во-первых широковещательный адрес или broadcast (ff:ff:ff:ff:ff:ff), MAC адрес, который используется, когда отправляемый эзернет кадр предназначается всем хостам в сети. Во-вторых и далее разные адреса для многоадресного (multicast) трафика, vrrp и прочих.

2. Общие сведения об струтуре кадра эзернет. Минимум, который нужно знать:

Кадр состоит из 3х частей - заголовка, полезных данных и контрольной суммы. Пока нам для последующего разбора надо знать из чего состоит заголовок. На рисунке заголовок представлен 14ю байтами из которых 6 - адрес назначения (destination, dst, d), 6 - адрес источника (source, src, s), 2 - тип кадра. Надо сказать, что на физическом уровне перед заголовком есть еще и преамбула, состоящая из 8ми байт, а после кадра межпакетный пропуск, но для начального понимания коммутации они несущественны. После нехитрого подсчета минимального payload в 46 и checksum в 4 байта получим минимальный кадр размером в 64 байта.

До появления коммутаторов все кадры в эзернет сети приходили всем хостам. То есть в такой сети (для удобства среда просто обозначена как шина):

Кадр отправленный от A к C с адресами в заголовке dst 00:00:00:00:00:03 и src 00:00:00:00:00:01 приходил и к B, B соответственно должен был его отбросить, так как кадр не для него, а C принять и обработать, A во время отправки ничего принимать не мог. Если C ответит A, то кадр также попадет и к A, где будет обработан, и к B, где будет отброшен. Любой кадр с dst ff:ff:ff:ff:ff:ff приходил ко всем и обрабатывался всеми, кроме отправителя, который, как водится, ничего не мог принимать во время отправки.

Сеть на концентраторах (хабах) принципиально ничего не меняла, кадры доставлялись точно также всегда всем.

Сеть на коммутаторах функционирует совершенно иначе, хотя для хостов все осталось как было и вроде бы ничего не изменилось.

Картина почти идентична предыдущей, но на ней не хватает существенных деталей, которые раньше не были существенными - номеров портов, исправим.

Теперь разберемся, что происходит в такой сети при таком же трафике как в предыдущих примерах.

Кадр отправленный от A к C с адресами в заголовке dst 00:00:00:00:00:03 и src 00:00:00:00:00:01 приходит в 3й порт свича. С этого момента все совсем не так как раньше. Я писал, что свич это специализированный сетевой компьютер. У него есть центральный процессор и память (ЗУ).

Итак шаг за шагом:

1. Приняв кадр на 3м порту с src-mac 00:00:00:00:00:01, свич, используя специализированную часть ЗУ, называемую CAM таблицей, запомнит на некоторое время, что хост A с MAC адресом 00:00:00:00:00:01 подключен где-то за 3м портом. CAM таблица представляет собой специализированное ЗУ, называемое ассоциативной памятью или АЗУ, в котором поиск данных по уникальным ключам происходит очень быстро.

2. Изучив dst-mac 00:00:00:00:00:02 из заголовка и определив, что это не адрес специального назначения, свич начнет поиск записи в CAM таблице, соответствующей ключу в виде этого адреса, если записи там нет (предположим в момент, когда сеть только включилась), то кадр будет отправлен во все порты кроме того, в который пришел этот кадр. То есть дальше кадр уйдет в порты 6 и 8, где будет обработан или отброшен соответствующими хостами.

3. Если C ответит A, то кадр с dst 00:00:00:00:00:01 и src 00:00:00:00:00:03 будет принят 8м портом свича.  Свич добавит в CAM таблицу запись о том, что хост C с MAC адресом 00:00:00:00:00:03 подключен где-то за 8м портом.

4. Изучив dst-mac 00:00:00:00:00:01 из заголовка и определив, что это не адрес специального назначения, свич начнет поиск записи в CAM таблице, соответствующей ключу в виде этого адреса, найдет запись о том, что хост с MAC адресом 00:00:00:00:00:01 подключен где-то за 3м портом. Дальше кадр уйдет только в порт 3, где будет обработан хостом A. В остальные порты кадр скоммутирован не будет.

Далее при каком-то значимом трафике между хостами кадры будут уходить уже адресно только получателям в соответствующие порты, это еще называется unicast.

5. Любой кадр с dst ff:ff:ff:ff:ff:ff будет после соответствующего обновления CAM таблицы по src-mac будет отправлен во все порты, кроме того на котором он был получен. Кадр будет обработан всеми хостами, кроме отправителя.

Для оценки значимости этих простых, в сущности алгоритмов я и написал предыдущие 3 части цикла. Поскольку это и предопределило революцию, описанную ранее.

В конце приведу несколько полезных ссылок в качестве, так сказать, дополнительной литературы.

Сети для самых маленьких. Часть вторая. Коммутация

Про MAC-таблицы в коммутаторах

Всё, что вы хотели знать о Ethernet фреймах, но боялись спросить, и не зря

В Интернет через Ethernet - Nag.ru

Первая часть.

Надеюсь, кто хотел, тот прочитал в вики про модель OSI, там статья весьма улучшилась с тех пор, как я её видела последний раз, так что рекомендую.

Сегодня я сделаю некоторый вбоквел. Почему именно удаленный доступ? Потому что мы, админы, пользуемся этим ежедневно.

Администрирование#02. Удаленный доступ.

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

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

1. Терминальный доступ. Сейчас этим словом называют доступ через консоль (такую, как в фильмах о хакерах – белые буковки на черном фоне). Этот вид доступа текстовый. Он используется для доступа на сервера без GUI (Graphical User Interface); для доступа на сервера с GUI, но с устройств без GUI; для доступа на различное сетевое оборудование; ну и просто как универсальный-доступ-куда-угодно, так как что может быть универсальнее консольки?

Кстати, цвет буковок и фона часто настраивается – всё для людей!

Для работы в терминале существуют команды с флагами и параметрами:

Терминал — он же консоль в повседневной речи, для желающих углубиться ссыль. В нашем случае, то самое черное окошко с белыми буквами. Открыть терминал можно в графическом интерфейсе (в Windows, Linux, MacOs), или же переключиться на один из стандартных терминалов с помощью Ctrl+Alt+F1(до F6) в некоторых Linux-системах (за все не поручусь). В Windows можно также использовать специальную программу Putty (ssh и telnet клиент + несколько фич).

Команда — команды набираются в терминале текстом, это программы, которые выполняют заложенные в них действия.

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

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

TELNET — такое название носит и команда, и протокол. Специфицирует передачу символов ANSI. Не рекомендуется использовать не через свою локальную сеть, так как telnet не поддерживает шифрование. Но telnet - простой протокол, его знают очень многие устройства и не тормозят при использовании.

Порт — идентифицируемый номером системный ресурс, выделяемый приложению, выполняемому на некотором сетевом хосте, для связи с приложениями, выполняемыми на других сетевых хостах.

Некоторые особо известные порты:

80 — http

20, 21 – ftp

22 — ssh

23 – telnet

25 — smtp

[Лайфхак] Можно посмотреть, открыт ли порт на оборудовании следующим образом:

Коннектимся на оборудование по telnet по проверяемому порту. Если можно нажать Enter и при этом курсор перескакивает на следующую строку, значит порт открыт.

Windows telnet-клиент включается из «программы и компоненты»->«Включение или отключение компонентов Windows».

SSH — Secure Shell. Это протокол по которому осуществляется защищенный удаленный доступ. Плюсы в том, что весь трафик шифруется. Логиниться по ssh можно как используя логин-пароль, так и пару открытый-закрытый ключ.

Изменить в конфигурации ssh-сервера порт не помешает, так как про стандартный все в курсе, и злобные хакеры нехорошие автосканеры портов найдут открытый 22 порт, сделают вам DdoS атаку и подвесят ваш сервер, что вызовет печаль.

Лирической отступление. Схемы удаленного доступа чаще всего клиент-серверные. В этом случае сервер стоит там, КУДА мы подключаемся, а клиент – там, ОТКУДА идет подключение. То есть, у сисадмина стоит клиент, а на другой стороне сервер (даже если другая сторона является компьютером пользователя).

1.1) Команды, выполняемые на удаленном устройстве. В Windows, в виду отсутствия ssh, для многих команд (как обычных, так и powershell) можно указать имя или IP компьютера, на котором они должны выполниться.

2) Доступ к удаленному рабочему столу. Здесь я подразумеваю доступ с ПК/сервера на ПК/Сервер, где на обоих сторонах есть графический интерфейс. Вы просто работаете на чужом рабочем столе как на своем.

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

Также часто используются сторонние решения, вроде VNC, radmin, team viewer, ammyy admin и других. Удобны тем, что пользователь видит ваши действия, которые вы выполняете у него на ПК. Многие решения имеют версию под разные платформы, в том числе мобильные. Большинство умеет работать за NAT. Однако в организациях, где следят за безопасностью, обычно запрещены как минимум «бесплатные» варианты таких программ. Например, вот поэтому.

3) «Низкоуровневый» доступ к серверам. ILO в серверах HP, IPMI в серверах DEPO (и вообще, там, где материнки supermicro), может кто дополнит в комментариях по решениям. Это фактически доступ к серверной платформе. Может осуществляться как из браузера, так и из специального клиента. Предоставляет доступ к серверам до загрузки ОС (можно зайти в BIOS, можно в конфигурилку RAID, можно подключить ISO-образ и накатить ось, можно даже перепрошить BIOS удаленно), а также ограниченный доступ к управлению железками (сделать power off/on, поправить скорость кулеров, посмотреть температуру). Очень-очень удобно. Прощай дежурства в офисе вечером, всё можно сделать из дома. Не надо мерзнуть в серверной, если что сломалось – всё можно сделать с рабочего места. Для всего этого достаточно назначить IP, маску и шлюз на интерфейс IPMI/ILO, это делается из BIOS.

В заключение: хотелось больше рассказать про shell, привести примеры подключений, расписать подробнее про RDP, но поняла, что получится а) много и б) не нужно для общего ознакомления, потому безжалостно удалила лишнее.

P.S.: баянометр люто ругался на скрин консольки, но ничего похожего по содержанию не нашла.

Давно. Зима. Филиал только переехал. Директор филиала: "да зачем нам кондиционер в серверную, у нас тут отличная центральная вентиляция". И правда, зачем? Где ещё так согреешься с мороза..

Продолжение IP over Ethernet.  Часть 1.

Итак об локальных сетях.

Цифровая передача данных как полезная штука начала широко входить в жизнь простого бюргера в 80х годах XX века. Появились телетексты, минители, а с ISDN и разные пользовательские терминалы, объявления, службы такси, прогнозы погоды и т. д. и т. п. Это не считая RS-232 с модемами. Некоторой части общественности стали доступны локальные сети на работе, а некоторые даже занимались промышленной автоматизацией, используя какие-нибудь MODBUS/RS-485 или CAN.

Сети были относительно молодыми и нужны были для разного. К RS-485, например, подключались какие-нибудь промышленные контроллеры, передававшие телеметрию из какого-нибудь большого адронного гудронного коллайдера в недрах какой-нибудь ТЭЦ районной котельной, где не нужны были эти ваши мегабиты, а пары килобит хватало за глаза, да и доморощенных кулхацкеров на таких предприятиях обычно быстро выкидывали на мороз.

В офисах и на заводах жили arcnet, ethernet и token-ring. Причем где надо было качественно передавать данные - преимущественно аркнет и токенринг, а где надо было дешево и быстро - преимущественно эзернет. Собственно вот это главное.

А дальше будет не менее главное второстепенное.

RS-485, arcnet, ethernet и token-ring - сети с множественным доступом (каждый участник может передавать каждому) на то время использовавшие общую разделяемую физическую среду передачи (за исключением токенринга, где все несколько сложнее/проще). Одной из существенных проблем, которую обязательно нужно решить в такой схеме - необходимость передачи информации в сети от только одного участника в каждый момент времени при молчании всех остальных. Если передавать одновременно будут несколько устройств, в сети произойдет смешение сигналов с последующей потерей данных. Решить эту проблему технически можно разными способами. Один из самых простых вариантов в MODBUS поверх RS-485 - master-slave модель, при таком варианте одно устройство в сети назначается ведущим, а остальные ведомыми, ведущее устройство опрашивает ведомые по очереди, после запроса у ведомых есть определенное время на ответ в течение которого ведущее устройство молчит и ждет, не отправляя новых запросов.

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

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

И тем не меннее вокруг нас один сплошной эзернет, а остальные почили, ну RS-485 нет, но он и не ЛВС, а промышленная сеть, а вот новых arcnet и token-ring нам скорее всего уже не увидеть.

Итак сначала об топологиях ЛВС на то время:

Эзернет - шина, токенринг - кольцевая шина, нет кольцо,нет даже сложно точно сформулировать, скорее точка-точка-кольцо или точка1->точка2->точка3->точка1, кольцевые бусы?, аркнет смешанная шина/звезда, сеть-мечта с практически произвольной топологией. В эзернет и аркнет для создания физической среды передачи применялся коаксиальный кабель, в токенринге неэкранированная витая пара.

Что было хорошего у аркнет - отсутствие коллизий, почти произвольная топология, передача данных в общей среде передачи всем участникам одновременно, у токенринга - отсутствие коллизий, 4 мбит/с против 2.5 мбит/с у аркнет, международный стандарт, у эзернет - 2 и 10 мбит/с, международный стандарт. В отличии от сетей с маркерным доступом, где очевидно были ограничения на размерность сетевого адреса и соответственно на количество устройств в сети, в эзернет довольно быстро появились 48-битные уникальные MAC адреса с механизмом их получения для производителей устройств, что позволяло теоретически запилить сеть с сотнями или тысячами устройств.

Дальше произошло несколько событий, определивших текущее положение вещей.

Сначала у эзернет появилась звездчатая топология с концентраторами/хабами (hub) внутри (как у аркнет), использующая витую пару (как у токенринг). И это произвело революционные изменения в дальнейшем. После появления сетей с хабами оказалось возможным коренным образом изменить все, заменив хаб на новое устройство, которое незамедлительно появилось. Называлось оно коммутатор или switch (свич) и представляло собой специализированный сетевой компьютер, обрабатывающий пакеты данных как пакеты, а не как электрические сигналы. Появление свичей сделало эзернет совершенно отличным от других ЛВС технологий, управление сетью стало более простым, надежность и скорость работы сети значительно увеличились, увеличилась качественно и сетевая безопасность. Доступ к среде передачи стал почти детерминированным как у конкурентов, коллизии практически ушли в прошлое. Цифровая обработка пакетов сразу предоставила громадные возможности для фантазии и творчества разработчикам программного обеспечения для сетевых устройств на десятилетия вперед.

Токенринг и аркнет создали новые высокоскоростные протоколы, но на подножку уходящего перрона запрыгивать было уже поздно...

Мутация из хабов в коммутаторы стала первой из череды особо значимых революций эзернета, во многом предопределив более 25 лет назад, то что происходит сегодня.

Продолжение следует...