Телефон +7 (812) 718-6184
СПб, Московский пр. 118
  1. О центре
  2. Статьи преподавателей
  3. Объединение сетей. Часть 2

Объединение сетей. Часть 2

13.10.2017

Введение

Продолжаем разбираться с темой построения составных корпоративных сетей. Ранее мы определились с задачами, которые необходимо решить для объединения локальных сетей и с проблемами, которые возникают на пути решения такой задачи. Свой выбор мы остановили на создании частной сети поверх существующей публичной сети интернет. Первое с чем мы столкнулись это невозможность передачи определенного типа трафика, например, трафика между сетями с корпоративными IP адресами. Очевидное решение - туннелирование. В прошлый раз мы в общем разобрали концепцию туннелирования и оценили такое решение, как IP-IP туннель. Напомню основные недостатки такого решения: отсутствие аутентификации узлов, информация не защищена от просмотра и изменения, отсутствие масштабируемости. Будем продвигаться далее. Понятно, что туннелировать можно чуть-ли не все во всем. Можно туннелировать трафик и в прикладных протоколах, типа HTTP, и в служебных, например, DNS. Но это больше решения для обхода различного рода защит, чем для организации полноценных соединений. Можно поверх IP передавать трафик других протоколов, но увы поле «protocol» в заголовке IP не резиновое, всего один байт или 256 значений. И перенос протоколов напрямую поверх IP категорически не приветствуется.
 

Постановка задачи

Итак, с учетом сказанного, ставим задачу. Необходимо туннелировать трафик различных протоколов, при этом не задевая концепцию инкапсуляции в IP. Более того, получить возможность переносить трафик других стеков протоколов, например, IPX или IPv6. Это означает, что нужна прокладка между IP и любыми другими протоколами для IP не известными, даже уровня 2, который ниже IP и по факту наоборот должен инкапсулировать в себя IP пакеты. Особенно востребованным здесь является желание инкапсулировать PPP трафик в IP. И желание это, абсолютно понятно. Ведь в PPP есть встроенная процедура аутентификации пиров в отличие от IP который этого делать не умеет. А одной из задач создания виртуальной частной сети мы как раз и обозначили возможность аутентификации узлов.
 

Решение

Одно из решений предложила компания CISCO. Это протокол GRE  Generic Routing Encapsulation. Некий общий протокол инкапсуляции. На сегодняшний день протокол является стандартом. Текущая версия RFC 2784. Более ранняя RFC 1701. На данный момент протокол упрощен, как раз до его целевого назначения. В ранней версии было много зарезервированных полей, которые не особо понадобились. Формат заголовка:
 
 

1бит
C
12 бит
Reserved0
3 бита
Ver
16 бит
Protocol Type

 
 

16 бит
Checksumm
16 бит
Reserved1

 



Как видим первый бит указывает на то, считалась ли контрольная сумма. Значимые поля остаются версия и тип протокола. В поле protocol заголовка IP ставится значение 47, закрепленное за GRE, а в самом GRE в поле «Protocol Type» указывается номер инкапсулируемого протокола. Вдаваться в дополнительные поля предыдущей версии мы не будем, так же, как и в вопросы их совместимости. Дополнительно по этому вопросу можно посмотреть RFC 2890.
Теперь самое время посмотреть на GRE в деле. Топологию возьмем опять незамысловатую.
 



 



Маршруты через туннель пока зададим статические. Посмотрим, что происходит внутри туннеля.



Все, как мы и предполагали. Исходный IP пакет инкапсулируется в GRE с полем 0Х800 (стандартно для IP). Сам GRE упаковывается в маршрутизируемый пакет между конечными точками туннеля с полем protocol 47. Заголовок GRE упрощен совершенно. Контрольная сумма не считается и соответственно поля совсем нет, как и зарезервированных бит в конце. Можно при конфигурировании дать команду tunnel key и указать ключ. Будет некое подобие аутентификации. Подобие, поскольку никакого шифрования ключа нет.



Ключ 0Х0000007b в нашем примере это ничто иное, как число 123, если перевести в десятичный вид. Указатель на ключ есть в поле флагов. Посмотрим на еще один пример. Проброс PPP трафика с помощью GRE. Очень популярный вариант у Microsoft. Сейчас не будем затрагивать все возможности PPTP. Отметим, что он может работать в режимах, как с шифрованием нагрузки, так и без. И в нашем примере прогоним трафик без шифрования. Сам PPP ведет себя классически. Сначала отрабатывает процедура LCP, происходит аутентификация, затем IPCP, назначение IP адресов. Ну и дале PPP в режиме просто адресации протокола верхнего уровня. В примере ниже немного другая адресация. Разрешенный трафик между 192.168.2.126 и 192.168.2.134. В данном примере будем смотреть на эти адреса, как на публичные и разрешенные в сети Интернет. Затунеллированный трафик между узлами 172.30.0.7 и 192.168.200.1



Версия GRE уже не 0, а 1. Здесь так же используется ключ и плюс Sequence Number, который может иметь значение для PPP, поскольку он является канальным протоколом точка точка и не предполагал прихода кадров с нарушением очередности. Довольно глубокая инкапсуляция IP-GRE-PPP-IP. И видно, что трафик не шифрованный, что можно исправить. В этом случае мы получим практически то, чего и добивались. Перенос неразрешенного трафика по публичной сети с помощью GRE, аутентификацию пиров с PPP и шифрование нагрузки PPP, это уже PPTP.
Напоминаю, что получить знания и попрактиковаться в настройках различных VPN решений на разнообразном оборудовании CISCO вы можете, прослушав курс SIMOS. На сегодня это все. Попрактикуйтесь в создании GRE туннелей. А в следующий раз мы попытаемся решить еще одну интересную задачку. Как построить более сложные топологии и как упростить процесс создания множества туннелей.