RU2669525C1

RU2669525C1 - Частные псевдонимы конечных точек для изолированных виртуальных сетей

Info

Publication number: RU2669525C1
Application number: RU2017107749A
Authority: RU
Inventors: Кевин Кристофер МИЛЛЕР; Ричард Александер ШИХАН; Дуглас Стюарт ЛОРЕНС; Марван Салах Эль-Дин ОВЕЙС; Эндрю Брюс ДИКИНСОН
Original assignee: Амазон Текнолоджис, Инк.
Priority date: 2014-09-19
Filing date: 2015-09-18
Publication date: 2018-10-11
Also published as: CN113014468B; AU2015317394B2; KR20170057357A; AU2018203702B2; US20160087940A1; CN107077367B; JP6810182B2; US20240097939A1; AU2015317394A1; KR101948598B1; CN107077367A; US10256993B2; US20180034663A1; WO2016044769A1; AU2018203702B9; JP7073475B2; JP2017529789A; US20210152392A1; JP6499276B2; EP3195531A1

Abstract

Изобретение относится к области связи. Технический результат заключается в предоставлении возможности маршрутизации сетевого трафика между изолированными виртуальными сетями (IVN, isolated virtual networks) сети провайдера и одной или более общедоступными службами без назначения общедоступных IP-адресов в IVN и без прохождения сетей пользователя. Способ передачи данных в изолированной виртуальной сети содержит: определение в туннельном посреднике сети провайдера, что первый частный псевдоним конечной точки (РАЕ) был назначен в качестве целевого объекта маршрутизации для трафика; получение в туннельном посреднике базового пакета; передачу посредством туннельного посредника на первый узел конкретной службы пакета инкапсуляции. 2 н. и 13 з.п. ф-лы, 10 ил.

Description

УРОВЕНЬ ТЕХНИКИ

[0001] Многие компании и другие организации работают с компьютерными сетями, которые соединяют между собой многочисленные вычислительные системы для поддержания своей работы, такие как вычислительные системы, расположенные в одном месте (например, как часть локальной сети) или находящиеся в нескольких различных географических местоположениях (например, соединенные посредством одной или более частных или общедоступных промежуточных сетей). Например, обычным явлением стали центры обработки данных, содержащие значительное количество соединенных между собой вычислительных систем, такие как частные центры обработки данных, которые находятся в ведении и работают от имени одной организации, а также общедоступные центры обработки данных, которые находятся в ведении лиц, таких как предприятия, чтобы предоставлять пользователям вычислительные ресурсы.

[0002] Некоторые из провайдеров дают своим пользователям возможность создавать логически изолированные сети, используя ресурсы, расположенные в таких центрах обработки данных. Например, пользователю может быть назначен некоторый набор виртуализированных серверов и/или других ресурсов, реализованных на управляемых провайдером узлах, и пользователю может быть предоставлена существенная гибкость в отношении сетевой конфигурации ресурсов. Например, пользователь может выбрать IP (протокол Интернета) адреса для серверов, по своему усмотрению определить подсети, и так далее. Такие настраиваемые пользователем сети, реализованные с использованием ресурсов провайдера, могут иметь различные названия, включая «изолированные виртуальные сети» или «виртуальные частные облака». В некоторых случаях пользователи могут назначить частные IP-адреса (например, адреса, которые не видны или не объявлены за пределами изолированных виртуальных сетей) некоторым ресурсам в пределах изолированной виртуальной сети, например, без необходимости заботиться об уникальности адресов ресурсов за пределами изолированной виртуальной сети. В таких средах провайдер может поддерживать высокий уровень безопасности, сетевой изоляции, а также доступности, что позволяет пользователям выполнять критически важные для бизнеса приложения в изолированных виртуальных сетях и получать такое же (или более высокое) качество обслуживания в сравнении с тем, которое достижимо в собственных помещениях пользователя.

[0003] По меньшей мере некоторые провайдеры, которые поддерживают изолированные виртуальные сети, могут также реализовывать ряд других служб, таких как службы хранения, службы баз данных и тому подобное. Некоторые из этих служб могут быть предназначены для доступа из Интернета общего пользования - например, для клиентов может быть создан ряд публично объявленных IP-адресов или соответствующих URI (универсальных идентификаторов ресурсов), чтобы получить доступ к ресурсам такой службы. По меньшей мере в некоторых средах, для пользователей, которые хотят получить доступ к таким публично объявленным службам из своих высоко безопасных изолированных виртуальных сетей, может быть непростой задачей сделать это, потенциально не уменьшая безопасность или не неся существенных затрат.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

[0004] На фиг. 1 показан пример системной среды, в которой могут быть созданы частные псевдонимы конечных точек (РАЕ, private alias endpoints), чтобы разрешить маршрутизацию сетевого трафика между изолированными виртуальными сетями (IVN, isolated virtual networks) сети провайдера и одной или более общедоступными службами без назначения общедоступных IP-адресов в IVN и без прохождения сетей пользователя, согласно по меньшей мере некоторым вариантам осуществления.

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

[0006] На фиг. 3а и 3b показаны соответствующие примеры альтернативных компонентов на стороне службы, которые могут обрабатывать пакеты, возникающие в вычислительном экземпляре изолированной виртуальной сети, согласно по меньшей мере некоторым вариантам осуществления.

[0007] На фиг. 4 показаны примеры форматов инкапсуляции для базового пакета, возникающего в вычислительном экземпляре, согласно по меньшей мере некоторым вариантам осуществления.

[0008] На фиг. 5 показаны примеры запросов и ответов конфигурации РАЕ, согласно по меньшей мере некоторым вариантам осуществления.

[0009] На фиг. 6 показаны примеры содержимого базы данных конфигурации РАЕ, согласно по меньшей мере некоторым вариантам осуществления.

[0010] На фиг. 7 показан пример использования идентификаторов IVN и РАЕ для различения запросов, полученных службой от вычислительных экземпляров с одинаковыми частными IP-адресами, согласно по меньшей мере некоторым вариантам осуществления.

[0011] На фиг. 8 показана блок-схема, иллюстрирующая аспекты операций, которые могут быть выполнены для настройки РАЕ, согласно по меньшей мере некоторым вариантам осуществления.

[0012] На фиг. 9 показана блок-схема, иллюстрирующая использование туннельного протокола для передачи пакетов от вычислительного экземпляра к общедоступной службе, согласно по меньшей мере некоторым вариантам осуществления.

[0013] На фиг. 10 показана блок-схема, иллюстрирующая пример вычислительного устройства, которое может использоваться по меньшей мере в некоторых вариантах осуществления.

[0014] Несмотря на то, что в настоящем документе описаны примеры некоторых вариантов осуществления и иллюстративных чертежей, специалисту в данной области техники будет понятно, что варианты осуществления изобретения не ограничиваются описанными вариантами осуществления или чертежами. Следует понимать, что чертежи и подробное описание не ограничивают варианты осуществления конкретными раскрытыми формами, а напротив, изобретение должно охватывать все модификации, эквиваленты и альтернативы, входящие в рамки сущности и объема изобретения, как определено в прилагаемой формуле изобретения. Заголовки разделов, используемые в настоящем документе, предназначены только для организационных целей и не предназначены для ограничения объема описания или формулы изобретения. В данной заявке слово «может» используется в допускающем смысле (т.е. в значении «имеет возможность»), а не в обязательном смысле (т.е. в значении «должен»). Аналогичным образом, слова «включает», «включающий» и «включает в себя» означают включающий, но не ограничивающийся этим.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

[0015] Ниже описаны различные варианты осуществления способов и устройств для поддержки частных псевдонимов конечных точек (РАЕ) в сети провайдера. Сети, созданные юридическим лицом, таким как компания или организация государственного сектора для предоставления одной или более служб (например, различных типов многоклиентских и/или одноклиентских облачных служб вычисления и хранения), доступных через Интернет и/или другие сети распределенному набору клиентов, в настоящем документе могут называться «сети провайдера». По меньшей мере некоторые сети провайдера также могут называться «общедоступные облачные среды». Данная сеть провайдера может включать в себя множество центров обработки данных, содержащих различные совокупности ресурсов, такие как объединения физических и/или виртуализированных компьютерных серверов, устройств хранения данных, сетевого оборудования и т.п., необходимые для реализации, настройки и распределения инфраструктуры и служб, предлагаемых провайдером. По меньшей мере в некоторых вариантах осуществления, виртуальная вычислительная служба, реализованная в сети провайдера, может позволить клиентам использовать для своих приложений одну или более гостевых виртуальных машин (которые могут называться в настоящем документе как «вычислительные экземпляры» или просто «экземпляры»), с одним или более вычислительных экземпляров, которые выполняются на узле экземпляра большого комплекса узлов экземпляров. В крупных сетях провайдера некоторые центры обработки данных могут располагаться в разных городах, штатах или странах и, в некоторых вариантах осуществления, ресурсы, выделенные для данного приложения, могут быть распределены между несколькими такими местами, чтобы достичь необходимых уровней доступности, отказоустойчивости и производительности.

[0016] По меньшей мере в некоторых вариантах осуществления, сеть провайдера может разрешать пользователям запрашивать создание «изолированных виртуальных сетей» (IVN) в центрах обработки данных провайдера. IVN (которая в некоторых средах также может называться «виртуальное частное облако» или VPC) может содержать совокупность вычислительных и/или других ресурсов в логически изолированном участке сети провайдера, над которым пользователю предоставляется существенный контроль в отношении конфигурации сети. В некоторых вариантах осуществления, например, пользователь может выбирать диапазоны IP (протокол Интернета) адресов, которые должны использоваться для ресурсов IVN, таких как различные вычислительные экземпляры, управлять созданием подсетей внутри IVN, а также настраивать таблицы маршрутов и подобное для IVN. В некоторых вариантах осуществления, IP-адреса по меньшей мере некоторых из устройств, находящихся в пределах IVN, могут быть не видны за пределами IVN, по меньшей мере по умолчанию. Такие IP-адреса могут называться в настоящем документе как «частные» IP-адреса, в отличие от «общедоступных» IP-адресов, которые доступны из Интернета общего пользования вследствие того, что они были прямо или косвенно объявлены в Интернете общего пользования с помощью протокола BGP (протокола граничного шлюза) или других аналогичных протоколов. Использование частных адресов может позволить клиентам защитить свои приложения от возможных атак, исходящих, например, из Интернета. В некоторых вариантах осуществления, поддержка IVN может быть одним из свойств более общей виртуальной вычислительной службы (VCS, virtual computing service) сети провайдера. Например, VCS может также поддерживать резервирование или выделение вычислительных экземпляров, которые не являются частью IVN и для которых VCS (а не клиент, которому выделяются экземпляры) выполняет большинство или все требуемые конфигурации сети.

[0017] По меньше мере некоторые из служб, реализованных в сети провайдера, например, одна или более служб хранения или служб базы данных могут быть открытыми для общего доступа. Т.е., некоторый набор IP-адресов (или соответствующих имен узлов/URI), которые могут использоваться для доступа к службе, может быть публично объявленным и, следовательно, клиент может иметь возможность отправлять запросы службы такой службе из устройства, которое имеет подключение к Интернету. Например, служба хранения, называемая «SvcX», может быть доступна клиенту через публично объявленный URI, такой как https://SvcX.<providername>.com, и IP-адрес для такой службы может быть получен от одного или более серверов службы доменных имен (DNS).

[0018] Некоторые приложения, которые выполняются в пределах IVN от имени клиента, могут требовать доступ к таким общедоступным службам. Например, приложению электронной коммерции, выполняющемуся на вычислительном экземпляре клиента в IVN, может потребоваться читать или записывать данные в общедоступную службу хранения сети провайдера. Один из способов установить подключение к общедоступной службе может включать в себя назначение одного или более общедоступных IP-адресов ресурсам в пределах IVN (и/или создание доступного из Интернета шлюза для IVN), что на практике может несколько противоречить требованиям к изоляции и безопасности клиента IVN. Другим способом установить подключение между вычислительными экземплярами, работающими в IVN, и ресурсами в общедоступной службе может быть сначала создание соединения по VPN (виртуальной частной сети) между IVN и сетью пользователя, а затем отправка косвенно трафика от IVN общедоступной службе через сеть пользователя. Однако по меньше мере в некоторых средах, такое подключение на основе VPN может быть достаточно дорогим, и непрямые пути, используемые для трафика, не обязательно могут быть достаточно быстрыми (например, в отношении сквозной задержки), чтобы соответствовать требованиям клиентских приложений.

[0019] Соответственно, чтобы обеспечить эффективное соединение между ресурсами IVN и по меньшей мере некоторыми общедоступными службами, в некоторых вариантах осуществления оператор сети провайдера может поддерживать создание частных псевдонимов конечных точек для IVN. Как следует из названия, РАЕ может выступать в качестве «виртуальной» конечной точки, представляющей общедоступную службу, а также РАЕ может быть «частным», поскольку его использование не требует назначения общедоступного сетевого адреса для любого субъекта в пределах IVN. В некоторых средах РАЕ также могут называться «виртуальные частные конечные точки». По меньшей мере в некоторых вариантах осуществления, РАЕ может позволять приложению, выполняющемуся в пределах IVN, созданной от имени клиента, отправлять запросы службы к (и получать ответы от) общедоступным службам, реализованным в другом месте в сети провайдера, например, без необходимости предоставлять IVN доступ к Интернету общего пользования и без прохождения сетевых каналов, находящихся за пределами сети провайдера. Туннельный протокол может быть использован, как описано ниже, чтобы инкапсулировать пакеты трафика, возникающего в IVN, для передачи в ту часть сети провайдера, где реализована общедоступная служба. Ни клиентские приложения, выполняющиеся в IVN, ни ресурсы общедоступной службы, которые реализуют клиентские запросы службы, не обязательно должны быть даже осведомлены об использовании туннельного протокола в различных вариантах осуществления. Т.е., в таких вариантах осуществления может не потребоваться никаких изменений для клиентских приложений или логики, участвующих в обслуживании клиентских запросов на ресурсах службы.

