VPN-MPLS

к нему одноранговыми сайтами. Заметим, что при этом пе-	пока их таблицы VRF не будут специально настроены
редаются данные только о тех маршрутах, которые порож-	для этого.
даются данной таблицей VRF. В результате на каждом РЕ-
маршрутизаторе формируются идентичные маршрутные	В таблице VRF на сайте Заказчик 1 Сайт A хранятся дан-
таблицы VFR данного заказчика, и каждый маршрут за-	ные о маршрутах для всех сайтов C1 (C1a, C1b Е). Точно
казчика становится доступным через следующий РЕ-мар-	так же в таблице VRF на сайте Заказчик 2 Сайт B хранятся
шрутизатор.	данные о маршрутах для всех сайтов C2 (C2a, C2b).
3.3. ìÒÎÛ„‡ ˝ÍÒÚ ‡ÌÂÚ VPN	Кроме этого, в таблицы VRF обоих сайтов дополни-
	тельно импортируются/экспортируются маршруты, ис-
3.3.1. á‡Í‡Á˜ËÍË Ò ÛÌË͇θÌ˚ÏË ‡‰ ÂÒ‡ÏË	пользуя параметр route-target. Таким образом, в таблице
Создание межкорпоративной сети (экстранет) требу-	VRF сайта Заказчик 1 Сайт A содержатся данные обо
ет импорта/экспорта данных о маршрутах между табли-	всех маршрутах C2b сайта Заказчик 2 Сайт B, а в табли-
цами VRF нескольких заказчиков. Если у этих заказчи-	це VRF сайта Заказчик 2 Сайт B содержатся данные обо
ков нет совпадающих IP-адресов, то есть все их IP-адре-	всех маршрутах C1a сайта Заказчик 1 Сайт A.
са являются уникальными, то маршруты могут напря-
мую импортироваться в таблицы VRF.	3.3.2. б‡Н‡Б˜ЛНЛ Т ТУ‚Ф‡‰‡˛˘ЛПЛ (МВЫМЛН‡О¸М˚ПЛ) ‡‰ ВТ‡ПЛ
	Если заказчики, желающие сформировать сеть экст-
На рисунке 12 показаны два заказчика, Заказчик 1 и	ранет, имеют пересекающееся адресное пространство
Заказчик 2, каждый из которых имеет по два сайта,	или если появление новых членов сети экстранет может
Сайт A и Сайт B. Эти заказчики создают общую сеть эк-	вызвать проблемы адресации, возникает необходимость
странет, но она включает только два сайта: Заказчик 1	в преобразовании (трансляции) адресов, прежде чем
Сайт A и Заказчик 2 Сайт B. Все другие сайты этих заказ-	трафик попадет в сеть экстранет.	19
чиков не будут подключены к сети экстранет до тех пор,	На рисунке 13 заказчики имеют совпадающее адрес-

кЛТЫМУН 12. еВКНУ ФУ ‡ЪЛ‚М˚В ТВЪЛ ˝НТЪ ‡МВЪ

á‡Í‡Á˜ËÍ 2 ë‡ÈÚ B

VRF

VRF

á‡Í‡Á˜ËÍ 2 ë‡ÈÚ A

á‡Í‡Á˜ËÍ 1 ë‡ÈÚ B

VRF

á‡Í‡Á˜ËÍ 1 ë‡ÈÚ A

аПФУ Ъ/щНТФУ Ъ П‡ ¯ ЫЪУ‚

кЛТЫМУН 13. еВКНУ ФУ ‡ЪЛ‚М˚В ТВЪЛ ˝НТЪ ‡МВЪ — ТУ‚Ф‡‰‡˛˘ЛВ ‡‰ ВТ‡

á‡Í‡Á˜ËÍ 2 ë‡ÈÚ B

VRF

	VRF
á‡Í‡Á˜ËÍ 2
ë‡ÈÚ A	á‡Í‡Á˜ËÍ 1
	ë‡ÈÚ B
	VRF
	á‡Í‡Á˜ËÍ 1
	ë‡ÈÚ A
	аПФУ Ъ/щНТФУ Ъ П‡ ¯ ЫЪУ‚

	ное пространство C. Чтобы сайт Заказчик 1 Сайт A	way), который подключается к VRF в соответствующей
	смог обмениваться данными о маршрутах с сайтом	сети Intranet VPN. Таблица VRF, подключенная к шлюзу
	Заказчик 2 Сайт B, необходимо преобразование адре-	NAT, будет включать данные о введенных в нее маршру-
	сов (NAT), позволяющее сайту C1A передавать трафик	тах преобразованных адресов другого заказчика. Поэто-
