По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В сегодняшней статье речь пойдет о способах организации виртуальных частных сетей 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 – туннель и установка считается завершенной.
Можете ли вы представить себе компанию, в которой никто бы не управлял IT-инфраструктурой и операциями? Скорее всего, нет. Вот здесь и начинается SRE (обеспечение надежности информационных систем) и DevOps (автоматизация сборки, настройки и развертывания ПО). В последние годы оба этих направления стали очень популярными в IT-среде, и их распространенность продолжает расти. Но все-таки, DevOps и SRE – это разные вещи или синонимы для одного и того же? Данная статья поможет во всем разобраться.
Что такое DevOps?
DevOps – это подход к разработке ПО. Ключевое отличие данной методологии заключается в том, что DevOps следует принципам Lean (бережливое производство) или Agile (гибкость). DevOps специализируется на постоянном развертывании ПО с частым выходом версий и автоматизированным подходом к разработке программ. DevOps-подход включает в себя набор норм и технологических приемов для быстрого выполнения запланированной работы. Под запланированной работой мы подразумеваем все – от разработки до тестирования и эксплуатации. DevOps преследует следующие цели:
ускорение доставки продуктов на рынок;
сокращение жизненного цикла разработки ПО;
повышение отзывчивости к потребностям рынка.
Так что же такое DevOps? DevOps – это объединение отделов разработки и эксплуатации для максимально быстрого и органичного развертывания кода. Данный подход основан на тесной коммуникации внутри команды в сочетании с высоким уровнем автоматизации. По правилам DevOps команда, пишущая код, отвечает также и за его обслуживание при эксплуатации. Иначе говоря, отделы разработки и эксплуатации, которые принято разделять, должны работать сообща над улучшением версий ПО.
В чем преимущества DevOps?
Во-первых, DevOps улучшает скорость доставки приложений. Это реализуется за счет создания небольших изменений и частого выхода новых версий. Таким образом, компании могут выводить продукты на рынок чаще. Обновления и исправления выполняются быстрее и проще, а стабильность ПО возрастает. Более того, вносить небольшие изменения гораздо проще, и такую систему легко вернуть к предыдущей версии. Еще один плюс: возможности доставки ПО у таких объединенных команд более безопасные.
Что делает DevOps и как?
DevOps – это отличный способ для создания культуры сотрудничества. Центральное место занимает команда, которая вместе работает над развертыванием кода в промышленную среду и его дальнейшим обслуживанием. То есть команда DevOps отвечает за написание кода, исправление ошибок и выполняет любые задачи, связанные с этим кодом. Процесс DevOps основан на 5 ключевых принципах:
Устранение обособленности. Роль команды DevOps заключается в том, чтобы аккумулировать знания со стороны разработки и эксплуатации. Поощряется коммуникация, что помогает лучше разобраться в ситуации.
Быстрое признание ошибок и прекращение. В процессе DevOps определяются методы минимизации риска, а одни и те же ошибки не делаются дважды. С помощью автоматизированного тестирования команда ищет ошибки на ранних стадиях цикла выхода ПО.
Постепенное внесение изменений. Команда DevOps не внедряет крупные изменения в рабочие версии, а регулярно развертывает небольшие поэтапные доработки. Это позволяет лучше проверять изменения и устранять ошибки.
Использование инструментов и автоматизации. Команда создает конвейер развертывания с помощью инструментов автоматизации. Тем самым повышается скорость и точность разработки, а также сводится к минимуму риск ошибок, допущенных человеком. Кроме того, сокращается объем ручной работы.
Измерение всего. DevOps использует данные для измерения результата всех предпринятых действий. Чаще всего для оценки успеха используются 4 главных метрики: время внесения изменений, частота развертывания, время восстановления и частота отказов.
Для эффективной работы команде DevOps необходимо использовать мощные инструменты. К ним относятся: системы управления версиями для всего кода (GitHub, GitLab и т.д.), инструменты непрерывной интеграции (Jenkins, Spinnaker и т.д.), инструменты автоматизации развертывания, инструменты автоматизации тестирования (Selenium и т.д.), а также инструменты управления инцидентами (PagerDuty, Opsgenie и т.д.)
Что такое SRE?
Концепция обеспечения надежности информационных систем (SRE - Site Reliability Engineering) появилась в 2003 году. Изначально она задумывалась как система для поддержки разработчиков, создающих крупномасштабные приложения. В наши дни SRE реализуется опытной командой экспертов, которая умеет применять методы проектирования при решении общих проблем, связанных с запуском систем в промышленную эксплуатацию. SRE – это как бы системный инженер, который отвечает еще и за эксплуатацию. Это сочетание работ по системным операциям с разработкой и проектированием ПО. В зоне ответственности таких сотрудников находится множество задач – от написания и создания кода до его доставки и поддержки в промышленной среде.
Главная цель SRE – разработка сверхнадежных и быстро масштабируемых систем. Раньше проектировщиков ПО и сотрудников эксплуатационного отдела разделяли на 2 отдела с разными зонами ответственности. Такие отделы подходили к решению проблем с разных сторон. SRE выходит за рамки этого ограничения. Принцип сотрудничества, лежащий в основе этой методологии, пришелся по душе многим компаниям.
В чем преимущества SRE?
SRE значительно улучшает период работоспособности. Основной приоритет – поддержание платформы или сервиса в рабочем состоянии, несмотря ни на что. Задачами первостепенной важности являются: предотвращение аварий, минимизация рисков, надежность и запас мощности. Главная цель команды SRE – найти способы по предотвращению проблем, которые могли бы привести к простою. Это критически важно, особенно при сопровождении крупномасштабных систем. Еще одно преимущество SRE заключается в том, что данный подход помогает компаниям отойти от ручной работы в пользу автоматизации. Тем самым у разработчиков высвобождается больше времени на инновационные решения. Любые ошибки быстро и эффективно находятся и устраняются.
Что делает SRE и как
Роль SRE в компании предельно проста и понятна: команда следит за тем, чтобы платформа или сервис были доступны клиентам в любой момент и в любых обстоятельствах.
Чем занимается SRE?
SRE устраняет разобщенность команд немного иначе, чем DevOps. Она помогает разработчикам создавать более надежные системы, поскольку эти сотрудники занимаются не только разработкой, но и эксплуатацией программ. Следовательно, разработчики лучше понимают свои продукты и могут качественнее поддерживать системы в промышленной эксплуатации.
Для улучшения системы SRE использует определенные метрики. Такая оценка надежности систем является решающим фактором, определяющим, попадет ли то или иное изменение в рабочую версию. Ключевые метрики SRE: SLO (цели уровня обслуживания), SLA (соглашение об уровне обслуживания) и SLI (количественная оценка работы сервиса).
SRE решает вопросы, связанные с эскалацией запросов в поддержку. Кроме того, эта система всячески побуждает людей выявлять и сообщать об инцидентах.
Команда SRE определяет и проверяет новый функционал с обновлениями, а также разрабатывает документацию по системе.
В своей работе команда SRE пользуется такими системами, как Kubernetes (один из самых известных оркестраторов контейнеров), облачными платформами (Microsoft Azure, Amazon AWS и т.д.), инструментами планирования и управления проектами (JIRA, Pivotal Tracker), а также системами контроля версий (GitHub и т.д.).
Чем отличаются SRE и DevOps?
Если говорить абстрактно, что DevOps – это написание и развертывание кода, а SRE – это комплексный подход ко всему, поскольку при работе над системой команда примеряет на себя роль конечного пользователя.
При работе над продуктом или приложение команда DevOps использует гибкий подход. Они быстро и качественно создают, тестируют и развертывают приложения. Команда SRE регулярно делится с командой разработчиков обратной связью. Их цель – эффективно использовать данные по эксплуатации и проектированию ПО (в основном, за счет автоматизации операционных задач) и, тем самым, ускорить доставку приложения. В то же время задача команды DevOps – сделать рабочие процессы более эффективными и автоматизированными.
Цель SRE – создать слаженные операционные процессы с помощью методологий, которыми раньше пользовались только разработчики ПО. Основная задача SRE – сделать так, чтобы платформа или приложение были постоянно доступны клиентам. Для этого оцениваются потребности клиентов и анализируются метрики SLA, SLI и SLO. DevOps делает акцент на процессе в целом, и результатом должно стать успешное развертывание ПО. Ниже описаны дополнительные отличия между DevOps и SRE.
Роль команды разработчиков
DevOps объединяет навыки разработчиков и инженеров по эксплуатации ПО. SRE решает проблемы IT-операций с помощью инструментов и парадигмы разработчиков.
Навыки
Команда DevOps работает преимущественно с кодом. Они пишут код, тестируют его и выпускают в промышленную версию. Итогом их работы должна стать программа, которая поможет решить чью-то проблему. Кроме того, они настраивают и запускают сборочный конвейер. SRE-подход немного шире. Команда анализирует, почему что-то пошло не так. Они делают все, чтобы та или иная проблема не повторилась.
Что общего в SRE и DevOps?
Мы разобрали отличия между DevOps и SRE, но есть ли в них что-то общее? По правде говоря, SRE и DevOps между ними много общего, ведь оба подхода – это методологии, которые применяются для анализа промышленных версий и обеспечения того, чтобы управление эксплуатациями работало как нужно. Их общая цель – получить качественный результат для сложных распределенных систем. Оба направления делают акцент на людях, которые работают как единая команда с общей зоной ответственности. DevOps и SRE верят в то, что поддерживать все в рабочем состоянии – это задача каждого. Вовлеченность в процесс должна быть общей – от написания первоначального кода до сборки приложения, развертывания в промышленную версию и обслуживания. Проектировщики DevOps и SRE пишут и оптимизируют код до того, как развертывать его в рабочей среде.
Подводя итог, можно сказать, что для достижения общей цели нужно сочетать DevOps и SRE.
Зачастую можно столкнуться с задачами, когда необходимо обеспечить доступ к внутренним корпоративным (или домашним) ресурсам из Интернета. В этом случае, нужно выполнить, так называемый "проброс портов". Что это такое, зачем это нужно и как настраивать на примере роутера Mikrotik 951Ui-2HnD – расскажем в данной статье.
/p>
Как это работает?
Давайте представим себе следующую ситуацию – у нас есть корпоративная сеть, в которой пока ещё локально разворачивается сервер IP-телефонии на базе Asterisk, управляется он при помощи графической оболочки FreePBX. Задача состоит в том, чтобы предоставить возможность администратору сервера управлять им из Интернета.
Итак, имеем следующую схему:
Для начала остановимся на понятии “проброс порта”. Проброс порта – это функционал маршрутизаторов, поддерживающих NAT, который позволяет получить доступ к ресурсам локальной сети, из Интернета по средствам перенаправления трафика определенных портов с внешнего адреса маршрутизатора на внутренний адрес хоста в локальной сети.
Иными словами, мы должны настроить на роутере правило, в котором при поступлении TCP запроса на внешний адрес, в данном случае 35.135.235.15 и определенный порт, например 23535, открывался бы доступ к интерфейсу FreePBX, который в данным момент доступен только в локальной сети по адресу 192.168.1.100 и, соответственно на порту 80 (HTTP).
Настройка
Перейдём к настройке. Заходим на адрес нашего роутера Mikrotik 951Ui-2HnD, видим следующее окно:
Скачиваем приложение WinBox. Вводим учётные данные и подключаемся. По умолчанию логин - admin, пароль - пустой. Если у вас уже настроены логин и пароль, то укажите их.
Далее необходимо создать NAT – правило. Для этого переходим по следующему пути – на панели управления слева выбираем IP → Firewall → NAT
Открывается следующее окно:
Нажимаем на +, открывается страница добавления нового NAT- правила.
Задаём следующие параметры:
Chain → dstnat - направление запроса из внешней сети во внутреннюю.
Protocol → tcp, поскольку в нашем случае нужно предоставить доступ к HTTP страничке.
Dst.Port → 23535 - это тот самый порт назначения, на который будет отправлять запрос из вне на получение доступа к FreePBX.
In.Interface → all ethernet - входной интерфейс. Это интерфейс, которым роутер смотрит в Интернет и на котором он будет прослушивать указанный выше порт.
Должно получиться вот так:
На вкладках Advanced и Extra настраиваются расширенные опции, такие как лимит по битрейту, политика IPsec, время, в течение которого правило будет активно и так далее.
Переходим на вкладку Action и объясняем роутеру, какие действия он должен выполнить при поступлении запроса на указанный порт. Выбираем Action → netmap, то есть трансляция с одного адреса на другой. To Addresses → 192.168.1.100, то есть адрес нашёго FreePBX. И последнее - To Ports → 80, то есть запрос на HTTP порт.
Должно получиться так:
Далее нажимаем OK и правило готово. Теперь если вбить в адресной строке браузера сокет 35.135.235.15:23535 то мы попадем на страницу авторизации FreePBX.