[0020] По меньшей мере в одном из вариантов осуществления, создание РАЕ может потребовать от клиента выполнить несколько дополнительных шагов конфигурации IVN, очень похожих по простоте использования на те шаги, которые обычно требуются для других аспектов конфигурации сети IVN, выполняемой клиентом. Например, клиент может запросить создание РАЕ для IVN с помощью программного интерфейса управления/администрирования (например, консоли или интерфейса программирования приложений (API, application programming interface)), a затем связать РАЕ с выбранной службой, имеющей понятное имя службы. Клиент может затем указать РАЕ, например, в таблице маршрутов, созданной для одной или более подсетей IVN, в качестве целевого объекта для трафика, чьим получателем является какой-либо узел или ресурс общедоступной службы в некоторых вариантах осуществления. В некоторых реализациях, общий псевдоним (например, имя службы «Svc1») может использоваться в таблице маршрутов для указания службы в качестве получателя, а идентификатор, назначенный РАЕ, может указываться в качестве целевого объекта. В таких реализациях клиент может не определять любые IP-адреса для службы при указании получателя. По меньшей мере в некоторых вариантах осуществления, клиент может создать несколько различных РАЕ в данной IVN, например, чтобы обеспечить доступ к ряду различных служб, реализованных за пределами IVN.

[0021] После того, как РАЕ был настроен и указан в качестве целевого объекта для трафика, предназначенного для службы из конкретной IVN, клиентское приложение, выполняющееся на вычислительном экземпляре IVN (где вычислительный экземпляр имеет назначенный частный IP-адрес и не имеет общедоступного IP-адреса), может посылать запросы службе аналогично тому, как такие запросы посылались бы от подключенного к Интернету устройства. Например, от вычислительного экземпляра может посылаться DNS-запрос (например, на DNS-сервер в сети провайдера), чтобы получить общедоступный IP-адрес службы. Приложение может отправлять запрос службы с помощью веб-службы API (или любого подобного программного интерфейса, поддерживаемого службой), который может преобразовываться операционной системой или другими компонентами вычислительного элемента в один или более базовых пакетов с общедоступным IP-адресом службы в качестве получателя и частным IP-адресом экземпляра в качестве источника.

[0022] Как упоминалось ранее, вычислительный экземпляр может быть реализован в виде гостевой виртуальной машины, выполняющейся на узле экземпляра. По меньшей мере в некоторых вариантах осуществления, узел экземпляра может включать в себя различные компоненты программного стека для управления виртуализацией, такие как гипервизор и/или экземпляр привилегированной операционной системы (часто называемый «dom-0» или экземпляр нулевого домена). Такой компонент управления виртуализацией (который может в настоящем документе называться VMC, virtualization management component) может отвечать за преобразование запросов ресурсов, посланных на гостевые виртуальные машины, в физические операции, выполняемые на аппаратных ресурсах. В одном варианте осуществления, VMC, выполняющийся на узле экземпляра, может перехватывать базовый пакет, посланный из вычислительного экземпляра, и VMC может отвечать за определение того, как базовый пакет должен (и должен ли) быть преобразован для передачи по физической сети, к которой подключен узел экземпляра. В некоторых реализациях, VMC может иметь доступ к записям метаданных IVN, указывающих выбор РАЕ в качестве целевого объекта для трафика, направленного службе, а также может иметь доступ к списку общедоступных IP-адресов службы. Таким образом, VMC в состоянии определить, что перехваченный базовый пакет должен быть передан службе, связанной с РАЕ.

[0023] По меньшей мере в некоторых вариантах осуществления, различные службы (включая виртуальную вычислительную службу, на которой настроены IVN, а также конечную службу, назначенную РАЕ) могут быть назначены соответствующим логически разделенным частям сети провайдера. Возможно, трафику между заданными парами служб придется пройти через мостовую сеть (которая также может называться как граничная сеть), чтобы попасть в конечную службу из исходной службы. Такие мостовые сети можно рассматривать как подмножества сети провайдера специального назначения, точно так же, как и сети исходной и конечной службы можно рассматривать как подмножества сети провайдера. Как следует из названия, мостовые сети могут выступать в качестве сетей-посредников между различными логически разделенными частями сети провайдера (и, в некоторых случаях, в качестве посредников между сетью провайдера и внешними сетями). VMC может не иметь прямого доступа к мостовой сети, которую необходимо пройти для достижения конечной службы, и, следовательно, может потребоваться использовать посредника, способного маршрутизировать пакеты по такой мостовой сети. Соответственно, по меньшей мере в некоторых вариантах осуществления, VMC может доставлять содержимое базового пакета туннельному посреднику, например, в первом инкапсулированном варианте пакета. Этот первый пакет инкапсуляции может затем быть преобразован туннельным посредником в соответствии с выбранным туннельным протоколом, и второй вариант инкапсуляции пакета может быть передан через путь или туннель мостовой сети на узел конечной службы. Любой из множества различных способов инкапсуляции может использоваться для любого этапа инкапсуляции в различных вариантах осуществления; некоторые конкретные примеры методов инкапсуляции описаны более подробно ниже.

[0024] В одном варианте осуществления, заголовок или заголовки, добавленные туннельным посредником, могут включать в себя кодирования или представления исходной IVN и/или РАЕ, связанной с конечной службой. В одной реализации, например, туннельный протокол может включать в себя инкапсуляцию базовых пакетов IPv4 в IPv6-совместимые форматы пакета, в котором некоторые из адресных битов IPv6 используются для кодирования идентификаторов IVN и/или РАЕ. В конечной службе, содержание базового пакета (включая, например, запрос службы, а также частный IP-адрес исходного вычислительного экземпляра) может извлекаться из инкапсулированного варианта вместе с идентификаторами IVN и/или РАЕ. В некоторых вариантах осуществления, идентификатор IVN или РАЕ может помогать отличать друг от друга различные исходные вычислительные экземпляры (в разных IVN), которым могут быть назначены одинаковые частные IP-адреса, как более подробно описано ниже. Запрошенные операции, указанные в теле базового пакета, могут выполняться, а ответ может возвращаться запрашивающему приложению на исходный узел экземпляра, например, с использованием аналогичных методов туннелирования и инкапсуляции в обратном направлении.

[0025] Клиенты могут иметь возможность применять к РАЕ политики контроля доступа, по меньшей мере в некоторых вариантах осуществления, например, с использованием типов программных интерфейсов управления, упомянутых ранее. Политика контроля доступа может, например, указывать типы операций или запросов службы, которые разрешаются (или запрещаются), объекты (например, файлы или каталоги в службе, связанной с хранением), над которыми разрешаются/запрещаются операции, периоды времени (например, определенные часы рабочего дня), в течение которых применяется политика, участников (например, конкретных пользователей или группы), к которым применяется политика, и так далее. В некоторых вариантах осуществления, в которых такая политика назначается для РАЕ, запросы, извлеченные из пакетов инкапсуляции в службе, могут проверяться, чтобы гарантировать, что они не нарушают действующие политики. В других вариантах осуществления, потенциальные нарушения политик могут проверяться на стороне IVN, вместо или в дополнение к проверке в конечной службе - например, VMC может прервать передачу запроса, если он определил, что запрос нарушает политику, связанную с РАЕ.

[0026] В одном варианте осуществления, РАЕ может использоваться не только для маршрутизации пакетов между IVN и службами, реализованными сетью провайдера, но и для маршрутизации пакетов между IVN и сторонними службами, которые реализованы в другом месте в сети провайдера. В таком варианте осуществления, третья сторона (например, другой пользователь виртуальной вычислительной службы сети провайдера) может создать службу, используя некоторый набор сетевых ресурсов провайдера, и объявить общедоступные IP-адреса, на которых служба может быть доступна. Сторонний провайдер может зарегистрировать свою службу для доступа РАЕ, например, путем отправки запроса диспетчеру конфигураций сети провайдера. Диспетчер конфигураций может проверять, что будущая сторонняя служба может поддерживать доступ через маршруты, для которых РАЕ указаны в качестве целевых объектов. Например, диспетчер конфигураций может инициировать назначение внешних узлов, которые способны реализовывать туннельный протокол (таких как интеллектуальные средства балансировки нагрузки) для сторонних служб в некоторых вариантах осуществления. В других вариантах осуществления, если оператор сторонней службы уже создал узлы, которые предназначены для реализации туннельного протокола, возможности таких узлов могут быть проверены. После того, как сторонняя служба была зарегистрирована и были созданы внешние узлы, которые могут извлекать (декапсулировать) и инкапсулировать пакеты в соответствии с туннельным протоколом, клиенты могут настроить РАЕ на своих IVN для доступа к сторонней службе. Например, имя или псевдоним сторонней службы (например,«ThirdPartySvc1») может быть добавлен в список опций адресата службы (например, «StorageSvc1», «DBSvc1» и т.д., представляющие общедоступные службы, которые уже настроены для поддержки РАЕ), помимо того, как быть связанным с РАЕ клиентами с использованием программных интерфейсов.

Пример системной среды

[0027] На фиг. 1 показан пример системной среды, в которой могут быть созданы частные псевдонимы конечных точек (РАЕ), чтобы разрешить маршрутизацию сетевого трафика между изолированными виртуальными сетями сети провайдера и одной или более общедоступными службами без назначения общедоступных IP-адресов в IVN и без прохождения сетей пользователя, согласно по меньшей мере некоторым вариантам осуществления. Как показано, система 100 содержит сеть 102 провайдера, в которой реализуется множество служб, включая виртуальную вычислительную службу (VCS) и общедоступную службу Svc1 (т.е., службу, которая позволяет своим клиентам отправлять запросы через публично объявленные IP-адреса или URI). Общедоступная служба Svc1 может содержать, например, службу хранения, обеспечивающую доступ на основе веб-службы к объектам хранилища произвольного размера, службу нереляционной базы данных, службу реляционной базы данных, службу уведомлений, службу очереди сообщений или любую из множества других типов служб. Каждая из этих служб может содержать множество узлов, устройств хранения данных и других вычислительных средств, которые в совокупности образуют логически отдельную часть сети провайдера, например, со своим собственным уровнем администрирования или плоскости управления. На фиг. 1, например, ресурсы VCS расположены в пределах VCS сети 104, в то время как ресурсы Svc1 расположены в пределах сети 170 Svc1.

[0028] В пределах VCS сети 104, от имени различных клиентов может быть создано несколько различных изолированных виртуальных сетей (IVN) 110, таких как IVN 110А и IVN 110 В. Клиенту, от имени которого создается данная IVN 110, может быть предоставлена существенная гибкость в отношении конфигурации сети IVN - например, клиент может назначить нужные IP-адреса различным вычислительным элементам 112 без необходимости убеждаться, что IP-адреса не совпадают с другими, использующимися за пределами IVN, создать подсети, заполнить таблицы маршрутов и так далее. Как показано, каждая IVN может включать в себя множество узлов 130 экземпляров (IH), таких как IH 130А и 130В в IVN 110А, и IH 130М и 130N в IVM 110В. На каждом IH 130 могут быть реализованы один или более вычислительных экземпляров (CI) 112, таких как CI 112А на IH 130А, CI 112В на IH 130В, CI 112К на IH 130М и CI 112L на IH 130N. Каждый из вычислительных экземпляров может использоваться для одного или более клиентских приложений или подкомпонентов приложений.

[0029] В варианте осуществления, показанном на фиг. 1, служба Svc1 содержит по меньшей мере два уровня ресурсов: внешние (FE) узлы 171 (такие как средства балансировки нагрузки и/или маршрутизаторы запросов), которые выполнены с возможностью принимать входящие запросы службы и передавать исходящие ответы службы, и внутренние (BE) узлы 173, на которых реализована логика службы для выполнения запросов службы. По меньше мере некоторые из FE узлов, такие как FE узлы 171А, 171В и 171С, могут иметь общедоступные IP-адреса, назначенные им, что делает Svc1 общедоступной, например, для устройств Интернета 139 общего пользования и для подключенных к Интернету устройств в собственных сетях пользователя, таких как сеть 185.

[0030] В показанном варианте осуществления, в IVN 110А был создан частный псевдоним 150 конечной точки (РАЕ), например, чтобы позволить относящимся к Svc1 пакетам передаваться между CI 110А (который имеет частный IP-адрес, недоступный напрямую из Интернета общего пользования) и сетью Svc1 170, не требуя от CI 110А иметь назначенный ему общедоступный IP-адрес и не требуя от трафика проходить через собственную сеть 185 пользователя или каналы 139 Интернета общего пользования. Как более подробно описано ниже, в некоторых вариантах осуществления для IVN 110А может быть создана запись таблицы маршрутов, чтобы указать, что трафик, возникающий в одной или более подсетях IVN 110А (включая подсеть, в которой настроен CI 110А) и предназначенный для Svc1, необходимо переадресовать на РАЕ 150. Эта запись таблицы маршрутов, а также другие метаданные, такие как список общедоступных IP-адресов Svc1, могут быть доступны компоненту управления виртуализацией (VMC) (например, компоненту гипервизора), выполняющемуся на каждом из узлов 130 экземпляров IVN 110А, по меньшей мере в некоторых вариантах осуществления. Диспетчер 106 конфигураций IVN может реализовывать один или более программных интерфейсов (таких как интерфейсы программирования приложений (API), веб-консоли, программы командной строки или графические интерфейсы пользователя и т.п.), что позволяет клиентам запрашивать создание РАЕ, связывание конкретных служб с РАЕ, создание или изменение записей таблицы маршрутов для IVN, и так далее.

