По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье речь пойдет о способах организации виртуальных частных сетей VPN (Virtual Private Network). VPN – это набор криптографических механизмов, обеспечивающих защищенный, двухсторонний канал для безопасной передачи данных через незащищенную сеть, такую как Интернет. Благодаря VPN пользователь может получить доступ к удаленной сети и работать с её ресурсами так, как если бы он находился внутри нее. Поэтому VPN получил широкое распространение у компаний, имеющих в своем штабе дистанционных сотрудников.
Терминология
VPN представляет собой соединение типа Point to point (точка-точка), которое принято называть “туннелем” (tunnel), а участников данного соединения – “пирами” (peer). Каждый пир шифрует данные, подлежащие передаче через туннель и дешифрует данные, которые получает из туннеля.
Если к одному пиру устанавливается несколько туннелей, то такой пир называется VPN – шлюзом, а сеть, находящаяся за ним – “доменом шифрования” (encryption domain). Несмотря на название, трафик внутри домена шифрования не шифруется, так как считается защищенным от попадания во внешнюю сеть. Кроме того, VPN – туннель может быть установлен между сетями.
Удаленный сотрудник, желающий настроить VPN - туннель с доменом шифрования своего офиса, должен установить на своей рабочей станции специальное ПО – VPN-клиент, например: OpenVPN, VyprVPN, TunnelBear и др.
Для большего понимания, на рисунке ниже отмечены все элементы, рассмотренные ранее:
Разберем основные принципы, по которым устанавливается VPN – соединение.
Перед установлением соединения пиры идентифицируют друг друга, чтобы удостовериться, что шифрованный трафик будет отправлен правильному получателю.
Пиры договариваются, по каким протоколам будет устанавливаться соединение для сохранения целостности и конфиденциальности данныхю
Создается ключ, который будет использоваться для шифрования и дешифрования данных
Существует множество механизмов, способных обеспечить выполнение данных функций, но мы рассмотрим самый распространенный - IPsec(IP Security).
IPsec – это целый набор протоколов, обеспечивающих сервисы приватности и аутентификации. Обычно в IPsec выделяют три основных протокола:
AH (Authentication Header) – протокол идентификации заголовка. Данный протокол обеспечивает защиту передаваемых данных от изменения, путем проверки каждого бита пакета после передачи. То есть обеспечивает функции целостности.
ESP (Encapsulating Security Protocol) Данный протокол обеспечивает не только функции целостности, но и конфиденциальности, путем добавления своего заголовка в пакет, подлежащий защите.
IKE (Internet Key Exchange protocol) – протокол обмена ключами. Данный протокол предназначен для автоматического генерирования, обновления и обмена ключами между участниками VPN – соединения.
В IPsec есть еще один важный термин – SA (Security Association). SA это непосредственно VPN – соединение в контексте IPsec. SA устанавливается сразу после того, как IPsec – узлы договорились и согласовали все параметры, по которым будет организован VPN – туннель.
Итак, VPN – соединение с использованием IPsec устанавливается в два этапа:
На первом этапе VPN – узлы идентифицируют друг друга и согласовывают алгоритмы шифрования, хэширования и аутентификации, после чего создается первый SA.
Второй этап возможен только после завершения первого. На втором этапе генерируются данные ключей и происходит согласование используемой политики. После завершения второй фазы формируется второй SA и все данные, подлежащие передаче, шифруются. Именно после второго этапа формируется VPN – туннель и установка считается завершенной.
Обмен сообщениями Publish/Subscribe, также известный как Pub/Sub, - это асинхронный метод связи между службами, который используется в бессерверных архитектурах и архитектурах микрослужб. В целом, модель Pub/Sub включает в себя:
Издателя (publisher), который отправляет сообщение
Подписчика (subscriber), который получает сообщение через брокера сообщений
В общих чертах, что такое обмен сообщениями Pub/Sub
С учетом того, что популярность несвязных приложений и приложений на основе микрослужб только растет, критически важное значение для общей функциональности приложения имеет надлежащая коммуникация между компонентами и службами. Обмен сообщениями Pub/Sub помогает здесь в двух аспектах:
предоставляет разработчикам возможность легко и просто создавать несвязные приложения, используя надежный метод;
предоставляет пользователям возможность легко и просто создавать событийно-управляемые архитектуры.
Модель Pub/Sub позволяет асинхронно передавать сообщения в несколько разделов приложений.
Основной компонент, который обеспечивает всю эту функциональность, называется Тема (Topic). Издатель отправляет сообщение в тему, а тема сразу же отправляет это сообщение всем подписчикам. Именно этот подход отличает модель Pub/Sub от обычных брокеров сообщений, где очередь сообщений группируется до тех пор, пока пользователь или служба не запросит и не извлечет их.
Что бы ни представляло из себя сообщение в модели Pub/Sub, оно в любом случае будет отправлено всем подписчикам. Единственное исключение – это политики для подписчиков, которые создаются пользователями и которые фильтруют сообщения.
Такой поход позволяет создавать событийно-управляемые сервисы, которые не будут требовать от подписчиков запрашивать сообщения из очереди. Также модель Pub/Sub позволяет разработчикам создавать различные отдельные функции, которые используют одно и то же сообщение (одни и те же данные) и которые могут выполняться параллельно, что дает возможность обслуживать сразу несколько подписчиков.
Шаблон Pub/Sub обособляет издателей от подписчиков для того, чтобы издатели не знали, где используется сообщение, а подписчики не знали ничего об издателе. Это способствует улучшению общей безопасности приложения.
Преимущества шаблона Pub/Sub
Распределенное приложение на основе микрослужб, которое к тому же было разработано с помощью шаблона Pub/Sub, приносит выгоду всей организации, от разработчиков программного обеспечения до инженеров, которые отвечают за контроль качества.
Ниже приведен список преимуществ шаблона Pub/Sub:
Несвязные/слабосвязные компоненты
Модель Pub/Sub позволяет легко разделить коммуникацию и логику приложения, это в свою очередь позволяет создать изолированные компоненты. Это обеспечивает:
создание модульных, более надежных и безопасных программных компонентов или модулей;
улучшение качества кода и удобство сопровождения.
Улучшенная наглядность в масштабе системы
Простота шаблона Pub/Sub позволяет пользователям легко понимать принцип работы приложения.
С помощью этого шаблона также можно создавать несвязные компоненты, которые позволяют наблюдать за информационным потоком. Мы можем точно знать, откуда идет информация и куда, без явного определения источников или адресатов в исходном коде.
Коммуникации в режиме реального времени
Pub/Sub мгновенно доставляет сообщения подписчикам с помощью push-доставки. Это делает данный подход идеальным для коммуникации в режиме, близком к режиму реального времени. Такой подход избавляет от необходимости отправки запроса для проверки наличия сообщений в очередях, в следствие чего снижается задержка доставки сообщений в приложении.
Простота разработки
Так как Pub/Sub не зависит от языка программирования, протокола или какой-то конкретной технологии, то в этот шаблон может быть интегрирован абсолютно любой поддерживаемый брокер сообщений с помощью любого языка программирования. Ко всему прочему, Pub/Sub может быть использован в качестве моста для обеспечения коммуникации между компонентами, которые были реализованы с помощью различных языков программирования, путем управления межкомпонентной связью.
Это приводит к тому, что такое приложение будет просто интегрировать с внешними системами и не нужно будет создавать дополнительные функции для упрощения процесса коммуникации или беспокоиться о последствиях нарушения безопасности. Мы можем просто опубликовать сообщение в теме и позволить внешнему приложению подписаться на эту тему, тем самым пропадает необходимость прямого взаимодействия с основным приложением.
Повышенная масштабируемость и надежность
Этот шаблон обмена сообщениями считается эластичным – не нужно заранее определять количество издателей или подписчиков. Их можно просто по необходимости добавить в нужную тему.
Тот факт, что коммуникация и логика приложения разделены, упрощает процесс устранения неисправностей, так как разработчики могут сосредоточиться на каком-то конкретном компоненте и не беспокоиться о том, что это может как-то повлиять на остальную часть приложения.
Шаблон Pub/Sub также улучшает масштабируемость приложения, так как позволяет менять архитектуру брокеров сообщений, фильтры и пользователей и не затрагивать при этом базовые компоненты. В модели Pub/Sub новая реализация обмена сообщениями в случае, если форматы сообщений совместимы даже со сложными изменениями в архитектуре, – это просто вопрос изменение темы.
Улучшенная способность к тестированию
В связи с тем, что приложение является модульным, тесты могут быть направлены на каждый модуль в отдельности, обеспечивая тем самым более оптимизированный процесс тестирования. Сосредоточенность на каждом отдельном компоненте приложения значительно снижает сложность тестовых сценариев.
Также шаблон Pub/Sub позволяет легко определить источник и адресат данных и информационный поток. Это особенно полезно, когда вы тестируете вопросы, связанные с:
повреждением данных;
форматированием;
безопасностью.
Недостатки шаблона Pub/Sub
Pub/Sub – это надежная служба обмена сообщениями, но она не всегда соответствует всем требованиям. Давайте кратко рассмотрим некоторые недостатки этого шаблона.
Излишняя сложность в небольших системах
Pub/Sub требует правильной настройки и сопровождения. Если масштабируемость и несвязность компонентов не являются жизненно важными аспектами для вашего приложения, то внедрение такого шаблона, как Pub/Sub, будет пустой тратой ресурсов и добавит небольшой системе излишнюю сложность.
Потоковая передача мультимедиа
Pub/Sub не подходит для работы с медиафайлами, такими как аудио или видео, так как они требуют плавной синхронной потоковой передачи между хостом и получателем. Так как этот шаблон не поддерживает синхронную сквозную передачу данных, то обмен сообщениями Pub/Sub не стоит рассматривать для:
видео-конференций;
голосовой связи по IP-протоколу;
обычных приложений для потоковой передачи мультимедиа.
Обмен сообщениями Pub/Sub: варианты использования
Итак, когда же лучше всего использовать шаблон Pub/Sub?
Шаблон Pub/Sub можно использовать в самых различных областях для того, чтобы облегчить обмен данными в режиме реального времени и при распределенных коммуникациях. Например, ключевая сфера, которой такой шаблон только на руку, - это автоматизация.
В следующих разделах вы найдете описание самых распространенных вариантов использования шаблона Pub/Sub.
Интернет вещей
В эпоху интеллектуальных устройств нам требуется надежный и эффективный способ сбора и распространения информации. Узел управления или сервер может публиковать обновления, которые будут автоматически доставляться на все подписанные устройства Интернета вещей.
Пользовательские устройства Интернета вещей также могут выступать в роли издателей и публиковать уведомления, информацию от датчиков и т.д. в облаке, которые затем будут переданы пользователю.
Контроль системы и уведомления о событиях
Pub/Sub позволяет пользователям создавать темы для сбора сведений о системе и отправки их в интерфейсы визуализации и уведомлений.
Такой подход будет крайне полезен при работе с крупномасштабными внедрениями:
Сообщения можно группировать по категориям.
Все серверы и службы могут публиковать данные в этих общих темах; при этом не нужно создавать отдельные конвейеры уведомлений.
Можно выйти за пределы этой функциональной возможности, подписавшись на функции сопровождения или управления темой. Например, если сервер сообщает об ошибке, то он запускает функцию, которая автоматически заменит этот сервер.
Резервное копирование и репликация базы данных
Крайне важно делать резервные копии баз данных, которые распределены по разным технологиям и поставщикам. Можно настроить периодическое резервное копирование или снимки состояний с помощью планировщика задач.
А теперь давайте представим, что нам необходимо переместить эти резервные копии в другие области или облачное хранилище. В таком случае нам нужно воспользоваться шаблоном обмена сообщениями Pub/Sub, чтобы создать конвейер, который будет отправлять сообщение о завершении резервного копирования. Затем подписанная функция будет использовать это сообщение в качестве триггера, чтобы запустить процесс переноса или копирования.
Управление журналами
Шаблон Pub/Sub может выступать в роли посредник для агрегации и распространения журналов. Журналы можно собирать из нескольких мест и отправлять в подписанные службы, такие как масштабируемый поиск, или хранить их в разных местах.
Журналы можно фильтровать по вопросам, журналам аудита, уведомлениям, фоновым задачами и т.д. и направлять их подписчикам. Таким образом, можно обеспечить надлежащее управление журналами.
Службы обмена сообщениями Pub/Sub
Существует большое количество различных служб обмена сообщениями по шаблону Pub/Sub, от специализированных брокеров сообщений до облачных решений. Далее представлен список некоторых популярных служб Pub/Sub.
Apache Kafka. Kafka разработан Apache и имеет надежные функции обмена сообщениями Pub/Sub с помощью журналов регистрации сообщений.
Faye. Это простая служба Pub/Sub, которая предназначена для обеспечения работы веб-приложений с помощью серверов, разработанных для NodeJS и Ruby.
Redis. Это один из самых популярных брокеров сообщений, который поддерживает как традиционную очередь сообщений, так и реализацию шаблона Pub/Sub.
Amazon SNS. Amazon Simple Notification Service – это полностью управляемая служба, которая использует реализацию обмена сообщениями Pub/Sub.
Google Pub/Sub. GPS подходит для реализации службы обмена сообщениями Pub/Sub.
Azure Service Bus. Надежная служба обмена сообщениями (MaaS) с возможностью использования шаблона Pub/Sub.
Простой пример: обмен сообщениями Pub/Sub
Теперь, когда мы разобрались в концепции Pub/Sub, давайте рассмотрим простой пример, который иллюстрирует рабочий процесс, с помощью Google Pub/Sub. Он опубликует сообщение в теме и вызовет подписанную функцию Google для того, чтобы напечатать отправленное сообщение.
Шаг 1. Создание темы
Первый шаг – создать тему в Google Pub/Sub для того, чтобы у нас была возможность публиковать сообщения в этой теме.
Шаг 2. Настройка триггера
Необходимо перейти в созданную тему (Test_Topic) и нажать «Trigger Google Function». Таким образом вы сможете создать функцию Google, где в качестве триггера будет выступать созданная тема.
Шаг 3. Создание функции Google (print_message_pubsub_test)
На первом экране вы можете дать функции название и настроить тему в качестве триггера. Для создания функции, которая будет просто собирать передаваемые данные и отправлять их на сайт Webhook, мы будем использовать Python.
Помимо этого, для создания запроса POST для отправки данных мы будем использовать библиотеку запросов.
Фрагмент кода облачной функции:
import base64
import requests
def get_quote(event, context):
# Decode the Message Data
message = base64.b64decode(event['data']).decode('utf-8')
# Create Request
url = "https://webhook.site/xxxxxxx-xxxx-xxxx-xxxx-739c28ebd7ad"
request_headers = {"Content-type": "application/json"}
request_data = {"quote": message}
response = requests.post(url, data=request_data, headers=request_headers)
# Print Response
print(response.status_code)
print(response.text)
После того, как функция будет успешно развернута, вы увидите, что в качестве триггера функции будет указана тема Test_Topic.
Шаг 4. Настройка издателя
На этом шаге нам нужно создать простую программу на Python, которая будет выступать в роли издателя.
Воспользуемся библиотекой Google Cloud pubsub_v1 для того, чтобы создать клиента Publisher и выбрать случайную вдохновляющую цитату с сайта quotable.io. После чего мы опубликуем объединенную строку (автор и цитата) в тему (Test_Topic).
message_publish.py
from google.oauth2 import service_account
from google.cloud import pubsub_v1
import requests
# Create Authentication Credentials
project_id = "test-applications-xxxxx"
topic_id = "Test_Topic"
gcp_credentials = service_account.Credentials.from_service_account_file('test-applications-xxxx-xxxxxxxxxx.json')
# Create Publisher Client
publisher = pubsub_v1.PublisherClient(credentials=gcp_credentials)
topic_path = publisher.topic_path(project_id, topic_id)
# Get a Random Quote
response = requests.get("https://api.quotable.io/random")
json_response = response.json()
message = f"{json_response['author']} - {json_response['content']}"
# Publish the Message
data = message.encode("utf-8")
future = publisher.publish(topic_path, data)
# Print Result
print(f"Published messages to {topic_path} - {future.result()}.")
Ну вот и все! Мы успешно настроили конвейер обмена сообщениями. Когда вы запустите скрипт «message_publish», данные опубликуются в Test_Topic, запустится облачная функция Google (print_message_pubsub_test), которая отправит данные на сайт Webhook.
Здесь мы можем видеть сообщения, которые были опубликованы в теме.
В журналах облачной функции Google будет зафиксировано, что функция была запущена.
И наконец, ниже мы можем видеть все сообщения, которые получил сайт Webhook.
Выше мы рассмотрели базовую структуру любого рабочего процесса обмена сообщениями по шаблону Pub/Sub. Можно использовать его как обычный шаблон или расширить его для того, чтобы улучшить какие-то функциональные возможности.
Простые коммуникации с широкими возможностями
Шаблон обмена сообщениями Pub/Sub – это мощный, но при этом простой метод передачи информации. Он выступает в роли краеугольного камня для обеспечения работы распределенных приложений на основе микрослужб в режиме реального времени. Он управляет всем процессом обмена данными между внутренними и внешними компонентами.
Шаблон Pub/Sub можно использовать для создания асинхронных масштабируемых потоков обработки сообщений с минимальными задержками при доставке. Все это возможно благодаря всем тем преимуществам, в которых он превосходит брокеров сообщений.
В больших корпоративных сетях, которые занимаются обслуживанием клиентов важно вовремя получать уведомления о неполадках в сети и устранять их. В этом деле администраторам помогают системы мониторинга, которых сегодня в сети существует достаточно много, как платных, так и бесплатных.
Своего рода стандартом в ИТ является PRTG (Paessler Router Traffic Grapher), которая может отправлять уведомления о событиях через e-mail, SMS, Push-уведомлений. Сегодня сложно представить кого-то, кто не пользуется хоть одним мессенджером. Среди них особо выделяется Telegram, который пользуется популярностью благодаря своей безопасности и функционалу. Здесь можно создать своего бота, который будет выполнять все ваши команды исходя из поставленной задачи. В одном из материалов мы рассказывали уже о том, как использовать Telegram для управления "Умным домом".
Здесь же расскажем о том, как интегрировать Telegram в PRTG и получать уведомления не на почту, на Telegram. Принцип работы такой: система мониторинга, в нашем случае PRTG, отправляет сообщения боту, а тот в свою очередь выводит их группу.
Что нам нужно
Telegram аккаунт
Группа, куда будем добавлять нашего бота
Доступ с PRTG сервера на https://api.telegram.org/
Создание бота
Для начала нам нужно создать бота, в чем на поможет "The Botfather". Начинаем новый чат с ним в Telegram:
Командой /newbot под руководством Botfather начинаем создание бота. Задаем ему имя, которое будет отображаться и имя пользователя:
После этих несложных манипуляций получаем API токен нашего бота, который используем в будущем. По умолчанию, бот может быть добавлен в любую группу и может получать сообщения от кого угодно. Ограничить это можно в настройках приватности, которые доступны командами /setprivacy и /setjoingroups.
Далее добавляем бота в группу, где находятся администраторы и другой заинтересованный персонал.
Через группу посылаем боту сообщение /start, чтобы активировать его. Затем уже настраиваем политики приватности, о которых говорилось выше. С созданием бота закончили, теперь нужно настроить получение уведомлений
Настройка уведомлений
Помните, в конце создания бота нам выдали API ключ. Перейдите по следующей ссылке, предварительно подставив вместо <apikey> API ключ вашего бота:
https://api.telegram.org/bot<apikey>/getMe
Вы должны получить что-то подобное:
{ "ok": true, "result": { "id": 1234567890, "first_name": "PRTGNotiBot", "username": "PRTGNotificationBot" }}
Если вышли какие-то ошибки, убедитесь, что API ключ введён правильно. Далее открываем ту же ссылку, только вместо getMe подставляем getUpdates. Мы получим список чатов, в которые добавлен наш бот.
{ "ok": true, "result": [{ "update_id": 521075218, "message": { "message_id": 3, "from": { "id": 11512298, "first_name": "xxxxxxxxx", "last_name": "xxxxxxxxx", "username": "xxxxxxxxx" }, "chat": { "id":-12345690, "title": "[Paessler] IT", "type": "group", "all_members_are_administrators": true }, "date": 1493834122, "text": "/start", "entities": [{ "type": "bot_command", "offset": 0, "length": 6 }] } }]}
Из этого вывода нам нужен идентификатор чата, включая знак "-". Теперь мы готовы создать шаблон уведомления в PRTG. Переходим в Setup > Account Settings > Notifications.
Добавляем новый шаблон уведомления:
Выбираем вводим название шаблона, выбираем тип сенсора (рекомендуем pingsensor)
В качестве шаблона выбираем HTTP. Вводим ссылку https://api.telegram.org/bot<your-api-key>/sendMessage, подставив API токен вашего бота.
В строку Postdata вводим следующие строки:
chat_id=-<your-chat-id>&text=There's a *%status* sensor in your PRTG*Last Message* %lastmessage*Down since* %since*Device* %device*Group* %group&parse_mode=Markdown
chat-id идентификатор чата, который получили выше.
text текст сообщения, который будет отправлять бот. Текст можно изменять по вашему усмотрению.
%status переменная PRTG. Звездочки вокруг него это стиль редактирования Telegram API. Как именно обрабатывать стиль указано в конце текста параметром parse_mode=Markdown.
Если нужно, чтобы уведомление пришло если сеть поднялась, то нужно создать другой шаблон с соответствующим текстом:
chat_id=-123456890&text=%device% is *%status*!&parse_mode=Markdown
Хотя можно совместить это в одном шаблоне, но лучше сделать два отдельных шаблона, на случай если каждому шаблону нужно добавить разные переменные, как в нашем случае.
Затем можно отправить тестовое сообщение, в результате чего должны получить что-то подобное:
Если все прошло успешно, нужно привязать шаблон к конкретному сенсору. Чтобы система не бомбила ваш Telegram из-за незначительных событий, лучше привязать шаблон к сенсору PING. Для этого переходим на вкладку Devices, среди сенсоров нужного устройства наводим курсор мыши на сенсор PING и кликаем на иконку звоночка.
Открывается страница добавления уведомлений. Выбираем Add State Trigger заполняем поля согласно политике организации. Можно сделать как на скриншоте:
Как видно на скриншоте, мы отправляем уведомление только когда сеть упала и поднялась. Повторно не посылаем, чтобы не надоедало.
Вот и всё. Думаю материал окажется полезным для вас.