Често задавани въпроси за виртуалната мрежа на Azure (ЧЗВ)
26.06.202029 минути за четенеAzure Виртуална мрежа (VNet) е представяне на вашата собствена мрежа в облака. Това е логична изолация на облака Azure, посветен на вашия абонамент. Можете да използвате VNets за осигуряване и управление на виртуални частни мрежи (VPN) в Azure и, по желание, да свържете VNets с други VNets в Azure или с вашата локална ИТ инфраструктура, за да създадете хибридни или кръстосани решения. Всяка VNet, която създавате, има свой собствен CIDR блок и може да бъде свързана с други VNet и локални мрежи, стига CIDR блоковете да не се припокриват. Освен това имате контрол върху настройките на DNS сървъра за VNets и сегментирането на VNet в подмрежи.
Използвайте VNets за:
Създайте специална частна VNet само за облак. Понякога не се нуждаете от конфигурация между помещенията за вашето решение. Когато създадете VNet, вашите услуги и виртуални машини във вашата VNet могат да комуникират директно и сигурно помежду си в облака. Все още можете да конфигурирате крайни връзки за виртуални машини и услуги, които изискват интернет комуникация, като част от вашето решение.
Сигурно разширете своя център за данни. С VNets можете да изградите традиционни VPN от сайт до сайт (S2S), за да увеличите сигурно капацитета на вашия център за данни. S2S VPN използват IPSEC, за да осигурят защитена връзка между вашия корпоративен VPN шлюз и Azure.
Активирайте сценарии за хибриден облак. Виртуалните мрежи ви дават гъвкавостта да поддържате набор от сценарии за хибриден облак. Можете сигурно да свържете базирани на облак приложения към всеки тип локална система, като мейнфрейми и Unix системи.
Посетете документацията за виртуална мрежа, за да започнете. Това съдържание предоставя преглед и информация за внедряване на всички VNet функции.
Да. Можете да използвате виртуална мрежа, без да я свързвате към вашите помещения. Например, можете да стартирате домейн контролери на Microsoft Windows Server Active Directory и ферми на SharePoint единствено в Azure VNet.
Да. Можете да разположите виртуално устройство за мрежа за оптимизиране на WAN от няколко доставчици чрез Azure Marketplace.
Можете да използвате следните инструменти, за да създадете или конфигурирате VNet:
Препоръчваме ви да използвате диапазоните от адреси, изброени в RFC 1918, които са определени от IETF за частни, немаршрутизирани адресни пространства:
10.0.0.0 - 10.255.255.255(префикс 10/8)172.16.0.0 - 172.31.255.255(префикс 172.16/12)192.168.0.0 - 192.168.255.255 (префикс 192.168/16)Други адресните пространства може да работят, но може и да работят нежелани странични ефекти.
Освен това не можете да добавяте следните диапазони от адреси:
224.0.0.0/4 (Multicast)255.255.255.255/32 (Broadcast)127.0.0.0/8 (Loopback)169.254.0.0/16 (Link-local)168.63.129.16/32 (Internal DNS)Да. За повече информация относно публичните диапазони на IP адреси вижте Създаване на виртуална мрежа. Публичните IP адреси не са директно достъпни от интернет.
Да. Вижте ограниченията на Azure за подробности. Подмрежовите адресни пространства не могат да се припокриват едно с друго.
Да. Azure запазва 5 IP адреса във всяка подмрежа. Това са x.x.x.0-x.x.x.3 и последния адрес на подмрежата. x.x.x.1-x.x.x.3 е запазено във всяка подмрежа за услуги на Azure.
x.x.x.0: Мрежов адресx.x.x.1: Запазен от Azure за шлюза по подразбиранеx.x.x.2, x.x.x.3: Запазен от Azure за картографиране на DNS IP адресите на Azure към VNet пространствотоx.x.x.255: Мрежов адрес за излъчване за подмрежи с размер /25 и по-голям. Това ще бъде различен адрес в по-малки подмрежи.Най-малката поддържана IPv4 подмрежа е /29, а най-голямата е /2 (използвайки CIDR подмрежа дефиниции).IPv6 подмрежите трябва да са с размер точно /64.
Не. VNets са Layer-3 наслагвания. Azure не поддържа семантика на Layer-2.
Да. Можете да създадете таблица с маршрути и да я свържете с подмрежа. За повече информация относно маршрутизирането в Azure вижте Общ преглед на маршрутизирането.
Не. Групово предаване и излъчване не се поддържат.
Можете да използвате TCP, UDP и ICMP TCP/IP протоколи във VNets. Unicast се поддържа във VNets, с изключение на Dynamic Host Configuration Protocol (DHCP) чрез Unicast (порт на източник UDP/68 / порт на местоназначение UDP/67) и UDP порт на източник 65330, който е запазен за хоста. Групово предаване, излъчване, капсулирани пакети IP в IP и пакети за капсулиране на общо маршрутизиране (GRE) са блокирани във VNets.
Не.
Не.
Да. Подмрежите могат да се добавят към VNets по всяко време, стига диапазонът от адреси на подмрежата да не е част от друга подмрежа и в диапазона от адреси на виртуалната мрежа е останало свободно място.
Да. Можете да добавяте, премахвате, разширявате или свивате подмрежа, ако в нея няма внедрени виртуални машини или услуги.
Да. Можете да добавяте, премахвате и модифицирате CIDR блоковете, използвани от VNet.
Да. Всички услуги, внедрени във VNet, могат да се свързват изходящо към интернет. За да научите повече за изходящите интернет връзки в Azure, вижте Изходящи връзки. Ако искате да се свържете входящо към ресурс, внедрен чрез Resource Manager, ресурсът трябва да има присвоен публичен IP адрес. За да научите повече за публичните IP адреси, вижте Публични IP адреси. Всяка облачна услуга на Azure, внедрена в Azure, има присвоен публично адресируем VIP. Вие дефинирате входни крайни точки за PaaS роли и крайни точки за виртуални машини, за да позволите на тези услуги да приемат връзки от интернет.
Да, VNets могат да бъдат само IPv4 или двоен стек (IPv4+IPv6). За подробности вижте Общ преглед на IPv6 за виртуални мрежи Azure.
Не. VNet е ограничен до един регион. Виртуалната мрежа обаче обхваща зони на достъпност. За да научите повече за зоните за достъпност, вижте Общ преглед на зоните за достъпност. Можете да свързвате виртуални мрежи в различни региони с peering на виртуална мрежа. За подробности вижте Общ преглед на пиринг на виртуална мрежа
Да. Можете да свържете една VNet към друга VNet, като използвате:
Използвайте таблицата с решения на страницата Разрешаване на имена за виртуални машини и ролеви инстанции, за да ви преведе през всички Налични опции за DNS.
Да. Можете да посочите IP адресите на DNS сървъра в настройките на VNet. Настройката се прилага като DNS сървър(и) по подразбиране за всички виртуални машини във VNet.
Справка с ограниченията на Azure.
Да. Можете да промените списъка с DNS сървъри за вашата VNet по всяко време. Ако промените списъка си с DNS сървъри, трябва да извършите подновяване на лизинг на DHCP на всички засегнати виртуални машини във VNet, за да влязат в сила новите DNS настройки. За виртуални машини, работещи с Windows OS, можете да направите това, като напишете ipconfig /renew директно на виртуалната машина. За други типове ОС вижте документацията за подновяване на наема на DHCP за конкретния тип ОС.
DNS, предоставен от Azure, е DNS услуга с множество клиенти, предлагана от Microsoft. Azure регистрира всички ваши виртуални машини и екземпляри на роли на облачна услуга в тази услуга. Тази услуга предоставя разрешаване на имена по име на хост за виртуални машини и екземпляри на роли, съдържащи се в една и съща облачна услуга, и чрез FQDN за виртуални машини и екземпляри на роли в една и съща VNet. За да научите повече за DNS, вижте Резолюция на имена за виртуални машини и ролеви екземпляри на облачни услуги.
Има ограничение за първите 100 облачни услуги във виртуална мрежа за разрешаване на имена на кръстосани клиенти с помощта на осигурен от Azure DNS. Ако използвате собствен DNS сървър, това ограничение не се прилага.
Да. Можете да зададете DNS сървъри за VM или облачна услуга, за да замените мрежовите настройки по подразбиране. Въпреки това се препоръчва да използвате DNS за цялата мрежа колкото е възможно повече.
Не. Не можете да посочите персонализиран DNS суфикс за вашите виртуални мрежи.
Да. Всички мрежови интерфейси (NIC), прикрепени към VM, внедрени чрез модела за разполагане на Resource Manager, трябва да бъдат свързани към VNet. Виртуалните машини, внедрени чрез класическия модел на внедряване, могат по избор да бъдат свързани към VNet.
Лични: Присвоени на всеки NIC във всяка виртуална машина. Адресът се присвоява чрез използване на статичен или динамичен метод. Частните IP адреси се присвояват от диапазона, който сте посочили в настройките на подмрежата на вашата VNet. На ресурсите, разгърнати чрез класическия модел на разгръщане, се присвояват частни IP адреси, дори ако не са свързани към VNet. Поведението на метода за разпределение е различно в зависимост от това дали даден ресурс е бил внедрен с Resource Manager или класически модел на разполагане:
Мениджър на ресурси: Частен IP адрес, присвоен с динамичния или статичен метод, остава присвоен на виртуална машина (мениджър на ресурси), докато ресурсът не бъде изтрит. Разликата е, че вие избирате адреса, който да присвоите, когато използвате статичен, а Azure избира, когато използвате динамичен. Класически: Частен IP адрес, присвоен с динамичния метод, може да се промени, когато виртуална машина (класическа) VM се рестартира, след като е била в спрян (освободено) състояние. Ако трябва да гарантирате, че частният IP адрес за ресурс, внедрен чрез класическия модел на разполагане, никога не се променя, задайте частен IP адрес със статичния метод.Публичен: По избор се присвоява на NIC, прикрепени към виртуални машини, внедрени чрез Azure Resource Manager модел на разгръщане. Адресът може да бъде присвоен със статичен или динамичен метод на разпределение. Всички виртуални машини и ролеви екземпляри на облачни услуги, внедрени чрез класическия модел на разгръщане, съществуват в облачна услуга, на която е присвоен динамичен публичен виртуален IP (VIP) адрес. Публичен статичен IP адрес, наречен резервиран IP адрес, може по избор да бъде назначен като VIP. Можете да присвоите публични IP адреси на отделни виртуални машини или ролеви екземпляри на облачни услуги, внедрени чрез класическия модел на внедряване. Тези адреси се наричат публичен IP на ниво инстанция (ILPIP адреси и могат да се присвояват динамично.
Не. Не можете да запазите личен IP адрес. Ако е наличен частен IP адрес, той се присвоява на VM или екземпляр на роля от DHCP сървъра. VM може или не може да бъде този, на който искате да бъде присвоен частният IP адрес. Можете обаче да промените частния IP адрес на вече създадена виртуална машина на всеки наличен частен IP адрес.
Зависи. Ако виртуалната машина е била разгърната чрез Resource Manager, не, независимо дали IP адресът е бил присвоен със статичен или динамичен метод за разпределение. Ако виртуалната машина е била разгърната чрез класическия модел на разгръщане, динамичните IP адреси могат да се променят, когато виртуална машина е стартирана, след като е била в спряно (освободено) състояние. Адресът се освобождава от виртуална машина, внедрена чрез един от двата модела на разполагане, когато виртуалната машина бъде изтрита.
Да, но не се препоръчва, освен ако не е необходимо, като например при присвояване на множество IP адреси на виртуална машина. За подробности вижте Добавяне на множество IP адреси към виртуална машина. Ако IP адресът, присвоен на Azure NIC, свързан към VM, се промени и IP адресът в операционната система на VM е различен, вие губите връзка с VM.
Нищо. IP адресите (публичен VIP, публичен и частен) остават присвоени на слота за внедряване на облачна услуга или VM.
Да. Можете да намерите повече информация в статията Как да преместите VM или екземпляр на роля в друга подмрежа.
Не. MAC адресът не може да бъде статично конфигуриран.
Да, MAC адресът остава същият за виртуална машина, внедрена както чрез Resource Manager, така и чрез класически модели за внедряване, докато не бъде изтрита. Преди MAC адресът се освобождаваше, ако VM беше спрян (освободен), но сега MAC адресът се запазва дори когато VM е в състояние на освобождаване. MAC адресът остава присвоен на мрежовия интерфейс, докато мрежовият интерфейс не бъде изтрит или частният IP адрес, присвоен на основната IP конфигурация на основния мрежов интерфейс, не бъде променен.
Да. Всички виртуални машини и ролеви екземпляри на облачни услуги, внедрени във VNet, могат да се свързват към интернет.
Да. Можете да разположите уеб приложения във VNet с помощта на ASE (App Service Environment), да свържете задната част на вашите приложения към вашите VNets с VNet Integration и да заключите входящия трафик към вашето приложение с крайни точки на услугата. За повече информация вижте следните статии:
Да. Можете (по избор) да внедрите екземпляри на роли на Cloud Services във VNets. За да направите това, посочвате името на VNet и съпоставянията на роля/подмрежа в раздела за мрежова конфигурация на вашата конфигурация на услугата. Не е необходимо да актуализирате никакви двоични файлове.
Да. Трябва да свържете набор от мащаби на виртуална машина към VNet.
Да, за подробности вижте Интегриране на виртуална мрежа за услуги на Azure.
Ресурсите, внедрени чрез някои услуги на Azure PaaS (като Azure Storage и Azure SQL база данни), могат да ограничат мрежовия достъп до VNet чрез използване на крайни точки на виртуална мрежова услуга или Azure Private Link. За подробности вижте Общ преглед на крайните точки на виртуална мрежова услуга, Общ преглед на Azure Private Link
Не. Не можете да местите услуги във и извън виртуални мрежи. За да преместите ресурс в друга VNet, трябва да изтриете и преразположите ресурса.
VNets са изолирани една от друга и други услуги, хоствани в инфраструктурата на Azure. VNet е граница на доверие.
Да. Можете да приложите групи за мрежова сигурност към отделни подмрежи във VNet, NIC, свързани към VNet, или и двете.
Да. Можете да разположите мрежово виртуално устройство за защитна стена от няколко доставчици чрез Azure Marketplace.
Да. За подробности вижте Общ преглед на мрежовата сигурност на Azure.
Не. Виртуалните мрежи не съхраняват данни за клиенти.
Да. Можете да използвате REST API за VNets в Azure Resource Manager и класическите модели за внедряване.
Да. Научете повече за използването на:
VNet peering (или виртуална мрежа peering) ви позволява да свързвате виртуални мрежи. VNet peering връзка между виртуални мрежи ви позволява да насочвате трафик между тях частно чрез IPv4 адреси. Виртуалните машини в пиърираните VNets могат да комуникират помежду си, сякаш са в една и съща мрежа. Тези виртуални мрежи могат да бъдат в един и същ регион или в различни региони (известни също като Global VNet Peering). VNet peering връзки могат също да бъдат създадени в абонаменти на Azure.
Да. Глобалният пиъринг на VNet ви позволява да пирингувате виртуални мрежи в различни региони. Глобалният VNet peering е достъпен във всички публични региони на Azure, облачни региони на Китай и облачни региони на правителството. Не можете глобално да препращате от публични региони на Azure към национални облачни региони.
Ако двете виртуални мрежи в два различни региона се надникват през Global VNet Peering, не можете да се свържете с ресурси, които са зад основен балансьор на натоварването през предния IP адрес на балансиращото натоварване. Това ограничение не съществува за стандартен Load Balancer. Следните ресурси могат да използват Basic Load Balancer, което означава, че не можете да ги достигнете чрез предния IP адрес на Load Balancer през Global VNet Peering. Можете обаче да използвате Global VNet peering, за да достигнете до ресурсите директно през техните частни VNet IP адреси, ако е разрешено.
Виртуални машини зад Basic Load Balancers Набори мащаби на виртуална машина с Basic Load BalancersRedis CacheApplication Gateway (v1) SKUService FabricAPI Management (stv1)Active Directory Domain Service (ADDS)Logic AppsHDInsightAzure BatchApp Service EnvironmentМожете да се свържете с тези ресурси чрез ExpressRoute или VNet-to -VNet чрез VNet Gateways.
Да. Възможно е да установите VNet Peering (независимо дали локален или глобален), ако вашите абонаменти принадлежат на различни клиенти на Azure Active Directory. Можете да направите това чрез портал, PowerShell или CLI.
Ако вашата peering връзка е в Инициирано състояние, това означава, че сте създали само една връзка. Трябва да се създаде двупосочна връзка, за да се установи успешна връзка. Например, за да се направи peer от VNet A към VNet B, трябва да се създаде връзка от VNetA към VNetB и от VNetB към VNetA. Създаването на двете връзки ще промени състоянието на Свързан.
Ако вашата VNet peering връзка е в прекъснато състояние, това означава, че една от създадените връзки е била изтрита. За да установите отново peering връзка, ще трябва да изтриете връзката и да я създадете отново.
Да. Можете да правите партньорски виртуални мрежи между абонаменти и региони.
Не. Адресните пространства не трябва да се припокриват, за да се активира VNet Peering.
Не. Можете да активирате опцията „Използване на отдалечен шлюз“ само на един пиъринг към една от виртуалните мрежи.
Няма такса за създаване на VNet peering връзка. Прехвърлянето на данни през пирингови връзки се таксува. Виж тук.
Когато трафикът на Azure се движи между центрове за данни (извън физически граници, които не се контролират от Microsoft или от името на Microsoft), MACsec криптирането на слоя за връзка към данни се използва на основния мрежов хардуер .Това е приложимо за VNet peering трафик.
Връзките на VNet peering преминават в състояние Disconnected, когато една VNet връзка за пиринг е изтрита. Трябва да изтриете и двете връзки, за да възстановите успешна peering връзка.
Не. Транзитивният пиъринг не се поддържа. Трябва да направите peer VNetA и VNetC, за да се случи това.
Не. Пирингът на VNet, независимо дали е локален или глобален, не налага никакви ограничения на честотната лента. Ширината на честотната лента е ограничена само от VM или изчислителния ресурс.
Ето ръководство за отстраняване на неизправности, което можете да опитате.
Визуализацията на виртуална мрежа TAP е налична във всички региони на Azure. Наблюдаваните мрежови интерфейси, виртуалният мрежов TAP ресурс и колекторът или решението за анализ трябва да бъдат разположени в един и същ регион.
Възможностите за филтриране не се поддържат с визуализацията на TAP за виртуална мрежа. Когато TAP конфигурация се добави към мрежов интерфейс, дълбоко копие на целия входящ и изходящ трафик на мрежовия интерфейс се предава поточно към TAP дестинацията.
Наблюдаван мрежов интерфейс може да има само една TAP конфигурация. Проверете при индивидуалното партньорско решение за възможността за поточно предаване на множество копия на TAP трафика към инструментите за анализ по ваш избор.
Да. Същият TAP ресурс на виртуална мрежа може да се използва за агрегиране на огледален трафик от наблюдавани мрежови интерфейси в пиърирани виртуални мрежи в същия абонамент или различен абонамент. Ресурсът TAP на виртуалната мрежа и целевият балансьор на натоварването или мрежовият интерфейс на местоназначението трябва да са в един и същи абонамент. Всички абонаменти трябва да бъдат под един и същ клиент на Azure Active Directory.
ТАР за виртуална мрежа е в предварителен преглед. По време на визуализацията няма споразумение за ниво на обслужване. Възможността не трябва да се използва за производствени натоварвания. Когато мрежовият интерфейс на виртуална машина е активиран с TAP конфигурация, същите ресурси на хоста на Azure, разпределени на виртуалната машина за изпращане на производствения трафик, се използват за изпълнение на функцията за дублиране и изпращане на дублирани пакети. Изберете правилния размер на виртуална машина за Linux или Windows, за да сте сигурни, че са налични достатъчно ресурси за виртуалната машина за изпращане на производствения трафик и огледалния трафик.
Ще можете да добавите TAP конфигурация към мрежов интерфейс, свързан към виртуална машина, която е активирана с ускорена работа в мрежа. Но производителността и закъснението на виртуалната машина ще бъдат засегнати от добавянето на TAP конфигурация, тъй като разтоварването за огледален трафик в момента не се поддържа от Azure ускорена мрежа.
Има две стъпки за защита на ресурс на услуга на Azure чрез услуга крайни точки:
Включете крайните точки на услугата за услугата Azure. Настройте VNet ACL на услугата Azure.Първата стъпка е операция от страна на мрежата, а втората стъпка е операция от страна на ресурса на услугата. И двете стъпки могат да бъдат изпълнени или от един и същ администратор, или от различни администратори въз основа на разрешенията на Azure RBAC, предоставени на администраторската роля. Препоръчваме ви първо да включите крайните точки на услугата за вашата виртуална мрежа, преди да настроите VNet ACL от страната на услугата Azure. Следователно, стъпките трябва да се изпълнят в последователността, посочена по-горе, за да настроите крайни точки на VNet услуга.
Забележка
И двете операции, описани по-горе, трябва да бъдат завършени, преди да можете да ограничите достъпа на услугата Azure до разрешената VNet и подмрежа. Само включването на крайни точки на услугата за услугата Azure от страната на мрежата не ви осигурява ограничения достъп. Освен това трябва да настроите VNet ACL от страната на услугата Azure.
Някои услуги (като SQL и CosmosDB) позволяват изключения от горната последователност чрез флага IgnoreMissingVnetServiceEndpoint. След като флагът е зададен на True, VNet ACL могат да бъдат зададени от страната на услугата Azure, преди да се настроят крайните точки на услугата от страната на мрежата. Услугите на Azure предоставят този флаг, за да помогнат на клиентите в случаите, когато специфичните IP защитни стени са конфигурирани на услуги на Azure и включването на крайните точки на услугата от страната на мрежата може да доведе до прекъсване на връзката, тъй като IP източникът се променя от публичен IPv4 адрес на частен адрес . Настройването на ACL на VNet от страната на услугата Azure преди задаване на крайни точки на услугата от страната на мрежата може да помогне за избягване на прекъсване на връзката.
Не, не всички услуги на Azure се намират във виртуалната мрежа на клиента. По-голямата част от услугите за данни на Azure, като Azure Storage, Azure SQL и Azure Cosmos DB, са услуги с множество клиенти, които могат да бъдат достъпни през публични IP адреси. Можете да научите повече за интегрирането на виртуална мрежа за услуги на Azure тук.
Когато използвате функцията за крайни точки на услуга на VNet (включване на крайна точка на услуга на VNet от страната на мрежата и настройка на подходящи ACL за VNet от страната на услугата Azure), достъпът до услуга на Azure е ограничен от разрешена VNet и подмрежа.
Функцията за крайна точка на услугата VNet (включване на крайна точка на услуга на VNet от страна на мрежата и настройка на подходящи ACL за VNet от страната на услугата Azure) ограничава достъпа до услугата Azure към разрешената VNet и подмрежа, като по този начин осигурява сигурност на мрежово ниво и изолиране на трафика на услугата Azure. Целият трафик, използващ крайни точки на VNet услуга, преминава през гръбнака на Microsoft, като по този начин осигурява още един слой на изолация от обществения интернет. Освен това, клиентите могат да изберат да премахнат напълно публичния интернет достъп до ресурсите на услугата Azure и да разрешат трафик само от тяхната виртуална мрежа чрез комбинация от IP защитна стена и VNet ACL, като по този начин защитават ресурсите на услугата Azure от неоторизиран достъп.
Крайните точки на услугата VNet помагат за защитата на ресурсите на услугата Azure. Ресурсите на VNet са защитени чрез групи за мрежова сигурност (NSG).
Не, няма допълнителни разходи за използване на крайни точки на VNet услуга.
Да, възможно е. Виртуалните мрежи и ресурсите на услугите на Azure могат да бъдат в едни и същи или различни абонаменти. Единственото изискване е както виртуалната мрежа, така и ресурсите на услугите на Azure да бъдат под един и същи клиент на Active Directory (AD).
Да, възможно е при използване на крайни точки на услуга за хранилище на Azure и Azure Key Vault. За останалата част от услугите крайните точки на услугата на VNet и ACL на VNet не се поддържат в клиенти на AD.
По подразбиране ресурсите на услугата на Azure са защитени към виртуални мрежите не са достъпни от локални мрежи. Ако искате да разрешите трафик от локално, трябва също да разрешите публични (обикновено NAT) IP адреси от вашия локален или ExpressRoute. Тези IP адреси могат да се добавят чрез конфигурацията на IP защитната стена за ресурсите на услугата Azure.
За да защитя услугите на Azure за множество подмрежи във виртуална мрежа или в множество виртуални мрежи , активирайте крайните точки на услугата от страната на мрежата на всяка от подмрежите независимо и след това осигурете ресурсите на услугите на Azure за всички подмрежи, като настроите подходящи VNet ACL от страната на услугата Azure.
Ако искате да инспектирате или филтрирате трафика, предназначен към услуга на Azure от виртуална мрежа, можете разположете мрежово виртуално устройство във виртуалната мрежа. След това можете да приложите крайни точки на услуги към подмрежата, където е разгърнато мрежовото виртуално устройство, и да защитите ресурсите на услугите на Azure само към тази подмрежа чрез VNet ACL. Този сценарий може също да бъде полезен, ако искате да ограничите достъпа до услугата на Azure от вашата виртуална мрежа само до конкретни ресурси на Azure, като използвате филтриране на мрежово виртуално устройство. За повече информация вижте излизане с мрежови виртуални устройства.
Връща се грешката HTTP 403 или HTTP 404.
Да, за повечето от услугите на Azure виртуалните мрежи, създадени в различни региони, имат достъп до услугите на Azure в друг регион чрез крайните точки на услугата VNet. Например, ако акаунт в Azure Cosmos DB е в Западна САЩ или Източна САЩ и виртуалните мрежи са в множество региони, виртуалната мрежа може да има достъп до Azure Cosmos DB. Съхранението и SQL са изключения и са регионални по природа и както виртуалната мрежа, така и услугата Azure трябва да са в един и същ регион.
Да, VNet ACL и IP защитна стена могат да съществуват едновременно. И двете функции се допълват взаимно, за да осигурят изолация и сигурност.
Изтриването на VNets и подмрежи са независими операции и се поддържат дори когато крайните точки на услугата са включени за Azure услуги. В случаите, когато услугите на Azure имат настроени VNet ACL, за тези VNet и подмрежи, информацията за VNet ACL, свързана с тази услуга на Azure, се деактивира, когато VNet или подмрежа, която има включена крайна точка на VNet услуга, се изтрие.
Изтриването на акаунт за услуга в Azure е независима операция и се поддържа дори когато крайната точка на услугата е активирана на мрежовата страна и VNet ACL се настройват от страната на услугата Azure.
Когато крайните точки на виртуална мрежова услуга са активирани, IP адресите на източника на ресурсите в подмрежата на вашата виртуална мрежа превключва от използване на публични IPV4 адреси към частни IP адреси на виртуалната мрежа на Azure за трафик към услугата на Azure. Имайте предвид, че това може да доведе до неуспех на конкретни IP защитни стени, които са зададени на публичен IPV4 адрес по-рано в услугите на Azure.
Крайните точки на услугата добавят системен маршрут, който има предимство пред BGP маршрутите и осигурява оптимално маршрутизиране за трафика на крайната точка на услугата. Крайните точки на услугата винаги приемат трафика на услугата директно от вашата виртуална мрежа към услугата в опорната мрежа на Microsoft Azure. За повече информация относно начина, по който Azure избира маршрут, вижте Маршрутизиране на трафика на виртуална мрежа на Azure.
Не, ICMP трафикът, който идва от подмрежа с активирани крайни точки на услугата, няма да отведе пътя на тунела на услугата до желаната крайна точка. Крайните точки на услугата ще обработват само TCP трафик. Това означава, че ако искате да тествате латентност или свързаност към крайна точка чрез крайни точки на услуги, инструменти като ping и tracert няма да покажат истинския път, по който ще поемат ресурсите в подмрежата.
За да достигнат до услугата Azure, NSG трябва да разрешат изходяща свързаност. Ако вашите NSG са отворени за целия изходящ интернет трафик, тогава трафикът на крайната точка на услугата трябва да работи. Можете също така да ограничите изходящия трафик до IP адреси на услуги само с помощта на маркерите на услугата.
Крайните точки на услугата могат да бъдат конфигурирани във виртуална мрежа независимо от потребител с достъп за запис във виртуалната мрежа. За да защити ресурсите на услугите на Azure към VNet, потребителят трябва да има разрешение Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action за подмрежите, които се добавят. Това разрешение е включено във вградената роля на администратор на услуга по подразбиране и може да бъде модифицирано чрез създаване на персонализирани роли. Научете повече за вградените роли и присвояването на конкретни разрешения на персонализирани роли.
Правилата за крайни точки на услугата на виртуална мрежа (VNet) ви позволяват да филтрирате трафика на виртуална мрежа към услуги на Azure , позволявайки само специфични ресурси на услугата Azure през крайните точки на услугата. Политиките за крайни точки осигуряват подробен контрол на достъпа от виртуалния мрежов трафик до услугите на Azure. Можете да научите повече за правилата за крайни точки на услугата тук.
Azure Active Directory (Azure AD) не поддържа първоначално крайни точки на услуга. Пълният списък на услугите на Azure, поддържащи крайни точки на VNet услуга, може да се види тук. Обърнете внимание, че етикетът „Microsoft.AzureActiveDirectory“, посочен под услуги, поддържащи крайни точки на услуги, се използва за поддръжка на крайни точки на услуги към ADLS Gen 1. За ADLS Gen 1 интеграцията на виртуална мрежа за Azure Data Lake Storage Gen1 използва сигурността на крайната точка на виртуалната мрежова услуга между вашата виртуална мрежа и Azure Active Directory (Azure AD), за да генерирате допълнителни искове за сигурност в маркера за достъп. След това тези твърдения се използват за удостоверяване на вашата виртуална мрежа към вашия акаунт Data Lake Storage Gen1 и разрешаване на достъп. Научете повече за VNet интеграцията на Azure Data Lake Store Gen 1
Няма ограничение за общия брой крайни точки на VNet услуга във виртуална мрежа. За ресурс на услуга на Azure (като акаунт за съхранение на Azure), услугите може да наложат ограничения върху броя на подмрежите, използвани за защита на ресурса. Следната таблица показва някои примерни ограничения:
Ограничения на услугите на Azure за VNet правила Azure Storage100Azure SQL128Azure Synapse Analytics128Azure KeyVault200Azure Cosmos DB64Azure Event Hub128Azure Service Bus128Azure Data Lake Store V1100Забележка
Ограниченията подлежат на промени по преценка на услугата Azure. Обърнете се към съответната сервизна документация за подробности за услугите.
PREV: Създаване на първи домейн контролер на Windows Server 2012 ...
NEXT: Разбиране на Active Directory в Windows Server 2012 R2 ...
![[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice](http://website-google-hk.oss-cn-hongkong.aliyuncs.com/drawing/26/2022-3-1/7051.jpeg "[Решен] Не може да се свърже с MySql сървър на localhost (10061) (Вижте темата) * Форум на общността на Apache OpenOffice")