[0031] VMC в узле 130А экземпляра может перехватывать исходящий сетевой базовый пакет, созданный в CI 112А и содержащий запрос службы, направленный Svc1. (Следует отметить, что некоторые запросы службы и связанные с ними параметры запроса могут требовать более чем один пакет. Для упрощения изложения, в последующем описании полагается, что запрос службы помещается в базовый пакет. Метод туннелирования, описанный в настоящем документе для таких запросов службы, может также использоваться для запросов службы, которые пересекают границы пакетов в различных вариантах осуществления). Запрос службы может форматироваться в соответствии с любым соответствующим интерфейсом, поддерживаемым Svc1, таким как HTTP (протокол передачи гипертекста), протокол HTTPs (защищенный HTTP), XML (расширяемый язык разметки) или тому подобное. Базовый пакет может указывать частный IP-адрес CI в качестве источника и общедоступный IP-адрес Svc1 в качестве получателя. В показанном варианте осуществления, VMC может создавать из базового пакета первый пакет инкапсуляции в соответствии с первым протоколом инкапсуляции. В некоторых реализациях, базовый пакет может быть включен в тело первого пакета инкапсуляции, при этом один или более дополнительных заголовков первого протокола инкапсуляции могут содержать (помимо другой информации) указание того, что пакет содержит трафик РАЕ. Первый пакет инкапсуляции может передаваться, как показано пунктирной стрелкой для трафика 162 РАЕ, от узла 112А экземпляра к туннельному посреднику (TI), такому как TI 142А комплекса 140 туннельных посредников в показанном варианте осуществления. Может быть создан комплекс 140 TI (который может содержать множество вычислительных устройств, настроенных как TI, таких как TI 142А, 142В и т.д.), чтобы позволить трафику передаваться между VCS сетью 104 и множеством других логически разделенных сетей сети провайдера, включая сеть 170 Svc1. В некоторых вариантах осуществления, туннельные посредники могут содержать вычислительные устройства специального назначения, оптимизированные для сетевой обработки. В других вариантах осуществления, туннельный посредник может содержать процесс или поток выполнения в вычислительном устройстве общего назначения.

[0032] По меньше мере в некоторых вариантах осуществления, после получения первого пакета инкапсуляции TI 142А может извлекать содержимое базового пакета, а также заголовки, добавленные VMC. В одном варианте осуществления, TI 142А может использовать базу данных сопоставления, связанную с конкретным туннельным протоколом, чтобы создать различные адреса источника и получателя, соответственно, из адресов источника и получателя в базовом пакете. Например, в одной реализации, IP-адреса источника и получателя базовых пакетов могут форматироваться в соответствии с IPv4 (протоколом Интернета версии 4), a TI 142А может заменять их на более длинные адреса IPv6 (протоколом Интернета версии 6) для второго пакета инкапсуляции, который будет отправляться в сеть 170 Svc1 через внутреннюю мостовую сеть 160. Внутренняя мостовая сеть 160 может использоваться в качестве пути для трафика между службами в сети провайдера, например, для трафика, который предназначен для общедоступных служб из виртуальной вычислительной службы. В некоторых вариантах осуществления, внутренняя мостовая сеть 160 может называться как граничная сеть, а также может использоваться для трафика, передающегося между Интернетом общего пользования и виртуальной вычислительной службой.

[0033] В одном из вариантов осуществления, в TI 142А, IP-адрес источника в базовом пакете может использоваться в качестве ключа в базе данных сопоставления, чтобы найти соответствующий адрес источника, который должен использоваться в исходящем втором пакете инкапсуляции. Аналогичным образом, IP-адрес получателя в базовом пакете может использоваться в качестве ключа в базе данных сопоставления, чтобы найти соответствующий адрес получателя, который должен использоваться в исходящем втором пакете инкапсуляции в такой реализации. По меньшей мере в некоторых вариантах осуществления, использование большего числа битов для адресов источника и получателя для второго пакета инкапсуляции может позволить TI 142А включать в себя кодирование идентификатора исходной IVN (например, IVN 110А в случае пакетов, возникающих в CI 112А) и/или идентификатора РАЕ (например, РАЕ 150) во втором пакете инкапсуляции. В некоторых вариантах осуществления, идентификатор РАЕ и/или IVN может быть включен в заголовки, добавленные VMC в первый пакет инкапсуляции, и TI 142 может получать идентификаторы из таких заголовков. В других вариантах осуществления, адреса источника и получателя, полученные из базы данных сопоставления, могут содержать кодированные идентификаторы IVN и/или РАЕ.

[0034] Второй пакет инкапсуляции, созданный в TI 142А, может передаваться через мостовую сеть 160 на внешний узел 171 (например, 171А) конечной службы Svc1. Внешний узел 171 может иметь возможность выполнять декапсуляцию в соответствии с туннельным протоколом, чтобы извлекать содержимое базового пакета (включая частный IP-адрес исходного CI), а также идентификатор исходной IVN (например, IVN 110A) и/или идентификатор РАЕ (например, РАЕ 150), использующиеся для маршрутизации. По меньшей мере в некоторых вариантах осуществления, идентификация РАЕ и/или исходной IVN может позволить узлам Svc1 различать запросы от разных вычислительных экземпляров с одинаковым частным IP-адресом источника, как более подробно описано ниже. Запрос службы, указанный в базовом пакете, может передаваться на внутренний узел 173 (например, 173А) для обработки. После обработки запроса, на внутреннем узле может создаваться базовый пакет ответа, инкапсулированный в соответствии с туннельным протоколом, и передаваться в обратном направлении источнику запроса (CI 112А). TI 142 (например, TI 142А или другой TI) может получать инкапсулированный ответ через внутреннюю мостовую сеть 160, создавать измененный вариант инкапсуляции, используя первый протокол инкапсуляции, и передавать его VMC на IH 130А. VMC может извлекать базовый пакет ответа и предоставлять его исходному CI 112А.

[0035] Следует отметить, что хотя выше были описаны два различных протокола инкапсуляции, в некоторых вариантах осуществления, для обеспечения трафика между вычислительными экземплярами и общедоступными службами может требоваться или использоваться только один протокол инкапсуляции. Например, в одном таком варианте осуществления, VMC могут иметь возможность реализовывать туннельный протокол, который используется для трафика по внутренней мостовой сети, и, таким образом, сами VMC могут выступать в качестве туннельных посредников. В таком варианте осуществления, VMC может перехватывать пакеты с помощью общедоступной службы, связанной с РАЕ 150 в качестве получателя, создавать инкапсулированный пакет, содержащий кодирование исходной IVN и/или РАЕ, и передавать инкапсулированный пакет на устройство мостовой сети.

[0036] При использовании РАЕ в качестве целевого объекта в записи таблицы маршрутов для трафика, направленного на Svc1, клиент может не нуждаться в применении двух других подходов к маршрутизации трафика между IVN и Svc1, которые также показаны на фиг. 1. В одном подходе, клиент, от имени которого создается IVN 110В, может решить создать шлюз 182 Интернета для своей IVN и/или назначить общедоступный IP-адрес (который может быть доступен из Интернета общего пользования) одному из своих экземпляров, таких как CI 112K. В таком случае, базовые пакеты, содержащие запросы Svc1, созданные в CI 112K, могут передаваться узлам Svc1 (например, FE узлу 171В) без использования типа туннельного протокола, описанного выше, например, через путь, такой же, как путь 163, указанный для трафика шлюза Интернета (IGW). В некоторых случаях, путь, использующийся для трафика, возникающего на общедоступном IP-адресе, может содержать каналы 139 Интернета общего пользования. Одним из потенциальных преимуществ использования подхода РАЕ по сравнению с использованием подхода шлюза Интернета является то, что IVN 110В может быть более уязвима (в силу предоставления общедоступных IP-адресов) для атак из Интернета общего пользования, чем IVN 110А (для которой не должно быть назначено ни одного общедоступного IP-адреса).

[0037] Во втором альтернативном варианте использования РАЕ, клиент может создать VPN-шлюз 183 (виртуальной частной сети), чтобы обеспечить безопасное соединение между IVN 110В и собственной сетью 185 пользователя. Пакеты, которые направляются на Svc1 от экземпляра, такого как CI 112L, сначала могут отправляться в собственную сеть 185 пользователя, а затем отправляться (например, через каналы 139 Интернета общего пользования) к узлам Svc1 (например, FE узлу 171С). Следует отметить, что IVN, такие как 110В, которые имеют созданный VPN-шлюз 185, могут не использовать общедоступные IP-адреса и могут не иметь настроенный шлюз 182 Интернета, и поэтому клиент, который использует только VPN-шлюз, может избежать уязвимостей безопасности, упомянутых выше. Тем не менее, во многих случаях, использование VPN-подключения к внешней сети для трафика, который возникает в пределах сети провайдера (например, в экземпляре в пределах IVN) и адресован получателю в пределах сети провайдера (например, узлу Svc1), может быть неэффективным по ряду причин. Например, по меньшей мере в некоторых вариантах осуществления, если используется VPN-подход, то, по сравнению с подходом РАЕ, могут возникнуть большие задержки, устойчиво снизиться пропускная способность и/или возрасти затраты на биллинг. Несмотря на то, что на фиг. 1 показаны три отдельных FE узла 171А, 171В и 171С, соответствующие описанным выше трем альтернативным подходам к маршрутизации (т.е. маршрутизации с использованием РАЕ, маршрутизации с использованием общедоступных IP-адресов в качестве IP-адресов источника, а также маршрутизации с использованием VPN), по меньшей мере в некоторых вариантах осуществления любой данный FE узел может иметь возможность обрабатывать передаваемый трафик, используя любой из альтернативных вариантов. Таким образом, иллюстрирование трех FE узлов не означает, что соответствующие наборы FE узлов требуются для различных вариантов подключения.

[0038] В одном варианте осуществления, виртуальная вычислительная служба может обеспечивать библиотеку подключений службы (SCL), предоставляя набор API, которые могут быть вызваны для доступа к общедоступным службам с использованием РАЕ из приложений, выполняющихся на вычислительных экземплярах IVN. В таком случае, приложение может послать вызов API, указывающий целевую службу Svc1, где содержание запроса службы указывается параметрами вызова API. SCL может определять, что приложение собирается отправить запрос службы в Svc1, и может инициировать реализацию соответствующей инкапсуляции, необходимой для передачи запроса службы в Svc1. Таким образом, вместо использования традиционного подхода, в котором приложение инициирует создание базового пакета, действия по созданию пакетов из запросов службы могут выполняться SCL. В некоторых таких вариантах осуществления, приложению даже не нужно получать конкретный общедоступный IP-адрес целевой службы; например, получатель запроса службы может указываться именем службы, а не конкретным сетевым адресом. В одном варианте осуществления, даже если приложение указывает в вызове API конкретный общедоступный целевой адрес службы, то SCL может передавать инкапсулированный вариант запроса службы на другой общедоступный или частный IP-адрес целевой службы (до тех пор, пока актуальный получатель, выбранный SCL, может должным образом отвечать на запрос службы).

Примеры потока пакетов

[0039] На фиг. 2 показаны примеры компонентов, участвующих в направлении пакета, возникающего в вычислительном экземпляре изолированной виртуальной сети, к получателю в общедоступной службе, согласно по меньшей мере некоторым вариантам осуществления. Как показано, узел 230 экземпляра IVN 210 может содержать множество вычислительных экземпляров 112, таких как экземпляры 112А и 112В. Каждый экземпляр 112 может содержать соответствующий экземпляр операционной системы, выполняющийся на гостевой виртуальной машине. На каждом вычислительном экземпляре может быть запущен один или более компонентов клиентских приложений, таких как процесс 220А приложения в вычислительном экземпляре 112А и процесс 220В приложения в вычислительном экземпляре 112В. Взаимодействием между вычислительными экземплярами и аппаратными компонентами узлов экземпляров (такими как сетевые интерфейсные платы или NIC, которые используются для сетевого трафика) может управлять один или более компонентов управления виртуализацией (VMC), таких как VMC 240. VMC может, например, включать в себя гипервизор и/или экземпляр привилегированной операционной системы (который иногда может называться как нулевой домен или экземпляр операционной системы dom0).

[0040] По меньшей мере некоторым из приложений может требоваться доступ к (например, могут отправлять запросы службы и могут принимать ответы от службы) одной или более службам, реализованным, в проиллюстрированном варианте осуществления, за пределами IVN. Например, процессу 220 В приложения может требоваться доступ к общедоступной службе Svc1. Соответственно, как указано стрелкой с подписью «1» на фиг. 2, от вычислительного экземпляра может отправляться DNS-запрос 204 на DNS-сервер 252 (например, на DNS-сервер, доступный изнутри сети виртуальной вычислительной службы, в которой реализована IVN 210), запрашивая IP-адрес Svc1. Как указано стрелкой с подписью «2», DNS-сервер 252 может обеспечивать общедоступный IP-адрес 205, предоставленный или объявленный Svc1. По меньшей мере в некоторых вариантах осуществления, поиск DNS может выполняться только в том случае, если приложение не взаимодействует с Svc1 некоторое время. Т.е., как только адрес Svc1 был получен, он может использоваться экземпляром 112В в течение длительного периода (например, до тех пор, пока адрес остается действительным) без дальнейшего взаимодействия с DNS-сервером 252.