20	в C2B и наоборот.	му Ct1 инжектируется в таблицу VRF сайта Заказчик 2
		Сайт B, а Ct2 инжектируется в таблицу VRF сайта
	Текущая версия MPLS не позволяет PE-маршрутиза-	Заказчик 1 Сайт А. Каждый заказчик может работать в
	тору напрямую преобразовывать адреса в таблицах	сети интранет с помощью двух шлюзов NAT. В качестве
	VRF, и поэтому данная операция должна происходить	шлюзов NAT могут использоваться межсетевые экраны
	за его пределами (либо в общей сервисной точке, либо	с функцией NAT. Это позволит дополнительно повысить
	на CE-маршрутизаторе).	безопасность при межсетевом взаимодействии заказчи-
		ков, включенных в один экстранет.
	3.3.3. è ÂÓ· ‡ÁÓ‚‡ÌË ‡‰ ÂÒÓ‚ ˝ÍÒÚ ‡ÌÂÚ
	‚ У·˘ВИ ТВ ‚ЛТМУИ ЪУ˜НВ
	На рисунке 14 показана трансляция адресов в цент-
	ральной сервисной точке. Каждый заказчик будет иметь
	отдельный шлюз преобразования адресов (NAT gate-	3.3.4. è ÂÓ· ‡ÁÓ‚‡ÌË ‡‰ ÂÒÓ‚ ˝ÍÒÚ ‡ÌÂÚ Ì‡ „ ‡ÌˈÂ
		á‡Í‡Á˜ËÍ 2
		ë‡ÈÚ B
	кЛТЫМУН 14. и ВУ· ‡БУ‚‡МЛВ ‡‰ ВТУ‚ ˝НТЪ ‡МВЪ ‚ У·˘ВИ ТВ ‚ЛТМУИ ЪУ˜НВ	VRF

òβÁ˚ NAT

á‡Í‡Á˜ËÍ 2	VRF
ë‡ÈÚ A

á‡Í‡Á˜ËÍ 1 VRF ë‡ÈÚ B

á‡Í‡Á˜ËÍ 1 ë‡ÈÚ A

аПФУ Ъ/щНТФУ Ъ П‡ ¯ ЫЪУ‚

ÒÂÚË Á‡Í‡Á˜Ë͇

В таблицах VRF обоих заказчиков будут храниться

введенные в них преобразованные адреса, которые поз-

На рисунке 15 показана трансляция адресов на грани-

волят направлять пакеты в сеть экстранет. Специальная

це сети заказчика. Трафик Extranet/NAT и Intranet/non-

карта маршрутов и виртуальный интерфейс, которые

NAT передается через один и тот же интерфейс, что по-

имеются на каждом маршрутизаторе CE NAT, предот-

зволяет экономить аппаратные ресурсы PE-маршрутиза-

вращают преобразование адресов трафика, предназна-

торов.

ченного для внутренних сетей интранет. К трафику инт-

Если CE-маршрутизаторы принадлежат заказчику,

ранет будет относиться любой пакет с адресом назначе-

именно он несет ответственность за преобразование ад-

ния, относящимся к адресному пространству C.

ресов на интерфейсах, выходящих на экстранет VRF, и

Поскольку трансляция адресов в экстранет происходит

за согласование используемых адресов. Сервис-провай-

с обеих сторон, то для каждого адреса хоста, требующего

дер берет на себя ответственность за создание таблиц

взаимодействия через экстранет, требуется статическое

кЛТЫМУН 15. и ВУ· ‡БУ‚‡МЛВ ‡‰ ВТУ‚ ˝НТЪ ‡МВЪ М‡ „ ‡МЛˆВ ТВЪЛ Б‡Н‡Б˜ЛН‡

á‡Í‡Á˜ËÍ 2

ë‡ÈÚ B

àÌÚ ‡ÌÂÚ

VRF

í ‡ÙËÍ ˝ÍÒÚ ‡ÌÂÚ

21

VRF

á‡Í‡Á˜ËÍ 2

ë‡ÈÚ A

á‡Í‡Á˜ËÍ 1

àÌÚ ‡ÌÂÚ

ë‡ÈÚ B

VRF

á‡Í‡Á˜ËÍ 1

ë‡ÈÚ A

аПФУ Ъ/щНТФУ Ъ П‡ ¯ ЫЪУ‚

Extranet_overlapping_nat13

VRF и инжектирование в них данных о маршрутах с пре-

преобразование. Если преобразование будет динамиче-

образованными адресами (в случае, когда используется

ским, мы никогда не сможем определить, какой NAT-ад-

статическая маршрутизация).

рес был присвоен каждому из внутренних xостов.

Более благоприятная ситуация возникает, когда сер-

вис-провайдер предлагает заказчику услугу по управле-

3.4. ìÒÎÛ„‡ ÒÂÚÂ‚Ó„Ó ÛÔ ‡‚ÎÂÌËfl MPLS-VPN

нию маршрутизаторами. В этом случае сервис-провай-

дер контролирует весь маршрут до CE-маршрутизатора

3.4.1. мФ ‡‚ОВМЛВ CE-П‡ ¯ ЫЪЛБ‡ЪУ ‡ПЛ

и может поддерживать между CE-маршрутизаторами

Сервис-провайдер может предоставлять заказчикам

сквозное (end-to-end) управление NAT.

услугу по управлению их маршрутизаторами, позволяю-

щую как минимум определять доступность того или ино-

На рисунке 15 показаны два заказчика: Заказчик 1

го устройства. Это особенно важно, если сервис-провай-

Сайт A (C1A) и Заказчик 2 Сайт B (C2B), которые работают

дер владеет устройствами CE, хотя в принципе все уст-

в сети экстранет с преобразованием адресов (NAT). Когда

ройства CE (в том числе принадлежащие заказчику)

C1A хочет установить связь с C2B, он транслирует свой

должны включаться в общую систему управления. Ниже

адрес источника, заменив его на адрес из пула Ct1, с помо-

описан один из способов решения этой задачи.

щью процедур динамической или статической трансля-

ции. C2B поступает точно так же, но он заменяет адрес тра-

В таблице сетевого управления VRF, которая называ-

фика, предназначенного для C1A , на адрес из пула Ct2.

ется

VPN_Network_Management, содержатся адреса

кЛТЫМУН 16. н‡·ОЛˆ‡ VRF ‰Оfl ЫФ ‡‚ОВМЛfl ЫТЪ УИТЪ‚‡ПЛ CE

VRF á‡Í‡Á˜Ë͇ 1

VRF á‡Í‡Á˜Ë͇ 2

VRF á‡Í‡Á˜Ë͇ 3

VRF ÛÔ ‡‚ÎÂÌËfl

ꇷӘ‡fl Òڇ̈Ëfl (Òڇ̈ËË) ÛÔ ‡‚ÎÂÌËfl

управлении P-маршрутизаторами и PE-маршрутизатора-

всех CE-маршрутизаторов. Имеющаяся у сервис-про-

22

вайдера станция сетевого управления (или несколько

ми с помощью таблицы VRF, а другой — в управлении

станций) использует в своей работе именно эту таблицу

ими с помощью глобальной таблицы.

VRF. С другой стороны, таблица VRF каждого заказчи-

ка должна содержать адрес станции управления сер-

3.4.2.1. мФ ‡‚ОВМЛВ ЫТЪ УИТЪ‚‡ПЛ P Л PE

вис-провайдера (или нескольких станций), чтобы под-

Ò ÔÓÏÓ˘¸˛ Ú‡·Îˈ˚ VRF

держать двустороннюю связь между станцией сетевого

Управление P-маршрутизаторами и PE-маршрутиза-

управления и CE-маршрутизатором.

торами с помощью таблицы VRF показано на рисунке 17.

Создание VRF сетевого управления позволяет управ-

лять всеми CE-маршрутизаторами из единой точки. При

Адреса loopback’ов P и PE находятся в глобальной таб-

этом гарантируется разделение маршрутизации между

лице маршрутизации, но адрес рабочей станции сетево-

CE-маршрутизаторами. На рисунке 16 показаны проце-

го управления находится в таблице VRF. Чтобы обеспе-

дуры импорта и экспорта маршрутов в таблице VRF.

Все CE-маршрутизаторы легко идентифицируются,

так как пользуются адресами из единого адресного про-

кЛТЫМУН 17. н‡·ОЛˆ‡ VRF ‰Оfl ЫФ ‡‚ОВМЛfl ЫТЪ УИТЪ‚‡ПЛ PE

странства, находящегося под управлением сервис-про-

вайдера.

3.4.2. мФ ‡‚ОВМЛВ П‡ ¯ ЫЪЛБ‡ЪУ ‡ПЛ MPLS

ÓÔÓ ÌÓÈ ÒÂÚË (P + PE)

Управление опорной сети необходимо как для монито-

ринга ее состояния и производительности, так и для под-

держки конфигурирования P- и PE-устройств с помо-

ÉÎÓ·‡Î¸Ì‡fl Ú‡·Îˈ‡

щью VPN Solutions Center.

χ ¯ ÛÚËÁ‡ˆËË

Конфигурация управления маршрутизаторами опор-

VRF ÛÔ ‡‚ÎÂÌËfl

ной сети несколько отличается от управления CE-марш-

рутизаторами, поскольку адреса PE-маршрутизаторов на-

ꇷӘ‡fl Òڇ̈Ëfl (Òڇ̈ËË) ÛÔ ‡‚ÎÂÌËfl

ходятся не в таблице VRF, а в глобальной таблице маршру-

тизации (Global Routing Table). Существует несколько

способов управления устройствами PE. Первый состоит в

чить связь между опорной сетью MPLS и рабочей стан-

кЛТЫМУН 18. мФ ‡‚ОВМЛВ PE-П‡ ¯ ЫЪЛБ‡ЪУ ‡ПЛ Т ФУПУ˘¸˛ „ОУ·‡О¸МУИ

цией управления, необходимо инжектировать в таблицу

Ú‡·Îˈ˚ χ ¯ ÛÚËÁ‡ˆËË (Global Routing Table)

VRF глобальный статический маршрут, указывающий на

адреса сети MPLS, а в глобальную таблицу маршрутиза-

ции нужно инжектировать статический маршрут, ука-

зывающий на адрес рабочей станции.

3.4.2.2. мФ ‡‚ОВМЛВ ЫТЪ УИТЪ‚‡ПЛ P Л PE Т ФУПУ˘¸˛

„ÎÓ·‡Î¸ÌÓÈ Ú‡·Îˈ˚

Другим способом управления опорной сетью является

прямое подключение сети управления к интерфейсу, оп-

ÉÎÓ·‡Î¸Ì‡fl Ú‡·Îˈ‡

ределенному в глобальной таблице маршрутизации.

χ ¯ ÛÚËÁ‡ˆËË

Другими словами, у нее не будет ассоциаций с таблицей

VRF. Это самый простой и прямой способ управления

опорной сетью. Он показан на рисунке 18.

ꇷӘ‡fl Òڇ̈Ëfl (Òڇ̈ËË) ÛÔ ‡‚ÎÂÌËfl

3.4.3. èÓ‰ÒÂÚ¸ ÒÂÚÂ‚Ó„Ó ÛÔ ‡‚ÎÂÌËfl: Extranet Multiple VPN

Для управления типа Extranet Multiple VPN (другое на-

звание — Rainbow Management) необходимо рабочие

Маршрутизатор MCE, подключаемый к PE-маршрути-

станции VPN Solutions Center и элемент-менеджеры

затору, должен подключаться к non-MPLS-VPN и MPLS-

подключить к единой локальной сети и к маршрутизато-

VPN через два разных интерфейса. Соединение MPLS-

ру управления (management router — MCE). На рисунке

VPN называется Extranet Multiple VPN. Эта сеть VPN бу-

19 подробно показана подсеть управления, подключен-

дет импортировать в таблицы VRF информацию о марш-

23

ная к MPE.

рутах для связи со всеми управляемыми устройствами

кЛТЫМУН 19. сВМЪ VPN Solutions Center: ПВЪУ‰ ЫФ ‡‚ОВМЛfl Extranet Multiple VPN

ìÔ ‡‚ÎflÂÏÓ ëÖ Ò

ЗМВ¯МВВ ЫФ ‡‚ОВМЛВ, МВ ЛТФУО¸БЫfl MPLS-VPN

ìÔ ‡‚ÎflÂÏÓ ëÖ Ò

‚МВ¯МЛП ЫФ ‡‚ОВМЛВП

ЗМЫЪ ЛН‡М‡О¸МУВ ЫФ ‡‚ОВМЛВ, МВ ЛТФУО¸БЫfl

‚ÌÛÚ Ë͇̇θÌ˚Ï

(Out of Band)

MPLS-VPN (In-Band)

ЫФ ‡‚ОВМЛВП (In-Band)

èÓ‰Íβ˜ÂÌËÂ Í ‡ÒÌÓÈ VPN

иУ‰НО˛˜ВМЛВ ТЛМВИ VPN

иУ‰НО˛˜ВМЛВ, ЛТФУО¸БЫfl VPN

CE

ЫФ ‡‚ОВМЛfl, Н VRF Н ‡ТМУИ Л ТЛМВИ VPN

ä ‡ÒÌ˚È VPN Ò‡ÈÚ 1

å‡ ¯ ÛÚËÁ‡ˆËfl ‚ fl‰ Â Í Í ‡ÒÌÓÈ VPN

CE

е‡ ¯ ЫЪЛБ‡ˆЛfl ‚ fl‰ В Н ТЛМВИ VPN

ä ‡ÒÌ˚È VPN Ò‡ÈÚ 2

PE

ü‰ Ó ÒÂÚË:

— MPLS

PE

ìÔ ‡‚ÎflÂÏÓ ëÖ Ò

— «ê»-χ ¯ ÛÚËÁ‡ÚÓ ˚

ÔÓ˝Ú‡ÔÌ˚Ï

‡Á‚ Ú˚‚‡ÌËÂÏ (staged)

PE

CE

Netflow Collector

åêÖ

PE

лЛМЛИ VPN Т‡ИЪ 2

χ ¯ ÛÚËÁ‡ÚÓ

ç MPLS-VPN

CE

MCE

LAN ЛОЛ НУМТУО¸МУВ ФУ‰НО˛˜ВМЛВ

çÂÛÔ ‡‚ÎflÂÏÓ ëÖ

χ ¯ ÛÚËÁ‡ÚÓ

Т ФУ‰НО˛˜ВМЛВП

е‡ ¯ ЫЪЛБ‡ЪУ , ФУ‰ОВК‡˘ЛИ НУМЩЛ„Ы Л У‚‡МЛ˛

лЛМЛИ VPN Т‡ИЪ 1

VPN SC IP Manager

ëÂÚ¸ ÛÔ ‡‚ÎÂÌËfl

CE, которые разрешено конфигурировать центру VPN Solutions Center. Соединение non-MPLS-VPN будет использоваться маршрутизатором MCE для связи с Netflow Collector и PE-маршрутизаторами. Неуправляемым CEмаршрутизаторам не нужны Extranet Multiple VPN, и канал non-MPLS-VPN link может использоваться для поддержки устройств PE. Для связи между устройствами MCE и MPE в сетях MPLS-VPN рекомендуется использовать динамическую маршрутизацию. Статический маршрут будет в этом случае опционным, и маршрут по умолчанию будет использоваться для связи с Интернет. С помощью VPN Solutions Center пользователь должен определять ресурсы, необходимые для поддержки связи между маршрутизаторами MCE, а PE-маршрутизаторы должны соединять между собой все сети VPN в случае наличия необходимых ресурсов.

VPN Solutions Center поддерживает управление сетями VPN с помощью экстранет на PE, поэтому устройства CE реально подключаются к сети управления (Management VPN) и сети заказчика (VPN). Оператор, выполняющий инсталляцию, должен пользоваться спи-

24сками доступа (access-lists) и экспортировать карты маршрутов на устройства PE, чтобы для управления СЕмаршрутизаторами использовалась только одна подсеть адреса хоста. В этой системе устройство CE будет считаться «спицей» (spoke) VPN управления, поэтому весь трафик управления в целях безопасности будет направляться на маршрутизатор MCE. В результате конечный пользователь не сможет проникнуть в другие сети VPN через VPN управления.

3.5. СУТЪЫФ Н ‚МВ¯МЛП ЫТОЫ„‡П

Одно из преимуществ MPLS-VPN состоит в том, что заказчики могут пользоваться единой IP-инфраструкту- рой с частными адресами, которые не обязательно должны быть уникальными для опорной сети сервис-провай- дера. Уникальность этих адресов должна соблюдаться только в пределах внутрикорпоративной сети интранет.

Проблемы с уникальностью адресации возникают только в случае соединений с абонентами, которые находятся за пределами сети VPN заказчика. К таким соединениям относятся:

•соединения с другим заказчиком или группой заказчиков (экстранет), которые могут иметь совпадающие адреса;

•подключения к услугам общего доступа (DNS, webкэширование, web-хостинг, электронная почта или Интернет);

•подключение к провайдерам информационного наполнения (например, к финансовым учреждениям).

3.5.1. á‡Í‡Á˜ËÍË Ò Á‡ „ËÒÚ Ë Ó‚‡ÌÌ˚ÏË ‡‰ ÂÒ‡ÏË

Если у заказчика уже есть зарегистрированное адресное пространство IP, то глобальная уникальность его адресов не представляет никакой проблемы. Любые услуги общего доступа и сети экстранет, к которым получает доступ этот заказчик, могут напрямую инжектировать свои префиксы в его таблицы VRF. В этом случае заказчик сам решает, как контролировать доступ к этим услугам. Собственно говоря, так он поступает и без MPLS-VPN, используя межсетевые экраны, прокси-устройства и средства контроля доступа на маршрутизаторах.

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

3.5.2. á‡Í‡Á˜ËÍË Ò ˜‡ÒÚÌ˚ÏË ‡‰ ÂÒ‡ÏË

Большинство заказчиков будет скорее всего использовать частные адреса (RFC 1918), и поэтому для связи между сетью VPN заказчика и услугами общего доступа и сетями экстранет нужно будет применять какую-то систему трансляции адресов. Если этого не сделать, то вы не сможете точно определить адрес-источник в сети заказчика, так как часть адресов обязательно будет совпадать.

В следующих разделах описываются два способа связи с абонентами, которые находятся за пределами частной сети VPN заказчика (это может быть Интернет или экстранет с преобразованием адресов). В обоих случаях используется функция преобразования адресов CISCO (Network Address Translation — NAT), которая поддерживается операционной системой IOS™. Разница между ними заключается в месте, где происходит преобразование. Эти способы доступа к услугам называются:

•доступ к услугам на устройстве СЕ (Service Access at the CE);

•доступ к услугам на шлюзе (Service Access at a Gateway) сервис-провайдера.

3.5.2.1. СУТЪЫФ Н ЫТОЫ„‡П М‡ ЫТЪ УИТЪ‚В CE

Для доступа устройств СЕ к услугам NAT лучше, когда эти устройства принадлежат сервис-провайдеру, который ими и управляет. Такая схема позволяет просто и легко предоставлять услуги NAT устройствам CE.

На рисунке 20 показаны услуги NAT, предоставляе-			кет с адресом назначения из пространства C мог об-
мые устройствам CE для связи с сетями общего доступа			щаться с другим хостом интранет VPN без преобразо-
и для связи с собственной сетью интранет через тот же			ваний адресов, поскольку CE-маршрутизатор будет и
физический канал. В принципе, это вариант экстранет-			без этого (в «родном» режиме) направлять IP-пакет на
доступа (заказчик–заказчик), хотя здесь чаще исполь-			устройство PE.
зуется динамическое, а не статическое преобразование			Если заказчик с исходным адресом C1 отправляет за-
адресов. Заметим, что «сетью общего доступа» здесь мо-			прос хост-системе с адресом P1, CE-маршутизатор пре-
жет быть все что угодно — от серверной фермы до сети			образует C1 в C1T, и PE-маршрутизатор, согласно табли-
Интернет-провайдера (ISP) или провайдера прикладных			це VRF, направит пакет к P1.
услуг (ASP).			Недостаток этого дизайна в том, что каждое устройст-
У заказчика в таблице VRF содержатся все адреса C,			во CE должно иметь пул зарегистрированных адресов.
которые импортируются и экспортируются между все-			Эту проблему можно смягчить, если одно устройство CE
ми другими таблицами VRF, принадлежащими к сети ин-			будет выступать в качестве концентратора доступа к ус-
транет этого заказчика. Все таблицы VRF, действующие			лугам для данного заказчика, как в топологии Hub-and-
на всех сайтах данного заказчика, определяют адресное			Spoke. Подход Hub-and-Spoke обычно будет использо-
пространство его сети Intranet VPN.			ваться для Интернет-доступа, когда трафик проходит че-
			рез прокси-серверы и межсетевые экраны, установлен-
В этой таблице VRF также содержится преобразован-			ные в информационном центре заказчика.
ное зарегистрированное адресное пространство CT. На
рисунке видно, что этот заказчик подписался на две ус-			3.5.2.2. СУТЪЫФ Н ЫТОЫ„‡П ˜В ВБ ¯О˛Б
луги — P1 и P3 — и импортировал в свою таблицу VRF			(Ò Ó ËÂÌÚ‡ˆËÂÈ Ì‡ Á‡Í‡Á˜Ë͇)
все маршруты, относящиеся к этим услугам.			Сервис-провайдер также может предоставить доступ
Кроме того, адресное пространство CT также экспор-			к услугам своей внутренней сети. Ниже описан подход к							25
тируется в каждую таблицу VRF, относящуюся к услу-			доступу через шлюз с ориентацией на заказчика. Это оз-
гам, чтобы обеспечить двустороннюю связь между про-			начает, что каждый заказчик будет идентифицироваться
вайдером приложений (ASP) и заказчиком.			на шлюзе с помощью отдельного подинтерфейса. Преи-
			мущество этого подхода заключается в точной иденти-
Карты маршрутов, виртуальные интерфейсы и спи-			фикации заказчиков, четком определении необходимых
ски доступа настраиваются таким образом, чтобы па-			им услуг и простоте управления. Любое изменение кон-
кЛТЫМУН 20. СУТЪЫФ Н ЫТОЫ„‡П Л Ф ВУ· ‡БУ‚‡МЛВ ‡‰ ВТУ‚ М‡ ЫТЪ УИТЪ‚В CE

кЛТЫМУН 21. мТОЫ„Л Л Ф ВУ· ‡БУ‚‡МЛВ ‡‰ ВТУ‚ М‡ ¯О˛БВ (Т У ЛВМЪ‡ˆЛВИ М‡ Б‡Н‡Б˜ЛН‡)

26
					дельный подинтерфейс. Шлюз подключается к соответ-
	фигурации связывается только с данным заказчиком
	(таблицей VRF и подинтерфейсом), что ограничивает				ствующему PE-маршрутизатору, который имеет табли-
	влияние конфигурационных ошибок на других заказчи-				цу VRF данного заказчика, определенную на каждом
	ков. Небольшой недостаток состоит в том, что для каж-				подинтерфейсе, ведущем к шлюзу.
	дого заказчика нужно определять отдельный интерфейс
	и таблицу VRF, что увеличивает объем конфигурации и				3.5.2.3 СУТЪЫФ Н ЫТОЫ„‡П ˜В ВБ ¯О˛Б
	требует большего объема памяти на шлюзе и PE-марш-				(Ò Ó ËÂÌÚ‡ˆËÂÈ Ì‡ ÛÒÎÛ„Ë)
	рутизаторах в точке предоставления услуг.				Описанную выше схему можно изменить, сориенти-
	В этом сценарии весь трафик, предназначенный для				ровав ее не на заказчиков, а на услуги. Каждая услуга на
	доступа к внешним услугам, должен проходить через				шлюзе (service gateway) будет иметь связанную с ней
	шлюз (service gateway router). Этот шлюз транслирует				таблицу VRF и подинтерфейс. Эти таблицы VRF опреде-
	адреса и отправляет пакет к следующей VRF или непо-				ляются в той части сети, где действуют непреобразован-
	средственно к подключенному хосту. Кроме этого, шлюз				ные адреса. Другими словами, в большинстве случаев в
	выполняет функции межсетевого экрана, повышая об-				этих таблицах будет отражаться частное адресное про-
	щий уровень безопасности. Преимущество шлюза со-				странство заказчика. Из этого вытекает, что адреса лю-
	стоит в том, что его пул адресов может использоваться				бого заказчика, который пользуется шлюзом (service
	всеми заказчиками. Таким образом повышается эффек-				gateway), не должны совпадать с адресами других заказ-
	тивность использования адресов.				чиков, которые пользуются тем же шлюзом (такое же
	На рисунке 21 показаны два заказчика, пользующиеся				правило действует и в предыдущем сценарии, ориенти-
	услугами, которые предоставляются через шлюз Service				рованном на заказчиков).
	Gateway 1. Этот шлюз настроен на предоставление пяти				Любой заказчик, подписывающийся на данную услу-
	разных услуг. Три из них предоставляются по прямым				гу, должен импортировать данные о маршрутах (route-
	каналам связи со шлюзом (A, B, C), а две другие предос-				target), которые экспортируются из сервисной таблицы
	тавляются в других местах, и доступ к ним осуществля-				VRF. И наоборот, каждая сервисная таблица VRF должна
	ется с помощью индивидуальных таблиц VRF (Public				импортировать маршруты заказчиков для поддержки
	Service 1 и Public Service 2). Эти таблицы определяются				двусторонней связи. В этом примере единая таблица
	на PE-маршрутизаторе. Все услуги должны иметь заре-				VRF для всех услуг создается в той части сети, где ис-
	гистрированные IP-адреса.				пользуются преобразованные адреса. Это упрощает за-
	Каждый заказчик должен иметь на шлюзе свой от-				дачи настройки конфигурации, но затрудняет точный

контроль над доступом.

На рисунке 22 показан тот же шлюз (service gateway), который был описан в сценарии, ориентированном на заказчика, но у него имеется пять таблиц VRF, определенных на стороне с непреобразованными адресами, и одна таблица VRF для всех услуг на стороне с преобразованными адресами. Заказчик 2 подписывается на услугу

P2, импортируя маршрут к P2 (route-target). Заказчик 1

подписывается на услуги P1 и A, импортируя маршрут к

P1 и маршрут к A.

С той стороны шлюза (service gateway), где действуют преобразованнные адреса, располагается единая таблица VRF со статическим маршрутом для всех преобразованных адресов Cxt . Этот маршрут ведет обратно к шлюзу. Пул преобразованных адресов Cxt также импортируется в каждую сервисную таблицу VRF (P1 и P2), чтобы трафик мог вернуться к шлюзу.

Таблицы VRF с преобразованными адресами на РЕмаршрутизаторе PE-I импоритруют маршруты каждой услуги (P1 и P2), к которой предоставляется доступ. Услуги A, B и C являются локальными для домена маршрутизации шлюза и поэтому не требуют специальной конфи-

кЛТЫМУН 22. СУТЪЫФ Н ЫТОЫ„‡П ˜В ВБ ¯О˛Б (Т У ЛВМЪ‡ˆЛВИ М‡ ЫТОЫ„Л)

гурации MPLS-VPN.
3.6. мТОЫ„‡ аМЪВ МВЪ-‰УТЪЫФ‡
3.6.1. и УТЪУИ ТУ‚ПВТЪМ˚И аМЪВ МВЪ-‰УТЪЫФ (Ъ ‡МТОflˆЛfl
‡‰ ВТУ‚ М‡ ПМУКВТЪ‚В У·˘Лı ¯О˛БУ‚)
Структура совместного доступа к Интернет предназна-
чена для заказчиков, которым нужен простой способ вы-
хода в Интернет без установки собственных средств кэ-
ширования и межсетевых экранов. Этот способ хорошо
подходит в основном для малых предприятий, не имею-
щих собственной информационно-технологической инф-
раструктуры. Преобразование адресов выполняется сер-
вис-провайдером на общем шлюзе (или шлюзах). В редких
случаях вся сеть заказчика пользуется зарегистрирован-
ными IP-адресами, и тогда трансляции адресов (NAT) не
требуется, а трафик проходит этап NAT без обработки.
Главное преимущество преобразования адресов в цен-
тральной точке состоит в экономии зарегистрированно-
го адресного пространства, так как все заказчики совме-
стно пользуются адресами из единого пула. На рисунке
23 показан общий шлюз для доступа в Интернет. Исполь-
зуемый по умолчанию маршрут I импортируется в таб-	27

кЛТЫМУН 23. лУ‚ПВТЪМ˚И аМЪВ МВЪ-‰УТЪЫФ — ПМУКВТЪ‚У ¯О˛БУ‚ NAT

адресном пространстве. Множество Интернет-шлюзов

лицы VRF каждого заказчика, и поэтому любой трафик

от заказчика, местонахождение которого явно не указы-

могут, однако, иметь общий доступ к единому межсетево-

вается, передается на маршрутизатор Internet Gateway.

му экрану, как показано на рисунке 23.

Соответствующие маршруты заказчиков импортируют-

ся в таблицы Интернет VRF и на РЕ-маршрутизатор PE-I.

3.6.2. и УТЪУИ ТУ‚ПВТЪМ˚И аМЪВ МВЪ-‰УТЪЫФ (Ъ ‡МТОflˆЛfl

28

Маршрутизатор Internet Gateway будет преобразовы-

‡‰ ÂÒÓ‚ ̇ Ó‰ÌÓÏ Ó·˘ÂÏ ¯Î˛ÁÂ)

вать адрес заказчика в зарегистрированный IP-адрес,

Если используется единый Интернет-шлюз (т.е. все

взятый из доступного пула (Cx -> Cxt), и затем переда-

преобразования адресов выполняются единым устрой-

вать пакет через механизм кэширования и межсетевой

ством) и если этим устройством пользуются заказчики с

экран в Интернет. Преобразование адресов может вы-

совпадающими адресами, трансляция адресов выполня-

полняться и на межсетевом экране.

ется в два этапа. Этот процесс называется «двойной

трансляцией» (double NAT). Первая трансляция выпол-

Проблема с этим дизайном, как и с любым дизайном,

няется на CE-маршрутизаторе с помощью незарегистри-

включающим центральный шлюз, заключается в том, что

рованных адресов, чтобы не тратить ограниченных ре-

единый шлюз может преобразовывать адреса только для

сурсов зарегистрированного пула. Это преобразование

заказчиков, адреса которых не совпадают. Если заказчики

позволяет шлюзу уникально идентифицировать заказ-

пользуются единым адресным пространством, они долж-

чиков с совпадающими адресами и затем производить

ны иметь отдельный шлюз, выполняющий преобразова-

вторую трансляцию (присвоение зарегистрированных

ние адресов для каждого заказчика, работающего в общем

адресов) для доступа в Интернет. Этот пример показан

кЛТЫМУН 24. лУ‚ПВТЪМ˚И аМЪВ МВЪ-‰УТЪЫФ — В‰ЛМ˚И ¯О˛Б NAT