По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
У облачного провайдера нам необходимо арендовать пул виртуальных серверов для создания на его основе облачного аналога перечисленной серверной части сети. К организованной облачной виртуальной инфраструктуре будут иметь доступ все отделения организации посредством VPN-туннелей. Все виртуальные машины создаются посредством гипервизора. Аналогичным образом виртуальные машины могут быть созданы и в обычной сети, но также могут использоваться и отдельные физические серверы. Для облачных же услуг технология виртуализации является основополагающей, поэтому в этом разделе подробнее будет рассмотрена технология виртуализации. В данном случае для организации собственных виртуальных серверов мы пользуемся услугами IaaS (чаще всего в списке услуг именуется как "аренда виртуальных серверов" или похожим образом). Но для организации серверов для, например, корпоративной почты или базы данных можно воспользоваться уже готовыми PaaS и SaaS-решениями, которые предлагаются некоторыми облачными провайдерами. При организации облачной инфраструктуры для крупной организации имеет смысл строить частное облако. Даже пусть оно иногда не будет покрывать все потребности организации и периодически придется превращать его в гибридное. Крупным компаниям нужна не столько экономия, столько полный контроль над обрабатываемыми данными - чтобы конфиденциальные данные не вышли за пределы компаний. Для небольших и средних организаций можно создать облачную инфраструктуру на базе публичного облака. Если компания только начинает свою деятельность, нет смысла покупать физические серверы - можно сразу арендовать виртуальные и сэкономить средства, которые можно потратить с большей пользой. Перевод в облако сразу всей инфраструктуры обусловлен еще и взаимосвязями между серверами и скоростью обмена данными между ними. Поэтому следует учитывать взаимосвязь серверов между собой и тот факт, что из любого офиса теперь скорость скачивания файла из того же облачного хранилища будет ограничиваться максимальной скоростью на сетях интернет-провайдера, однако обмен данными в сетях облачного провайдера будет гораздо выше в силу специализированности построенной сети ЦОД. Виртуальные машины Гипервизор - это программное или микропрограммное обеспечение, позволяющее виртуализировать системные ресурсы. Виртуальные машины в гипервизоре логически отделены друг от друга и не привязаны к аппаратному обеспечению, поэтому вирусы и ошибки на одной виртуальной машине никак не влияют на другие на том же гипервизоре и на аппаратную часть сервера, и могут быть легко перемещены с одного сервера на другой. Гипервизор по своей сути аналогичен операционной системе. Существуют 2 типа гипервизоров: гипервизор 1-го типа устанавливается поверх аппаратной части оборудования, 2-й тип устанавливается поверх операционной системы, а также гибридные. В таблице 1 приведены некоторые примеры гипервизоров. Таблица 1 Примеры гипервизоров Гипервизор Тип Требуемые ОС для установки Гостевые ОС KVM 2 Linux, FreeBSD, illumos FreeBSD, Linux, Solaris, Windows, Plan 9 VMware: ESX Server 1 Не требует ОС Windows, Linux, Solaris, FreeBSD, OSx86 (as FreeBSD), virtual appliances, Netware, OS/2, SCO, BeOS, Haiku, Darwin, others: runs arbitrary OS ESXi Server 1 Не требует ОС Fusion 2 macOS Server 2 Windows, Linux Workstation 2 Windows, Linux VMware ESXi (vSphere) 1 No host OS Same as VMware ESX Server Microsoft Hyper-V Hyper-V 2 Windows FreeBSD, Linux (SUSE 10, RHEL 6, CentOS 6) Hyper-V Server 1 Не требует ОС Xen гиб- рид GNU/Liux, Unix-like GNU/Linux, FreeBSD, MiniOS, NetBSD, Solaris, Windows 7/XP/Vista/Server 2008 (requires Intel VT-x (Vanderpool) or AMD-V (Pacifica)-capable CPU), Plan 9 VirtualBox 2 Windows, Linux, macOS, Solaris, FreeBSD, eComStation DOS, Linux, macOS, FreeBSD, Haiku, OS/2, Solaris, Syllable, Windows, and OpenBSD (with Intel VT-x or AMD-V PowerVM ? PowerVM Firmware Linux PowerPC, x86; AIX, IBM i Таким образом при проектировании корпоративной сети с помощью виртуальных серверов, следует заранее определиться с типом виртуальной машины и совместимых с ней операционных систем. Для облачных виртуальных серверов достаточно учитывать совместимые гостевые ОС, обеспечение работоспособности физических серверов и гипервизора берет на себя облачный провайдер. Создание виртуальной машины или виртуальной сети Для переноса элементов корпоративной сети в облако необходимо арендовать у облачного провайдера один или несколько виртуальных серверов, на которых будут развернуты необходимые нам системы. Часто достаточно обойтись моделью предоставления услуги VPS/VDS, описанной в разделе 2, арендовав несколько виртуальных серверов для каждого элемента инфраструктуры. Готовая виртуальная машина (ВМ) на сервере, по сути, будет представлять из себя два файла: файл конфигурации аппаратной части машины и образ диска этой машины, предназначенный для размещения в нем операционной системы. На диске ВМ помимо ОС размещается все программное обеспечение и файлы пользователей. Оба файла, а значит и вся ВМ целиком, могут быть без особых сложностей перенесены или дублированы с одного гипервизора и сервера на другой, что позволяет гибко распределять серверные ресурсы, создавать и восстанавливать резервные копии данных пользователей, а также помогать в процессе миграции на облачную инфраструктуру с уже заранее заготовленными образами систем. Для создания виртуальной машины на сайте почти любого облачного провайдера можно найти параметры конфигурации и "ползунки" для точной настройки вычислительных ресурсов арендуемой виртуальной машины, подобрав все параметры под цели и задачи сервера. Либо же можно воспользоваться "кейсами" - готовыми наборами настроек. А также часто клиентам предлагаются услуги тестирования, платного или бесплатного, арендуемого сервера, чтобы оценить его возможности и соответствие требованиям. Примеры параметров настройки виртуального сервера приведены на рисунке 1. В первом случае идет выбор именно ресурсов сервера, для дальнейшего развертывания на нем "целого парка виртуальных машин". Во втором случае настраивается конкретно виртуальный сервер данный вариант хорошо подойдет. Разворачивание частного облака позволяет создать и настроить необходимое количество виртуальных машин со своими приложениями, но организация и сопровождение такой структуры будет требовать больших затрат по сравнению с выделенным сервером. После создания виртуального сервера на рабочем столе рабочей станции появляется значок подключения к виртуальному серверу. Далее рассмотрим подробнее облачные решения для необходимых нам серверных структур. Терминальный сервер Как уже было упомянуто в разделе 1, терминальный сервер будет представлять собой сервер с заранее установленным на него приложением для удаленной работы с ним посредством "тонкого клиента". Например, такая возможность будет востребована при групповой работе с 1С. В таком случае сервер должен быть связан с сервером базы данных. Это означает, что клиенты подключаются к серверу приложения, а сервер приложения взаимодействует с сервером базы данных. Оба сервера должны находиться в облаке, чтобы между ними была хорошая связь. К терминальному серверу приложений сотрудники могут осуществлять подключение посредством протокола RDP. К приложению (1С, например) может быть организован доступ посредством публикации базы через web-сервер и, соответственно, работой с web-интерфейсом 1С, подключением с помощью "тонкого" или "толстого" клиента 1С или же подключением ко всему серверу терминалов по протоколам удаленного доступа (RDP и другие). Файловый сервер По сути, работа с файловым сервером в облаке ничем не отличается от того, если бы он был в локальной сети. Подключение к файловому серверу обычно осуществляется через протокол FTP (File Transport Protocol) с помощью файлового проводника. Однако следует тщательно взвесить решение о переносе файлового сервера в облако, т.к. объем данных при сообщении с сервером может сильно повлиять на тарифы услуг Интернет. Почтовый сервер В качестве почтового сервера, согласно перечню облачных сервисов, представленному в разделе 2, чаще всего облачные провайдеры используют Microsoft Exchange Server. Он является одним из самых распространенных ПО для корпоративной почты. Подключение к почтовому серверу может осуществляться аналогично другим терминальный приложениям: web, клиенты или удаленный доступ. Также требует доступа к базам данных Виртуальное рабочее место VDI или виртуальное рабочее место позволяет сотрудникам организации использовать рабочую станцию с любой конфигурацией для работы из любого места и в любое время. Для подключения к VDI чаще всего используется специальное клиентское ПО, или же иногда это может осуществляться из браузера. Web-сервер Формально web-приложение также должно быть соединено c сервером базы данных и может быть разбито на 3 части: исполняемый модуль на стороне браузера клиента; исполняемый модуль на стороне сервера; база данных. База данных представляет собой систематизированный набор данных для сетей и пользователей и управляемый посредством системы управления базами данных (СУБД). Пример СУБД MySQL. Сервер печати Следует учесть, что сервер печати однозначно не требует переноса в облако, т.к. выполняет задачу сообщения с офисным оборудованием, таким как принтеры и факсы. Конфигурация сервера Развертывание терминального сервера, а в частности внедрение продуктов 1С одна из самых распространенных задач системны администраторов. И подбор серверной аппаратной конфигурации под данную задачу может служить хорошим примером требований серверных систем к техническим параметрам оборудования. Рассмотрим несколько вариантов организации и аппаратной конфигураций для развертывания 1С сервера с базой данных. Можно предложить 3 варианта: Один сервер с файловой 1С; Один сервер с виртуальными машинами 1С и БД; Два физических сервера: один терминальный 1С, второй с БД. В первом случае будет организован терминальный сервер, на котором будет использоваться файловая версия 1С, таким образом БД будет находиться в файловой системе самого сервера вместе с программой 1С. Для большого количества пользователей разработчик рекомендует использовать систему "клиент-сервер". Организовать терминальный сервер, сервер БД и сервер 1С на одной операционной системе все равно можно, но это будет подвергать сомнению стабильность и информационную безопасность такой системы. Во втором случае как раз-таки и используется такая система, но оба сервера будут виртуальными на одном физическом. Данный вариант и используется в облачной инфраструктуре. Первый сервер будет содержать серверную часть 1С, второй базу данных. В третьем случае будут отдельно использоваться два сервера, а базы данных и программа будут разделены. Для конфигурации общего терминального сервера с двумя виртуальными машинами с расчетом работы примерно на 50 человек должно хватить следующей конфигурации: 10 ядер центрального процессора: по 6-8 терминальных сессий на одно ядро примерно 8 ядер, 1-2 ядра на базу данных, дополнительно еще запас, но для облачных серверов можно в любой момент докупить дополнительную вычислительную мощность; 64 Гб оперативной памяти: операционная система (например, Windows Server) 2 Гб база данных 4-6 Гб сервер 1С 2-4 Гб примерно 700 Мб на каждого пользователя 35 Гб SSD (для быстрых операций) и SAS (для хранения) память данных в условиях облачной инфраструктуры выбор дисковой подсистемы сводится к выбору конкретного типа дисков и их объемов: быстрых твердотельных накопителей (SSD) для быстрых операций чтения/записи и/или более медленных, но вместительных жестких дисков жестких дисков с интерфейсов SAS, подходящих для хранения баз данных. Подключение к облаку Для подключения сотрудников к корпоративному облаку могут применяться комбинации сразу нескольких решений, каждое из которых более детально рассмотрено в таблице 2. Таблица 2 Способы подключения к инфраструктуре в облаке Способ подключения Назначение Требования со стороны сервера Требования со стороны клиента Веб-доступ Доступ к сайту, расположенному на web-сервере через протокол HTTP/HTTPS Наличие выделенного терминального сервера + служба TS Web Access Использование адреса сайта для доступа к ресурсу с помощью браузера RDP Доступ к виртуальным серверам Наличие выделенного терминального сервера Запуск клиента RDP RemoteApp Доступ к терминальным сессиям Наличие конфигурационног о файла со списком программ, имеющим доступ к приложению Запуск сконфигурированного rdp-файла или иконки приложения для подключения к приложению по RDP Remote access VPN Подключение каждого пользователя к серверу через VPN-туннель Наличие сконфигурированного VPN- устройства/сервера. Запуск ярлыка для подключения к VPN-серверу. Продолжение таблицы 2 VPN site-to-site Подключение офиса к серверу через VPN- туннель Наличие двух сконфигурированных VPN-серверов. Пример: VPN-сервер в компании и VPN- сервер в облаке. Отсутствие необходимости создания и запуска ярлыка VPN- подключения. Обращение к ресурсам филиала / центрального офиса / облака напрямую. При обращении к ресурсам VPN- подключение организуется автоматически на уровне серверов. DirectAccess Автоматическая установка связи со всей корпоративной сетью сразу Наличие одного или более серверов DirectAccess в составе домена. Наличие центра сертификации (PKI). Windows - инфраструктура. Только Windows Компьютер клиента должен входить в состав домена. Отсутствие необходимости в создании и запуске ярлыка подключения. VDI Доступ к отдельному виртуальному рабочему месту Развернутая инфраструктура виртуальных рабочих столов VDI Пользователь получает свой собственный виртуальный рабочий стол, к которому можно подключаться с помощью тонкого клиента с любой рабочей станции. Выбор каждого конкретного способа подключения может зависеть от потребностей пользователей, что будет быстрее и удобнее для работы. Облачная инфраструктура корпоративной сети Теперь мы можем составить схему облачной инфраструктуры корпоративной сети. Это будет модифицированная схема из раздела 1. Схема представлена на рисунке:
img
NoSQL СУБД, или нереляционные базы данных, обладают уникальными возможностями, которые компенсируют ограничения моделей реляционных баз. Нереляционные СУБД – это общее название для 4 основных подгрупп: базы данных типа «ключ-значение» колоночные базы данных графовые базы данных документные базы данных В этой статье мы расскажем о том, что такое документная база данных, опишем ее плюсы и минусы, а также рассмотрим примеры. Документная база данных Документная (или документоориентированная) база данных – это тип нереляционных СУБД, который хранит данные не в столбцах и строках, а в виде документов JSON. JSON является нативным языком, используемым для хранения и запросов данных. Такие документы можно сгруппировать в коллекции, которые образуют системы баз данных. Каждый документ состоит из нескольких пар «ключ-значение». Ниже приведен пример документа из 4 пар «ключ-значение»: { "ID" : "001", "Book" : "Java: The Complete Reference", "Genre" : "Reference work", "Author" : "Herbert Schildt", } JSON позволяет разработчикам приложений хранить и запрашивать данные в том же формате документной модели, который используется ими для структурирования кода приложений. Объектную модель можно преобразовать в такие форматы, как JSON, BSON и XML. Сравнение реляционной и документной базы данных Реляционная система управления базами данных (РСУБД) основана на языке структурированных запросов (SQL). Для нереляционных баз они не нужны. РСУБД занимается созданием связей между файлами для хранения и считывания данных. Документные базы данных ориентированы на сами данные, а связи между ними представлены в виде вложенных данных. Ключевое сравнение реляционных и документных баз данных: РСУБД   Система документных баз данных Выстроена вокруг концепции о связях Сосредоточена на данных, а не связях Структурирует данные в кортежи (или строки) Вместо строк в документах имеются свойства без теоретических определений. Определяет данные (образует связи) через ограничения и внешние ключи (например, дочерняя таблица ссылается на основную таблицу через ее идентификатор). Для определения схем не нужен язык DDL. Для создания связей использует язык DDL (язык описания данных). Вместо внешних ключей связи реализованы через вложенные данные (в одном документе могут содержаться другие, вложенные в него, документы, из-за чего между двумя сущностями документов формируется связь 1 ко многим (или многие к одному)). Обеспечивает исключительную согласованность. В некоторых случаях она просто необходима (например, ежедневные банковские операции). Обеспечивает согласованность в конечном счете (с периодом несогласованности). Особенности документной базы данных Документные базы данных обеспечивают быстрые запросы, структуру, которая отлично подходит для обработки больших данных, гибкое индексирование и упрощенный принцип поддержания баз данных. Такая СУБД эффективна для веб-приложений и была полностью интегрирована крупными ИТ-компаниями уровня Amazon. Несмотря на то, что базы данных SQL могут похвастаться отличной стабильность и вертикальной структурой, им свойственна «тяжеловесность» данных. В сценариях использования, когда требуется моментальный доступ к данным (например, медицинские приложения), лучше выбирать документные базы данных. Так вы сможете легко запрашивать данные в той же модели документа, в которой писался код приложения. Примеры использования документной базы данных База данных «Книга» Для создания баз данных «Книга» используются как реляционные, так и нереляционные СУБД, хотя и по-разному. В реляционных СУБД связи между книгами и авторами выражаются через таблицы с идентификаторами ID: таблица Author (Автор) и таблица Books (Книги). Данная модель не допускает пустых значений, поэтому за каждым «Автором» должна быть закреплена как минимум одна запись в таблице «Книги». В документной модели вы можете вкладывать данные. Такая модель показывает взаимосвязи проще и естественнее: в каждом документе с авторами есть свойство Books с массивом связанных документов «Книги». При поиске по автору отображается вся коллекция книг. Управление содержимым Разработчики пользуются документными базами данных для создания блогов, платформ с потоковыми видео и аналогичных сервисов. Каждый файл сохраняется в виде отдельного документа, и со временем, по мере разрастания сервиса, такую базу легче поддерживать. На значимые изменения в данных (как, например, изменения модели данных) не требуется простоя, поскольку им не нужно обновление схемы. Каталоги Когда дело касается хранения и чтения файлов каталога, документные базы данных оказываются в разы эффективнее реляционных СУБД. В каталогах могут храниться тысячи атрибутов, а документная база данных обеспечивает их быстрое считывание. В документных базах данных атрибуты, связанные с одним продуктом, хранятся в одном документе. Изменение атрибутов в одном из продуктов не влияет на другие документы. Плюсы и минусы документной базы данных Ниже представлены главные плюсы и минусы документной базы данных: Плюсы документной БД Минусы документной БД  Отсутствие схемы Ограничения по проверке на согласованность Быстрое создание и обслуживание Проблемы с атомарностью Отсутствие внешних ключей Безопасность Открытые форматы Встроенное управление версиями Плюсы Отсутствие схемы. Нет ограничений по формату и структуре хранилищ данных. Это хорошо для сохранения существующих данных в больших объемах и разных структурных состояниях, особенно в непрерывно преобразующихся системах. Быстрое создание и обслуживание. Как только вы создали документ, ему требуется лишь минимальная поддержка – она может оказаться не сложнее разового добавления вашего сложного объекта. Отсутствие внешних ключей. Когда эта динамика связей отсутствует, документы становятся независимыми друг от друга. Открытые форматы. Чистый процесс сборки, в котором для описания документов используется XML, JSON и другие производные. Встроенное управление версиями. По мере того, как увеличивает размер ваших документов, повышается и их сложность. Управление версиями уменьшает количество конфликтов. Минусы Ограничения по проверке на согласованность. В примере с базой данных «Книга» можно искать книги по несуществующему автору. При поиске по коллекциям книг вы можете находить документы, не связанные с коллекцией авторов. Кроме того, в каждом списке для каждой книги может дублироваться информация об авторе. В некоторых случаях такая несогласованность не особо важна. Но при более высоких стандартах непротиворечивости РСУБД несогласованность серьезно снижает производительность баз данных. Проблемы с атомарностью. Реляционные системы позволяют изменять данные из одного места без использования JOIN. Все новые запросы на чтение унаследуют изменения, внесенные в данные по одной команде (например, обновление или удаление строки). Для документных баз данных изменение, затрагивающее 2 коллекции, выполняется через 2 отдельных запроса (по одному на коллекцию). Это нарушает требования к атомарности. Безопасность. Почти в половине современных веб-приложений отмечается активная утечка конфиденциальных данных. Поэтому владельцам нереляционных баз данных следует быть крайне внимательными к уязвимостям веб-приложения. Лучшие документные базы данных Amazon DocumentDB Особенности: совместимость с MongoDB; полная управляемость; высокая производительность с низкой задержкой запросов; строгое соответствие требованиям и безопасность; высокая доступность. Как используется: Вся команда разработки Amazon пользуется Amazon DocumentDB для повышения оперативности и продуктивности. Им нужны были вложенные индексы, агрегирование, ad-hoc запросы (запросы узкой специализации), а также полностью управляемый процесс. BBC использует документные БД для запросов и хранения данных из нескольких потоков данных с компиляцией их в единый канал для клиентов. Они перешли на Amazon DocumentDB, чтобы получить полностью управляемы сервис с высокой доступностью, прочностью и резервным копированием по умолчанию. Rappi выбрали Amazon DocumentDB для сокращения времени на написание кода, Dow Jones – для упрощения операций, а Samsung – для более гибкой обработки больших журналов. MongoDB Особенности: ad-hoc запросы; оптимизированное индексирование для запросов; сегментирование; балансировка нагрузки. Как используется: Forbes сократил время компоновки на 58%, получив прирост в 28% по количеству подписок, за счет более быстрого создания новых функций, более простого объединения и более качественной обработки разнообразных типов данных. Toyota заметила, что разработчикам было проще работать с документными БД на больших скоростях за счет использования нативных JSON-документов. Больше времени тратилось на создание ценности бизнеса, а не на моделирование данных. Cosmos DB Особенности: быстрое чтение в любом масштабе; 99,999% доступность; полная управляемость; NoSQL/Native Core API; бессерверное, экономичное/мгновенное масштабирование. Как используется: Coca-Cola получает информацию за минуты, что способствует глобальному масштабированию. До перехода на Cosmos DB на это уходили часы. ASOS искали распределенную базу данных, которая легко и гибко масштабируется для обслуживания 100+ миллионов розничных клиентов по всему миру. ArangoDB Особенности: валидации схем; разноплановое индексирование; быстрые распределенные кластеры; эффективность с большими наборами данных; поддержка многих нереляционных моделей данных; объединение моделей в единые запросы. Как используется: Оксфордский университет разработал онлайн-тестирование на сердечно-легочные заболевания, благодаря чему снизил посещаемость больниц и усовершенствовал результаты анализов. FlightStats привел к единому стандарту разрозненную информацию о полетах (статус рейса, погодные условия, задержки в аэропорту, справочные данные), что позволило получить точные, прогнозирующие и аналитические результаты. Couchbase Server Особенность: возможность управления глобальными развертываниями; крайняя гибкость и адаптивность; быстрота в крупных масштабах; простые облачные интеграции. Как используется: BT использовал гибкую модель данных Couchbase для ускорения собственных возможностей по высокопроизводительной поставке контента, а также легкого масштабирования в моменты резкого повышения спроса. eBay перешел от Oracle к более экономичному и функциональному решению (их документной системы/хранилища типа «ключ-значение»). Возросла доступность и производительность приложения, а разработчики могли пользоваться своим опытом в SQL для ускорения пайплайна CI/CD (конвейера сборки) через более гибкую схему. CouchDB Особенности: графический интерфейс на базе браузера; простейшие репликации; аутентификация пользователя; свойства ACID (Атомарность – Согласованность – Изолированность – Прочность). Как используется: Meebo (соцсеть) пользуется CouchDB для веб-интерфейса и его приложений. The BBC выбрал CouchDB за платформы динамического контента Как выбрать? Структуру данных определяют важнейшие требования, предъявляемые к приложению. Вот несколько ключевых вопросов: Вы будете больше читать или записывать? В случае, если вы чаще записываете данные, лучше подойдут реляционные системы, поскольку они позволяют избегать задвоений при обновлениях. Насколько важна синхронизация? Благодаря стандартам ACID, реляционные системы справляются с этой задачей лучше. Насколько сильно потребуется изменять вашу схему базы данных в будущем? Документные БД – это беспроигрышный вариант, если вы работаете с разнообразными данными в масштабе и ищете минимальной поддержки. Нельзя сказать, что документная СУБД или SQL база лучше во всем. Правильный выбор зависит от вашего сценария использования. Принимая решение, подумайте, какие типы операций будут выполняться чаще всего. Заключение В данной статье мы объяснили особенности документной базы данных, поговорили о плюсах и минусах системы, а также рассмотрели сценарии использования. Кроме того, был приведен список лучших документных СУБД и рассказано, как компании из рейтинга Forbes 500 пользуются этими системами для повышения эффективности своей деятельности и процессов разработки.
img
Всем привет! Сегодня в статье мы расскажем про настройку Point-to-Point GRE VPN туннелей на оборудовании Cisco и о том, как сделать их защищенными при помощи IPsec. Generic Routing Encapsulation (GRE) - это протокол туннелирования, разработанный компанией Cisco, который позволяет инкапсулировать широкий спектр протоколов сетевого уровня в point-to-point каналах. Туннель GRE используется, когда пакеты должны быть отправлены из одной сети в другую через Интернет или незащищенную сеть. В GRE виртуальный туннель создается между двумя конечными точками (маршрутизаторами Cisco), а пакеты отправляются через туннель GRE. Важно отметить, что пакеты, проходящие внутри туннеля GRE, не шифруются, поскольку GRE не шифрует туннель, а инкапсулирует его с заголовком GRE. Если требуется защита данных, IPSec должен быть настроен для обеспечения конфиденциальности данных - тогда GRE-туннель преобразуется в безопасный VPN-туннель GRE. На приведенной ниже схеме показана процедура инкапсуляции простого незащищенного пакета GRE, проходящего через маршрутизатор и входящего в туннельный интерфейс: Хотя многие могут подумать, что туннель GRE IPSec между двумя маршрутизаторами похож на VPN-соединение IPSec между сайтами, это не так. Основное отличие состоит в том, что туннели GRE позволяют multicast пакетам проходить через туннель, тогда как IPSec VPN не поддерживает multicast пакеты. В больших сетях, где необходимы протоколы маршрутизации, такие как OSPF, EIGRP, туннели GRE - ваш лучший выбор. По этой причине, а также из-за того, что туннели GRE гораздо проще в настройке, инженеры предпочитают использовать GRE, а не IPSec VPN. В этой статье объясняется, как создавать простые незащищенные (unprotected) и безопасные (IPSec encrypted) туннели GRE между конечными точками. Мы объясним все необходимые шаги для создания и проверки туннеля GRE (незащищенного и защищенного) и настройки маршрутизации между двумя сетями. Создание Cisco GRE туннеля Туннель GRE использует интерфейс «туннель» - логический интерфейс, настроенный на маршрутизаторе с IP-адресом, где пакеты инкапсулируются и декапсулируются при входе или выходе из туннеля GRE. Первым шагом является создание нашего туннельного интерфейса на R1: R1(config)# interface Tunnel0 R1(config-if)# ip address 172.16.0.1 255.255.255.0 R1(config-if)# ip mtu 1400 R1(config-if)# ip tcp adjust-mss 1360 R1(config-if)# tunnel source 1.1.1.10 R1(config-if)# tunnel destination 2.2.2.10 Все туннельные интерфейсы участвующих маршрутизаторов всегда должны быть настроены с IP-адресом, который не используется где-либо еще в сети. Каждому туннельному интерфейсу назначается IP-адрес в той же сети, что и другим туннельным интерфейсам. В нашем примере оба туннельных интерфейса являются частью сети 172.16.0.0/24. Поскольку GRE является протоколом инкапсуляции, мы устанавливаем максимальную единицу передачи (MTU - Maximum Transfer Unit) до 1400 байт, а максимальный размер сегмента (MSS - Maximum Segment Size) - до 1360 байт. Поскольку большинство транспортных MTU имеют размер 1500 байт и у нас есть дополнительные издержки из-за GRE, мы должны уменьшить MTU для учета дополнительных служебных данных. Установка 1400 является обычной практикой и гарантирует, что ненужная фрагментация пакетов будет сведена к минимуму. В заключение мы определяем туннельный источник, который является публичным IP-адресом R1, и пункт назначения - публичный IP-адрес R2. Как только мы завершим настройку R1, маршрутизатор подтвердит создание туннеля и сообщит о его состоянии: R1# *May 21 16:33:27.321: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up Поскольку интерфейс Tunnel 0 является логическим интерфейсом, он останется включенным, даже если туннель GRE не настроен или не подключен на другом конце. Далее мы должны создать интерфейс Tunnel 0 на R2: R2(config)# interface Tunnel0 R2(config-if)# ip address 172.16.0.2 255.255.255.0 R2(config-if)# ip mtu 1400 R2(config-if)# ip tcp adjust-mss 1360 R2(config-if)# tunnel source 2.2.2.10 R2(config-if)# tunnel destination 1.1.1.10 Интерфейс туннеля R2 настроен с соответствующим IP-адресом источника и назначения туннеля. Как и в случае с R1, маршрутизатор R2 сообщит нам, что интерфейс Tunnel0 работает: R2# *May 21 16:45:30.442: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up Маршрутизация сетей через туннель GRE На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга. Echo icmp от одного конца подтвердит это: R1# ping 172.16.0.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms R1# Опять же, этот результат означает, что две конечные точки туннеля могут видеть друг друга. Рабочие станции в любой сети по-прежнему не смогут достичь другой стороны, если на каждой конечной точке не установлен статический маршрут: R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2 На R1 мы добавляем статический маршрут к удаленной сети 192.168.2.0/24 через 172.16.0.2, который является другим концом нашего туннеля GRE. Когда R1 получает пакет для сети 192.168.2.0, он теперь знает, что следующим переходом является 172.16.0.2, и поэтому отправит его через туннель. Та же конфигурация должна быть повторена для R2: R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.0.1 Теперь обе сети могут свободно общаться друг с другом через туннель GRE. Защита туннеля GRE с помощью IPSec Как упоминалось ранее, GRE является протоколом инкапсуляции и не выполняет шифрование. Создание туннеля GRE точка-точка без какого-либо шифрования чрезвычайно рискованно, поскольку конфиденциальные данные могут быть легко извлечены из туннеля и просмотрены другими. Для этого мы используем IPSec для добавления уровня шифрования и защиты туннеля GRE. Это обеспечивает нам необходимое шифрование военного уровня и спокойствие. Наш пример ниже охватывает режим туннеля GRE IPSec. Настройка шифрования IPSec для туннеля GRE (GRE over IPSec) Шифрование IPSec включает в себя два этапа для каждого маршрутизатора. Эти шаги: Настройка ISAKMP (ISAKMP Phase 1) Настройка IPSec (ISAKMP Phase 2) Настройка ISAKMP (ISAKMP Phase 1) IKE существует только для установления SA (Security Association) для IPsec. Прежде чем он сможет это сделать, IKE должен согласовать отношения SA (ISAKMP SA) с партнером. Для начала, мы начнем работать над R1. Первым шагом является настройка политики ISAKMP Phase 1: R1(config)# crypto isakmp policy 1 R1(config-isakmp)# encr 3des R1(config-isakmp)# hash md5 R1(config-isakmp)# authentication pre-share R1(config-isakmp)# group 2 R1(config-isakmp)# lifetime 86400 Приведенные выше команды определяют следующее (в указанном порядке): 3DES - метод шифрования, который будет использоваться на этапе 1 Phase 1 MD5 - алгоритм хеширования Authentication pre-share - использование предварительного общего ключа в качестве метода проверки подлинности Group 2 - группа Диффи-Хеллмана, которая будет использоваться 86400 - время жизни ключа сеанса. Выражается в килобайтах или в секундах. Значение установлено по умолчанию. Далее мы собираемся определить Pre Shared Key (PSK) для аутентификации с партнером R1, 2.2.2.10: R1(config)# crypto isakmp key merionet address 2.2.2.10 PSK ключ партнера установлен на merionet. Этот ключ будет использоваться для всех переговоров ISAKMP с партнером 2.2.2.10 (R2). Создание IPSec Transform (ISAKMP Phase 2 policy) Теперь нам нужно создать набор преобразований, используемый для защиты наших данных. Мы назвали это TS: R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac R1(cfg-crypto-trans)# mode transport Вышеуказанные команды определяют следующее: SP-3DES - метод шифрования MD5 - алгоритм хеширования Установите IPSec в транспортный режим. Наконец, мы создаем профиль IPSec для соединения ранее определенной конфигурации ISAKMP и IPSec. Мы назвали наш профиль IPSec protect-gre: R1(config)# crypto ipsec profile protect-gre R1(ipsec-profile)# set security-association lifetime seconds 86400 R1(ipsec-profile)# set transform-set TS Теперь мы готовы применить шифрование IPSec к интерфейсу туннеля: R1(config)# interface Tunnel 0 R1(config-if)# tunnel protection ipsec profile protect-gre Ну и наконец пришло время применить ту же конфигурацию на R2: R2(config)# crypto isakmp policy 1 R2(config-isakmp)# encr 3des R2(config-isakmp)# hash md5 R2(config-isakmp)# authentication pre-share R2(config-isakmp)# group 2 R2(config-isakmp)# lifetime 86400 R2(config)# crypto isakmp key merionet address 1.1.1.10 R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac R2(cfg-crypto-trans)# mode transport R2(config)# crypto ipsec profile protect-gre R2(ipsec-profile)# set security-association lifetime seconds 86400 R2(ipsec-profile)# set transform-set TS R2(config)# interface Tunnel 0 R2(config-if)# tunnel protection ipsec profile protect-gre Проверка GRE over IPSec туннеля Наконец, наш туннель был зашифрован с помощью IPSec, предоставляя нам столь необходимый уровень безопасности. Чтобы проверить и проверить это, все, что требуется, это попинговать другой конец и заставить туннель VPN IPSec подойти и начать шифрование/дешифрование наших данных: R1# ping 192.168.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms Используя команду show crypto session, мы можем быстро убедиться, что шифрование установлено и выполняет свою работу: R1# show crypto session Crypto session current status Interface: Tunnel0 Session status: UP-ACTIVE Peer: 2.2.2.10 port 500 IKE SA: local 1.1.1.10/500 remote 2.2.2.10/500 Active IPSEC FLOW: permit 47 host 1.1.1.10 host 2.2.2.10 Active SAs: 2, origin: crypto map Поздравляю! Мы только что успешно создали Point-to-point GRE over IPSec VPN туннель между двумя маршрутизаторами Cisco.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59