[0041] Запрос службы, направленный в Svc1, может быть включен в тело базового пакета 250, созданного, в показанном варианте осуществления, в экземпляре 112В и отправленного в сетевой стек вычислительного экземпляра для распространения к Svc1. Базовый пакет 250 может указывать частный IP-адрес экземпляра 112В в качестве адреса своего источника и общедоступный IP-адрес Svc1 в качестве получателя. Как и в случае других сетевых пакетов, базовый пакет может быть перехвачен VMC 240 (который может отвечать за передачи по физической сети), как указано стрелкой с подписью «3».

[0042] В показанном варианте осуществления, VMC 240 может иметь доступ к относящимся к РАЕ метаданным, а также другим метаданным IVN, таким как таблица 235 маршрутов и список 236 общедоступных IP-адресов Svc1. Таблица 235 маршрутов может включать в себя данные, указывающие на целевые объекты, которые должны использоваться для маршрутизации пакетов, предназначенных для различных получателей - например, для пакетов с адресами получателя в диапазоне N1.N2.N3.* следует использовать целевой объект K.L.M.N. B примере, показанном на фиг. 2, была создана таблица маршрутов для пакетов, предназначенных для любого узла Svc1, с частным псевдонимом РАЕ-1 конечной точки, указанным в качестве целевого объекта. В изображенном варианте, на основании анализа получателя, указанного в базовом пакете 250, и относящихся к РАЕ метаданных, доступных ему, VMC 240 может создать первый пакет 251 инкапсуляции. Тело пакета 251 может включать в себя содержимое базового пакета 250 (включая информацию о его источнике и получателе), в то время как дополнительные заголовки 260 могут создаваться VMC 240 в соответствии с первым протоколом Р1 инкапсуляции, который используется для связи между VMC и туннельными посредниками 242. Инкапсулированный пакет 251 может отправляться от VMC 240 конкретному туннельному посреднику 242, как указано стрелкой с подписью «4». По меньшей мере в некоторых вариантах осуществления, заголовки 260 Р1 могут включать в себя указание того, что базовый пакет связан с РАЕ1 и/или возник в IVN 210. Следует отметить, что путь между VMC 240 и туннельным посредником 242 может сам содержать несколько транзитных участков, например, с целевыми объектами для различных транзитных участков, выбранных на основании записей таблицы маршрутов, не показанных на фиг. 2.

[0043] Туннельный посредник 242 может проверять заголовки 260 Р1 и/или заголовки источника/получателя базового пакета 250, содержащиеся в инкапсулированном пакете 251. Используя базу 262 данных сопоставления второго протокола Р2 инкапсуляции (также называемого в настоящем документе как туннельный протокол), туннельный посредник 242 может создавать второй пакет 255 инкапсуляции, содержащий один или более заголовков 261 Р2 и базовый пакет 250. В некоторых вариантах осуществления, адреса источника и получателя базового пакета могут использоваться в качестве индексов в базе 262 данных сопоставления, чтобы определять новые заголовки источника и пакета, которые должны использоваться для пакета 255. В некоторых реализациях, в соответствии с протоколом Р2, базовый пакет 250 IPv4 может инкапсулироваться в IPv6-совместимый пакет 255, например, с помощью SIIT (трансляции IP/ICMP (протокол Интернета/протокол управления сообщениями Интернета) без отслеживания состояний (Stateless IP/ICMP)) или аналогичного механизма трансляции заголовков IPv4-IPv6. В других вариантах осуществления, для создания пакета 255 инкапсуляции может использоваться собственный протокол инкапсуляции сети провайдера. В некоторых вариантах осуществления, вместо использования IPv6, туннельными посредниками могут использоваться дополнительные заголовки IPv4, такие как необязательные заголовки TCP, или может использоваться инкапсуляция UDP (протокол пользовательских датаграмм) (например, путем включения содержимого базового пакета в UDP-сообщения). Примеры видов информации, которые могут быть включены в заголовки 260 Р1 и заголовки 261 Р2 в некоторых вариантах осуществления, представлены на фиг. 4 и описаны ниже. Пакет 255 инкапсуляции может передаваться от туннельного посредника 242 на устройство соответствующей мостовой сети 160, которую необходимо пройти для достижения узлов Svc2.

[0044] На фиг. 3а и 3b показаны соответствующие примеры компонентов на стороне службы, которые могут обрабатывать пакеты, возникающие в вычислительном экземпляре изолированной виртуальной сети, согласно по меньшей мере некоторым вариантам осуществления. Как упоминалось ранее, в некоторых вариантах осуществления по меньшей мере два типа служб могут поддерживать клиентский доступ из IVN, для которых были настроены РАЕ. Первый тип службы может быть реализован оператором сети провайдера, в то время как второй тип может включать службы, реализованными третьими сторонами, такими как пользователи сети провайдера. Для служб первого типа, таких как реализованная в сети провайдера служба 376, показанная на фиг. 3а, внешние узлы 374 могут «понимать» (т.е., иметь возможность реализации) протокол инкапсуляции Р2, используемый туннельными посредниками 242. Т.е., при получении пакета 255, форматированного в соответствии с протоколом Р2, внешний узел 374 службы 376 может иметь возможность извлекать содержимое базового пакета и создавать соответствующий внутренний запрос 350, который может быть отправлен на внутренний узел 374 для обработки. В некоторых случаях, реализованная в сети провайдера служба может поддерживать запросы службы, форматированные, например, в соответствии с HTTP (протоколом передачи гипертекста), и внешний узел может добавлять один или более X-Forwarded-For-заголовков к базовому запросу, чтобы указать идентификаторы исходной IVN, в которой был создан базовый пакет, и/или РАЕ, использованного для маршрутизации базового пакета. После того, как на внутренних узлах были выполнены все запрошенные операции, ответ может быть передан обратно запрашивающему вычислительному экземпляру, например, с использованием аналогичных методов инкапсуляции в пути ответа. Например, Р2-понимающие внешние узлы 374 службы 376 могут создавать Р2-совместимый пакет инкапсуляции, содержащий по меньшей мере часть базового ответа, и отправлять его через мостовую сеть 160 туннельному посреднику 242, который, в свою очередь, может создавать Р1-совместимый пакет инкапсуляции и передавать его соответствующему VMC 240. VMC 240 может извлекать базовый ответ из Р1-совместимого пакета и предоставлять его исходному вычислительному экземпляру, такому как 112В.

[0045] В отличие от узлов служб, реализованных оператором сети провайдера, по меньшей мере некоторые сторонние службы (например, сторонняя служба 378, показанная на фиг. 3b) могут не включать в себя узлы, которые способны извлекать базовые пакеты из пакетов 255 инкапсуляции, созданных в соответствии с протоколом Р2. В некоторых случаях, например, подробные сведения о Р2 могут быть недоступны операторам сторонних служб или такие операторы могут не иметь ресурсов или квалификации для построения Р2-совместимых узлов служб. Соответственно, по меньшей мере в некоторых реализациях, в ответ на запросы зарегистрировать такие сторонние службы для маршрутизации на основе РАЕ, или в ответ на запросы после регистрации, компонент конфигурации или плоскости управления сети провайдера может создать на стороне службы один или более Р2-понимающих посредников 370. Такой посредник 370 на стороне службы может извлекать базовые пакеты 250 из пакетов 255 инкапсуляции и передавать их на внешние узлы 375 сторонней службы 378. Внешний узел 375 может затем преобразовывать базовые пакеты 250 во внутренние запросы 352, которые могут создаваться в собственных форматах третьей стороны, в формате HTTP или в соответствии с любым другим интерфейсом, поддерживаемым внутренними узлами 380 службы 378. Операции, соответствующие внутренним запросам 352, могут затем выполняться на внутренних узлах, а ответы, после инкапсуляции в посредниках 370, могут передаваться обратно вычислительным экземплярам, в которых возникли запросы.

Форматы инкапсуляции

[0046] На фиг. 4 показаны примеры форматов инкапсуляции для базового пакета, возникающего в вычислительном экземпляре, согласно по меньшей мере некоторым вариантам осуществления. В изображенном варианте осуществления, базовый пакет 402 может указывать IP-адреса версии 4 источника и получателя. Например, в пределах изолированной виртуальной сети, клиент может назначить вычислительному экземпляру 112 частный IP-адрес «10. 0. 1. 2» (не объявленный за пределами IVN) и этот частный IP-адрес может быть указан в базовом пакете 402 в качестве адреса источника. Общедоступный IP-адрес версии 4 «176. 32. 101. 25» может быть предоставлен DNS-сервером в ответ на DNS-запрос для адреса конкретной общедоступной службы Svc1, который должен быть доступен из вычислительного экземпляра. Этот общедоступный адрес службы может быть указан в качестве получателя базового пакета 402. В базовом пакете также могут указываться номера TCP-портов, например, порт 4321 в качестве исходного порта в вычислительном экземпляре и порт 80 в качестве порта конечной службы. Полезные данные или тело базового пакета 402 может указывать тип передаваемого запроса службы, такой как запрос на запись или чтение, направленный службе хранения, а также параметры запроса службы.

[0047] В изображенном варианте осуществления, базовый пакет 402 может инкапсулироваться с помощью компонента управления виртуализацией (например, VMC-x) в узле экземпляра в соответствии с первым протоколом Р1 инкапсуляции, используемым для связи с туннельными посредниками. Базовый пакет может быть включен в тело Р1-совместимого пакета 404, а также могут быть добавлены один или более заголовков Р1. В некоторых реализациях, идентификатор VMC может быть указан в качестве источника, а комплекс туннельных посредников может быть указан в качестве получателя. В некоторых вариантах осуществления, в пакет 404 могут быть включены другие определяемые Р1 заголовки, например, идентифицирующие исходную IVN, в которой был создан базовый пакет, и/или указывающие РАЕ, который был указан в записи таблицы маршрутов, задавая Svc1 в качестве получателя. Р1-совместимый формат может использовать для различных полей заголовка форматы IP версии 4, по меньшей мере в некоторых вариантах осуществления.

[0048] В изображенном варианте осуществления, в туннельном посреднике из Р1-совместимого пакета 404 могут удаляться его заголовки Р1, и может добавляться другой набор заголовков в соответствии с туннельным протоколом Р2, который будет использоваться для связи через мостовую сеть с конечной службой. В показанном варианте осуществления, Р2-совместимый пакет 406, созданный туннельным посредником, может включать в себя поля источника и получателя IPv6. 32-битное подмножество из 128 битов, доступных для адреса источника в IPv6, может использоваться для указания частного IPv4-адреса исходного вычислительного экземпляра в некоторых вариантах осуществления. Аналогично, 32-битное подмножество из 128 битов, доступных для адреса получателя в IPv6, может использоваться для указания общедоступного IPv4-адреса конечной службы. Например, младшими битами адреса источника пакета 406 являются 0А00:0102, которые являются альтернативным представлением адреса источника IPV4 10.0.1.2, а младшими битами адреса получателя пакета 406 являются B020:657D, которые являются альтернативным представлением адреса получателя IPv4 176.32.101.25.

[0049] В одной реализации, как указано в структуре 408 адресов на фиг. 4, 128 адресных битов, доступных в IPv6, могут использоваться следующим образом в соответствии с туннельным протоколом Р2. Младшие 32 бита (биты с 0 по 31) могут использоваться для IPv4-адреса источника или получателя, биты 40-71 могут использоваться для указания идентификатора РАЕ, а биты 80-127 могут использоваться для 48-битного префикса IPv6, выделенного расположению сети провайдера или центру обработки данных, в которым реализуется исходная IVN или конечная служба. 24 бита (например, старшие 24 бита) из 32 битов, предназначенных для идентификатора РАЕ, могут указывать идентификатор исходной IVN в изображенном варианте реализации. Таким образом, по меньшей мере в некоторых вариантах осуществления, идентификатор IVN может быть внедренным в идентификатор РАЕ и, следовательно, быть извлекаемым из него. В различных реализациях, для представления идентификатора исходной IVN, идентификатора РАЕ, или обоих могут использоваться другие методы кодирования. Некоторое число битов может быть зарезервировано для последующего использования (RFU, reserved for future use), такие как биты 31-39 и биты 72-80, например, для обеспечения возможного будущего увеличения числа битов, требуемых для уникальной идентификации РАЕ. Одним из преимуществ структурирования показанных Р2-совместимых адресов пакетов инкапсуляции (например, с самыми младшими 32 битами, используемыми для кодирования IPv4-адресов источника/получателя) является то, что по меньшей мере некоторые средства балансировки при получении такого IPv6-совместимого пакета могут выбирать одни и те же направления, как было бы выбрано, если бы только IPv4-часть из 128 битов была указана в качестве получателя. Для разделения IPv6-совместимой структуры адресов, в различных вариантах осуществления могут использоваться другие подходы, например, в которых другое подмножество битов используется для указания идентификатора IVN и/или идентификатора РАЕ.

[0050] Согласно по меньшей мере некоторым вариантам осуществления, на узле экземпляра, на котором работает исходный вычислительный экземпляр, может быть реализован туннельный протокол, например, без необходимости использовать отдельный комплекс туннельных посредников. В таких вариантах осуществления, двухэтапная инкапсуляция, показанная на фиг. 4, может быть объединена в один логический шаг, реализованный в VMC и/или другом компоненте подключения службы, выполняющимся на узле экземпляра. VMC и/или компонент подключения службы может рассматриваться как туннельный посредник между исходным вычислительным экземпляром и конечной службой в таких вариантах осуществления.

