Сети для самых маленьких часть 7

Туннели GRE между объектами

Универсальная инкапсуляция при маршрутизации (Generic Routing Encapsulation, GRE) — один из примеров базового, незащищённого протокола создания туннелей для site-to-site VPN. GRE — это протокол туннелирования, разработанный компанией Cisco, позволяющий инкапсулировать пакеты протоколов различного типа внутри IP-туннелей. Благодаря этому создаётся виртуальный канал «точка-точка» до маршрутизаторов Cisco в удалённых точках поверх IP-сети.

GRE предназначен для управления процессом передачи многопротокольного и группового IP-трафика между двумя и более площадками, между которыми связь может обеспечиваться только по IP. Он может инкапсулировать пакеты протоколов различного типа в IP-туннеле.

Как показано на рисунке, интерфейс туннеля поддерживает заголовки для всех указанных ниже протоколов:

• Инкапсулированный протокол (или «протокол-пассажир»), например IPv4, IPv6, AppleTalk, DECnet или IPX

• Протокол инкапсуляции (или несущий протокол), в данном случае GRE

• Протокол доставки («протокол-транспорт»), например IP, который передаёт данные протокола инкапсуляции.

Характеристики GRE

GRE — это протокол туннелирования, разработанный компанией Cisco, который позволяет инкапсулировать пакеты протоколов различного типа внутри IP-туннелей и создавать виртуальный канал «точка-точка» до маршрутизаторов Cisco в удалённых точках поверх IP-сети. Туннелирование IP с помощью GRE позволять расширять сеть через однопротокольную магистральную среду. Это обеспечивается путем соединения между собой различных многопротокольных подсетей в однопротокольной магистральной среде.

Протокол GRE обладает следующими характеристиками:

• Спецификации GRE определены в стандарте IETF (RFC 2784).

• Во внешнем заголовке IP в поле протокола используется значение 47, указывающее на то, что за ним будет следовать заголовок GRE.

• При инкапсуляции GRE для поддержки инкапсуляции любого протокола 3 уровня модели OSI в заголовке GRE используется поле «типа протокола» (protocol type). Типы протоколов определены в стандарте RFC 1700 как «EtherTypes».

• Сам протокол GRE является протоколом без отслеживания состояния (stateless) и по умолчанию не содержит механизмов управления потоком.

• Для защиты полезной нагрузки в протоколе GRE отсутствуют какие-либо стойкие механизмы безопасности.

• Заголовок GRE вместе с заголовком IP туннелирования, указанным на рисунке, создаёт, по крайней мере, 24 байта дополнительной служебной информации для туннелированных пакетов.
• GRE используется для создания туннеля VPN между двумя узлами, как показано на рисунке 1. Для реализации туннеля GRE сетевой администратор должен сначала узнать IP-адреса конечных точек туннеля. После этого для настройки туннеля GRE следует выполнить следующую процедуру:Шаг 1. Создайте интерфейс туннеля с помощью команды interface tunnel number.Шаг 2. Укажите IP-адрес источника туннеля.Шаг 3. Укажите IP-адрес назначения туннеля.Шаг 4. Укажите IP-адрес для интерфейса туннеля.Шаг 5. (Дополнительно) Укажите на интерфейсе туннеля в качестве используемого режима режим GRE Режим GRE является режимом по умолчанию для интерфейса туннеля в программном обеспечении Cisco IOS.На рисунке 2 приведен пример базовой настройки туннеля GRE для маршрутизатора R1.
• Настройка маршрутизатора R2 на рисунке 3 зеркальна по отношению к настройке R1.
• Для минимальной настройки требуется указать адреса источника и назначения туннеля. Подсеть IP также необходимо настроить таким образом, чтобы обеспечить связь по IP через канал туннеля. Для обоих интерфейсов туннеля в качестве источника туннеля указан локальный интерфейс serial S0/0/0, а в качестве назначения туннеля — интерфейс serial S0/0/0 маршрутизатора, с которым устанавливается туннель. IP-адрес назначается интерфейсам туннеля на обоих маршрутизаторах. Настройка протокола OSPF также позволяет обмениваться маршрутами через туннель GRE.Описания отдельных команд для туннеля GRE приведены на рисунке 4.
• Примечание. При настройке туннелей GRE может оказаться трудно запомнить, какие сети IP связаны с физическими интерфейсами, а какие — с интерфейсами туннеля. Следует помнить, что перед созданием туннеля GRE физические интерфейсы уже настроены. Команды tunnel source иtunnel destination указывают на IP-адреса предварительно настроенных физических интерфейсов. Команды ip address на интерфейсах туннеля определяют сеть IP, созданную специально для туннеля GRE.

