По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всякий раз, когда мы отправляем данные из одного узла в другой в компьютерной сети, данные инкапсулируются на стороне отправителя, а деинкапсулируются на стороне получателя. В этой статье мы узнаем, что такое инкапсуляция. Мы также подробно изучим процесс инкапсуляции и деинкапсуляции в моделях OSI и TCP/IP.
Инкапсуляция данных
Инкапсуляция данных - это процесс, в котором некоторая дополнительная информация добавляется к элементу данных, чтобы добавить к нему некоторые функции. В нашей сети мы используем модель OSI или TCP/IP, и в этих моделях передача данных происходит через различные уровни. Инкапсуляция данных добавляет к данным информацию протокола, чтобы передача данных могла происходить надлежащим образом. Эта информация может быть добавлена в заголовок (header) или в конец (footer или trailer) данных.
Данные инкапсулируются на стороне отправителя, начиная с уровня приложения и заканчивая физическим уровнем. Каждый уровень берет инкапсулированные данные из предыдущего слоя и добавляет некоторую дополнительную информацию для их инкапсуляции и некоторые другие функции с данными. Эти функции могут включать в себя последовательность данных, контроль и обнаружение ошибок, управление потоком, контроль перегрузки, информацию о маршрутизации и так далее.
Деинкапсуляция данных
Деинкапсуляция данных - это процесс, обратный инкапсуляции данных. Инкапсулированная информация удаляется из полученных данных для получения исходных данных. Этот процесс происходит на стороне получателя. Данные деинкапсулируются на том же уровне на стороне получателя, что и инкапсулированный уровень на стороне отправителя. Добавленная информация заголовка и футера удаляется из данных в этом процессе.
На рисунке показано, как футер и хедер добавляются и удаляются из данных в процессе инкапсуляции и деинкапсуляции соответственно.
Данные инкапсулируются на каждом уровне на стороне отправителя, а также деинкапсулируются на том же уровне на стороне получателя модели OSI или TCP/IP.
Процесс инкапсуляции (на стороне отправителя)
Шаг 1. Уровень приложения, представления и сеанса в модели OSI принимает пользовательские данные в виде потоков данных, инкапсулирует их и пересылает данные на транспортный уровень. Тут не обязательно добавится к данным какой-либо хедер или футер - это зависит от приложения.
Шаг 2. Транспортный уровень берет поток данных с верхних уровней и разделяет его на несколько частей. Транспортный уровень инкапсулирует данные, добавляя соответствующий заголовок к каждой части. Эти фрагменты данных теперь называются сегментами данных. Заголовок содержит информацию о последовательности, так что сегменты данных могут быть повторно собраны на стороне получателя.
Шаг 3. Сетевой уровень берет сегменты данных с транспортного уровня и инкапсулирует их, добавляя дополнительный заголовок к сегменту данных. Этот заголовок данных содержит всю информацию о маршрутизации для правильной доставки данных. Здесь инкапсулированные данные называются пакетом данных или дейтаграммой.
Шаг 4: Канальный уровень берет пакет данных или дейтаграмму с сетевого уровня и инкапсулирует ее, добавляя дополнительный заголовок и нижний футер. Заголовок содержит всю информацию о коммутации для правильной доставки данных соответствующим аппаратным компонентам, а футер содержит всю информацию, связанную с обнаружением ошибок и контролем. Здесь инкапсулированные данные называются фреймом данных.
Шаг 5: Физический уровень берет кадры данных с уровня канала передачи данных и инкапсулирует их, преобразовывая их в соответствующие сигналы данных или биты, соответствующие физической среде.
Процесс деинкапсуляции (на стороне получателя)
Шаг 1: Физический уровень принимает инкапсулированные сигналы данных или биты от отправителя и деинкапсулирует их в форме кадра данных, который будет перенаправлен на верхний уровень, то есть на канальный уровень.
Шаг 2: Канальный уровень берет кадры данных с физического уровня. Он деинкапсулирует фреймы данных и проверяет заголовок фрейма, скоммутирован ли фрейм данных на правильное оборудование или нет. Если кадр пришел в неправильное место назначения, он отбрасывается, иначе он проверяет информацию в футере. Если есть какая-либо ошибка в данных, запрашивается повторная передача данных, если нет, то они деинкапсулируются, и пакет данных пересылается на верхний уровень.
Шаг 3. Сетевой уровень принимает пакет данных или дейтаграмму из канального уровня. Он деинкапсулирует пакеты данных и проверяет заголовок пакета, направлен ли пакет в правильное место назначения или нет. Если пакет направляется в неправильный пункт назначения, пакет отбрасывается, если все ок, то он деинкапсулируется, и сегмент данных пересылается на верхний уровень.
Шаг 4: Транспортный уровень берет сегменты данных с сетевого уровня и деинкапсулирует их. Сначала он проверяет заголовок сегмента, а затем повторно собирает сегменты данных для формирования потоков данных, а затем эти потоки данных пересылаются на верхние уровни.
Шаг 5: Уровень приложения, представления и сеанса в модели OSI берет инкапсулированные данные с транспортного уровня, деинкапсулирует их, и данные, относящиеся к конкретному приложению, пересылаются в приложения.
В данной статье мы рассмотрим стандартный демон логирования syslog. Он немного устарел, но с ним разобраться стоит потому, что все современные системы логирования построены по такому же принципу и имеют лишь небольшие отличия и небольшие улучшения, немного расширенный функционал.
Система логирования в любой операционной системе играет важнейшую роль. Это связано с тем, что с помощью нее осуществляется разбор ошибок, поиск неисправностей и восстановление работоспособности сервисов. Очень часто бывает так что операционная система или сервисы ведут себя не так, как мы ожидаем от них и лучший способ разобраться с проблемой заглянуть в журнал логирования.
Мы разберем, как настраивается стандартный демон syslog, понятия источников событий и приоритета событий. В операционной системе Windows тоже есть данный функционал, но развит не так хорошо, как в операционных системах Linux.
Итак, стандарт конфигурации событий выглядит следующим образом:
Мы пишем для каждого источника события, источник, приоритет и куда такие события отправлять, т.е действие. Формат:
источник.приоритет назначение
Источников в операционной системе Linux может быть много, более 20 штук. Самые популярные представлены на картинке.
В операционной системе Windows, есть 3 уровня приоритетов - информационные, предупреждения и ошибка. У операционной системы Linux приоритетов 8 штук, разберем их:
Emergency – чрезвычайная ситуация
Alert – тревога
Critical – критическое событие
Error – ошибка
Warning – предупреждение
Notice – замечание
Info – информационное сообщение
Debug – отладочное событие
И последняя колонка на картинке – это примеры куда мы можем записывать те или иные события:
Файл – мы можем записывать в журнал
Консоль – мы можем выводить в консоль
Конвейер – мы можем передавать с помощью конвейера сразу следующей команде
Удаленная система – можем передавать удаленной системе
Группа пользователей – можем передавать группе пользователей
К сожалению, открыть файл cat /etc/syslog.conf (CentOS 5) не получится, т.к является устаревшим, но подходит для объяснения принципа настройки. Например современный rsyslog, настраивается практически идентично в разных системах, находится в разных местах на виртуальной машине, в Ubuntu 20.04 расположен в /etc/rsyslog.d/ 50-default.conf
Примерно таким образом выглядит конфигурационный файл. В данном файле все настройки демона. Мы можем увидеть, что все события ядра kern.* выводятся в файл /var/log/kern.log. Символ * говорит о том, что события с любым приоритетом. Мы можем изменить указав явно приоритет например kern.info или kern.debug, можем так же изменить куда выводить например в консоль /dev/console.
У нас в файле есть строчка закомментированная *.info; *.=notice;*.=warn; - отправлять в /var/log/messages, и если мы ее раскомментируем, то данные все события будут уходить в указанный файл.
Есть строчка auth,authpriv.* /var/log/auth.log, которая означает, что все события авторизации, в том числе и с вводом паролей будут записываться в отдельный файл /var/log/auth.log, это сделано специально, в целях информационной безопасности. На отдельный файл проще поставить особые права доступа.
Есть в файле еще интересная строчка mail.* -/var/log/mail.log, которая говорит нам о том, что все почтовые события будут записываться в журнал /var/log/mail.log.
Обратите внимание, что некоторые файлы имеет значок - перед указанием пути. Этот символ указывает демону на то, что после использования данного журнала, не нужно выгружать из оперативной памяти. Это сделано для того, чтобы более оперативно работать с журналами и в оперативной памяти всегда есть кэш данного файла. Есть и минус такого подхода. Если у нас случится паника ядра, т.е аппаратная ошибка и система вылетит, то те события, которые находились в оперативке, не успеют сбросится на жесткий диск и мы их потеряем.
Файлы логов можно читать командой cat, правда не все форматы и не все логи, но популярными являются утилиты less и tail. Причем утилита tail с ключем -f позволяет, читать файл лога в реальном времени. Пользоваться утилитами достаточно просто:
less [опции] [файл_лога]
tail [опции] [файл_лога]
Но работая с данными утилитами не все форматы можно прочитать.
Можно порекомендовать для чтения логов утилиту, которая сможет прочесть практически любой формат лога - lnav. Устанавливается стандартно - apt install lnav -y.
Синтаксис утилиты - lnsv [опции] [файл_лога]
lnav dmesg
Получаем вот такой красивый вывод команды. Дополнительно утилита раскрашивает лог для удобства чтения.
С тех пор, как различные организации и предприятия решили увеличить эффективность своих сотрудников за счет организации полноценных электронных рабочих мест, стали использоваться различные IT-решения для создания виртуальных локальных сетей. Private Virtual Local Area Network, или просто PVLAN, одно из них.
Идея PVLAN
По сути, идея PVLAN проста. Как можно понять по названию, это некая приватная часть локальной сети. Обмен информацией между Host-устройствами, подключение которых организовано через PVLAN, и остальными невозможен. Однако они не полностью изолированы. Внутри приватной сети может быть несколько хостов, и они смогут взаимодействовать, но на определенных условиях.
Конечно, для реализации таких задач можно воспользоваться средствами ACL (Access Control List), в рамках которых можно выбрать любое количество допусков для каждого пользователя относительно того или иного процесса. Но на практике это будет значить большое количество лишних манипуляций. Ведь всегда легче изначально заложить некую особенность в архитектуру сети, чем дополнять ее ситуационными "заплатками".
Как это работает?
Рассмотрим типы портов коммутатора, доступных при использовании PVLAN:
"Promiscuous" - смешанный порт. Коммутатор, организованный таким образом, позволит устройству взаимодействовать с любыми другими внутри PVLAN.
"Isolated" - изолированный порт. При использовании этого типа порт изолируется на 2 уровне (именно Layer 2 имеется в виду, когда мы упоминаем VLAN), от любых других коммутаторов, кроме настроенных с типом promiscuous. Таким образом, именно в рамках этого типа возможна реализация основной идеи PVLAN. Изолированные порты не могут обмениваться трафиком друг с другом, а изолированные и смешанные - могут.
"Community" - порт группы. Отдельная группа портов, host-участники которой могут делить трафик друг с другом и смешанными портами, но не могут с изолированными портами и коммутаторами другой группы.
Чтобы реализовать приватную локальную сеть задействуются 2 VLAN:
Основная (Primary) - эта сеть имеет принадлежность к смешанному порту. В свою очередь, этот порт подключается к устройствам стоящих в иерархии выше (например - маршрутизатор или сервер).
Вторичная (Secondary) - VLAN, в которой производится настройка изолированных и групповых коммутаторов.
Несмотря на то, что в сети можно найти в основном англоязычные материалы по этой теме, освоить ее можно достаточно легко, несколько раз применив на практике. Отличный вариант - пробная настройка PVLAN на маршрутизаторах Nexus и Catalyst от Cisco (при выборе первого стоит убедиться, что его версия старше 3560).
Как эффективно использовать PVLAN?
На сегодняшний день решить проблему защиты данных в VLAN можно при помощи большого количества инструментов (яркий пример - разбивка трафика при помощи QinQ), однако, как и было указано выше, использование приватной подсети, как ничто другое говорит о логичности изначальной архитектуры сети и ее общей продуманности.
Основные задачи, которые можно без лишних хлопот реализовать посредством PVLAN:
Обеспечение защищенного трафика для большого количества пользователей. Отличным примером является организация сети провайдеров, которые оказывают услуги частным лицам. Если VLAN изначально ориентирован на наличие приватного трафика и построен соответственно, то можно избежать потери огромного количества времени, которое обычно уходит на настройку изоляции пользователей вторичными средствами. Конечно, для реализации строгой изоляции понадобится довольно дорогостоящее оборудование, но это уже другой вопрос.
Внесение корректировок в уже отлаженную систему обмена данными. Иногда в больших компаниях, с целью усиления контроля за информационной безопасностью принимаются решения по изоляции потоков трафика, которые не предусмотрены текущей архитектурой сети. Порой IT-специалисты вынуждены работать в настолько узких рамках, что не могут получить согласование на добавление новой отдельной сети. Именно для таких комплексных задач используется видоизменение некоторых частей общей VLAN в приватную. Главным плюсом таких мероприятий является безопасность для уже сложившейся инфраструктуры взаимодействия пользователей.