Конфигурация РАЕ

[0051] На фиг. 5 показаны примеры запросов и ответов конфигурации РАЕ, согласно по меньшей мере некоторым вариантам осуществления. Как показано, диспетчер 592 конфигураций сети провайдера может реализовывать один или более программных интерфейсов 550, таких как API, веб-консоли, настраиваемые графические интерфейсы пользователя или программы командной строки. Используя такой интерфейс, клиент 502 может отправить запрос 505 «создать РАЕ в IVN» для создания в указанной IVN частного псевдонима конечной точки, например, с указанием в запросе идентификатора IVN в качестве параметра. В ответ диспетчер 592 конфигураций может создавать и хранить в своей базе данных конфигурации одну или более записей для запрошенного РАЕ, а также предоставить в ответе 507 идентификатор новосозданного РАЕ. В некоторых вариантах осуществления, один или более РАЕ для IVN могут создаваться автоматически, в то время, когда IVN создается для клиента, и в таких случаях может не требоваться отправлять явный запрос на создание РАЕ.

[0052] После создания РАЕ клиент 502 может отправить диспетчеру 592 конфигураций запрос 509 «назначить службу РАЕ», указывая конкретную службу, чей трафик должен маршрутизироваться с использованием РАЕ. В некоторых реализациях, в таком запросе идентификатор РАЕ и идентификатор службы могут предоставляться в качестве параметров. В ответ диспетчер 592 конфигураций может обновить свои метаданные конфигурации, относящиеся к РАЕ, и предоставить подтверждение 511 назначения службы. В некоторых вариантах осуществления, программные интерфейсы 550 могут предоставлять список зарегистрированных имен служб (например, в раскрывающемся меню), из которого можно выбрать службу для связи с настроенным РАЕ.

[0053] В некоторых вариантах осуществления, РАЕ могут быть назначены различные типы политик контроля доступа, например, в ответ на запрос 513 «назначить политику РАЕ», задающий политику и РАЕ. Примеры применимых политик показаны на фиг. 6 и описаны ниже. Диспетчер 592 конфигураций может хранить представление указанной политики и связь политики с РАЕ, а также предоставлять клиенту подтверждение 515 связи. По меньшей мере в некоторых вариантах осуществления, хотя и для РАЕ может быть запрошена связь с политикой, фактическое применение политики может выполняться в одном или более местах: (а) службе, назначенной РАЕ, (b) другой службе, такой как служба авторизации и проверки подлинности сети провайдера, которая может вызываться назначенной РАЕ службой для применения политики, или (с) в VMC узла экземпляра, с которого запрос службы маршрутизируется в соответствии с РАЕ. В некоторых вариантах осуществления, указание политики может передаваться с помощью диспетчера конфигураций компоненту плоскости управления службы, назначенной РАЕ, например, до того, как клиенту предоставляется подтверждение 515.

[0054] В некоторых вариантах осуществления, клиент сети провайдера также может подать запрос 517, чтобы зарегистрировать службу для связанной с РАЕ маршрутизации. Например, сторонняя служба (т.е. служба, которая непосредственно не управляется оператором сети провайдера) может быть создана с использованием некоторого набора ресурсов сети провайдера, а оператор такой сторонней службы, возможно, захочет получить доступ к службе изнутри IVN, не запрашивая общедоступных IP-адресов, которые будут использоваться в IVN. В таком случае, клиентом 502 может отправляться запрос «регистрировать службу для РАЕ», содержащий подробную информацию о конфигурации службы (например, адреса внешних узлов службы). По меньшей мере в некоторых реализациях, за регистрацию служб может отвечать другой диспетчер конфигураций, а не диспетчер конфигураций, отвечающий за создание РАЕ, и для запросов на регистрацию службы может использоваться другой набор программных интерфейсов. В ответ на запрос на регистрацию службы, перед тем, как принять службу и предоставить клиенту в ответе 519 зарегистрированное имя или идентификатор зарегистрированной службы, диспетчер конфигураций может выполнять одну или более операций проверки, например, чтобы проверить, что предлагаемая для регистрации служба соответствует определенным критериям для совместимости с РАЕ. В одной реализации, например, внешний компонент службы может быть запрошен или протестирован, чтобы убедиться, что он может получать запросы, создаваемые туннельными посредниками, которые используют протокол инкапсуляции сети провайдера.

[0055] В некоторых вариантах осуществления, могут поддерживаться дополнительные типы запросов конфигурации, помимо тех, которые показаны на фиг. 5. Например, запросы для настройки туннельных посредников на стороне службы (таких как Р2-понимающий посредник 370 из фиг. 3b) могут отправляться клиентами, которые создали сторонние службы в некоторых вариантах осуществления. В одном варианте осуществления, клиенты могут иметь возможность повторно назначать РАЕ различным службам, или назначать РАЕ более одной службы, используя дополнительные типы запросов конфигурации. В некоторых реализациях, могут поддерживаться не все типы запросов конфигурации, показанные на фиг. 5. Как упоминалось ранее, клиент может создать множество РАЕ, связанных с данной IVN (например, для доступа к различным службам изнутри этой IVN), и клиенты, которые имеют множество IVN, могут создавать один или более РАЕ в каждой такой IVN.

[0056] На фиг. 6 показаны примеры содержимого базы данных конфигурации РАЕ, согласно по меньшей мере некоторым вариантам осуществления. Показана база данных конфигурации для конкретной IVN (IVN-j), для которой с помощью диспетчера 592 конфигураций были созданы два РАЕ. РАЕ 604А назначается служба «StorageSvc1» (служба хранения, реализованная в сети провайдера), как указано в поле 606А идентификатора службы, при этом РАЕ 604В назначается служба «DBSvc1» (служба базы данных, реализованная в сети провайдера), как указано в поле 606В идентификатора службы. РАЕ 604А имеет политику 608А доступа, назначенную ему, при этом РАЕ 604В имеет две политики доступа 608В и 608С.

[0057] В показанном примере, политика 608А доступа применяется к трафику StorageSvc1, направленному в или из вычислительных экземпляров, IP-адреса которых лежат в диапазоне 610A IP адресов CI. В некоторых вариантах осуществления, вместо использования IP-адресов для указания трафика, к которому должна применяться политика, могут использоваться имена экземпляров или другие идентификационные данные вычислительных экземпляров. Список типов операций, для которых с диапазона 610А адресов разрешены запросы (например, чтения и записи) может указываться в поле 612А разрешенных типов операций политики 608А, а объекты службы StorageSvc1 (например, объекты, хранящиеся в каталоге «/xyz»), к которым эти операции могут направляться, указываются в списке 614А объектов. В показанном примере, диапазоны времени, для которых должна применяться политика 608А (например, определенные часы каждого рабочего дня или определенные дни недели) могут указываться в поле 616А применимых диапазонов времени. Список 618А участников (например, идентификаторы пользователей или групп) также может быть связан с политикой 608А, указывая лиц, чьи запросы службы должны регулироваться правилами, указанными в политике 608А.

[0058] Каждая из политик доступа 608В и 608С, которая должна применяться для РАЕ 604В, может указывать свои соответствующие диапазоны 610 IP адресов CI, указывая вычислительные экземпляры, к которым должны применяться правила политики. В некоторых политиках, таких как 608В, могут указываться типы операций, которые запрещены (например, в поле 613 запрещенных типов операций), например, вместо или в дополнение к типам операций, которые разрешены. Как указано «*» в списке 614В объектов, операции, указанные в поле 613, могут быть запрещенными для всех объектов DBSvc1, в проиллюстрированном примере, для участников, указанных в списке 618В участников. Как показано, не все типы записей, которые могут быть включены в политику, нужно задавать для каждой политики - например, политика 608В не включает в себя применимый диапазон времени, при этом политика 608С не включает в себя список участников. Для типов записей, которые не включены в политику, могут использоваться значения по умолчанию - например, целый день может считаться применимым диапазоном времени, а правила политики могут применяться ко всем участникам, если никакие конкретные участники не указаны. В показанном примере, поле 612В может указывать типы операций, разрешенных на объектах, перечисленных в поле 614С, во время применимых диапазонов 616С времени.

[0059] В некоторых вариантах осуществления, если для данного РАЕ клиент не указал конкретные политики доступа, сеть провайдера может применять некоторый набор по умолчанию, чтобы определить правила, которые должны применяться к запросам службы, отправляемых соответствующей службе. В некоторых реализациях, различные службы могут иметь различные значения по умолчанию. Как упоминалось ранее, в некоторых вариантах осуществления, службы, которым были назначены РАЕ, могут отвечать за применение политик (либо на собственных узлах службы, либо путем отправки запроса другой службе сети провайдера, такой как служба управления удостоверениями и авторизацией). Запросы службы для некоторых служб могут быть зашифрованы таким образом, что возможно определить только тип операции, которая запрашивается после того, как запрос достигает службы, в результате чего в конце службы могут применяться политики доступа. В таких случаях, политики могут передаваться службам (например, компонентам плоскости управления или администрирования служб) с помощью диспетчеров конфигураций, в которых политики указываются клиентами (например, диспетчеров конфигураций IVN). В других вариантах осуществления, по меньшей мере некоторые из правил политики могут применяться в конце инициатора запроса (например, в конце IVN) - например, VMC может иметь возможность отклонять запрос на запись, посланный от вычислительного элемента, если соответствующий пользователь находится в списке участников применимой политики и все операции записи для перечисленных участников запрещены.

Определение различных запросов среди запросов от повторно используемых частных IP-адресов

[0060] В некоторых вариантах осуществления, как описано выше, клиенты могут использовать предоставляемую конфигурацией сети IVN гибкость, чтобы по своему усмотрению назначать частные IP-адреса вычислительным экземплярам IVN, например, без учета того, что такие же адреса используются в других местах (например, в других IVN или в Интернете общего пользования). В некоторых случаях клиент может назначить один и тот же IP-адрес экземплярам, находящимся в различных IVN. По ряду причин (например, для точной регистрации источников, из которых поступили запросы службы) для службы может быть полезно иметь возможность различать запросы от различных IVN, даже если в запросах могут указываться одинаковые IP-адреса источника.

[0061] На фиг. 7 показан пример использования идентификаторов IVN и РАЕ для различения запросов, полученных службой от вычислительных экземпляров с одинаковыми частными IP-адресами, согласно по меньшей мере некоторым вариантам осуществления. Как показано, соответствующие IVN 702А и 702В могут быть созданы с помощью клиента С1, где IVN 702А создана для использования в инженерно-техническом отделе организации клиента, a IVN 702В создана для использования в отделе маркетинга организации. В показанном примере, обоим подразделениям, возможно, потребуется получить доступ к объектам, хранящимся в одной общедоступной службе хранения «StorageSvc1». РАЕ 750А может быть создан для доступа к StorageSvc1 из IVN 702А и РАЕ 750В может быть создан для доступа к StorageSvc1 из IVN 702В.

[0062] Клиент С1 может (например, преднамеренно или случайно) назначить один и тот же частный IP-адрес 10. 4. 5. 6 вычислительному экземпляру 710А в IVN 702А и вычислительному экземпляру 710K в IVN 702В. Запросы службы, направленные в StorageSvc1, могут создаваться в обоих вычислительных экземплярах 710А и 710K. В соответствии с протоколом инкапсуляции, который может быть реализован в туннельных посредниках сети провайдера, как описано выше, пакет 774А инкапсуляции запроса службы, содержащий запрос от IVN 702А на чтение объекта X StorageSvc1, может передаваться внешнему узлу 771. Пакет 774А инкапсуляции может указывать частный IP-адрес 10. 4. 5. 6 в качестве исходного источника запроса, а также может включать в себя кодирование идентификатора 702А IVN и РАЕ 750А, используемое для маршрутизации запроса. Аналогичным образом, пакет 774В инкапсуляции, указывающий запрос на чтение объекта Y службы, может приниматься внешним узлом 771. Пакет 774В может также указывать частный IP-адрес своего исходного экземпляра (10. 4. 5. 6, идентичный адресу, указанному в пакете 774А), исходную IVN (702 В), а также РАЕ 750В, использующийся для маршрутизации запроса в показанном варианте осуществления.

[0063] Внешний узел 771 (и/или внутренний узел 773, в котором выполняется запрашиваемая работа) может иметь возможность использовать сведения об идентификации IVN и/или РАЕ, включенные в принятые пакеты, чтобы различать источник запросов, даже если IP-адреса источника, указанные в пакетах 774А и 774В, идентичны. Таким образом, может быть создана запись 733А журнала (FE узлом или BE узлом), с указанием временной метки Т1, когда запрос на чтение X был получен или обработан, частного IP-адреса 10. 4. 5. 6 запрашивающего вычислительного экземпляра, а также идентификаторов IVN 702А и РАЕ 750А. Аналогичная запись 733В журнала может быть создана для запроса на чтение Y, с указанием временной метки Т2 приема или обработки, IP-адреса источника 10. 4. 5. 6, а также идентификаторов IVN 702В и 750В РАЕ. В некоторых вариантах осуществления, в записи журнала (или в пакеты инкапсуляции) может включаться только идентификатор IVN или только идентификатор РАЕ, так как любого из них может быть достаточно для устранения неоднозначности источника запроса.