Проверка туннеля GRE 

Для наблюдения и устранения неполадок в туннелях GRE можно использовать несколько команд. Для определения работоспособности интерфейса туннеля используйте команду show ip interface brief, как показано на рисунке 1.

Для проверки состояния туннеля GRE используйте команду show interface tunnel. Протокол канального уровня в интерфейсе туннеля GRE активен до тех пор, пока существует маршрут до адреса назначения туннеля. Перед реализацией туннеля GRE между IP-адресами физических интерфейсов на противоположных сторонах потенциального туннеля GRE должна уже существовать связь по IP. Транспортный протокол туннелирования отображается в выходных данных, также показанных на рисунке 1.

Если OSPF также настроен на обмен маршрутами по туннелю GRE, то с помощью команды show ip ospf neighbor убедитесь, что через интерфейс туннеля установлены отношения смежности OSPF. На рисунке 2 видно, что адрес соседнего устройства OSPF находится в сети IP, созданной для туннеля GRE.

GRE считается VPN, так как это частная сеть, которая создаётся посредством туннелирования через публичную сеть. Благодаря инкапсуляции туннель GRE создаёт виртуальный канал «точка-точка» до маршрутизаторов Cisco в удалённых точках поверх IP-сети.

Преимущества GRE заключаются в том, что его можно использовать для туннелирования трафика, отличного от IP, по сети IP, что делает возможным расширение сети путем подключения различных многопротокольных подсетей через однопротокольную магистральную среду. GRE также поддерживает процесс туннелирования групповой рассылки IP (IP multicast).

Это означает, что в туннеле можно использовать протоколы маршрутизации, что позволяет обеспечивать динамический обмен данными о маршрутизации в виртуальной сети. Наконец, на практике часто создаются туннели GRE «IPv6 по IPv4», где IPv6 является инкапсулированным протоколом, а IPv4 — протоколом-транспортом. В будущем их роли, очевидно, поменяются местами, так как IPv6 становится стандартным протоколом IP.

Однако GRE не обеспечивает шифрования и никаких других механизмов безопасности. Поэтому данные, отправляемые по туннелю GRE, не защищены. Если требуется безопасная передача данных, то необходимо настроить сети VPN с IPsec или с SSL.

Источник: http://zaycev.me/index.php/myblog/entry/2015/12/18/tunneli-gre-mezhdu-ob-ektami

Twistedminds

С каждым разом статьи становятся все больше, а почерк размашистей 🙂 В этот раз я решил разделить тему настройки GRE Туннелей, а так же их защиту с помощью IPSec на две части – теоретическую и практическую. Если вы пришли сюда из поисковых систем и сразу собираетесь бросаться в омут с головой, то можете непосредственно перейти к настройке GRE over IPSec с применением IPSec профилей и crypto map.

Туннели

В интерпретации Cisco туннель – это логический интерфейс, роль которого состоит в том, чтобы инкапсулирование пакеты одного протокола (passenger protocol), с помощью второго (carrier protocol) и передать его по третьему (transport protocol).

В роли протокола, который занимается инкапсуляцией могут выступать такие протоколы как GRE, IPIP. GRE (Generic Routing Encapsulation) – протокол, который в отличии от IPIP, позволяет инкапсулировать в себя другие протоколы, такие как AppleTalk, IP, IPX и другие.

Лишь бы ethertype был правильным.

Пакет, попавший в туннель с инкапсуляцией GRE, будет выглядеть следующим образом:

Внешний заголовок IP, заголовок GRE, внутренний заголовок IP, полезная нагрузка

Заголовок GRE может варьироваться от 4 до 16 байт в зависимости от того какие опции включены.

• C, K и S в заголовке это опции, говорящие следует ли ожидать поля с контрольной суммой (checksum), ключом (key) и номер последовательности (sequence number)
• ver – номер версии GRE (0)
• Protocol – ethertype инкапсулируемого протокола
• Checksum – контрольная сумма (опциональна)
• Key – ключ безопасности туннеля (опционален)
• Sequence number – номер последовательности (опционален)

По умолчанию все опции отключены и заголовок равен 4 байтами. Остальные опции можно включить в процессе конфигурации туннельного интерфейса:

Rx(config)#int tunnel #_number Rx(config-if)#tunnel checksum Rx(config-if)#tunnel key [0-4294967295] Rx(config-if)#tunnel sequence-datagrams

