Что умеет туннельный интерфейс.

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

Начнем немного с теории. Что такое туннель? Сразу представляется длинная сквозная дырка в земле, да? И когда мы говорим о сетевом туннеле, тоже представляется какая-то длинная труба, в которую впихиваются пакеты с одной стороны и выкидываются с другой, а маршрутизаторы их ловят (тем более, что так обычно и рисуют). Лично мне такая аналогия кажется немного притянутой за уши. Особенно если учесть, что ip-сети – это сети с пакетной коммутацией, в которых пакет может пройти различными путями, а туннель воспринимается как что-то стабильное. Более правильно, скорее, говорить о почтовых отправлениях, а туннельный интерфейс в этом случае почтальон, который упаковывает уже упакованные посылки и на новой упаковке пишет не адреса конечных отправителей и получателей, а адреса промежуточных почтовых отделений. А между этими отделениями такая посылка может путешествовать самыми разными путями и по земле, и по воде, и по воздуху, и даже, если вам угодно, по космосу. По прибытии в пункт назначения другой почтальон (туннельный интерфейс) распаковывает внешнюю упаковку и отправляет посылку уже конечному получателю.

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

Итак, поехали.

Представим, что у нас есть предприятие, которое хочет объединить свои подсети. Но само это сделать не хочет — дорого. Зато можно попросить другое предприятие (провайдера) дать попользоваться для этой цели своей сетью. Да вот незадача. Адресация совпадает. Да и вообще, не хотим мы с сетью провайдера иметь ничего общего (по крайней мере на сетевом уровне). Тогда мы можем построить сеть так, как показано на рисунке 1.

GRE_Logik

Рисунок 1. Логическая схема сети.

Конечно, можно сделать какую-то промежуточную подсеть с другой адресацией, настроить NAT, например, или еще что-то, однако в приведенных условиях всегда возможны (и наверняка будут) какие-то коллизии. Единственный надежный способ соединить сети не соединяя их – виртуальные маршрутизаторы. Вспомним, что они позволяют иметь на одном железном маршрутизаторе несколько таблиц маршрутизации никак между собой не связанных, а значит и обслуживать несколько отдельных сетей. Тем более такое разделение надежно, что передавать трафик из одного виртуального маршрутизатора в другой напрямую не мы можем.  Для этого нужно делать специальные настройки. А как же тогда передавать трафик? Даже если бы могли это делать напрямую, это ничего не решает, адресация совпадает и пакет не дойдет до адресата. Вот тут нам и поможет наш «почтальон» виртуальный туннельный интерфейс.

Фигурально, я уже описал, как работает туннельный интерфейс. Фактически происходит следующее: ip-пакет, поступающий на туннельный интерфейс (а поступает он туда после изучения таблицы маршрутизации, как на любой другой интерфейс), берется весь целиком и вставляется в другой ip-пакет, в котором кроме ip заголовка присутствует также информация о типе туннеля и прочая служебная информация. Затем этот пакет снова передается в маршрутизатор, снова происходит изучение таблицы маршрутизации, но уже в соответствии с новым заголовком, и принимается решение о том, куда передавать этот пакет дальше. Потом этот пакет путешествует по сети до тех пор, пока не встречает на своем пути интерфейс указанный как destination, а рядом с этим интерфейсом должен существовать приемный туннельный интерфейс, который распакует нашу посылку, и ее содержимое вновь отправит на изучение и отправку к уже конечному пункту назначения.

Итак, рассмотрим конфиг туннельного интерфейса на R4:

 

!
interface Tunnel1
ip vrf forwarding TEST
ip address 172.16.0.2 255.255.255.252
tunnel source Loopback0
tunnel destination 10.1.0.2
tunnel vrf TEST_GRE
!

Построчно здесь написано следующее:

- интерфейс туннель 1;
— этот интерфейс будет получать пакеты на упаковку и возвращать распакованные пакеты виртуальному маршрутизатору TEST. Если команда не указана, то пакеты ожидаются от основного железного маршрутизатора (смотри R2);
— как и у каждого интерфейса, у него должен быть адрес. Он может быть назначен явно, а может быть и заимствован;
— источник туннеля, т.е. адрес, который будет указан как отправитель, лучше указывать loopback интерфейс, все по той же старой, набившей оскомину причине, он никогда не падает, кроме того использование loopback позволяет выбирать (если есть из чего) для туннельного пакета наилучший маршрут, который может начинаться на разных интерфейсах. Есть условие – выходные интерфейсы (через которые может выходить туннель) и loopback должны быть в одной таблице маршрутизации, т.е. в нашем примере если на R4 Eth0/0 и Eth0/2 принадлежат TEST_GRE, то и loopback тоже должен принадлежать TEST_GRE.
— пункт назначения – интерфейс в сети, рядом с которым есть туннельный интерфейс, использующий его как источник;
— туннельный виртуальный маршрутизатор – виртуальный маршрутизатор, который будет принимать решение о пересылке пакета после его упаковки и из которого туннельный интерфейс будет получать для распаковки пакеты, полученные интерфейсом-источником. Если эта команда не указана, то упакованными пакетами интерфейс обменивается с основным железным маршрутизатором.

Вот как-то так. Вроде все понятно. Если не понятно, пишите комменты, буду пояснять.

Аверьянов Кирилл
network-lab.ru

Как всегда в конце полные конфиги: R1, R2, R3, R4, R5, R6.


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me