[0064] Следует отметить, что в вариантах осуществления, в которых туннельные посредники внедряют идентификаторы IVN или РАЕ в исходные заголовки пакетов 774 инкапсуляции как описано выше, устранить неоднозначность для трафика из различных IVN можно даже в ситуациях, когда узлы на стороне службы (такие как внешние узлы 771 и/или внутренние узлы 773) не обязательно могут иметь возможность разбирать содержимое исходных заголовков. Например, если для использования маршрутизации на основе РАЕ регистрируется сторонняя служба, и для инкапсуляции используется IPv6, узлы сторонней службы могут не знать, какие конкретные биты заголовка IPv6 используются для кодирования сведений об исходной IVN или сведений об исходном РАЕ. Тем не менее, так как исходный заголовок IPv6 для пакета Р1 из IVN 702А будет отличаться от исходного заголовка IPv6 для пакета Р2 из IVN 702В, узлы сторонней службы по меньшей мере будут иметь возможность определять, что Р1 и Р2 принадлежат разным источникам, даже если подробные сведения касательно идентификаторов IVN и/или идентификаторов РАЕ в узлах сторонней службы не определяются. Конечно же, если узел сторонней службы отвечает за реализацию политик контроля доступа, аналогичным показанным на фиг. 6, и политики контроля доступа связаны с конкретными IVN или конкретными РАЕ, узел сторонней службы может получить идентификаторы IVN/PAE.

Способы создания частных псевдонимов конечных точек

[0065] На фиг. 8 показана блок-схема, иллюстрирующая аспекты операций, которые могут быть выполнены для настройки РАЕ, согласно по меньшей мере некоторым вариантам осуществления. Как показано в элементе 801, в сети провайдера от имени клиента С1 может быть создана одна или более изолированных виртуальных сетей, например, с использованием ресурсов виртуальной вычислительной службы. Каждая IVN может включать в себя некоторый набор ресурсов, таких как вычислительные экземпляры и т.п., для которых выборы внутренней конфигурации сети (такие как настройки подсети, назначение IP-адреса и т.д.) могут быть сделаны клиентом. Например, клиент может назначать частные IP-адреса (адреса, которые не объявляются за пределами IVN) виртуальным сетевым интерфейсам вычислительных экземпляров без необходимости убеждаться в уникальности данного частного IP-адреса в отношении ресурсов за пределами IVN. Например, если клиент желает использовать один и тот же частный IP-адрес «а. b. с. d» в двух различных IVN, IVN1 и IVN2, такой адрес может быть назначен вычислительному экземпляру СI1 в IVN1 и другому вычислительному экземпляру CI1 в IVN2. Следует отметить, что уникальность IP-адресов все еще может требоваться в пределах данной IVN, по меньшей мере в некоторых вариантах осуществления - например, тот же самый IP-адрес не может быть назначен двум экземплярам, которые запускаются в пределах одной IVN.

[0066] В показанном варианте осуществления, виртуальная вычислительная служба может позволять клиентам отправлять запросы службы от вычислительных экземпляров IVN с частными IP-адресами общедоступным службам (например, службам хранения или базы данных, реализованных оператором сети провайдера и/или сторонним службам, реализованным другими пользователями сети провайдера) с использованием частных псевдонимов конечных точек (РАЕ), связанных с IVN. Как показано в элементе 804, запись метаданных, представляющая конкретный РАЕ (РАЕ1), созданный для IVN1 от имени С1, может быть создан и сохранен, например, с помощью компонента диспетчера конфигураций виртуальной вычислительной службы или сети провайдера. По меньшей мере в некоторых реализациях, во время создания РАЕ1 (например, в ответ на программный запрос С1), РАЕ1 не должен быть связан или привязан к какой-либо конкретной службе. В таблице маршрутов, связанной с IVN1, РАЕ1 может, в итоге, быть указана в качестве целевого маршрута для сетевого трафика, возникающего в пределах IVN1 и направленного в сторону выбранной службы, реализованной в другом месте в сети провайдера (т.е. за пределами IVN1), например, после отдельного этапа конфигурации, на котором выбранная служба назначается РАЕ1, как указано в элементе 807.

[0067] По меньшей мере в некоторых вариантах осуществления, для поддержки РАЕ может быть зарегистрировано несколько служб, например, после того, как оператор сети провайдера создал и протестировал/проверил компоненты (такие как туннельные посредники), которые могут потребоваться для реализации протоколов инкапсуляции, использующихся для передачи пакетов между экземплярами с частными IP-адресами в конце IVN и узлами службы с общедоступными IP-адресами в конце службы. В некоторых вариантах осуществления, общедоступные IP-адреса служб также могут проверяться (и обновляться по мере необходимости) внутри базы данных конфигурации, доступной для туннельных посредников и/или компонентов управления виртуализацией в узлах экземпляров IVN. По меньшей мере в одном варианте осуществления, программные интерфейсы, доступные клиенту С1, могут позволять клиенту при назначении службы Svc1 для РАЕ1 выбирать службы из зарегистрированного набора (элемент 807) - т.е., клиентам может разрешаться связывать только заранее утвержденные службы с РАЕ, созданными для своих IVN. В одной реализации, связь между РАЕ, таким как РАЕ1, и службой, такой как Svc1, может быть представлена в базе данных конфигурации IVN путем установки значения атрибута «служба» РАЕ.

[0068] Одна или более политик доступа могут быть связаны с данным РАЕ, таким как РАЕ1 в некоторых вариантах осуществления (элемент 810). Политики доступа могут, например, указывать типы операций или запросов службы, которые разрешаются или запрещаются с использованием РАЕ1, типы объектов, доступ к которым предоставляется через РАЕ1, участников (например, пользователей или группы), к которым применяются правила политики, периоды времени, для которых применяются правила политики, и так далее. В некоторых вариантах осуществления, клиент С1 может по своему усмотрению указывать политики доступа для РАЕ1, например, с использованием программного интерфейса. В некоторых реализациях, к РАЕ может применяться политика доступа по умолчанию, если клиент не указал ни одну политику. Политики также могут быть представлены в виде атрибутов РАЕ, в некоторых реализациях. В некоторых вариантах осуществления, в которых множество политик могут быть назначены для данного РАЕ, диспетчер конфигураций может отвечать за обнаружение конфликтов между различными политиками. Например, одна политика может разрешать конкретный тип операции на конкретном объекте, при этом другая политика может запрещать этот тип операции. В некоторых реализациях, диспетчер конфигураций может запросить клиента назначить приоритет среди конфликтующих политик или удалить конфликты. В других вариантах осуществления, диспетчер конфигураций может просто применить заданные политики в некотором порядке приоритета по умолчанию (например, последние примененные политики заменяют более ранние политики по умолчанию), устраняя таким образом конфликты.

[0069] Запись таблицы маршрутов, указывающая РАЕ1 в качестве целевого объекта для трафика, чьим получателем является Svc1, может быть создана и присоединена (например, С1 посредством запроса, отправленного с использованием программного интерфейса) к одной или более подсетям IVN1 в изображенном варианте осуществления (элемент 813). Вместо того, чтобы в записи таблицы маршрутов указывать конкретные диапазоны IP-адресов в качестве источников и получателей, в качестве получателя может быть указано зарегистрированное имя службы, а имя или идентификатор, назначенный РАЕ1 при создании РАЕ1, может быть указан в качестве целевого объекта, что значительно упрощает для клиента С1 управление маршрутами между IVN1 и Svc1. После присоединения записи таблицы маршрутов может начинаться передача трафика между экземплярами подсети и Svc1.

[0070] По меньшей мере в некоторых вариантах осуществления, возможна ситуация, когда набор общедоступных IP-адресов, связанных со службой (например, Svc1), назначенной одному или более РАЕ (например, РАЕ1), может изменяться с течением времени. В изображенном варианте осуществления (элемент 816), компоненты плоскости управления или администрирования зарегистрированных служб, таких как Svc1, и/или диспетчер конфигураций виртуальной вычислительной службы могут отвечать за распространение обновлений списка общедоступных IP-адресов и/или других, относящихся к РАЕ данных о конфигурации, на компоненты, где такие адреса могут использоваться. Такие обновления могут применяться, например, к базам данных конфигурации, доступным из туннельных посредников, на которых должны быть реализованы протоколы инкапсуляции описанного выше типа, и/или к базам данных, доступным из компонентов управления виртуализацией узлов экземпляров IVN.

[0071] На фиг. 9 показана блок-схема, иллюстрирующая использование туннельного протокола для передачи пакетов от вычислительного экземпляра к общедоступной службе, согласно по меньшей мере некоторым вариантам осуществления. Как показано в элементе 901, общедоступный IP-адрес «Addr1» для доступа к службе Svc1 может быть определен (например, с использованием DNS-запроса) в вычислительном экземпляре CI1, реализованном на IVN (IVN1), для которой был создан РАЕ (РАЕ1), чтобы обеспечить трафик в/из Svc1. В вычислительном экземпляре CI1 может быть создан базовый пакет ВР1, тело которого содержит по меньшей мере часть запроса SR1 службы (элемент 904). Частный IP-адрес CI1 может быть указан в качестве адреса источника ВР1, a Addr1 может быть указан в качестве получателя. ВР1 может передаваться из CI1 по направлению к Addr1, например, с использованием виртуального сетевого интерфейса, присоединенного к CI1.

[0072] В показанном варианте осуществления, на узле экземпляра, где работает CI1, базовый пакет ВР1 может быть перехвачен компонентом управления виртуализацией (VMC), таким как гипервизор или привилегированный домен операционной системы (элемент 907). VMC может, например, выступать в качестве посредника между виртуализированными ресурсами (такими как виртуальный сетевой интерфейс) и аппаратными компонентами (такими как физическая сетевая интерфейсная плата) узла экземпляра. VMC может анализировать адрес получателя ВР1 и/или один или более элементов данных о конфигурации РАЕ, таких как записи таблицы маршрутов, указывающие, что трафик от CI1 к Svc1 должен направляться на РАЕ1. По меньшей мере в одном варианте осуществления, VMC может, в дополнение или вместо вышеуказанного, иметь возможность искать Addr1 в списке общедоступных IP-адресов Svc1. На основании изучения данных о конфигурации, VMC может иметь возможность определять, что первый пакет ЕР1 инкапсуляции, полученный из ВР1, должен направляться туннельному посреднику, например, для дальнейшей передачи по направлению к Addr1 через мостовую сеть (элемент 910). Туннельный посредник может, например, быть одним узлом многоузлового комплекса, который был создан для маршрутизации трафика между узлами виртуальной вычислительной службы (такими как CI1) и узлами общедоступных служб (такой как Svc1) через внутреннюю мостовую сеть. Первый пакет ЕР1 инкапсуляции может форматироваться в соответствии с первым протоколом Р1 инкапсуляции, который используется для маршрутизации в пределах различных компонентов виртуальной вычислительной службы в некоторых вариантах осуществления. В некоторых реализациях, ВР1 (включая заголовки источника и получателя ВР1) может внедряться в компонент тела пакета ЕР1, и один или более заголовков Р1 могут добавляться с помощью VMC. Добавленные заголовки ЕР1 могут указывать, например, VMC (или узел экземпляра, в котором выполняется VMC) в качестве источника, а туннельный комплекс (или конкретный туннельный посредник) в качестве получателя. В одной реализации, идентификатор IVN1 и/или РАЕ1 также может быть включен в заголовок ЕР1. В некоторых вариантах осуществления, заголовок ЕР1 не обязательно может указывать идентификатор РАЕ1, но может содержать поле, указывающее, что ЕР1 представляет собой пакет, связанный с РАЕ.

[0073] В показанном варианте осуществления ЕР1 может в итоге достичь туннельного посредника, например, после прохождения одного или более транзитных участков сети виртуальной вычислительной службы. В туннельном посреднике ВР1 может извлекаться, а содержимое заголовков ЕР1 может изучаться. Адреса источника и получателя ВР1 (т.е., частный IP-адрес CI1 и адрес Addr1 службы Svc1) могут использоваться для поиска соответствующих адресов источника и получателя в базе данных сопоставления туннельного протокола Р2, которые должны указываться во втором пакете ЕР2 инкапсуляции (элемент 913). В некоторых вариантах осуществления, базовый пакет ВР1 (и/или ЕР1) может форматироваться в соответствии с IPv4, при этом адреса источника и получателя, которые будут использоваться в туннельном протоколе, могут форматироваться в соответствии с IPv6, например, с использованием SIIT или аналогичного протокола трансляции IPv4-IPv6. В других вариантах осуществления, туннельный протокол может быть собственным, например, не обязательно должны использоваться адреса типа IPv6. В некоторых вариантах осуществления, в которых для туннельного протокола не используются IPv6-адреса, инкапсуляция базовых пакетов может выполняться с использованием дополнительных заголовков IPv4, таких как необязательные заголовки TCP. По меньшей мере в одном варианте осуществления, может использоваться инкапсуляция UDP (протокол пользовательских датаграмм) (например, путем включения базового пакета в UDP-сообщение). В показанном варианте осуществления, в туннельном посреднике заголовки ЕР1 могут удаляться и заменяться заголовками ЕР2. Как показано на фиг. 4, в некоторых вариантах осуществления, один или более заголовков ЕР2 могут, соответственно, указывать или кодировать: (а) адреса источника и получателя ВР1 (например, используя 32 бита 128-битного заголовка адреса источника ЕР2 для кодирования 32-битного IP-адреса источника ВР1 и используя 32 бита 128-битного поля адреса получателя ЕР2 для кодирования 32-битного IP-адреса получателя ВР1) и/или (b) идентификаторы исходной IVN (IVN1) и РАЕ, использующиеся для маршрутизации (РАЕ1). В некоторых реализациях, идентификатор РАЕ, который может быть включен в заголовок ЕР2, сам может содержать кодирование соответствующего идентификатора IVN, и поэтому идентификатор РАЕ может применяться в службе для определения как IVN, так и РАЕ, из которых был получен запрос. По меньшей мере в одной реализации, адрес получателя ВР1 может включаться в заголовки источника и получателя ЕР2 таким образом (например, в младшие 32 бита), что средства балансировки маршрутизируют данный пакет на один и тот же внешний узел службы, независимо от того, используется адрес получателя ВР1 или адрес получателя ЕР2.