Пакет, попавший в IPIP туннель, будет выглядеть точно так же, только без заголовка GRE. По понятным причинам в качестве passenger protocol в IPIP туннеле может выступать только IP.

Чем же так хороши туннели?

• Например, когда ваши площадки используют приватные адреса и их надо объединить через Интернет.
• Позволяют объединять мультипротокольные сети, что уже не очень актуально.
• Ну, и самое главное,  позволяют шифровать информацию, передаваемую через сети с низким уровнем доверия, в комбинации с IPSec.Причем, в отличии от чистого IPSec, по такому каналу можно передавать не только unicast трафик, но и broadcast с multicast. Последний делает возможным работу протоколов динамической маршрутизации. Такие VPN являются постоянно доступными (always on), а не только когда существуют данные, попадающие под crypto ACL.

А проблемы?

• Recursive routing – когда протокол маршрутизации начинает считать, что использовать туннель до удаленного хоста выгоднее, чем реальный путь. Решается этот вопрос либо статическими маршрутами, либо процессом маршрутизации, отличным от используемого на WAN интерфейсах.
• IP Fragmentation

MTU и IP Fragmentation

MTU (Maximum Transfer Unit) указывает на максимальный размер информации в байтах, которая может быть передана. Для ethernet это 1500 байт, если не принимать во внимание Jumbo Frames. MSS или Maximum Segment Size – это максимальный размер передаваемого TCP сегмента и обычно равен 1460 байтам (1500 – 20 байт заголовка IP – 20 байт заголовка TCP).

Но тут в дело вступают туннели. Как я уже говорил, GRE добавляет свой заголовок (4 байта) и новый IP заголовок (20 байт), соответственно MTU на туннельном интерфейсе нужно уменьшить до 1476 байт в случае GRE и до 1480 в случае IPIP. Сделать это можно вручную или с помощью PMTUD – path MTU discovery.

Так же не стоит забывать о накладных расходах IPSec, в случае если мы решим шифровать данные попадающие в туннель. В худшем случае накладные расходы для IPSec, вдобавок к тем 24 байтам от GRE, будут выглядеть следующим образом:

Transform set	Накладные расходы, байт
esp AES + hash	73
esp AES	61
esp DES, 3DES	45
esp DES, 3DES + hash	57
esp NULL + hash	45
NAT-T	8
ah + hash	44

Сама Cisco рекомендует устанавливать MTU в 1400 байт вне зависимости от того работает GRE поверх IPSec в туннельном или в транспортном режиме. Делается это так:

Rx(config)# interface interface Rx(config-if)# ip mtu size

При использования VTI и чистых IPSec туннелей происходит префрагментация трафика до того, как он будет зашифрован.

Path MTU Discovery (PMTUD)

Основная проблема в ручной настройке MTU и/или MSS состоит в том, что по пути между вашими площадками может оказаться линк с MTU, скажем, 1300. Тут на помощь может придти PMTUD. Протокол целиком и полностью полагается на ICMP unreachable messages, которые должны быть разрешены на всем пути между соседями.

На GRE туннели он включается следующим образом:

Rx(config)# interface tunnel #_number Rx(config-if)# tunnel path-mtu-discovery

Работу PMTUD можно лицезреть с помощью команды debug tunnel.

Настройка GRE over IPSec >>>

Источник: http://twistedminds.ru/2012/08/tunnels/

Сети для самых маленьких Планирование

Статья расположена на хабре.Это 1-ая статья из серии «Сети для самых малеханьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN’ы, настройка оборудования.

В итоге решили начать с вещи базисной и, можно сказать, важной: планирование. Потому что цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), осознаете о типах имеющихся VLAN’ов (эту статью я безотступно рекомендую к чтению), о более популярном сейчас port-based VLAN и о IP адресах (более кропотливо). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это стршные слова.

Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем для вас придётся встречаться каждый день, поэтому в течение этого цикла мы попытаемся раскрыть их смысл и отношение к реальности.

Начнём с постановки задачи. Есть некая компания, занимающаяся, допустим, созданием лифтов, идущих только ввысь и потому называется ООО «Лифт ми ап».

Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у их трагическая потребность в сетевой инфраструктуре и средств куры не клюют, что даёт для вас возможность бескрайнего выбора.

Что дальше?

Следует несколько конкретизировать ситуацию.

