Сети для самых маленьких. Часть седьмая. VPN

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

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

Давайте по порядку.

А) Собственноручно строить физический канал. Тогда это может быть:

1. Ethernet – витая пара. До 100 метров. Максимум по зданию или между соседними строениями. Скорость до 1 Гбит/c (Строго говоря, есть стандарт 10GBASE-T, позволяющий на том же расстоянии передавать данные на скорости 10Гбит/с).

2. WiFi. Расстояние зависит от реализации: можно добиться работоспособности на 40 км при использовании мощных направленных антенн. В среднем до 5 км при прямой видимости. Скорость зависит от используемого стандарта и от расстояния. Необходимо регистрировать в “Роскомнадзоре”, а при больших мощностях излучения и получать разрешение на включение.

3. xDSL – два-четыре провода. Скорость зависит от расстояния (теоретический максимум 250 Мбит/с, расстояние до 6 км). Хотя ходят слухи о разработке стандарта 1Гб/c по двум проводам.
Или решения вроде E1.

Имеется ввиду не подключение к интернету через xDSL, а именно линк: модем<-кабель->модем. Да, и такие решения существуют. Можно назвать это мостом.

4. Радио-Релейные Линии. Расстояние до нескольких десятков километров. Скорость до 600 Мб/с. Но это решение уже операторского уровня, поскольку требует массу согласований и мероприятий по планированию, строительству, вводу в эксплуатацию.

5. Оптоволокно. 1Гб/с (решения на 10 и 100 Гб/с могут стоить неоправданно дорого). Расстояние зависит от многих факторов: от нескольких километров до сотен. Необходимы согласования по прокладке кабеля, квалифицированный персонал для строительства и обслуживания. Для небольших компаний есть смысл только для подключения здания не очень далеко от центрального узла. Вообще, конечно, каждый случай индивидуален и требует расчёта.

В этом случае для вас всё прозрачно – вы используете свою собственную физическую линию, поэтому пропускать через неё можете что угодно без ограничений.

Б) Второй вариант – арендовать канал у провайдера. В случае необходимости стабильного канала до другого города – это самый распространённый и надёжный вариант. Провайдер может вам предоставить следующие услуги:

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

2. L2VPN. Вы так же можете пускать в канал всё, что угодно, но в данном случае, ваш трафик пойдёт через активное оборудование провайдера, поэтому может ограничиваться, например, по скорости.
Под этим термином понимается сразу несколько услуг второго уровня:
VLAN – в том или ином виде между филиалами вам предоставлен VLAN.
Псевдокабель (PWE3) – это услуга Точка-Точка, когда у вас как будто бы кабель между двумя узлами. Все переданные вами фреймы без изменений доставляются до удалённой точки. Аналогично обратным образом. Это возможно благодаря тому, что ваш фрейм, приходящий на маршрутизатор провайдера инкапсулируется в PDU вышестоящего уровня, как правило, это пакет MPLS.
VPLS (Виртуальная частная сеть) – это симуляция локальной сети. В этом случае вся сеть провайдера для вас будет как некий абстрактный гигантский коммутатор. Как и настоящий он будет хранить таблицу MAC-адресов и принимать решение о том, куда отправить пришедший кадр. Реализуется это также инкапсуляцией кадра в MPLS пакет.

3. L3VPN. В данном случае сеть провайдера – это как большой маршрутизатор с несколькими интерфейсами. То есть стык у вас будет происходить на сетевом уровне. Вы настраиваете IP-адреса на своих маршрутизаторах с обеих сторон, а вот маршрутизация в сети провайдера – это уже головная боль провайдера. IP-адреса для точек стыка можете либо определять вы, либо выдать провайдер – зависит от реализации и от вашей договорённости. Функционировать это может на основе GRE, IPSec или того же MPLS.

Эта услуга выглядит очень простой с точки зрения клиента – как в плане настройки, так и в плане реализации – но сложной – с точки зрения оператора.
С реализацией L2/L3 VPN на основе MPLS мы будем разбираться, но гораздо позже.

В) Ну и последний вариант: туннель через публичную сеть. Предположим, у вас есть выход в Интернет на обеих ваших точках. Зачастую самым дешёвым способом оказывается построить туннель между этими двумя точками. Для этого вам достаточно всего лишь иметь белые (публичные) статические адреса на всех точках (а иногда достаточно и на одной) и оборудование, на котором это реализовать. У этого решения есть ряд недостатков, которые мы рассмотрим ниже, но тем не менее именно на нём мы сегодня и остановимся.