[0074] ЕР2 может передаваться из туннельного посредника на внешний узел Svc1 (элемент 916), например, через выбранный путь мостовой сети, созданной внутри сети провайдера. В некоторых вариантах осуществления, ЕР2 может достигать Svc1 с использованием только каналов частной сети, управляемых и/или принадлежащих оператору сети провайдера. В других вариантах осуществления, путь, использующийся для ЕР2, может включать в себя каналы сети общего пользования (например, пакет может проходить через сетевые устройства, находящиеся за пределами сети провайдера, или управляемые/принадлежащие юридическим лицам, не являющимся оператором сети провайдера). Во внешнем узле Svc1 может извлекаться содержимое ВР1, указывающее запрос SR1 службы (элемент 919). Кроме того, в службе, использующей заголовки ЕР2, возможна уникальная идентификация исходного экземпляра CI1, например, даже если для СI1 назначается такой же IP-адрес, как и другим экземплярам других IVN. Например, идентификатор исходной IVN и/или РАЕ, использующийся для маршрутизации содержимого ВР1, которое может быть извлечено из заголовка или заголовков ЕР2, может использоваться для устранения неоднозначности запросов службы от таких экземпляров, в вариантах осуществления, в которых каждая IVN может содержать только один экземпляр с определенным частным IP-адресом. По меньшей мере в некоторых вариантах осуществления, запрос SR1 службы может проверяться на стороне службы в соответствии с одной или более политик контроля доступа, связанных с РАЕ. После проверки прав доступа, запрошенные операции могут выполняться, например, во внутренних узлах службы Svc1. По меньшей мере в некоторых вариантах осуществления, может создаваться ответ по меньшей мере на некоторые типы запросов, и ответ может передаваться в обратном направлении к CI1, используя те же протоколы в обратном порядке. Например, базовый ответ, содержание которого создается на внутреннем узле службы, может форматироваться в соответствии с туннельным протоколом Р2 на внешнем узле службы и передаваться через мостовую сеть туннельному посреднику виртуальной вычислительной службы. В туннельном посреднике ответ может извлекаться, форматироваться в соответствии с первым протоколом Р1 инкапсуляции, и передаваться VMC на узле экземпляра, где работает CI1. VMC может извлекать базовый ответ и предоставлять его CI1.

[0075] Следует отметить, что в различных вариантах осуществления, операции, отличные от показанных в блок-схемах на фиг. 8 и 9, могут использоваться для реализации по меньшей мере некоторых из методов для поддержки частных псевдонимов конечных точек. В некоторых вариантах осуществления, некоторые из показанных операций могут быть не реализованы, могут быть реализованы в другом порядке или в другом компоненте, не как показано на фиг. 8 или 9, или выполняться параллельно, а не последовательно. По меньшей мере в одном варианте осуществления, например, описанные функциональные возможности туннельного посредника и VMC могут объединяться, - например, в VMC может быть реализован туннельный протокол, который позволяет пакетам передаваться службе через выбранный путь без дальнейшей инкапсуляции с помощью отдельного посредника. В другом варианте осуществления, базовые пакеты могут передаваться от вычислительного экземпляра или от невиртуализированного вычислительного устройства к туннельному посреднику без инкапсуляции посредством VMC.

Примеры использования

[0076] Описанные выше способы создания частных псевдонимов конечных точек, выступающих в качестве целевых объектов маршрутизации трафика, направленного от вычислительных экземпляров изолированных виртуальных сетей к общедоступным службам, могут быть полезны в различных случаях. Так как в среды сетей провайдеров все больше и больше переносится распределенных приложений, а умения сетевых злоумышленников совершенствуются, растет и потребность в защите и изоляции клиентских приложений от сетевых вторжений из Интернета общего пользования. И хотя изолированные виртуальные сети позволяют клиентам назначать вычислительным экземплярам частные IP-адреса, которые не объявляются в Интернете общего пользования или недоступны из него, при доступе к службам, которые ожидают запросы от таких экземпляров, возникающие на общедоступных IP-адресах, могут возникнуть проблемы. Частные псевдонимы конечных точек могут позволить таким запросам службы передаваться без потенциальных нарушений правил безопасности и без неэффективной/дорогой маршрутизации запросов через VPN-подключения.

[0077] Варианты осуществления настоящего изобретения могут быть описаны с учетом следующих пунктов:

1. Система, содержащая:

диспетчер конфигураций сети провайдера;

компонент управления виртуализацией (VMC) узла экземпляра, в котором первый вычислительный экземпляр первой изолированной виртуальной сети (IVN), созданной от имени клиента, реализуется на узле экземпляра, и в котором первый вычислительный экземпляр имеет частный сетевой адрес, выбранный клиентом; и

туннельный посредник;

в которой диспетчер конфигураций выполнен с возможностью хранить первую запись метаданных, представляющую собой обозначение первого частного псевдонима конечной точки (РАЕ) в качестве целевого объекта маршрутизации для пакетов, возникающих в первой IVN и направленных конкретной службе, где пакеты должны доставляться конкретной службе без указания публично объявленного сетевого адреса в качестве адреса источника;

в которой VMC выполнен с возможностью передавать туннельному посреднику, основываясь по меньшей мере на части изучения первой записи метаданных, первый пакет инкапсуляции, полученный из базового пакета, перехваченного в VMC, где базовый пакет создается в первом вычислительном экземпляре и направляется на публично объявленный сетевой адрес конкретной службы; и

в которой туннельный посредник выполнен с возможностью:

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

передавать второй пакет инкапсуляции первому узлу одного или более узлов конкретной службы, где первый узел выполнен с возможностью (а) определять, из второго пакета инкапсуляции, идентификатор первой IVN и частный сетевой адрес и (b) инициировать одну или более операций для выполнения запроса службы, указанного в базовом пакете.

2. Система по п. 1, в которой второй пакет инкапсуляции форматируется в соответствии с IPv6 (протоколом Интернета версии 6) и в которой базовый пакет форматируется в соответствии с IPv4 (протоколом Интернета версии 4).

3. Система по п. 1, в которой конкретная служба поддерживает множество типов операций на множестве объектов, где один или более из (а) первого узла конкретной службы или (b) VMC выполнены с возможностью:

инициировать определение, перед инициированием одной или более операций, того, соответствует ли запрос службы первой политике контроля доступа, назначенной первому РАЕ, где первая политика контроля доступа указывает, в отношении запросов, отправленных с использованием первого РАЕ в качестве целевого объекта маршрутизации, один или более: (а) разрешенный тип операции из множества типов операций, (b) запрещенный тип операции из множества типов операций, (с) интервал времени, в течение которого разрешается конкретный тип операции из множества типов операций, или (d) конкретный объект из множества объектов, на которых разрешается конкретный тип операции из множества типов операций.

4. Система по п. 1, в которой диспетчер конфигураций дополнительно выполнен с возможностью:

назначать второй РАЕ в качестве целевого объекта маршрутизации для дополнительных пакетов, возникающих в первой IVN, где дополнительные пакеты должны доставляться другой службе.

5. Система по п. 1, в которой диспетчер конфигураций дополнительно выполнен с возможностью:

назначать, по запросу клиента, частный сетевой адрес второму вычислительному экземпляру, созданному во второй IVN клиента;

создавать второй РАЕ, который должен использоваться для маршрутизации трафика, возникающего во второй IVN и направленного конкретной службе;

и в которой первый узел службы выполнен с возможностью:

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

6. Способ, включающий в себя:

определение, в туннельном посреднике сети провайдера, что первый частный псевдоним конечной точки (РАЕ) был назначен в качестве целевого объекта маршрутизации для трафика, возникающего в первой изолированной виртуальной сети (IVN), созданной от имени клиента, где трафик должен доставляться конкретной общедоступной службе;

получение, в туннельном посреднике, базового пакета, направленного от первого вычислительного экземпляра первой IVN на публично объявленный сетевой адрес конкретной общедоступной службы; и

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

7. Способ по п. 6, в котором пакет инкапсуляции форматируется в соответствии с IPv6 (протоколом Интернета версии 6) и в котором базовый пакет форматируется в соответствии с IPv4 (протоколом Интернета версии 4).

8. Способ по п. 6, в котором конкретная служба поддерживает множество типов операций на множестве объектов, дополнительно включающий в себя:

получение, в диспетчере конфигураций первой IVN, от клиента запроса на применение первой политики контроля доступа к первому РАЕ, где первая политика контроля доступа указывает, в отношении запросов, отправленных с использованием первого РАЕ в качестве целевого объекта маршрутизации, один или более: (а) разрешенный тип операции из множества типов операций, (b) запрещенный тип операции из множества типов операций, (с) интервал времени, в течение которого разрешается конкретный тип операции из множества типов операций, или (d) конкретный объект из множества объектов, на которых разрешается конкретный тип операции из множества типов операций; и

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

9. Способ по п. 6, дополнительно включающий в себя:

назначение второго РАЕ в качестве целевого объекта маршрутизации для дополнительного трафика, возникающего в первой IVN, где дополнительный трафик должен доставляться другой службе.

10. Способ по п. 6, в котором первый вычислительный экземпляр имеет конкретный частный IP-адрес, назначенный ему по запросу клиента, дополнительно включающий в себя:

создание от имени клиента второй IVN, где вторая IVN содержит второй вычислительный экземпляр;

назначение, по запросу клиента, конкретного частного IP-адреса второму вычислительному экземпляру;

создание второго РАЕ, который должен использоваться для маршрутизации трафика, возникающего во второй IVN и направленного конкретной службе;

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

11. Способ по п. 6, в котором пакет инкапсуляции форматируется в соответствии с собственным туннельным протоколом, реализованным в сети провайдера.

12. Способ по п. 6, в котором пакет инкапсуляции содержит заголовок, включающий в себя представление идентификатора первого РАЕ.

13. Способ по п. 6, дополнительно включающий в себя:

получение, в диспетчере конфигураций сети провайдера, через программный интерфейс, от клиента запроса на создание первого РАЕ; и

хранение, диспетчером конфигурации в ответ на запрос, записи метаданных, представляющей первый РАЕ.

14. Способ по п. 6, дополнительно включающий в себя:

получение, в диспетчере конфигураций сети провайдера, через программный интерфейс, запроса на регистрацию другой службы для доступа с использованием РАЕ; и

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

15. Способ по п. 14, в котором другая служба реализуется другим клиентом сети провайдера с использованием набора ресурсов сети провайдера, дополнительно включающий в себя:

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

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

получать, в соответствии с назначением первого частного псевдонима конечной точки (РАЕ) в качестве целевого объекта маршрутизации для трафика, направленного конкретной службе из первой изолированной виртуальной сети (IVN), созданной в сети провайдера от имени клиента, базовый пакет, созданный в первом вычислительном экземпляре первой IVN, где базовый пакет указывает общедоступный IP (протокол Интернета) адрес конкретной службы в качестве его адреса получателя;

создавать, в соответствии с выбранным туннельным протоколом, пакет инкапсуляции, содержащий (а) по меньшей мере часть содержимого базового пакета и (b) компонент заголовка, указывающий первую IVN в качестве исходной IVN; и

передавать пакет инкапсуляции на первый узел конкретной службы.

17. Энергонезависимый машиночитаемый носитель по п. 16, в котором пакет инкапсуляции форматируется в соответствии с IPv6 (протоколом Интернета версии 6) и в котором базовый пакет форматируется в соответствии с IPv4 (протоколом Интернета версии 4).

18. Энергонезависимый машиночитаемый носитель по п. 16, в котором туннельный посредник дополнительно выполнен с возможностью:

получать, в соответствии с назначением второго РАЕ в качестве целевого объекта маршрутизации для трафика, направленного другой службе из первой IVN, представление второго базового пакета, созданного во втором вычислительном экземпляре первой IVN, где второй базовый пакет указывает общедоступный IP-адрес другой службы в качестве его адреса получателя;

создавать, в соответствии с выбранным туннельным протоколом, второй пакет инкапсуляции, содержащий (а) по меньшей мере часть содержимого второго базового пакета и (b) компонент заголовка, указывающий первую IVN в качестве исходной IVN; и

передавать второй пакет инкапсуляции на другой узел другой службы.

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

получать, в соответствии с назначением второго РАЕ в качестве целевого объекта маршрутизации для трафика, направленного конкретной службе из второй IVN, созданной от имени клиента, представление второго базового пакета, созданного во втором вычислительном экземпляре второй IVN, где второй базовый пакет указывает общедоступный IP-адрес конкретной службы в качестве его адреса получателя;

создавать, в соответствии с выбранным туннельным протоколом, второй пакет инкапсуляции, содержащий (а) по меньшей мере часть содержимого второго базового пакета, (b) компонент заголовка, указывающий вторую IVN в качестве исходной IVN, и (с) указание частного IP-адреса; и

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

