По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Давайте рассмотрим один пример настройки DHCPv6:
В этом примере у нас есть DHCP-клиент, маршрутизатор и DHCP-сервер. Поскольку DHCP-клиент и DHCP-сервер не находятся в одной подсети, нам придется настроить маршрутизатор для ретрансляции сообщений DHCP.
Поиск клиентом IPv6 адреса будет начинаться с сообщения запроса:
Клиент будет использовать свой link-local адрес в качестве источника, а адрес назначения будет многоадресный адрес FF02:: 1:2 (all-DHCP-agents). Это link-local multicast адрес, поэтому он не будет покидать подсеть. В результате DHCP-сервер никогда не получит это сообщение запроса.
На маршрутизаторе мы настроим ретрансляцию DHCP таким образом, чтобы запрашивающее сообщение было переадресовано на DHCP-сервер:
Router(config)#interface fa0/0
Router(config-if)#ipv6 dhcp relay destination 2001:5:6:7::2
Это гарантирует, что маршрутизатор пересылает сообщения DHCP между клиентом и DHCP-сервером. Вот как это выглядит:
Маршрутизатор переадресует сообщение запроса, и адрес будет изменнен. Источником будет IPv6-адрес на интерфейсе Fa1/0 нашего маршрутизатора, а местом назначения-IPv6-адрес DHCP-сервера. Это большая разница по сравнению с DHCP relay для IPv4, где был бы использован IP-адрес на Fa0/0.
Другие сообщения DHCP будут использовать те же адреса. Между маршрутизатором и DHCP-сервером мы будем использовать 2001:5:6:7::1 и еще 2001:5:6:7::2 адреса. Маршрутизатор будет перенаправлять трафик на DHCP-клиент, используя его link-local адрес и в качестве места назначения.
Всем привет! Сегодня в статье мы расскажем про настройку 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.
Построение модели API требует стратегического подхода, и он связан с CRUD. Направляя разработчиков целиком и полностью, CRUD прокладывает путь для разработчиков API, ведя их по пути разработки доработанных и высококлассных API.
Что такое CRUD?
CRUD – это сокращение от Create (создание), Read (чтение), Update (модификация) и Delete (удаление). Эти четыре функции являются ключевыми принципами, которым следуют разработчики и программисты API при создании надежных API. В соответствии с отраслевым стандартом каждая модель API должна следовать всем этим четырем (или как минимум трем) принципам в процессе выполнения.
Некоторые языки программирования следуют CRUD в том виде, в котором он есть, в то время как лишь некоторые используют адаптированную версию CRUD. К языкам, использующим инфраструктуру CRUD, относятся: Python, PHP, Java и .Net.
CRUD работает как напоминание для разработчиков о том, что необходимо для того, чтобы приложение чувствовало себя полноценным. Она возникла в начале 80-х годов. В то время его использовали для иллюстрирования жизнеспособности базы данных SQL. Со временем он расширил список областей применения и стал ключевым принципом проектирования для DDS и HTTP.
Определение функций CRUD
Однозначное понимание функций CRUD позволяет разработчикам максимально эффективно использовать их. Итак, ознакомьтесь с каждой из 4 функций и рассмотрите примеры для того, чтобы лучше понимать их принцип действия.
Create
Эта функция используется для оповещения о введении любых новых изменений в базу данных и обеспечения их реализации. В реляционной базе данных SQL, Create называется INSERT. Этот оператор разрешает конечному пользователю создавать новые строки данных и позволяет ранее сохраненным данным легко взаимодействовать с новой базой данных.
Пример:
Допустим, мы добавляем Фрукты в список http://www.example.com/fruits/. Для того, чтобы создать объект «Манго», мы должны оправить запрос POST на этот URL:
{
“fruit": {
"name": “Mango”,
"color": “Yellow”
}
}
Этот код создаст еще один объект в списке фруктов с именем «манго», у которого есть свойство (цвет) со значением «желтый». При успешном создании вы получите HTTP-ответ 201.
Read
Что функция поиска делает в обычных случаях, вы можете узнать, почитав о реляционных базах данных. Конечным пользователям разрешено искать различимые значения или данные в таблице данных и находить значения. Можно использовать определённые ключевые слова или фильтровать данные, чтобы получить точную информацию.
Пример:
Теперь для того, чтобы прочитать список, в который вы добавили объект в предыдущем примере, воспользуемся GET-запросом.
Используйте этот код:
GET http://www.example.com/fruits/
Если для вашего запроса существует запись, то вы увидите HTTP-ответ 200. Также вы увидите список фруктов.
{
"fruits": [
{
"id": 1,
"name": “Apple”,
"color": “Red”
},
{
"id": 2,
"name": “Grapes”,
"color": “Green”
},
...
{
"id": 3,
"name": “Mango”,
"color": “Yellow”
}
]
}
Для того, чтобы увидеть детали, связанные с конкретным объектом Манго, который мы создали, используйте этот код:
GET http://www.example.com/fruits/3/
Update
Функция модификации полезна для изменения уже существующих записей без внесения каких-либо нарушений в существующую базу данных.
Для полной модификации требуется некоторая модификация в нескольких областях. Эта функция известна как Update как в SQL, так и в Oracle HCM Cloud.
Пример:
Для того, чтобы изменить значение объекта, выполним PUT-запрос для URL-адреса конкретного объекта. Вот так:
PUT http://www.example.com/fruits/3/
{
"fruits": {
"name": “Ripe Watermelon”,
"color": “Blood Red”
}
}
Если возвращается идентификатор состояния 200, то обновление прошло успешно. Для подтверждения вы можете прочитать этот объект повторно и просмотреть значения для него.
Delete
При помощи этой функции пользователи могут удалять определенные записи или данные из определенной базы данных. Вы можете удалять данные, которые больше не нужны или устарели.
Удаление бывает двух типов: обратимое или необратимое удаление. Необратимое удаление удаляет данные один раз, а обратимое используется для обновления состояния строки данных без ее окончательного удаления.
Пример:
Это очень просто. Давайте удалим созданный нами объект.
DELETE http://www.example.com/fruits/3/
Теперь при GET-запросе (чтение) вы получите код 404, который говорит о том, что данных по вашему запросу нет.
Преимущества CRUD
Есть что-то, что заставляет разработчиков и дизайнеров приложений предпочитать CRUD любому другому подходу. Это «что-то» - это непревзойденная производительность, интегрированная с некоторыми уникальными функциями. Основные преимущества, которыми можно воспользоваться после запуска CRUD, представлены ниже.
Меньшая вероятность атак путем внедрения SQL-кода
Использование SQL-языка имеет больше шансов столкнуться с SQL-атаками, поскольку все операторы SQL выполняются непосредственно на SQL-серверах. Сервер также хранит инструкции и процедуры SQL, доступ неавторизованных ресурсов к которым может оказаться фатальным.
Использование CRUD позволяет контролировать возможные атаки путем внедрения SQL-кода, поскольку использует уже сохраненные действия и не требует создания динамических запросов с использованием данных конечного пользователя. Кроме того, такой подход использует однозначное цитирование параметров SQL-операторов.
Лучшая защита от случайного просмотра
Пользователи специальных SQL-операторов должны получить разрешение на доступ к таблицам базы данных. После успешного предоставления разрешения конечным пользователям разрешается читать и управлять данными, имеющимися в Excel, Word и любой другой программе. Также возможен обход бизнес-правил приложения.
Однако делать это не всегда выгодно. Риски утечки данных есть всегда. CRUD в такой ситуации полезен, так как делает возможным использование ролей приложений. Используя роли приложений, можно обеспечить высоко интегрированную безопасность базы данных и контролировать права доступа.
Полномочия могут защищаться паролем, а поскольку пароли также интегрированы в приложение, то изменить их сложно. Таким образом, можно покончить со случайным просмотром.
CRUD vs REST – сравнение
CRUD и REST очень часто используют для обозначения одного и того же подхода. Такая путаница очевидна, так как приложения REST следуют принципу, подобному CRUD, для взаимодействия с другими приложениями или компонентами. Тем не менее, эти два термина не идентичны и имеют ряд явных сходств и различий.
Что общего?
Приложения REST разрабатываются с сохранением определенного набора ресурсов в смысловом центре. Эти ресурсы, как и ресурсы CRUD, можно легко создавать, читать, модифицировать и удалять. Просто вместо Create, Read, Update и Delete в REST используются ресурсы PUT/POST, GET, PATCH/POST и DELETE.
В чем разница?
Абсолютно точно, то у этих двоих больше различий, чем сходств. Взгляните на ключевые различия между ними.
В части определения REST упоминается как архитектурная система, а CRUD – как функция.
REST «крутится» вокруг ресурсов, основанных на компонентах HTTP.
CRUD «крутится» вокруг информации, хранящейся в настройках базы данных.
CRUD может быть частью REST, но REST не может быть частью CRUD. REST – это независимый подход, который может правильно функционировать и без CRUD.
Что такое CRUD-тестирование?
CRUD-тестирование – это оригинальная методология тестирования методом «черного ящика», которая широко используется для подтверждения полезности данного программного обеспечения в режиме реального времени. Это понятие используется для SQL и других ресурсов СУБД, для которых гарантируется точное отображение данных, сквозное обслуживание ACID-свойств и несравнимая целостность данных.
Обеспечение безопасности в REST и CRUD-операциях
Аутентификация, авторизация и учет использования ресурсов (или ААА – Authentication, Authorization, Accounting) – это крайне эффективная практика безопасности, которая одинаково хорошо подходят для REST и CRUD. Она включает в себя аутентификацию конечных пользователей, выполнение авторизации перед каждым доступом и привлечение конечных пользователей к ответственности за свои действия или использование данных.