По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
3-уровневая иерархическая модель Cisco нацелена на построение надежной, масштабируемой и высокопроизводительной сетевой конструкции. Этот высокоэффективный сетевой иерархический подход обеспечивает экономичный, модульный, структурированный и простой метод (обеспечивает несложный и единообразный проект) для удовлетворения существующих и будущих потребностей роста сети. Каждый из уровней имеет свои особенности и функциональность, что еще больше упрощает сети.
Что же заставляет нас переходить к использованию 3-уровневневого иерархического подхода, представлены ниже -
Масштабируемость (Scalability) - эффективно приспосабливается к будущему росту сети;
Простота управления и устранения неполадок - эффективное управление и простота в устранении причины сбоя;
Более простая и структурированная фильтрация и принудительное применение политик - проще создавать фильтры/политики и применять их в сети;
Избыточность и отказоустойчивость - в сети могут происходить сбои/простои устройств, и она должна продолжать предоставлять услуги с той же производительностью, в случае выхода из строя основного устройства;
Высокая производительность - иерархическая архитектура для поддержки высокой пропускной способности и высокой производительности базовой активной инфраструктуры;
Модульность - обеспечивает гибкость в проектировании сети и облегчает простое внедрение и устранение неполадок.
Уровень ядра (внутренний уровень) | Core layer
Этот уровень также называется сетевым магистральным уровнем и отвечает за обеспечение быстрого транспорта между распределительными коммутаторами в пределах кампуса предприятия.
Станциями внутреннего уровня являются коммутаторы высокого класса и высокопроизводительные коммутаторы, имеющие модульный форм-фактор. Это полностью резервные устройства, поддерживающие расширенные функции коммутации уровня 3 и протоколы динамической маршрутизации. Основным здесь является сохранение конфигурации как можно более минимальной на уровне ядра.
Из-за очень высокой критичности этого слоя, проектирование его требует высокого уровня устойчивости для быстрого и плавного восстановления, после любого события сбоя сети в пределах блока ядра.
Ниже приведены основные характеристики внутреннего уровня -
Высокая производительность и сквозная коммутация;
Обеспечение надежности и отказоустойчивости;
Масштабируемый;
Избегание интенсивных манипуляций с пакетами ЦП, вызванных безопасностью, инспекцией, классификацией качества обслуживания (QoS) или другими процессами.
Вот некоторые модели коммутаторов Cisco, работающих на уровне ядра, являются Catalyst серии 9500/6800/6500 и nexus серии 7000.
Распределительный уровень | Distribution layer
Распределительный уровень расположен между уровнями доступа и ядра. Основная функция этого уровня - обеспечить маршрутизацию, фильтрацию и WAN-доступ, а также визуализировать связь между уровнями доступа и ядра. Кроме того, коммутаторы уровня распределения могут предоставлять восходящие службы для многих коммутаторов уровня доступа. Уровень распределения гарантирует, что пакеты маршрутизируются между подсетями и Inter/Intra VLAN в среде кампуса. Как стандартный подход, шлюзы по умолчанию для всех VLAN будут коммутаторами уровня распределения. На самом деле серверные устройства не должны быть напрямую подключены к распределительным коммутаторам. Этот подход обеспечивает экономию затрат на один порт за счет высокой плотности портов при менее дорогостоящих коммутаторах уровня доступа.
Основные функции распределительного уровня перечислены ниже -
Аккумулирование каналов LAN / WAN;
Контроль доступа и фильтрация, такие как ACLs и PBR;
Маршрутизация между локальными сетями и VLAN, а также между доменами маршрутизации;
Избыточность и балансировка нагрузки;
Суммирование подсетей и агрегирование маршрутов на границах / к уровню ядра;
Управление широковещательным доменом. Устройство уровня распределения действует как демаркационная точка между широковещательными доменами.
Основными моделями коммутаторов Cisco, работающих на распределительном уровне, являются Catalyst серии 6800/6500/4500/3850
Уровень доступа | Access layer
Этот уровень включает в себя коммутаторы уровня 2 и точки доступа, обеспечивающие подключение к рабочим станциям и серверам. На восходящих линиях связи устройства уровня доступа подключаются к распределительным коммутаторам. Мы можем управлять контролем доступа и политикой, создавать отдельные коллизионные домены и обеспечивать безопасность портов на уровне доступа. Коммутаторы уровня доступа обеспечивают доставку пакетов на конечные устройства.
Уровень доступа выполняет ряд функций, в том числе:
Коммутация уровня 2;
Высокая доступность;
Безопасность портов;
Классификация и маркировка QoS;
Граница доверия;
Списки контроля доступа (ACL);
Остовное дерево.
Основными моделями коммутаторов Cisco, работающих на уровне доступа, являются Catalyst серии 3850/3750/4500/3560/2960.
МТТ бизнес - виртуальная АТС от компании МТТ. Платформа позволяет обеспечить офис телефонной связью, организовать голосовую почту, маршрутизацию вызовов и прочие параметры. Сегодня мы поговорим о том, как интегрировать облачную ВАТС от МТТ Бизнес и IP – АТС Asterisk по протоколу SIP.
Настройки ЛК МТТ Бизнес
Приступаем к работе. Переходим по адресу https://business.mtt.ru/user/login:
Указываем наш логин и пароль. Входим в интерфейс управления ВАТС и переходим в раздел Настройки → Рабочие места → Создать рабочее место, как показано на скриншоте ниже:
Создаем рабочее место, как показано на скриншоте ниже:
Имя - придумайте имя для вашего пользователя;
Должность/Описание - какое – то описание. Можете написать что-то связанное с Asterisk, для очевидности и прозрачности дальнейшего администрирования;
SIP ID - отмечаем чекбокс, как показано на скриншоте;
Логин - сохраняем и записываем отдельно. Он нам пригодится :)
Пароль на оборудование - можете указать свой пароль, можете сгенерировать автоматически. Сохраните его – им мы тоже воспользуемся;
Кстати, если находитесь в поиске виртуальной АТС, то посмотрите в сторону МТТ Бизнес. Неплохое соотношение цена/качество :)
Попробовать ВАТС от МТТ Бизнес
Продолжаем экскурсию. Настроим маршрутизацию на нашего пользователя. Для этого, переходим в раздел Настройки → Входящая связь. Там, где указан ваш номер телефона, нажмите на зеленый плюсик («+»):
В появившемся окне выбираем На рабочее место:
В разделе настроек Переадресация на рабочее место нажимаем кнопку Выбрать:
Выбираем нашего юзера через чекбокс. В нашем случае мы создали PBXuser, как показали ранее:
Когда выбрали пользователя, нажимаем Сохранить:
В итоге работы, у вас должно получиться вот так:
Большая часть настроек позади. Приступаем к конфигурации на стороне Asterisk. Настройки выполним через FreePBX.
Настройки Asterisk (FreePBX)
Классика. Нам нужно сделать SIP – транк, а потом настроить маршрутизацию. Начнем с SIP – транка. Переходим в раздел Connectivity → Trunks. Далее нажимаем Add Trunk → Add Chan_sip trunk.
Что тут нужно сделать:
Trunk name - имя транка. Как вам имя mtt? :);
Outbound CallerID - номер телефона, который у вас прикручен к ВАТС МТТ Бизнес. То есть тот, на который звонят клиенты;
Тут все. Переходим во вкладку sip Setting, заполняем секцию Outgoing:
username=Логин
type=peer
secret=Пароль на оборудование
qualify=3000
nat=yes
insecure=invite,port
host=login.mtt.ru
dtmfmode=rfc2833
disallow=all
allow=alaw,ulaw
Переключитесь на вкладку Incoming и там в поле Register String укажите следующую конструкцию:
логин:пароль_на_оборудование@login.mtt.ru/ваш_номер
Сохраняем. Теперь нужно настроить только исходящую и входящую маршрутизацию. О том, как это сделать, можете прочитать в статье по ссылке ниже:
Настройка маршрутизации вызовов
Стандарт JSON Web Tokens (JWT) – это лаконичный метод передачи данных, поддающихся проверке. Каждый токен содержит подпись, с помощью которой эмитент может проверить целостность сообщения.
С помощью этой статьи вы можете узнать, что из себя представляет структура JWT и как можно создать свои собственные токены. JWT – это популярный способ защиты API и аутентификации сеансов пользователей, так как они достаточно просты и являются автономными.
Как работают JWT?
Одна из самых распространенных задач в любом API – это проверка того факта, что пользователи являются теми, за кого себя выдают. Как правило, аутентификация выполняется тогда, когда клиент использует ключ API для запросов, которые он отправляет на сервер. Этот ключ содержит информацию, которая подтверждает личность пользователя. Но все еще остается вопрос: как сервер проверяет, что пользователь сначала предоставил ключ?
JWT с легкостью решают эту проблему с помощью секретного ключа, который используется для подписи каждого токена. Сервер проверяет действительность токена, повторно пересчитывая подпись с помощью своего секретного ключа. Любое несанкционированное вмешательство приведет к тому, что проверка не будет выполнена.
Структура JWT
JWT состоят из трех отдельных компонентов:
Заголовок
(header) – содержит метаданные о токене, например, алгоритм подписи, который был использован.
Полезная нагрузка
(payload) – в качестве полезной нагрузки могут выступать любые случайные данные, которые так или иначе относятся к вашей системе. Полезная нагрузка может содержать ID пользователя и набор определенных функций, с которыми пользователь может взаимодействовать.
Подпись
(signature) – подпись позволяет в дальнейшем проверить целостность токена. Подпись создается путем подписания заголовка и полезной нагрузки с помощью секретного ключа, который знает только сервер.
Для того, чтобы сформировать JWT, все эти три компонента нужно записать через точку:
header.payload.signature
Каждый компонент кодируется с помощью стандарта Base-64. Готовый токен представляет собой строку текста, которую можно использовать в средах разработки программ и отправлять вместе с HTTP-запросами.
Создание JWT
Создать JWT можно на любом языке программирования. В данном случае мы будем использовать PHP, но вы можете использовать и другой язык, процесс будет аналогичным.
Начнем с создания заголовка. Как правило, он включает в себя два поля –
alg
и
typ
:
alg
– это алгоритм хеширования, который мы будем использовать для создания подписи. Как правило, используют HMAC SHA256 (
HS256
).
typ
– это тип токена, который мы создаем. Здесь мы должны указать
JWT
.
Вот так выглядит объект JSON, который определяет заголовок:
{
"alg": "HS256",
"typ": "JWT"
}
Заголовок необходимо закодировать с помощью Base-64:
$headerData = ["alg" => "HS256", "typ" => "JWT"];
$header = base64_encode(json_encode($headerData));
Затем нам необходимо определить еще один объект JSON - полезную нагрузку токена. Что из себя будет представлять полезная нагрузка зависит от приложения. В данном примере мы используем информацию об учетной записи аутентифицированного пользователя и информацию о самом токене.
exp
,
iat
и
nbf
– это условные поля, которые используются для того, чтобы указать время истечения срока действия токена, время его создания и момент времени (начальный), до которого он считается недействительным. Полезную нагрузку также необходимо закодировать с помощью Base-64.
$payloadData = [
"userId" => 1001,
"userName" => "demo",
"licensedFeatures" => ["todos", "calendar", "invoicing"],
"exp" => (time() + 900),
"iat" => time(),
"nbf" => time()
];
$payload = base64_encode(json_encode($payloadData));
Нам остается только создать подпись. Для этого сначала нужно объединить заголовок и полезную нагрузку в одну сроку, разделив их точкой:
$headerAndPayload = "$header.$payload";
Затем мы должны сгенерировать уникальный секретный ключ, который мы будем использовать в качестве секретного ключа подписи. Этот ключ должен надежно храниться на вашем сервере, и его ни в коем случае нельзя передавать клиентам. Если значение секретного ключа будет раскрыто, то любой пользователь сможет создавать действительные токены.
// PHP method to generate 32 random characters
$secret = bin2hex(openssl_random_pseudo_bytes(16));
И мы завершаем процесс с помощью подписи объединенной строки (заголовка и полезной нагрузки) с помощью секретного ключа. Для этого мы будем использовать алгоритм хеширования, который мы указали в заголовке. Получившаяся подпись также, как и другие компоненты, должна быть закодирована с помощью Base-64.
$signature = base64_encode(hash_hmac("sha256", $headerAndPayload, $secret, true));
Итак, у нас теперь есть заголовок, полезная нагрузка и подпись. Они представляют собой отдельные текстовые компоненты. Для того, чтобы создать JWT, мы должны объединить из с помощью точки. И теперь мы можем отправить его клиенту:
$jwt = "$header.$payload.$signature";
Проверка входящих JWT
Клиентское приложение может определить, какие функции доступны пользователю, если расшифрует полезную нагрузку токена. Вот пример, написанный на JavaScript:
const tokenComponents = jwt.split(".");
const payload = token[1];
const payloadDecoded = JSON.parse(atob(payload));
// ["todos", "calendar", "invoicing"]
console.log(payloadDecoded.licensedFeatures);
Злоумышленник может подумать, что эти данные представляют собой простой текст и его легко изменить. Он может попробовать убедить сервер в том, что у него есть некая дополнительная доступная ему функция, изменив полезную нагрузку токена в своем запросе:
// Create a new payload component
const modifiedPayload = btoa(JSON.stringify({
...payloadDecoded,
licensedFeatures: ["todos", "calendar", "invoicing", "extraPremiumFeature"]
}));
// Stitch the JWT back together with the original header and signature
const newJwt = `${token[0]}.${modifiedPayload}.${token[2]}`
Как же сервер защищается от подобных атак? Ответ заключается в процессе создания подписи. Значение подписи учитывает, как заголовок токена, так и его полезную нагрузку. В случае данного примера изменение полезной нагрузки ведет к тому, что подпись становится недействительной.
Серверная программа проверяет входящие JWT путем пересчета их подписей. Если подпись, отправленная клиентом, не совпадает с подписью, посчитанной на сервере, то можно сделать вывод о том, что токен был подделан.
$tamperedToken = $_POST["apiKey"];
list($header, $payload, $signature) = $tamperedToken;
// Determine the signature this token *should* have
// when the server's secret is used as the key
$expectedSignature = hash_hmac("sha256", "$header.$payload", $secret, true);
// The token has been tampered with because its
// signature is incorrect for the data it includes
if ($signature !== $expectedSignature) {
http_response_code(403);
}
// The signatures match - we generated this
// token and can safely trust its data
else {
$user = fetchUserById($payload["userId"]);
}
Злоумышленник не может создать действительный токен, если он не знает секретный ключ, который хранится на сервере. Также это означает, что случайная утеря или преднамеренная передача секретного ключа сразу же делает все ранее созданные токены недействительными.
В реальной ситуации ваш код аутентификации должен проверять срок действия токена, а также должен убедиться, что он уже является действительным (
nbf
в полезной нагрузке). Это все необходимо для того, чтобы определить, является ли сеанс пользователя действительным.
Когда нужно использовать JWT
JWT, как правило используют для аутентификации API, поскольку их достаточно просто реализовать на сервере, легко использовать на клиентской стороне и просто передавать через границы сети. Но несмотря на то, что они такие простые, они обеспечивают хороший уровень безопасности за счет того, что каждый токен подписывается с помощью секретного ключа, который хранится на сервере.
JWT – это механизм, который не фиксирует текущее состояние, поэтому нет необходимости фиксировать информацию о созданных токенах на вашем сервере. Информацию о клиенте, который предоставляет вам JWT, вы можете получить из полезной нагрузки, а не искать ее в базе данных. После того, как подпись будет проверена, эта информация будет считаться достоверной.
Если вам необходимо обмениваться информацией между двумя сторонами без какого-либо постороннего вмешательства, то использование JWT – это отличный вариант. Однако у этого механизма есть слабые места, о которых следует знать заранее. В случае, если произойдет утечка секретного ключа или если ваш код проверки подписи содержит ошибку, то будет скомпрометирована вся система. Именно поэтому для реализации процесса создания и проверки JWT многие разработчики используют библиотеку с открытым исходным кодом. Функции доступны для всех популярных языков программирования, и они исключают риск ошибок при проверке токена.
Заключение
Стандарт JWT – это формат обмена данными, который включает в себя проверку целостности. Как правило, JWT используют для защиты взаимодействия между серверами API и клиентскими приложениями. Сервер может доверять входящим токенам, если у него получается воспроизвести их подписи. С помощью информации, полученной из полезной нагрузки, можно обеспечить безопасность при выполнении каких-либо действий
JWT достаточно удобны, но при этом имеют некоторые недостатки. Текстовое представление JWT в кодировке Base-64 может быть слишком объемным, если в полезной нагрузке будет слишком много полей. Это будет недопустимым потреблением ресурсов, если ваш клиент собирается отправлять JWT с каждым запросом.
Еще одним возможным недостатком может оказаться то, что JWT не фиксирует текущее состояние. После того, как токен был создан, он является неизменяемым и должен использоваться как есть до истечения своего срока действия. Клиенты, которые используют полезные данные JWT для определения прав доступа пользователя или для использования лицензированных функций, должны будут получать новый токен с сервера каждый раз, когда что-то из этого меняется.