20. Энергонезависимый машиночитаемый носитель по п. 16, в котором пакет инкапсуляции содержит заголовок, включающий в себя представление идентификатора первого РАЕ.

Иллюстративная компьютерная система

[0078] По меньшей мере в некоторых вариантах осуществления, сервер, который реализует один или более компонентов, которые используются для поддержки частных псевдонимов конечных точек, например, диспетчеры конфигураций, VMC, туннельные посредники, а также узлы общедоступных служб, может включать в себя компьютерную систему общего назначения, которая содержит или выполнена с возможностью получать доступ к одному или более машиночитаемым носителям. На фиг. 10 показано такое вычислительное устройство 9000 общего назначения. В показанном варианте осуществления, вычислительное устройство 9000 включает в себя один или более процессоров 9010, соединенных с системной памятью 9020 (которая может содержать и энергонезависимые, и энергозависимые модули памяти) посредством интерфейса 9030 ввода/вывода (I/O). Вычислительное устройство 9000 дополнительно включает в себя сетевой интерфейс 9040, соединенный с интерфейсом 9030 ввода/вывода.

[0079] В различных вариантах осуществления, вычислительное устройство 9000 может представлять собой однопроцессорную систему, содержащую один процессор 9010, или многопроцессорную систему, содержащую несколько процессоров 9010 (например, два, четыре, восемь, или другое подходящее количество). Процессорами 9010 могут быть любые подходящие процессоры, способные выполнять команды. Например, в различных вариантах осуществления, процессорами 9010 могут быть процессоры общего назначения или встроенные процессоры, реализующие любую из множества архитектур набора команд (ISA), таких как х86, PowerPC, SPARC или MIPS ISA, или любую другую подходящую ISA. В многопроцессорных системах, каждый из процессоров 9010, как правило, но не обязательно, может реализовывать одинаковую ISA. В некоторых реализациях, вместо или в дополнение к обычным процессорам, могут использоваться графические процессоры (GPU).

[0080] Системная память 9020 может быть выполнена с возможностью хранения команд и данных, доступных процессору (процессорам) 9010. По меньшей мере в некоторых вариантах осуществления, системная память 9020 может включать в себя как энергозависимые, так и энергонезависимые части; в других вариантах осуществления может использоваться только энергозависимая память. В различных вариантах осуществления, энергозависимая часть системной памяти 9020 может быть реализована с использованием любой подходящей технологии памяти, такой как статическая память с произвольным доступом (SRAM), синхронное динамическое ОЗУ или любой другой тип памяти. Для энергонезависимой части системной памяти (которая может содержать, например, один или более модулей NVDIMM), в некоторых вариантах осуществления могут использоваться устройства на основе флэш-памяти, включая устройства NAND-флэш. По меньшей мере в некоторых вариантах осуществления, энергонезависимая часть системной памяти может содержать источник питания, такой как ионистор или другое устройство накопления энергии (например, батарею). В различных вариантах осуществления, мемристор на основе резистивной памяти с произвольным доступом (ReRAM), технологий трехмерной NAND, сегнетоэлектрической ОЗУ, магниторезистивной ОЗУ (MRAM) или любой из различных типов памяти на фазовых переходах (РСМ) может использоваться по меньшей мере для энергонезависимой части системной памяти. В показанном варианте осуществления, программные команды и данные, реализующие одну или более необходимых функций, таких как способы, методы и данные, описанные выше, хранятся в системной памяти 9020 в виде кода 9025 и данных 9026.

[0081] В одном варианте осуществления, интерфейс 9030 ввода/вывода может быть выполнен с возможностью координировать трафик ввода/вывода между процессором 9010, системной памятью 9020 и периферийными устройствами в устройстве, включающем сетевой интерфейс 9040 или другие периферийные интерфейсы, такие как различные типы устройств постоянного и/или кратковременного хранения данных. В некоторых вариантах осуществления, интерфейс 9030 ввода/вывода может выполнять любые необходимые протокольные, временные или другие преобразования данных для преобразования сигналов данных одного компонента (например, системной памяти 9020) в формат, подходящий для использования другим компонентом (например, процессором 9010). В некоторых вариантах осуществления, интерфейс 9030 ввода/вывода может включать поддержку устройств, подключенных через различные типы периферийных шин, таких как шина взаимосвязи периферийных компонентов (PCI) или, например, универсальная последовательная шина (USB). В некоторых вариантах осуществления, функция интерфейса 9030 ввода/вывода может разделяться на два или более отдельных компонента, таких как, например, северный мост и южный мост. Также, в некоторых вариантах осуществления, некоторые или все функциональные возможности интерфейса 9030 ввода/вывода, такие как взаимодействие с системной памятью 9020, могут быть встроены непосредственно в процессор 9010.

[0082] Сетевой интерфейс 9040 может быть выполнен с возможностью разрешать обмен данными между вычислительным устройством 9000 и другими устройствами 9060, подключенными к сети или к сетям 9050, например, таким как другие компьютерные системы или устройства, показанные на фиг. 1-9. В различных вариантах осуществления, сетевой интерфейс 9040 может поддерживать связь с помощью любых подходящих проводных или беспроводных сетей общих данных, например, таких как сеть Ethernet. Кроме того, сетевой интерфейс 9040 может поддерживать связь через телекоммуникационные/телефонные сети, такие как аналоговые голосовые сети или сети цифровой волоконно-оптической связи, через сети хранения данных, такие как сети SAN стандарта Fibre Channel, или через любую другую подходящую сеть и/или протокол.

[0083] В некоторых вариантах осуществления, системной памятью 9020 может быть один вариант осуществления машиночитаемого носителя, выполненный с возможностью хранить программные команды и данные, как описано выше для фиг. 1-9, для реализации вариантов осуществления соответствующих способов и устройств. Тем не менее, в других вариантах осуществления, программные команды и/или данные могут получаться, передаваться или храниться на машиночитаемых носителях различного типа. В общем случае, машиночитаемый носитель может включать в себя энергонезависимые носители или системы памяти, такие как магнитные или оптические носители, например, дискету или DVD/CD, соединенный с вычислительным устройством 9000 через интерфейс 9030 ввода/вывода. Энергонезависимый машиночитаемый носитель может также включать в себя любые энергозависимые или энергонезависимые носители, такие как ОЗУ (например, SDRAM, DDR SDRAM, RDRAM, SRAM и т.д.), ПЗУ и т.д., которые могут быть включены в некоторые варианты осуществления вычислительного устройства 9000 в качестве системной памяти 9020 или памяти другого типа. Кроме того, машиночитаемый носитель может включать в себя средства передачи данных или сигналы, такие как электрические, электромагнитные или цифровые сигналы, передаваемые через средство связи, такое как сеть и/или беспроводной канал, которое может быть реализовано через сетевой интерфейс 9040. Часть или все из множества вычислительных устройств, таких как приведенные на фиг. 10, могут использоваться для реализации описанных функциональных возможностей в различных вариантах осуществления; например, компоненты программного обеспечения, выполняющиеся на множестве различных устройств и серверов, могут действовать совместно для обеспечения функциональных возможностей. В некоторых вариантах осуществления, часть описанных функциональных возможностей может быть реализована с использованием устройств хранения данных, сетевых устройств или компьютерных систем специального назначения, в дополнение или вместо того, чтобы быть реализованной с использованием компьютерных систем общего назначения. Термин «вычислительное устройство», используемый в настоящем документе, охватывает по меньшей мере все типы таких устройств и не ограничивается этими типами устройств.

Заключение

[0084] Различные варианты осуществления дополнительно могут включать в себя получение, отправку или хранение команд и/или данных, реализованных в соответствии с приведенным выше описанием машиночитаемого носителя. В общем случае, машиночитаемый носитель может включать в себя носители данных или системы памяти, такие как магнитные или оптические носители, например, дискета или DVD/CD-ROM, энергозависимые или энергонезависимые носители, такие как ОЗУ (например, SDRAM, DDR, RDRAM, SRAM и т.д.), ПЗУ и т.д., а также средства передачи данных или сигналы, такие как электрические, электромагнитные или цифровые сигналы, передаваемые через средство связи, такое как сеть и/или беспроводной канал.

[0085] Различные способы, показанные на фигурах и описанные в настоящем документе, представляют типовые варианты осуществления способов. Способы могут быть реализованы в виде программного обеспечения, аппаратного обеспечения или их комбинаций. Порядок способа может быть изменен, и различные элементы могут быть добавлены, перегруппированы, комбинированы, опущены, модифицированы и т.п.

[0086] Могут быть выполнены различные модификации и изменения, как будет понятно специалисту в данной области техники благодаря этому описанию. Оно охватывает все такие модификации и изменения, и, следовательно, приведенное выше описание следует рассматривать в иллюстративном, а не ограничительном смысле.

Claims

1. Способ передачи данных в изолированной виртуальной сети, содержащий:

определение в туннельном посреднике сети провайдера, что первый частный псевдоним конечной точки (РАЕ) был назначен в качестве целевого объекта маршрутизации для трафика, возникающего в первой изолированной виртуальной сети (IVN), созданной в пределах сети провайдера от имени клиента, причем трафик предназначен для доставки конкретной общедоступной службе, реализованной в сети провайдера;

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

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

2. Способ по п. 1, в котором пакет инкапсуляции форматирован в соответствии с IPv6 (протоколом Интернета версии 6) и в котором базовый пакет форматирован в соответствии с IPv4 (протоколом Интернета версии 4).

3. Способ по п. 1, в котором конкретная служба поддерживает множество типов операций на множестве объектов, дополнительно содержащий:

получение в диспетчере конфигураций первой изолированной виртуальной сети от клиента запроса на применение первой политики контроля доступа к первому частному псевдониму конечной точки, причем первая политика контроля доступа указывает в отношении запросов, отправленных с использованием первого частного псевдонима конечной точки в качестве целевого объекта маршрутизации, один или более из следующего: (а) разрешенный тип операции из множества типов операций, (b) запрещенный тип операции из множества типов операций, (с) интервал времени, в течение которого разрешается конкретный тип операции из множества типов операций, или (d) конкретный объект из множества объектов, на которых разрешается конкретный тип операции из множества типов операций; и

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

4. Способ по п. 1, дополнительно содержащий:

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

5. Способ по п. 1, в котором первый вычислительный экземпляр имеет конкретный частный IP-адрес, назначенный ему по запросу клиента, способ, дополнительно содержащий:

создание от имени клиента второй изолированной виртуальной сети, причем вторая изолированная виртуальная сеть содержит второй вычислительный экземпляр;

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

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

6. Способ по п. 1, дополнительно содержащий:

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

7. Способ по п. 1, в котором пакет инкапсуляции содержит заголовок, включающий в себя представление идентификатора первого частного псевдонима конечной точки.

8. Способ по п. 1, дополнительно включающий:

получение в диспетчере конфигураций сети провайдера через программный интерфейс от клиента запроса на создание первого частного псевдонима конечной точки и

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

9. Способ по п. 1, дополнительно содержащий:

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

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

10. Способ по п. 9, в котором указанная другая служба реализуется другим клиентом сети провайдера с использованием набора ресурсов сети провайдера, дополнительно содержащий:

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

11. Система передачи данных в изолированной виртуальной сети, содержащая:

одну или более компьютерных систем, включающих одно или более запоминающих устройств, причем одно или более запоминающих устройств содержат команды, которые при выполнении принуждают систему:

получать, в соответствии с назначением первого частного псевдонима конечной точки (РАЕ) в качестве целевого объекта маршрутизации для трафика, направленного конкретной службе, реализованной в сети провайдера, из первой изолированной виртуальной сети (IVN), созданной в пределах сети провайдера от имени клиента, базовый пакет, созданный в первом вычислительном экземпляре первой изолированной виртуальной сети, причем базовый пакет указывает общедоступный IP (протокол Интернета) адрес конкретной службы в качестве его адреса получателя;

создавать в соответствии с выбранным туннельным протоколом пакет инкапсуляции, содержащий (а) по меньшей мере часть содержимого базового пакета и (b) компонент заголовка, указывающий первую изолированную виртуальную сеть в качестве исходной изолированной виртуальной сети, и

12. Система по п. 11, в которой пакет инкапсуляции форматирован в соответствии с IPv6 (протоколом Интернета версии 6) и в которой базовый пакет форматирован в соответствии с IPv4 (протоколом Интернета версии 4).

13. Система по п. 11, в которой одно или более запоминающих устройств содержат команды, которые при выполнении принуждают систему:

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

создавать в соответствии с выбранным туннельным протоколом второй пакет инкапсуляции, содержащий (а) по меньшей мере часть содержимого второго базового пакета и (b) компонент заголовка, указывающий первую изолированную виртуальную сеть в качестве исходной изолированной виртуальной сети, и

передавать второй пакет инкапсуляции на другой узел указанной другой службы.

14. Система по п. 11, в которой первый пакет инкапсуляции содержит указание частного IP-адреса первого вычислительного экземпляра и в которой одно или более запоминающих устройств содержат команды, которые при выполнении принуждают систему:

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

создавать, в соответствии с выбранным туннельным протоколом, второй пакет инкапсуляции, содержащий (а) по меньшей мере часть содержимого второго базового пакета, (b) компонент заголовка, указывающий вторую изолированную виртуальную сеть в качестве исходной изолированной виртуальной сети, и (с) указание частного IP-адреса; и

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

15. Система по п. 11, в которой пакет инкапсуляции содержит заголовок, содержащий представление идентификатора первого частного псевдонима конечной точки.