ИТ База знаний
Курс по Asterisk
Полезно
— Узнать IP — адрес компьютера в интернете
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Калькулятор инсталляции IP — АТС Asterisk
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Популярное и похожее
Курс по сетям
Настройка Site-To-Site IPSec VPN на Cisco
Cisco ASA 5506-X: интерфейс BVI
Настройка Router-on-a-Stick на Cisco
Обнаружен! NDP: теория и настройка
Фильтрация маршрутов с помощью карт маршрутов
Настройка IPv6 с EUI-64 на Cisco
Пример настройки SPAN/RSPAN/ERSPAN
Еженедельный дайджест
Настройка GRE туннеля на Cisco
Всем привет! Сегодня в статье мы расскажем про настройку Point-to-Point GRE VPN туннелей на оборудовании Cisco и о том, как сделать их защищенными при помощи IPsec. Generic Routing Encapsulation (GRE) — это протокол туннелирования, разработанный компанией Cisco, который позволяет инкапсулировать широкий спектр протоколов сетевого уровня в point-to-point каналах.
Обучайся в Merion Academy
Пройди курс по сетевым технологиям
Начать
Туннель 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:
Все туннельные интерфейсы участвующих маршрутизаторов всегда должны быть настроены с 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, маршрутизатор подтвердит создание туннеля и сообщит о его состоянии:
Поскольку интерфейс Tunnel 0 является логическим интерфейсом, он останется включенным, даже если туннель GRE не настроен или не подключен на другом конце.
Далее мы должны создать интерфейс Tunnel 0 на R2:
Интерфейс туннеля R2 настроен с соответствующим IP-адресом источника и назначения туннеля. Как и в случае с R1, маршрутизатор R2 сообщит нам, что интерфейс Tunnel0 работает:
Маршрутизация сетей через туннель GRE
На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга. Echo icmp от одного конца подтвердит это:
Опять же, этот результат означает, что две конечные точки туннеля могут видеть друг друга. Рабочие станции в любой сети по-прежнему не смогут достичь другой стороны, если на каждой конечной точке не установлен статический маршрут:
На R1 мы добавляем статический маршрут к удаленной сети 192.168.2.0/24 через 172.16.0.2, который является другим концом нашего туннеля GRE. Когда R1 получает пакет для сети 192.168.2.0, он теперь знает, что следующим переходом является 172.16.0.2, и поэтому отправит его через туннель.
Та же конфигурация должна быть повторена для R2:
Теперь обе сети могут свободно общаться друг с другом через туннель 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:
Приведенные выше команды определяют следующее (в указанном порядке):
- 3DES — метод шифрования, который будет использоваться на этапе 1 Phase 1
- MD5 — алгоритм хеширования
- Authentication pre-share — использование предварительного общего ключа в качестве метода проверки подлинности
- Group 2 — группа Диффи-Хеллмана, которая будет использоваться
- 86400 — время жизни ключа сеанса. Выражается в килобайтах или в секундах. Значение установлено по умолчанию.
Далее мы собираемся определить Pre Shared Key (PSK) для аутентификации с партнером R1, 2.2.2.10:
PSK ключ партнера установлен на merionet. Этот ключ будет использоваться для всех переговоров ISAKMP с партнером 2.2.2.10 (R2).
Создание IPSec Transform (ISAKMP Phase 2 policy)
Теперь нам нужно создать набор преобразований, используемый для защиты наших данных. Мы назвали это TS:
Вышеуказанные команды определяют следующее:
- SP-3DES — метод шифрования
- MD5 — алгоритм хеширования
- Установите IPSec в транспортный режим.
Наконец, мы создаем профиль IPSec для соединения ранее определенной конфигурации ISAKMP и IPSec. Мы назвали наш профиль IPSec protect-gre:
Теперь мы готовы применить шифрование IPSec к интерфейсу туннеля:
Ну и наконец пришло время применить ту же конфигурацию на R2:
Проверка GRE over IPSec туннеля
Наконец, наш туннель был зашифрован с помощью IPSec, предоставляя нам столь необходимый уровень безопасности. Чтобы проверить и проверить это, все, что требуется, это попинговать другой конец и заставить туннель VPN IPSec подойти и начать шифрование/дешифрование наших данных:
Используя команду show crypto session, мы можем быстро убедиться, что шифрование установлено и выполняет свою работу:
Поздравляю! Мы только что успешно создали Point-to-point GRE over IPSec VPN туннель между двумя маршрутизаторами Cisco.
Источник
Настройка GRE туннелей в MikroTik RouterOS
Очень часто перед системным администратором стоит задача по объеденению в одну сеть 2 или более офисов находящихся в разных районах города, или вообще в разных городах, чтобы пользователи могли пользоваться общими ресурсами. Если не нужно шифровать данные(что в большинстве случаев так и есть), то наиболее оптимальным вариантом является объеденение двух точек через GRE туннель.
Нужно разобраться с MikroTik, но не определились с чего начать? В курсе «Настройка оборудования MikroTik» все по порядку. Подойдет и для начала работы с этим оборудованием, и для того, чтобы систематизировать знания. Это видеокурс из 162 уроков и 45 лабораторных работ, построен на официальной программе MTCNA. Проходить можно, когда удобно и пересматривать по необходимости – материалы курса выдаются бессрочно. Также есть 30 дней на личные консультации с автором. На пробу выдают 25 уроков бесплатно, заказать их можно на странице курса.
На рисунке показан пример работы GRE туннеля, между двумя маршрутизаторами A и B находится несколько маршрутизаторов, туннель позволяет обеспечить связь между сегментами сети 192.168.1.0/24 и 192.168.3.0/24 так, как если бы маршрутизаторы A и B были соединены прямым линком.
Для работы GRE туннеля оба маршрутизатора должены иметь внешние ip адреса на маршрутизаторе А это 11.11.11.11 на маршрутизаторе B 33.33.33.33 . Настройку маршрутизаторов А и В будем производить через консоль winbox.
На стройка маршрутизатора A
Создаем новый интерфейс для GRE, для этого заходим в панель interfaces, нажимаем на плюсик и выбираем GRE Tunnel. Указываем Remote Address, ip адрес маршрутизатора В, в нашем случае 33.33.33.33, все остальное оставим как есть.
Затем идем в меню IP->Addresses, нажимаем на плюсик и в строке Address прописываем ip адрес для GRE интерфейса у нас он 192.168.2.1/30, этот адрес может быть любым, мы его сами назначаем для туннеля, в строке interface, из выпадающего списка, выбираем название нашего интерфейса созданного выше, в нашем случае это» gre-tunnel1″ 
Заходим в меню IP->Routes нажимаем на плюсик и добавляем маршут до локальной сети маршрутизатора В, в строке DST.Address прописываем нашу удаленную сеть, которая настроена на маршрутизаторе В, у нас она 192.168.3.0/24, Gateway указываем ip адрес который мы назначили на GRE туннель на маршрутизаторе В, у нас это 192.168.2.2
Настройка маршрутизатора В
Маршрутизатор В настраивается зеркально маршрутизатору А.
1.Добавляем новый GRE интерфейс, в качестве Remote Address указываем внешний ip маршрутизатора А, у нас он 11.11.11.11
2.Прописываем на созданном GRE интерфейсе адрес, он должен быть в одной сети с адресом GRE интерфейса маршрутизатора А, у нас это 192.168.2.2
3.Прописываем новый маршрут, DST.Address указываем локальную сеть маршрутизатора А(у нас 192.168.1.1), а Gateway прописываем ip адрес на GRE интерфейсе маршрутизатора А(у нас 192.168.2.1).
После этих настроек компьютеры из локальной сети А должны «увидеть» компьютеры из локальной сети В. Это можно проверить командой ping.
Обучающий курс по настройке MikroTik
Нужно разобраться с MikroTik, но не определились с чего начать? В курсе «Настройка оборудования MikroTik» все по порядку. Подойдет и для начала работы с этим оборудованием, и для того, чтобы систематизировать знания. Это видеокурс из 162 уроков и 45 лабораторных работ, построен на официальной программе MTCNA. Проходить можно, когда удобно и пересматривать по необходимости – материалы курса выдаются бессрочно. Также есть 30 дней на личные консультации с автором. На пробу выдают 25 уроков бесплатно, заказать их можно на странице курса.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
Сайт ARNY.RU
CISCO GRE — в статье рассмотрено развёртывание туннеля GRE и связанные с этим особенности на роутерах CISCO в виртуальной среде EVE-NG.
Немного о GRE
GRE (Generic Routing Encapsulation), нет ничего проще, чем GRE туннель. Буквально пара настроек и туннель готов. Какой-то большой смысловой нагрузки в этом туннеле нет. Но не всё так просто, дальше будет видно 🙂 GRE «всеядный»: GRE может инкапсулировать мульткаст-трафик, броадкаст-трафик. В этом основное его достоинство. Сам GRE не имеет собственного шифрования, отсюда и пользы от GRE в чистом виде нет. Существовать так он может только где-то внутри большой корпоративной сети. В частности GRE может применяться чтобы соединить 2 области IPv6 через область IPv4.
Состоит GRE из 3 компонентов (на картинке):
- Протокола-«пассажира» — любой протокол 3 уровня;
- Несущего протокола — непосредственно сам GRE;
- Протокола-«транспорта» — это IP.
- Про GRE говорится много, начиная с CCNA R&S (200-105 ICND2);
- Во внешнем заголовке IP в поле Protocol используется значение 47, указывающее на то, что внутри инкапсулирован GRE;
- GRE разработан CISCO, но сейчас это IETF стандарт. Он расписан в RFC 2784 и обновлён в RFC 2890;
- Протокол GRE по умолчанию является протоколом без отслеживания состояния (stateless) и не содержит механизмов управления потоком;
- Заголовок GRE вместе с заголовком IP туннелирования, создаёт 24 байта дополнительной служебной информации;
- Пакеты GRE являются юникаст-пакетами;
- Туннель GRE поддерживает функцию Keepalive.
Тестовая среда
Средой для тестов как всегда является EVE-NG (кто ещё не настраивал, бежать настраивать). Тестовая схема:
Почему такая вот странная схема? Как раз симулирует «большую» корпоративную среду. Роутеры не граничные, ната на них нет, он там не нужен при таком развёртывании. Зато есть какой-то протокол маршрутизации (IGP). Для определённости на всех роутерах настроен EIGRP:
Поэтому есть полная доступность всех адресов с любого устройства:
Нужно обратить внимание, что подсеть 192.168.2.0/24 находится в 5 переходах (хопах) от подсети 192.168.1.0/24. В качестве хопа считается только входящий интерфейс каждого роутера по пути следования пакета.
Настройка GRE
Туннель прокидывается между интерфейсами роутеров R1 и R4:
- Как можно видеть, из-за дополнительных заголовков в 24 байта MTU сокращён до 1476 байт;
- Протокол/транспорт по умолчанию GRE/IP, поэтому не надо вводить дополнительную команду для туннеля:
Особенности настройки
Посмотрим таблицу маршрутизации:
Из таблицы видно, что на данный момент компьютеры ещё не используют туннель, маршрут EIGRP для подсети 192.168.2.0 указывает на интерфейс GigabitEthernet0/0, а должен на интерфейс Tunnel1. Добавим подсеть туннеля в EIGRP:
Роутеры R1 и R4 сформировали отношения смежности через туннель (а значит мультикаст через туннель ходит):
Но если посмотреть снова таблицу маршрутизации, то ничего ровным счетом не изменилось, смотрим теперь таблицу топологии EIGRP:
Маршрут через туннель имеет бОльшую метрику и не попадает в таблицу маршрутизации. Посмотрим интерфейсы:
Проверим/посчитаем метрику EIGRP для каждого интерфейса по формуле:
Всё верно. Как же заставить трафик идти через туннель?
Изменение параметров интерфейса
Можно изменять параметры Bandwidth (Delay) на интерфейсах. Изменять Bandwidth не рекомендуется, так как он участвует в расчётах для QoS, SNMP. Рекомендуется крутить Delay. При изменении данных параметров, одного или обоих, физические характеристики интерфейса не изменяются. Эти параметры нужны только для настройки протоколов.
Но из-за таких изменений можно словить всякие неочевидные штуки (типа петли в нашем случае). Поэтому лучше этой возможностью пользоваться в крайнем случае.
Попробуем уменьшить Bandwidth на интерфейсе GigabitEthernet0/0:
Как только метрика через туннель становится меньше, чем через гигабитный интерфейс, туннель сразу гасится с сообщениями о петле и рекурсивном роутинге.
Статическая маршрутизация
Смотрим таблицу маршрутизации:
Что произошло? Статический маршрут, который имеет административное расстояние равное 1, заменил собой маршрут EIGRP, у которого административное расстояние (AD) 90. Проверяем на компьютере:
Другой протокол маршрутизации
Убираем статику, иначе она своей AD = 1 забьёт все другие маршруты:
Настраиваем протокол OSPF на R1 и R4:
Обращаю внимание, что для OSPF совпадение Process ID (1 и 101) необязательно.
Убираем информацию о подсетях 192.168.1.0/24, 192.168.2.0/24 из EIGRP:
Зачем это делать? EIGRP имеет AD = 90, против 110 у OSPF. Поэтому пока существует маршрут EIGRP, у маршрута OSPF нет шансов попасть в таблицу маршрутизации.
Смотрим таблицу маршрутизации:
Policy-Based Routing
Возвращаем как было изначально EIGRP:
Если кто обратил внимание, то подсети были добавлены без обратной маски. Так можно сделать потому, что наши подсети совпадают с подсетью класса C.
Пакеты от PC1 к PC2 и обратно снова ходят мимо туннеля.
Создаём ACL для отбора трафика между PC1 и PC2:
Создаём политику перенаправления трафика:
Политика может быть применена для трафика порождаемого внутри самого роутера, тогда она вводится как локальная в режиме глобальной конфигурации. Или же политика применяется для транзитного трафика, тогда она вешается на интерфейс.
PBR для локального трафика
Запускаем трассировку с роутера R1:
Теперь применяем политику и снова проверяем:
PBR для транзитного трафика
Убираем локальную политику:
Вешаем на внутренний интерфейс:
Теперь все пакеты, проходящие через GigabitEthernet 0/1 проверяются на совпадение с ACL 101 и при таком совпадении перенаправляются в туннель. Проверяем для PC1:
Как видно, пакеты для адресов 10.10.0.0/16 по прежнему ходят мимо туннеля, так и должно быть.
Особенности PBR
С PBR нужно обращаться аккуратно, любая ошибка в настройке может привести к неочевидным последствиям. Удалим «случайно» ACL 101 на R1:
Теперь пакеты для адресов 10.10.0.0/16 (кроме адреса интерфейса роутера R1 10.10.10.1) заворачивают сначала в туннель и уже из него к нужному адресу. Маршрут получается не оптимальный, а кривой.
PBR перехватывает пакеты до стандартной маршрутизации. Другими словами PBR действует на входящий (ingress) трафик:
Поэтому если повесть политику на GigabitEthernet 0/0 (куда прибывают уже смаршрутизированные пакеты), то политика не отрабатывает, попаданий в ACL 101 нет. Включим дебаг и ещё раз запустим пинг с PC1 на PC2. Что при этом происходит, интересная штука:
Политика не проверяет исходящие с GigabitEthernet 0/0 пакеты PC1, но проверяет ответные от PC2, так как они являются входящими для интерфейса.
Keepalive
Протокол GRE по умолчанию является протоколом без отслеживания состояния, то есть статус одной оконечной точки туннеля неизвестен для другой. Интерфейс туннеля сразу переходит в Up, если в таблице маршрутизации имеется маршрут до destination туннеля. Когда маршрут динамический, туннель полагается на таймеры протокола маршрутизации, чтобы отслеживать состояние маршрута и значит состояние туннеля. Если же это статический маршрут, то и механизмов никаких нет.
Механизм Keepalive исправляет эту ситуацию. И траблшутинге позволит сразу оценить в каком состоянии туннель. Подробно работа Keepalive для GRE в реализации CISCO рассказана тут, значения параметров описаны здесь. Параметры:
- Period — Опциональный параметр частоты отправки сообщений Keepalive (по умолчанию 10 секунд);
- Retries — Опциональный параметр, счётчик невернувшихся обратных пакетов (по умолчанию 5).
Кратко перескажу работу Keepalive: сторона туннеля (R1), на которой настроен Keepalive периодически отправляет «хитрые» пакеты другой стороне (R4), когда хитрый пакет распакуется на R4, то внутри окажется обратный пакет для R1 (пустой, без нагрузки). Когда R1 получит обратный пакет, то он поймёт, что всё в порядке. Если обратный пакет не вернётся, то счетчик увеличивается на 1. Когда счётчик достигнет установленного значения, Keepalive переведёт Line Protocol для интерфейса Tunnel в состояние Down. Пользовательский трафик отправляться не сможет. При этом отправка пакетов Keepalive продолжится. Как только будет получен обратный пакет, Line Protocol будет переведён в UP, а счётчик обнулится.
При работе Keepalive сразу можно увидеть когда есть проблема с туннелем по упавшему Line Protocol. Для нашего примера:
Должно быть по умолчанию keepalive 10 5, на практике немного отличается: keepalive 10 3. Теперь посмотрим WireShark:
Теперь погасим интерфейс Tunnel 1 на R4:
И посмотрим что будет на R1:
После поднятия интерфейса туннеля на R4, туннель полностью поднимается и на R1.
Заключение
Рассмотренные примеры больше умозрительные, чем боевые, так как GRE в чистом виде неинтересен, кроме каких-то очень частных случаев. Рекомендую рассмотреть боевую реализацию GRE over IPSec.
Источник