По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегментная маршрутизация (Segment Routing, SR) может или не может считаться туннельным решением, в зависимости от конкретной реализации и того, насколько строго вы хотите придерживаться определения туннелей, представленного ранее в статье "Виртуализация сетей". В этой статье будет рассмотрена основная концепция сегментной маршрутизации и две возможные схемы реализации: одна с использованием меток потока IPv6, а другая с использованием меток многопротокольной коммутации по меткам (Multiprotocol Label Switching -MPLS).
Каждому устройству в сети с поддержкой SR присваивается уникальная метка. Стек меток, описывающий путь в терминах этих уникальных меток, может быть присоединен к любому пакету, заставляя его принимать определенный указанный путь. Рисунок 5 демонстрирует это.
Каждый маршрутизатор на рисунке 5 объявляет IP-адрес в качестве идентификатора вместе с меткой, прикрепленной к этому IP-адресу. В SR метка, прикрепленная к идентификатору маршрутизатора, называется идентификатором сегмента узла (SID узла). Поскольку каждому маршрутизатору в сети присваивается уникальная метка, путь через сеть может быть описан с использованием только этих меток. Например:
Если вы хотите перенаправить трафик от A к K по пути [B, E, F, H], вы можете описать этот путь с помощью меток [101,104,105,107].
Если вы хотите перенаправить трафик от A к K по пути [B, D, G, H], вы можете описать этот путь с помощью меток [101,103,106,107].
Набор меток, используемых для описания пути, называется стеком меток. Между D и H есть две связи; как это можно описать? В SR доступно несколько опций, в том числе:
Стек меток может включать в себя только идентификаторы SID узла, описывающие путь через сеть в терминах маршрутизаторов, как показано ранее. В этом случае, если бы стек меток включал пару [103,107], D просто перенаправлял бы H в обычном режиме на основе информации локальной маршрутизации, поэтому он будет использовать любой локальный процесс, который он будет использовать для пересылки любого другого пакета, например, распределение нагрузки между двумя каналами для пересылки трафика с меткой SR.
Стек меток может включать явную метку для загрузки общего ресурса по любому доступному набору путей, доступных в этой точке сети.
H может назначить метку для каждого входящего интерфейса, а также SID узла, привязанный к его локальному идентификатору маршрутизатора. Эти метки будут объявляться так же, как SID узла, но, поскольку они описывают смежность, они называются SID смежности (adjacency). SID смежности уникален локально; он уникален для маршрутизатора, объявляющего сам SID смежности.
Третий вид SID, префиксный SID, описывает конкретный достижимый пункт назначения (префикс) в сети. SID узла может быть реализован как SID префикса, привязанный к loopback адресу на каждом маршрутизаторе в сети.
Не обязательно, чтобы весь путь описывался стеком меток. Например, стек меток [101,103] будет направлять трафик в B, затем в D, но затем позволит D использовать любой доступный путь для достижения IP-адреса назначения в K. Стек меток [105] обеспечит прохождение трафика через сеть к K будет проходить через F. Не имеет значения, как трафик достиг этой точки в сети и как он был перенаправлен после того, как достигнет F, если он проходит через F, будучи направленным к K.
Каждая метка в стеке представляет собой сегмент. Пакеты переносятся от метки к метке через каждый сегмент в сети, чтобы быть транспортированными от головной части пути к хвостовой части пути.
Маршрутизация сегментов с многопротокольной коммутацией меток
MPLS был изобретен как способ сочетать преимущества асинхронного режима передачи (ATM), который больше не используется широко, с IP-коммутацией. В первые дни сетевой инженерии наборы микросхем, используемые для коммутации пакетов, были более ограничены в своих возможностях, чем сейчас. Многие из используемых наборов микросхем были Field Programmable Gate Arrays (FPGA), а не Application-Specific Integrated Circuits (ASIC), поэтому длина поля, в котором коммутировался пакет, напрямую коррелировала со скоростью, с которой пакет мог коммутироваться. Часто было проще переработать пакет или обработать его дважды, чем включать в заголовок много сложной информации, чтобы пакет можно было обработать один раз.
Примечание: повторное использование пакетов по-прежнему часто используется во многих наборах микросхем для поддержки внутренних и внешних заголовков или даже для обработки различных частей более длинного и сложного заголовка пакета.
MPLS инкапсулирует исходный пакет в заголовок MPLS, который затем используется для коммутации пакета по сети. На рисунке 6 показан заголовок MPLS. Весь заголовок состоит из 32 бит, метка 20 бит. Устройство пересылки MPLS может выполнять три операции:
Текущая метка в заголовке MPLS может быть заменена другой меткой (SWAP).
В пакет можно вставить новую метку (PUSH).
Текущая метка может быть очищена, а метка под текущей меткой обработана (POP).
Операции PUSH и POP переносятся непосредственно в SR: операция SWAP реализована в SR как CONTINUE, что означает, что текущая метка заменяется той же меткой (т. е. заголовок с меткой 100 будет заменен меткой 100), и обработка этого текущего сегмента будет продолжена. Проще всего понять процесс обработки на примере. Рисунок 7 демонстрирует это.
На рисунке 7 каждому маршрутизатору присвоена глобально уникальная метка из глобального блока сегментной маршрутизации (Segment Routing Global Block -SRGB). Они объявляются через протокол маршрутизации или другую плоскость управления. Когда A получает пакет, предназначенный для N, он выбирает путь через сеть, используя некоторый локальный механизм. В этот момент:
Чтобы начать процесс, A выполнит PUSH серии заголовков MPLS на пакете, которые описывают путь через сеть, [101,103,104,202,105,106,109, 110]. Когда A коммутирует пакет в сторону B, он вставит первую метку в стек, так как нет необходимости отправлять свою собственную метку в заголовке. Стек меток на канале [A,B] будет равен [103,104,202,105,106,109,110].
Когда B получает пакет, он проверяет следующую метку в стеке. Обнаружив, что метка равна 103, он выполнит POP этой метки и перешлет пакет в D. В этом случае стек меток SR выбрал один из двух возможных путей с равной стоимостью через сеть, так что это пример выбора SR конкретного пути. Стек меток на канале [B, D] будет [104,202,105,106,109,110].
Когда D получает пакет, верхняя метка в стеке будет 104. D выполнит POP этой метки и отправит пакет в E. Стек меток на канале [D, E] будет [202,105,106,109,110].
Когда E получает этот пакет, верхняя метка в стеке - 202. Это селектор смежности, поэтому он выбирает конкретный интерфейс, а не конкретного соседа. E выберет правильный интерфейс, нижний из двух интерфейсов на рисунке, и POP этой метки. Верхняя метка теперь представляет собой SID узла для F, который можно удалить, поскольку пакет передается на F. E переработает пакет и также откроет эту POP. Стек меток на канале [E, F] будет [106,109,110].
Когда пакет достигает F, следующей меткой в стеке будет 106. Эта метка указывает, что пакет должен быть передан в G. F выполнит POP метки и передаст ее G. Стек меток на канале [F, G] будет [109,110].
Когда пакет достигает G, следующая метка в стеке - 109, что указывает на то, что пакет должен быть направлен к L. Поскольку G не соединен напрямую с L, он может использовать локальный, свободный от петель (обычно самый короткий) путь к L. В этом случае есть два пути с равной стоимостью к L, поэтому G выполнит POP метки 109 и переадресовывает по одному из этих двух путей к L. В сегменте [G, L] стек меток равен [110].
Предположим, что G решает отправить пакет через K. Когда K получает пакет, он будет иметь стек меток, содержащий [110], который не является ни локальной меткой, ни смежным узлом. В этом случае метка должна оставаться прежней, или сегмент должен иметь CONTINUE. Чтобы реализовать это, K поменяет текущую метку 110 на другую копию той же метки, так что K будет пересылать трафик с той же меткой. На канале [K,L] стек меток будет равен [110].
Когда L принимает пакет, единственной оставшейся меткой будет 110, что указывает на то, что пакет должен быть направлен в M. L будет выполнена POP метки 109, эффективно удалив всю инкапсуляцию MPLS, и перенаправит пакет в M.
Когда M получает пакет, он пересылает его, используя обычный IP-адрес, в конечный пункт назначения - N.
Концепция стека меток в MPLS реализована в виде серии заголовков MPLS, уложенных друг на друга. Pop метки означает удаление самой верхней метки, push метки означает добавление нового заголовка MPLS в пакет, а continue означает замену метки идентичной меткой. Когда вы работаете со стопкой меток, понятия внутреннего и внешнего часто сбивают с толку, особенно, поскольку многие люди используют идею метки и заголовка как взаимозаменяемые. Возможно, лучший способ уменьшить путаницу - использовать термин "заголовок" для обозначения всего стека меток и исходного заголовка, переносимого внутри MPLS, при этом обращаясь к меткам как к отдельным меткам в стеке. Тогда внутренний заголовок будет исходным заголовком пакета, а внешний заголовок будет стеком меток. Внутренняя метка будет следующей меткой в стеке в любой момент прохождения пакета по сети, а внешняя метка будет меткой, по которой пакет фактически переключается.
Хотя в приведенном здесь примере используются IP-пакеты внутри MPLS, протокол MPLS предназначен для передачи практически любого протокола, включая Ethernet. Таким образом, SR MPLS не ограничивается использованием для передачи одного типа трафика, но может также использоваться для передачи кадров Ethernet по сети на основе IP / MPLS. Это означает, что SR можно использовать для поддержки первого варианта использования, обсуждаемого в этой статье, - предоставления услуг Ethernet по IP-сети.
MPLS - это туннель?
Много написанных и произнесенных слов были пролиты на вопрос о том, является ли MPLS протоколом туннелирования. Здесь туннелирование определяется как действие, а не протокол; это намеренная попытка отделить идею протокола туннелирования от концепции туннелирования как действия, предпринимаемого при передаче трафика через сеть. В случае MPLS это означает, что он может быть, а может и не быть протоколом туннелирования, в зависимости от того, как он используется - как и любой другой протокол. Например, если у вас есть стек меток, помещенных поверх пакета с IP-заголовком, внешняя метка, на которую коммутируется пакет, не является (технически) туннелем. Этот внешний заголовок в сети MPLS фактически является локальным для сегмента, поэтому он либо выталкивается, либо отправляется на каждом маршрутизаторе. Это аналогично заголовку Ethernet для каждого канала. Однако внутренний заголовок переносится в пакете MPLS и, следовательно, технически туннелируется. Внутренняя метка не используется на текущем устройстве для коммутации пакета; он просто переносится как часть пакета.
Это определение не идеально. Например, в случае MPLS SWAP или SR CONTINUE, используется ли метка для коммутации пакета или нет? Кроме того, в отличие от заголовка Ethernet в пакете, заголовок MPLS фактически используется при принятии решения о пересылке. Заголовок Ethernet, напротив, просто используется для достижения следующего перехода, а затем отбрасывается. Возможно, более подходящим сравнением было бы следующее: Заголовок MPLS подобен заголовку Ethernet, который используется для достижения перехода за пределы устройства, на которое маршрутизатор в настоящее время передает.
Независимо от этих ограничений, этого определения обычно достаточно, чтобы мысленно управлять различием между туннелированием и не туннелированием в MPLS, а также в большинстве других протоколов.
Основной причиной серьезных атак является предоставление доступа к таким активам, которые не должен быть открыты для всех.
Одной из цифровых инфраструктур, где часто встречаются проблемы с безопасностью является Kubernetes. "Облачное" программное обеспечение, развернутое на устаревших центрах обработки данных, требует от конечных пользователей и администраторов своевременного обнаружения и устранения некорректных настроек, в виде предоставление привилегий высокого уровня программам и людям, которым они вовсе не нужны.
IBM Study пришла к выводу, что в 95% случаям нарушения безопасности, которые они исследовали, содействовали или были вызваны человеческими ошибками, в том числе и разработчиками программного обеспечения. Остальные же были, главным образом, из-за технической оплошности.
В последующих исследованиях, касающихся нарушений безопасности, также приводились аналогичные выводы с цифровыми инструментами всех видов.
В Kubernetes привилегии часто предоставляются с помощью ролевых средств управления доступом. Он может ошибочно разрешить административные разрешения для всего кластера, даже если это не требуется. Тот факт, что Kubernetes может включать крупномасштабные и автоматизированные разрешения на инфраструктуру, также создает почву для атаки на контейнеры, приложения и злоупотребления разрешениями.
Проблемы также включают множество встроенных функций безопасности, но не все они включены в инструменте по умолчанию. Поскольку Kubernetes способствует быстрому развертыванию и разработке приложений, управление может помешать быстрому развертыванию инфраструктуры.
После окончательного развертывания приложений, делая их доступными для пользователей, неверно сделанные конфигурации безопасности увеличивают возможные риски.
Стратегии безопасности для облачных инструментов
Для защиты облачных средств с помощью контейнеров необходима другая стратегия, отличная от стратегии, используемой для устаревших инфраструктурных систем. С ростом внедрения облачных инструментов существуют два подхода к обеспечению безопасности, главным образом, Kubernetes-ориентированный и контейнерный.
В ориентированном на контейнеры подходе к обеспечению безопасности основное внимание уделяется обеспечению безопасности среды выполнения контейнеров и образов. Для управления связью между контейнерами используются такие методы управления, как shim специально написанный интерфейс и встроенные прокси-серверы.
С другой стороны, подход, ориентированный на Kubernetes, использует встроенную масштабируемость и гибкость Kubernetes. Она работает на уровнях Kubernetes и продвигает свои принудительные политики. Следовательно, вы должны позволить ему контролировать как вашу инфраструктуру, так и безопасность.
Что делает встроенное средство безопасности Kubernetes?
Характеристики, которые делают средство безопасности Kubernetes-ориентированным или Kubernetes-native, представляют собой сочетание того, что они выполняют и как. Во-первых, необходимо интегрировать инфраструктуру и рабочие нагрузки с API Kubernetes и оценить уязвимости.
Убедитесь, что функции безопасности основаны на ресурсах Kubernetes, включая службы, развертывания, модули и пространства имен. Также необходимо использовать встроенные функции безопасности Kubernetes. Такая глубокая интеграция охватывает все аспекты среды Kubernetes, включая управление уязвимостями, управление конфигурацией, сегментацию сети, реагирование на инциденты, соответствие нормативным требованиям и обнаружение угроз.
Почему инструменты, ориентированные на Kubernetes, превосходят контейнеры?
Платформы безопасности, ориентированные на Kubernetes, считаются превосходными, если вы работаете с контейнерами. Причину можно сформулировать тремя способами.
Во-первых, они обеспечивают лучшую защиту с помощью богатого понимания принципов работы контейнеров и самого Kubernetes. Они также используют декларативные данные для контекстуализации рисков и информирования о них.
Во-вторых, платформы безопасности Kubernetes обеспечивают повышенную операционную эффективность, что позволяет быстро обнаруживать угрозы, а также оценивать риски на приоритетном уровне. Он позволяет всем членам вашей команды находиться на одной странице для устранения неполадок и более быстрой работы.
В-третьих, ваш операционный риск может быть снижен с помощью встроенных средств управления Kubernetes, облегчающих масштабируемость и адаптируемость. Кроме того, между оркестратором и внешними элементами управления не может возникнуть никакого конфликта.
Таким образом, собственные возможности Kubernetes в области безопасности могут лучше защитить контейнерные экосистемы. Если вашим специалистам по безопасности инфраструктуры и DevOps удается использовать весь потенциал этих инструментов, вы можете продолжать обнаруживать угрозы и останавливать их, когда у вас есть время.
Современные IP сети должны обеспечивать надежную передачу пакетов сети VoIP и других важных служб. Эти сервисы должны обеспечивать безопасную передачу, определенную долю предсказуемости поведения трафика на ключевых узлах и конечно гарантированный уровень доставки пакетов. Сетевые администраторы и инженеры обеспечивают гарантированную доставку пакетов путем изменения параметров задержки, джиттера, резервирования полосы пропускания и контроля за потерей пакетов с помощью Quality Of Service (QoS).
Современные сети конвергентны. Это означает, что приходящей трафик в корпоративный сегмент сети, будь то VoIP, пакеты видеоконференцсвязи или обычный e-mail приходят по одному каналу передачу от Wide Area Network (WAN) . Каждый из указанных типов имеет свои собственные требования к передаче, например, для электронной почты задержка 700 мс некритична, но задержка 700 мс при обмене RTP пакетами телефонного разговора уже недопустима. Для этого и создаются механизмы QoS [описаны в рекомендации Y.1541]. Рассмотрим главные проблемы в корпоративных сетях:
Размер полосы пропускания: Большие графические файлы, мультимедиа, растущее количество голосового и видео трафика создает определенные проблемы для сети передачи;
Задержка пакетов (фиксированная и джиттер): Задержка – это время, которое проходит от момента передачи пакета до момента получения. Зачастую, такая задержка называется «end-to-end», что означает точка – точка. Она бывает двух типов:
Фиксированная задержка: Данные вид задержки имеет так же два подтипа: задержка сериализации и распространения. Сериализация - это время затрачиваемое оборудованием на перемещение бит информации в канал передачи. Чем шире пропускная способность канала передачи, тем меньше время тратится на сериализацию. Задержка распространения это время, требуемое для передачи одного бита информации на другой конец канала передачи;
Переменная сетевая задержка: Задержка пакета в очереди относится к категории переменной задержки. В частности, время, которое пакет проводит в буфере интерфейса, зависит от загрузки сети и относится так же к переменной сетевой задержке;
Изменение задержки (джиттер): Джиттер это дельта, а именно, разница между задержками двух пакетов;
Потеря пакетов: Потеря пакетов, как правило, вызывается превышением лимита пропускной способности, в результате чего теряются пакеты и происходят неудобства в процессе телефонного разговора.
Размер полосы пропускания
Рисунок иллюстрирует сети с четырьмя «хопами» - промежуточными узлами на пути следования пакета между сервером и клиентом. Каждый «хоп» соединен между собой своим типом среды передачи в разной пропускной способностью. В данном случае, максимальная доступная полоса для передачи равна полосе пропускания самого «узкого» места, то есть с самой низкой пропускной способностью.
Расчет доступной пропускной способности - это неотъемлемая часть настройки QoS, которая является процессом, осложненным наличием множества потоков трафика проходящего через сеть передачи данных и их необходимо учесть. Расчет доступной полосы пропускания происходит приблизительно по следующей формуле:
A=Bmax/F
где A – доступная полоса пропускания, Bmax – максимальная полоса пропускания, а F – количество потоков. Наиболее правильным методом при расчете пропускной способности является расчет с запасом в 10-20% от расчетной величины. Однако, увеличение пропускной способности вызывает удорожание всей сети и занимает много времени на осуществление. Но современные механизмы QoS могут быть использованы для эффективного и оптимального увеличения доступной пропускной способности для приоритетных приложений.
С помощью метода классификации трафика, алгоритм QoS может отдавать приоритет вызову в зависимости от важности, будь то голос или критически важные для бизнеса приложения. Алгоритмы QoS подразумевают предоставление эффективной полосы пропускания согласно требованиям подобных приложений; голосовой трафик должен получать приоритет отправки. Перечислим механизмы Cisco IOS для обеспечения необходимой полосы пропускания:
Priority queuing (приоритетная очередь или - PQ) или Custom queuing (пользовательская или настраиваемая очередь - CQ);
Modified deficit round robin - MDRR - Модифицированный циклический алгоритм с дополнительной очередью (маршрутизаторы Cisco 1200 серии);
Распределенный тип обслуживания, или Type Of Service (ToS) и алгоритм взвешенных очередей (WFQ) (маршрутизаторы Cisco 7x00 серии);
Class-Based Weighted Fair Queuing (CBWFQ) или алгоритм очередей, базирующийся на классах;
Low latency queuing (LLQ) или очередь с малой задержкой. Оптимизация использования канала путем компрессии поля полезной нагрузки «фреймов» увеличивает пропускную способность канала. С другой стороны, компрессия может увеличить задержку по причине сложности алгоритмов сжатия. Методы Stacker (укладчик) и Predictor (предсказатель) - это два алгоритма сжатия, которые используются в Cisco IOS.
Другой алгоритм эффективного использования канала передачи это компрессия заголовков. Сжатие заголовков особенно эффективно в тех сетях, где большинство пакетов имеют маленькое количество информационной нагрузки. Другими словами, если отношение вида (Полезная нагрузка)/(Размер заголовка) мало, то сжатие заголовков будет очень эффективно. Типичным примером компрессии заголовков может стать сжатие TCP и Real-time Transport Protocol (RTP) заголовков.
Задержка пакетов из конца в конец и джиттер
Рисунок ниже иллюстрирует воздействие сети передачи на такие параметры как задержка пакетов проходящих из одной части сетевого сегмента в другой. Кроме того, если задержка между пакетом с номером i и i + 1 есть величина, не равная нулю, то в добавок к задержке "end-to-end" возникает джиттер. Потеря пакетов в сети при передаче трафика происходит не по причине наличия джиттера, но важно понимать, что его высокое значение может привести к пробелам в телефонном разговоре. Каждый из узлов в сети вносит свою роль в общую задержку:
Задержка распространения (propagation delay) появляется в результате ограничения скорости распространения фотонов или электронов в среде передачи (волоконно-оптический кабель или медная витая пара);
Задержка сериализации (serialization delay) это время, которое необходимо интерфейсу чтобы переместить биты информации в канал передачи. Это фиксированное значение, которое является функцией от скорости интерфейса;
Задержка обработки и очереди в рамках маршрутизатора.
Рассмотрим пример, в котором маршрутизаторы корпоративной сети находятся в Иркутске и Москве, и каждый подключен через WAN каналом передачи 128 кбит/с. Расстояние между городами около 5000 км, что означает, что задержка распространения сигнала по оптическому волокну составит примерно 40 мс. Заказчик отправляет голосовой фрейм размером 66 байт (528 бит). Отправка данного фрейма займет фиксированное время на сериализацию, равное:
tзс = 528/128000=0,004125с=4.125 мс.
Также, необходимо прибавить 40 мс на распространение сигнала. Тогда суммарное время задержки составит 44.125 мс. Исходя из рисунка расчет задержки будет происходить следующим способом:
D1+Q1+D2+Q2+D3+Q3+D4
Если канал передачи будет заменен на поток Е1, в таком случае, мы получим задержку серилизации, равную:
tзс=528/2048000=0,00025781с=0,258 мс
В этом случае, общая задержка передачи будет равнять 40,258 мс.