1. В данный момент у компании есть два кабинета: Двести квадратов на Арбате под рабочие места и серверную. Там представлены несколько провайдеров. Другой на Рублёвке.
2. Есть четыре группы юзеров: бухгалтерия (Б), финансово-экономический отдел (ФЭО), производственно-технический отдел (ПТО), другие пользователи (Д). А так же есть сервера (С), которые вынесены в отдельную группу. Все группы разграничены и не имеют прямого доступа друг к другу.
3. Пользователи групп С, Б и ФЭО будут только в кабинете на Арбате, ПТО и Д будут в обоих кабинетах.

Прикинув количество юзеров, нужные интерфейсы, каналы связи, вы готовите схему сети и IP-план.
При проектировании сети следует стараться придерживаться иерархической модели сети, которая имеет много плюсов по сравнению с “плоской сетью”:

• упрощается понимание организации сети
• модель подразумевает модульность, что означает простоту наращивания мощностей непосредственно там, где необходимо
• легче найти и изолировать делему
• завышенная отказоустойчивость за счет дублирования устройств и\либо соединений
• распределение функций по обеспечению работоспособности сети по различным устройствам.

Согласно этой модели, сеть разбивается на три логических уровня: ядро сети (Core layer: высокопроизводительные устройства, главное назначение — быстрый транспорт), уровень распространения (Distribution layer: обеспечивает применение политик безопасности, QoS, агрегацию и маршрутизацию в VLAN, определяет широковещательные домены), и уровень доступа (Access-layer: обычно, L2 свичи, назначение: подключение конечных устройств, маркирование трафика для QoS, защита от колец в сети (STP) и широковещательных штормов, обеспечение питания для PoE устройств).

В таких масштабах, как наш, роль каждого устройства размывается, но логически поделить сеть можно.
Набросаем схему будущей сети:

На представленной схеме ядром (Core) будет маршрутизатор 2811, коммутатор Две тыщи девятьсот шестьдесят отнесём к уровню распространения (Distribution), потому что на нём агрегируются все VLAN в общий транк. Коммутаторы Две тыщи девятьсот 50 будут устройствами доступа (Access). К ним будут подключаться конечные пользователи, офисная техника, сервера.

Именовать устройства будем следующим образом: сокращённое название города (msk) — географическое размещение (улица, здание) (arbat) — роль устройства в сети + порядковый номер.
Соответственно их ролям и месту расположения выбираем hostname:
Маршрутизатор 2811: msk-arbat-gw1 (gw=GateWay=шлюз)
Коммутатор 2960: msk-arbat-dsw1 (dsw=Distribution switch)
Коммутаторы 2950: msk-arbat-aswN, msk-rubl-asw1 (asw=Access switch)

Документация сети

Вся сеть должна быть строго документирована: от принципиальной схемы, до имени интерфейса.Ранее, чем приступить к настройке, я бы вожделел привести список подходящих документов и действий:

• Схемы сети L1, L2, L3 в согласовании с уровнями модели OSI (Физический, канальный, сетевой)

• План IP-адресации = IP-план.
• Список VLAN
• Подписи (description) интерфейсов• Список устройств (для каждого следует указать: модель железки, установленная версия IOS, объем RAMVRAM, список интерфейсов)• Метки на кабелях (откуда и куда идёт), в том числе на кабелях питания и заземления и устройствах

• Единый регламент, определяющий все вышеприведённые свойства и другие.

Говоря о метках/наклейках на кабели, мы имеем ввиду это:

На этой фото отлично видно, что промаркирован каждый кабель, значение каждого автомата на щитке в стойке, также каждое устройство.

Жирным выделено то, за чем мы будем глядеть в рамках программы-симулятора. Разумеется, все конфигурации сети нужно вносить в документацию и конфигурацию, чтобы они были в актуальном состоянии.

Подготовим нужные нам документы:

Список VLAN

Неважно какая группа будет выделена в отдельный влан. Таким образом мы ограничим их широковещательные домены. Также введём особенный VLAN для управления устройствами.
Номера VLAN по 100 зарезервированы для будущих нужд.

IP-план

Выделение подсетей в общем-то случайное, соответствующее только числу узлов в этой локальной сети с учётом возможного роста. В данном примере все подсети имеют маску /24 (/24=255.255.255.0) — это сеть класса C — нередко такие и употребляются в локальных сетях.

Советуем почитать о классах сетей. В дальнейшем мы обратимся и к бесклассовой адресации.

Мы понимаем, что ссылки на технические статьи в википедии — это моветон, но они дают не нехорошее определение, а мы попробуем в свою очередь перенести это на картину реального мира.

Под сетью Point-to-Point подразумеваем подключение 1-го маршрутизатора к другому в режиме точка-точка. Обычно берутся адреса с маской 30 (возвращаясь к тебе бесклассовых сетей), другими словами содержащие два адреса узла. Позже станет понятно, о чём идёт речь.