Итак, ваша воля выбирать, какой вариант использовать, исходя из бюджета, целесообразности и ваших способностей к убеждению руководства.
В рамках данного выпуска нам нужно подключить 3 офиса: в Новосибирске, Томске и Брно. Условимся, что везде мы будем использовать только подключение к сети Интернет.

Схема подключения узлов hub and spoke – по-русски говоря, звезда:

Напоминаю, что общая схема сети ЛинкМиАп выглядит сейчас уже так:

Но от неё мы абстрагируемся, напирая только на существенные вещи.

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

Сегодня рассмотрим такие самые распространённые варианты:

· GRE

· IPSec (туннельный и транспортный режимы)

· GRE over IPSec

· VTI

· DMVN

GRE

Generic Routing Encapsulation – очень простой протокол туннелирования.
Такс, туннелирование. Это что ещё за зверь? Грубо говоря, это означает, что берутся ваши изначальные данные вместе со служебными заголовками (как правило, это IP, но может быть и Ethernet и ATM), упаковываются в пакет и передаются по публичной сети, словно машина едет в туннеле через горы. На конечном узле заголовки нового пакета снимаются, а ваши данные в исходном виде продолжают своё путешествие.
Не очень понятно, да? Разберём на примере с GRE.

Два маршрутизатора подключены к интернету через статические белые адреса. На каждом из них заведены приватные сети из диапазона 10.0.0.0/8.
Разумеется, эти сети не маршрутизируются в Интернете. (На картинке нарисованы компьютер и ноутбук, но на практике мы будем настраивать виртуальный интерфейс Loopback0)
Наша задача прокинуть туннель:

Таким образом для ПК1 при общении с ПК2 не существует никакого Интернета – они оба будут думать, что находятся в одной локальной сети.

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

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

В качестве адреса источника можно выбрать как IP-адрес выходного интерфейса
(белый адрес, предоставленный провайдером), так и его имя (FE0/0 в нашем случае):

Адрес destination – публичный адрес удалённой стороны:

Законченный вид:

Сразу после этого туннель должен подняться:

R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1
Tunnel protocol/transport GRE/IP

Вся основная информация здесь отражена. Обратите внимание на размер MTU – он не 1500, как ставится для обычных физических интерфейсов. О параметре MTU мы поговорим в конце статьи

По умолчанию GRE не проверяет доступность адреса назначения и сразу отправляет туннель в Up. Но стоит только добавить в туннельный интерфейс команду keepalive X, как маршрутизатор начинает отсылать кипалайвы и не поднимется, пока не будет ответа.

В нашей тестовой схеме в качестве локальной сети мы просто настроили Loopback-интерфейсы – они всегда в Up'е. Дали им адреса с маской /32. На самом же деле под ними подразумеваются реальные подсети вашего предприятия (ну, как на картинке).

На маршрутизаторе у вас должно быть два статических маршрута:

Первый говорит о том, что шлюзом по умолчанию является адрес провайдера 100.0.0.2:

R1#traceroute 200.0.0.1
Type escape sequence to abort.
Tracing the route to 200.0.0.1
1 100.0.0.2 56 msec 48 msec 36 msec
2 200.0.0.1 64 msec * 60 msec

Второй перенаправляет пакеты, адресованные хосту с адресом 10.1.1.0, на next-hop 10.2.2.2 – это адрес туннеля с обратной стороны.

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

nsk-obsea-gw1:

Пробуем запустить пинг:

R1#ping 10.1.1.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.0, timeout is 2 seconds:
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/71/136 ms
R1#tracer 10.1.1.0
Type escape sequence to abort.
Tracing the route to 10.1.1.0
1 10.2.2.2 68 msec * 80 msec

Великолепно! Но что происходит за кулисами?
А там, ребята, удивительные вещи:

Когда вы запускаете ping 10.1.1.0, что делает маршрутизатор?
1) Формирует IP-пакет::

2) Смотрит таблицу маршрутизации

R1#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «static», distance 1, metric 0
Routing Descriptor Blocks:
* 10.2.2.2
Route metric is 0, traffic share count is 1

Далее рекурсивно смотрит, где адрес 10.2.2.2:

R1#sh ip rou 10.2.2.2
Routing entry for 10.2.2.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Tunnel0
Route metric is 0, traffic share count is 1

Такссс, Tunnel 0:

R1#sh int tun 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 10.2.2.1/30
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 100.0.0.1, destination 200.0.0.1

3) Понимая, что это GRE-туннель, добавляет к пакету заголове GRE:

А сверху новый заголовок IР. В качестве отправителя будет значиться адрес tunnel source, а в качестве получателя – tunnel destination.

4) Новоиспечённый пакет отправляется в дивный мир по дефолтному маршруту:

R1#sh ip route
Gateway of last resort is 100.0.0.2 to network 0.0.0.0