План подключения оборудования по портам

Разумеется, сейчас есть коммутаторы с кучей портов 1Gb Ethernet, есть коммутаторы с 10G, на продвинутых операторских железках, стоящих немалые тысячи баксов есть 40Gb, в разработке находится 100Gb (а по слухам уже даже есть такие платы, вышедшие в промышленное создание). Соответственно, вы можете выбирать в реальном мире коммутаторы и маршрутизаторы согласно вашим потребностям, не забывая про бюджет.

А конкретно гигабитный свич сейчас можно приобрести незадорого (20-30 тысяч) и это с запасом на будущее (если вы не провайдер, естественно).

Маршрутизатор с гигабитными портами стоит уже ощутимо дороже, чем со 100Mbps портами, но оно того стоит, потому что FE-модели (100Mbps FastEthernet), устарели и их пропускная способность очень невысока.

Но в программах эмуляторах/симуляторах,которые мы будем использовать, к огорчению, есть только обыкновенные модели оборудования, поэтому при моделировании сети будем отталкиваться от того, что имеем:

Маршрутизация

Почему непосредственно так распределены VLAN’ы, мы объясним в следующих частях.

Excel-документ со списком VLAN, IP, портов

Схемы сети

На основании этих данных можно составить все три схемы сети на этом шаге. Для этого можно воспользоваться Microsoft Visio, хоть каким бесплатным приложением, но с привязкой к собственному формату, или редакторами графики (можно и от руки, но это будет тяжело держать в актуальном состоянии ).

Не пропаганды опен сорса для, а контраста средств ради, воспользуемся Dia. В линуксе, я считаю, его одним из лучших приложений для работы со схемами. Есть версия для Виндоус, но, к огорчению, сопоставимости в визио никакой.

L1

Другими словами на схеме L1 мы отражаем физические устройства сети с номерами портов: что куда подключено.

L2

На схеме L2 мы указываем наши VLAN’ы

L3

В нашем примере схема третьего уровня вышла довольно бесполезная и ненаглядная, из-за наличия только 1-го маршрутизирующего устройства. Но со временем она обрастёт подробностями.

Dia-файлы со схемами сети: L1, L2, L3

Как видите, информация в файлах избыточна. Например, номера VLAN повторяются и на схеме и в плане по портам. Тут как бы кто на что горазд. Как для вас удобнее, так и делайте.

Такая избыточность затрудняет обновление в случае конфигурации конфигурации, потому что нужно исправиться слету в нескольких местах, но с другой стороны, упрощает понимание.

К этой первой статье мы не раз ещё вернёмся в предстоящем, равно как и для вас придётся всегда возвращаться к тому, что вы сначала напланировали.Практически задание для тех, кто пока только начинает учиться и готов приложить для этого усилия: много читать про вланы, найти программы Packet Tracer и GNS3.

В следующей части мы будем учиться подключаться к оборудованию, разбираться с интерфейсом и поведаем, что делать нерадивому админу, забывшему пароль.

• ipcalc калькулятор для расчета сетей

  Малая и комфортабельная утилитка по расчету сетевых адресов, все в цвете и отлично .Ставиться просто для хоть какого Debian based дистрибутива:$ aptitude install ipcalcВнедрение: ipcalc [options] ADD…

• Настройка системы мониторинга Zabbix — сотворения своей карты сети

  Продолжаем знакомиться с системой мониторинга Zabbix, уже поставили установка системы мониторинга Zabbix на Debian 6.0 и выполнили предварительную настройку системы мониторинга Zabbix версии 1.8….

• SSH для обыденных смертных (возможности SSH)

  Дополнительные возможности SSHКопирование файловиз командной строки употребляется команда scp.$ scp [file1] [[email protected]:file2]некоторые функции:-l limit — Ограничивает пропускную способность заданную…

• SSH для обыденных смертных

  В сети много документов по настройке удалённого управления в Линукс и БСД-системах, но часто в их умалчиваются простые (после прокуривания мануалов и гуглежа) вещи. Непосредственно о их я расскаж…

• Скрипт для оптимизации Mysql

  Скрипт, который может в выявлении проблемных мест конфигурации сервера mysql, и даст полезные советы по оптимизации. Скрипт написанный на языке perl и не просит установки. Его просто нужно ск…

: +13

Источник: https://hpunix.org/v-pomoshh-sysadminy/seti-dlja-samyh-malehankih-planirovanie.html