5) Не забываем про заголовок Ethernet, при отправке провайдеру он также должен быть сформирован.
Поскольку GRE-туннель – виртуальный интерфейс 3-го уровня, он не обладает собственным MAC-адресом (как и Loopback, например). В конечном итоге кадр уйдёт с физического интерфейса FastEthernet0/0:

R1#sh ip route 100.0.0.2
Routing entry for 100.0.0.0/30
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via FastEthernet0/0
Route metric is 0, traffic share count is 1

Соответственно его адрес он и укажет в качестве Source MAC

R1#sh int
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c000.25a0.0000 (bia c000.25a0.0000)
Internet address is 100.0.0.1/30

Destination по традиции берётся из ARP-кэша или получается с помощью ARP-запроса от адреса 100.0.0.2:

R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 100.0.0.1 – c000.25a0.0000 ARPA FastEthernet0/0
Internet 100.0.0.2 71 c001.25a0.0000 ARPA FastEthernet0/0

6) И в таком виде новый IP-пакет передаётся в интернет. А поскольку каждый маршрутизатор не раздербанивает пакет, а принимает решение на основе первого же заголовка IP, то никто в Интернете не будет знать о том, что где-то там внутри кроются ваши приватные адреса 10.1.1.0 и 10.0.0.0.

7) И наконец пребывает в точку назначения.
R3 обнаруживает, что адрес назначения принадлежит ему самому, снимает заголовок IP и что он под ним находит? GRE-заголовок.

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

В данном случае передать на обработку интерфейсу Loopback 0

R3#sh ip route 10.1.1.0
Routing entry for 10.1.1.0/32
Known via «connected», distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Loopback0
Route metric is 0, traffic share count is 1

Вот такие нехитрые манипуляции.
Пока пакет в локальной сети он выглядит так:

и обрабатывается на основе приватных адресов.
Как только попадает в публичную сеть, GRE вешает на него дополнительный IP-заголовок:

и пакет обрабатывается на основе публичных адресов.

1 – изначальные данные
2 – первый IP-заголовок (внутренний)
3 – заголовок GRE (с указанием, что внутри лежат данные протокола IP)
4 – новый заголовок IP (внешний, с туннельными адресами)

Рядовой обмен ICMP-сообщениями может при детальном рассмотрении выглядеть и так.

Если попытаться провести аналогии с осязаемым миром, то представим ситуацию, когда вы едете из деревни, инкапсулированные в автомобиль. Доезжаете до реки, и вам надо перебраться на другой берег и там продолжить своё путешествие в город.
На речном порту ваш автомобиль инкапсулируют в паром и переправляют через бушующие волны на другую сторону, где ваш автомобиль извлекают, и вы продолжаете движение. Так вот этот паром и был GRE-паромом.

Сделаем три ремарки:
Во-первых, интерфейсы Loopback и адреса с маской /32 мы выбрали просто для теста, фактически это вполне бы могли быть интерфейсы fa1/0.15 и fa0/1.16 с подсетями 172.16.15.0/24 и 172.16.16.0/24, например, или любые другие.
Во-вторых, мы тут всё ведём речи о публичных сетях и адресах, но на самом деле, конечно, это не имеет значения и туннели вполне можно поднимать даже внутри своей корпоративной сети, когда конечные сети и так имеют IP-связность без туннеля.
В-третьих, несмотря на то, что теоретически обратно трафик может возвращаться и не по туннелю, создать его необходимо, чтобы конечный узел могу успешно декапсулировать GRE-пакеты

Обычный GRE – яркий пример туннелирования, который очень просто настраивается и сравнительно легко траблшутится.
Очевидно, вы уже догадываетесь, какие три большие проблемы подстерегают нас на этом поле?

· Безопасность. Данные, инкапсулированные в GRE, передаются тем не менее в открытом виде.

· Сложность масштабирования. Если у вас 5-7 филиалов, обслуживание такого количества туннелей ещё кажется возможным, а если их 50? Причём туннелирование трафика зачастую производится на CPU, особенно на младшей и средней линейках, поэтому это лишняя нагрузка на процессор.

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

IPSec

Первую озвученную выше проблему призвано решить шифрование.

Сейчас для организации шифрованного VPN-канала используются преимущественно следующие технологии: IPSec (IP Security), OpenVPN и PPTP (Point-to-Point Tunneling Protocol).

Бессменным лидером, конечно, является IPSec, о нём и поговорим.

Для начала нужно уяснить себе, что IPSec – это не протокол, это стандарт, включающий в себя целых три протокола, каждый со своими функциями:

1. ESP (Encapsulating Security Payload – безопасная инкапсуляция полезной нагрузки) занимается непосредственно шифрованием данных, а также может обеспечивать аутентификацию источника и проверку целостности данных

2. AH (Authentication Header – заголовок аутентификации) отвечает за аутентификацию источника и проверку целостности данных

3. IKE (Internet Key Exchange protocol – протокол обмена ключами) используется для формирования IPSec SA (Security Association, об этом чуть ниже), проще говоря, согласования работы участников защищенного соединения. Используя этот протокол, участники договариваются, какой алгоритм шифрования будет использоваться, по какому алгоритму будет производиться (и будет ли вообще) проверка целостности, как аутентифицировать друг друга

Прежде чем переходить дальше, разберемся с термином SA – Security Association. SA в общем смысле представляет собой набор параметров защищенного соединения (например, алгоритм шифрования, ключ шифрования), который может использоваться обеими сторонами соединения. У каждого соединения есть ассоциированный с ним SA.
Теперь по порядку, как создается защищенное соединение в IPSec:

· Для начала, участникам надо договорится, какие алгоритмы/механизмы защиты они будут использовать для своего защищенного соединения, поэтому в дело вступает IKE. Процесс состоит из двух фаз:

· Фаза первая: участники аутентифицируют друг друга и договариваются о параметрах установки специального соединения (тоже защищенного), предназначенного только для обмена информацией о желаемых/поддерживаемых алгоритмах шифрования и прочих деталях будущего IPSec-туннеля. Параметры этого мини-туннеля (правильно он называется ISAKMP Tunnel) определяются политикой ISAKMP, в режим редактирования которой мы можем попасть из конфигурационного режима командой crypto isakmp policy номер_политики. Если стороны пришли к соглашению, устанавливается ISAKMP туннель (его наличие можно посмотреть командой show crypto isakmp sa), по которому уже проходит вторая фаза IKE.

· Фаза вторая: уже доверяющие друг другу участники договариваются о том, как строить основной туннель для данных. Они по очереди предлагают друг другу варианты, указанные в команде crypto ipsec transform-set, и, если приходят к согласию, поднимают основной туннель. Нужно сказать, что, после его установления, вспомогательный ISAKMP туннель никуда не пропадает – он используется для обновления SA основного. Дело в том, что ключи, выбираемые для шифрования информации в IPSec-туннеле, имеют некоторое “время жизни” (может выражаться как в количестве байт, так и в секундах – что первое достигнет порогового значения), по истечение которого должны быть заменены. Это как пароль, который вы меняете раз в час (по умолчанию lifetime IPSec SA составляет 4608000 килобайт/3600 секунд).

· Участники получили шифрованный туннель с параметрами, которые их всех устраивают, и направляют туда потоки данных, подлежащие шифрованию, т.е., подпадающие под указанный в crypto map аксесс-лист.

· Периодически, в соответствии с настроенным lifetime, обновляются ключи шифрования для основного туннеля: участники вновь связываются по ISAKMP-туннелю, проходят вторую фазу и устанавливают новые SA.

Строго говоря, в этом процессе есть нулевой шаг: некий трафик должен попасть в соответствие аксесс-листу в крипто мапе. Только после этого будет происходить все остальное.

Теперь немного о трансформ-сете и чем отличается ESP от AH. Как будут шифроваться наши данные, идущие через туннель, определяет команда crypto ipsec transform-set имя_сета, после которой идет название протокола, который будет использован (ESP или AH) + алгоритм, по которому будет работать протокол. Например, команда crypto ipsec transform-set SET1 esp-aes даст понять роутеру, что трансформ-сет с именем “SET1”, если он будет применен, будет работать только по протоколу ESP c шифрованием алгоритмом AES. Ну если с ESP все более-менее понятно, его дело-шифровать (обеспечивать конфиденциальность), то что такое AH и зачем он вообще нужен? AH обеспечивает аутентификацию данных, то есть дает уверенность, что эти данные пришли именно от того, с кем мы установили связь, и не были изменены по дороге. Если не углубляться в подробности, работает это так: в каждый пакет между заголовком IP и заголовком транспортного уровня вставляется заголовок AH, в котором присутствует:

· информация, по которой получатель может понять, к какой SA относится данный пакет (т.е., в том числе, по какому алгоритму ему считать хеш для сравнения – MD5 или SHA)

· так называемый ICV (Integrity Check Value), представляющий собой хеш от пакета (на самом деле, не всего пакета, а неизменяемых в процессе путешествия полей), который позволяет однозначно убедиться получателю, что этот пакет не изменялся по дороге, путем вычисления хеша от той же информации и сравнения результата со значением этого поля.

IPSec может работать в двух режимах: туннельном и транспортном.

Поиск по сайту: