Azure'da merkez-uç ağ topolojisi uygulamaImplement a hub-spoke network topology in Azure

Bu başvuru mimarisinde, Azure'da bir merkez-uç ağ topolojisinin nasıl uygulanacağı gösterilmektedir.This reference architecture shows how to implement a hub-spoke topology in Azure. Merkez, şirket içi ağınıza yönelik merkezi bir bağlantı noktası görevini gören Azure’daki bir sanal ağdır (VNet).The hub is a virtual network (VNet) in Azure that acts as a central point of connectivity to your on-premises network. Uçlar ise merkezle eşlenen sanal ağlardır ve iş yüklerini yalıtmak için kullanılabilirler.The spokes are VNets that peer with the hub, and can be used to isolate workloads. Şirket içi veri merkezi ile merkez arasındaki trafik akışı bir ExpressRoute veya VPN ağ geçidi bağlantısı üzerinden gerçekleşir.Traffic flows between the on-premises datacenter and the hub through an ExpressRoute or VPN gateway connection. Bu çözümü dağıtın.Deploy this solution.

00

Bu mimarinin bir Visio dosyasını indirinDownload a Visio file of this architecture

Bu topolojinin yararları şunlardır:The benefits of this topology include:

  • Maliyet tasarrufu: Ağ sanal gereçleri (NVA) ve DNS sunucuları gibi birden çok iş yükü tarafından paylaşılabilen hizmetler tek bir konumda merkezi hale getirilerek tasarruf sağlanır.Cost savings by centralizing services that can be shared by multiple workloads, such as network virtual appliances (NVAs) and DNS servers, in a single location.
  • Abonelik sınırlarını aşma: Farklı aboneliklere ait sanal ağlar merkeze eşlenerek sınırlar aşılabilir.Overcome subscriptions limits by peering VNets from different subscriptions to the central hub.
  • İşlerin ayrılması: Merkezi BT (SecOps, InfraOps) ve iş yüklerini (DevOps) ilgilendiren konular ayrılır.Separation of concerns between central IT (SecOps, InfraOps) and workloads (DevOps).

Bu mimarinin tipik kullanımları şunlardır:Typical uses for this architecture include:

  • Geliştirme, test ve üretim gibi farklı ortamlarda dağıtılan ve DNS, IDS, NTP veya AD DS gibi paylaşılan hizmetlere gerek duyan iş yükleri.Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Paylaşılan hizmetler merkezi sanal ağa yerleştirilir. Her bir ortam ise bir uca dağıtılarak yalıtım sağlanır.Shared services are placed in the hub VNet, while each environment is deployed to a spoke to maintain isolation.
  • Birbirlerine bağlı olmaları gerekmeyen ancak paylaşılan hizmetlere erişmeleri gereken iş yükleri.Workloads that do not require connectivity to each other, but require access to shared services.
  • Güvenlik konuları üzerinde merkezi denetime (merkezdeki bir güvenlik duvarı ile elde edilen bir DMZ gibi) ve her bir uçtaki iş yüklerinin ayrılmış bir şekilde yönetilmesine gerek duyan kurumlar.Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.

MimariArchitecture

Mimari aşağıdaki bileşenlerden oluşur.The architecture consists of the following components.

  • Şirket içi ağı.On-premises network. Bir kuruluşun içinde çalışan özel bir yerel ağ.A private local-area network running within an organization.

  • VPN cihazı.VPN device. Şirket içi ağa dış bağlantı sağlayan bir cihaz veya hizmet.A device or service that provides external connectivity to the on-premises network. VPN cihazı, bir donanım cihazı veya Windows Server 2012’deki Yönlendirme ve Uzaktan Erişim Hizmeti (RRAS) gibi bir yazılım çözümü olabilir.The VPN device may be a hardware device, or a software solution such as the Routing and Remote Access Service (RRAS) in Windows Server 2012. Desteklenen VPN gereçlerinin listesini görmek ve Azure'a bağlanmak için belirli VPN gereçlerini yapılandırma hakkında bilgi edinmek istiyorsanız bkz. Siteden siteye VPN Gateway bağlantıları için VPN cihazları hakkında.For a list of supported VPN appliances and information on configuring selected VPN appliances for connecting to Azure, see About VPN devices for Site-to-Site VPN Gateway connections.

  • VPN sanal ağ geçidi veya ExpressRoute ağ geçidi.VPN virtual network gateway or ExpressRoute gateway. Sanal ağ geçidi, sanal ağın şirket içi ağınız ile bağlantı için kullanılan VPN cihazına veya ExpressRoute bağlantı hattına bağlanmasına olanak sağlar.The virtual network gateway enables the VNet to connect to the VPN device, or ExpressRoute circuit, used for connectivity with your on-premises network. Daha fazla bilgi için bkz. Şirket içi bir ağı Microsoft Azure sanal ağına bağlama.For more information, see Connect an on-premises network to a Microsoft Azure virtual network.

Not

Bu başvuru mimarisine ait dağıtım betikleri, bağlantı için bir VPN ağ geçidi ve şirket içi ağınızın benzetimini yapmak için Azure’daki bir sanal ağı kullanmaktadır.The deployment scripts for this reference architecture use a VPN gateway for connectivity, and a VNet in Azure to simulate your on-premises network.

  • Merkezi sanal ağ.Hub VNet. Merkez-uç topolojisinde merkez olarak kullanılan Azure sanal ağı.Azure VNet used as the hub in the hub-spoke topology. Merkez, şirket içi ağınıza bağlantı için merkezi noktadır. Uç sanal ağlarında barındırılan farklı iş yükleri tarafından kullanılabilecek hizmetler burada barındırılır.The hub is the central point of connectivity to your on-premises network, and a place to host services that can be consumed by the different workloads hosted in the spoke VNets.

  • Ağ geçidi alt ağı.Gateway subnet. Sanal ağ geçitleri aynı alt ağda tutulur.The virtual network gateways are held in the same subnet.

  • Uç sanal ağları.Spoke VNets. Merkez-uç topolojisinde uç olarak kullanılan bir veya daha fazla Azure sanal ağı.One or more Azure VNets that are used as spokes in the hub-spoke topology. Uçlar, iş yüklerini diğer uçlardan ayrı olarak yönetilen kendi sanal ağlarında yalıtmak için kullanılabilir.Spokes can be used to isolate workloads in their own VNets, managed separately from other spokes. Her iş yükü birden fazla katman içerebilir. Birden fazla alt ağ, Azure yük dengeleyicileri aracılığıyla birbirine bağlanır.Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers. Uygulama altyapısı hakkında daha fazla bilgi için bkz. Windows VM iş yüklerini çalıştırma ve Linux VM iş yüklerini çalıştırma.For more information about the application infrastructure, see Running Windows VM workloads and Running Linux VM workloads.

  • Sanal ağ eşlemesi.VNet peering. İki sanal ağ kullanılarak bağlanabilir bir eşleme bağlantısı.Two VNets can be connected using a peering connection. Eşleme bağlantıları, sanal ağlar arasındaki geçişsiz ve gecikme süresi düşük bağlantılardır.Peering connections are non-transitive, low latency connections between VNets. Sanal ağlar, eşlendikten sonra bir yönlendiriciye gerek kalmadan Azure omurgasını kullanarak aralarında bir trafik oluşturabilir.Once peered, the VNets exchange traffic by using the Azure backbone, without the need for a router. Merkez-uç ağ topolojisinde her ucu merkeze bağlamak için sanal ağ eşlemesi kullanılır.In a hub-spoke network topology, you use VNet peering to connect the hub to each spoke. Aynı bölgede ya da farklı bölgelerdeki sanal ağları eşleyebilirsiniz.You can peer virtual networks in the same region, or different regions. Daha fazla bilgi için gereksinimler ve kısıtlamalar.For more information, see Requirements and constraints.

Not

Bu makalede yalnızca Resource Manager dağıtımlarından bahsedilmektedir. Ancak, aynı abonelikte klasik bir sanal ağı Resource Manager sanal ağına bağlamak da mümkündür.This article only covers Resource Manager deployments, but you can also connect a classic VNet to a Resource Manager VNet in the same subscription. Bu sayede, uçlarınız klasik dağıtımlar barındırıp aynı zamanda merkezde paylaşılan hizmetlerden de yararlanabilir.That way, your spokes can host classic deployments and still benefit from services shared in the hub.

ÖnerilerRecommendations

Aşağıdaki öneriler çoğu senaryo için geçerlidir.The following recommendations apply for most scenarios. Bu önerileri geçersiz kılan belirli bir gereksiniminiz olmadığı sürece izlemeniz önerilir.Follow these recommendations unless you have a specific requirement that overrides them.

Kaynak gruplarıResource groups

Merkez sanal ağa ve her bir uç sanal ağı, farklı kaynak gruplarında ve hatta farklı Aboneliklerde uygulanabilir.The hub VNet, and each spoke VNet, can be implemented in different resource groups, and even different subscriptions. Farklı Aboneliklerdeki sanal ağları eşleyebilme, aynı veya farklı Azure Active Directory kiracısı ile ilişkilendirilmesi iki abonelik de olabilir.When you peer virtual networks in different subscriptions, both subscriptions can be associated to the same or different Azure Active Directory tenant. Böylece, merkez sanal ağda tutulan hizmetler paylaşılırken iş yükleri merkezi olmayan bir şekilde yönetilebilir.This allows for a decentralized management of each workload, while sharing services maintained in the hub VNet.

VNet ve GatewaySubnetVNet and GatewaySubnet

GatewaySubnet adlı ve /27 adres aralığına sahip bir alt ağ oluşturun.Create a subnet named GatewaySubnet, with an address range of /27. Bu alt ağ, sanal ağ geçidi için gereklidir.This subnet is required by the virtual network gateway. Bu alt ağa 32 adres ayrılması, ileride ağ geçidi boyutu sınırlamaları yaşanmasını önleyecektir.Allocating 32 addresses to this subnet will help to prevent reaching gateway size limitations in the future.

Ağ geçidini ayarlama hakkında daha fazla bilgi için bağlantınızın türüne bağlı olarak aşağıdaki başvuru mimarilerine bakın:For more information about setting up the gateway, see the following reference architectures, depending on your connection type:

Daha yüksek kullanılabilirlik elde etmek için yük devretmeye yönelik bir VPN ile birlikte ExpressRoute kullanabilirsiniz.For higher availability, you can use ExpressRoute plus a VPN for failover. Bkz. Şirket içi bir ağı ExpressRoute kullanarak VPN yük devretme özelliğiyle birlikte Azure’a bağlama.See Connect an on-premises network to Azure using ExpressRoute with VPN failover.

Merkez-uç topolojisi, şirket içi ağınızla bağlantıya gerek duymuyorsanız ağ geçidi olmadan da kullanılabilir.A hub-spoke topology can also be used without a gateway, if you don't need connectivity with your on-premises network.

VNet eşlemesiVNet peering

Sanal ağ eşlemesi, iki sanal ağ arasındaki geçişsiz bir ilişkidir.VNet peering is a non-transitive relationship between two VNets. Uçların birbirine bağlanmasına gerek duyuyorsanız bu uçlar arasında ayrı bir eşleme bağlantısı ekleyebilirsiniz.If you require spokes to connect to each other, consider adding a separate peering connection between those spokes.

Ancak, birbiriyle bağlanması gereken birçok ucunuz varsa sanal ağ başına sanal ağ eşlemeleri sayısındaki sınırlama nedeniyle kısa sürede kullanabileceğiniz eşleme bağlantısı kalmaz.However, if you have several spokes that need to connect with each other, you will run out of possible peering connections very quickly due to the limitation on number of VNets peerings per VNet. Bu senaryoda, Azure güvenlik duvarı veya merkez sanal ağda yönlendirici görevi gören bir NVA'ya gönderilmesini bir uç hedefleyen trafiği zorlamak için kullanıcı tanımlı yollar (Udr) kullanmayı düşünün.In this scenario, consider using user defined routes (UDRs) to force traffic destined to a spoke to be sent to Azure Firewall or an NVA acting as a router at the hub VNet. Bu sayede uçlar birbiriyle bağlantı kurabilir.This will allow the spokes to connect to each other.

Ayrıca uçları merkez sanal ağ geçidini kullanarak uzak ağlarla iletişim kuracak şekilde yapılandırabilirsiniz.You can also configure spokes to use the hub VNet gateway to communicate with remote networks. Ağ geçidi trafiğinin uçtan merkeze akıp uzak ağlara bağlanmasına olanak sağlamak için şunları yapmalısınız:To allow gateway traffic to flow from spoke to hub, and connect to remote networks, you must:

  • Merkezdeki sanal ağ eşleme bağlantısını ağ geçidi geçişine izin verecek şekilde yapılandırın.Configure the VNet peering connection in the hub to allow gateway transit.
  • Her uçtaki sanal ağ eşleme bağlantısını uzak ağ geçitlerini kullanacak şekilde yapılandırın.Configure the VNet peering connection in each spoke to use remote gateways.
  • Tüm sanal ağ eşleme bağlantılarını iletilen trafiğe izin verecek şekilde yapılandırın.Configure all VNet peering connections to allow forwarded traffic.

Dikkat edilmesi gerekenlerConsiderations

Uç bağlantısıSpoke connectivity

Uçlar arasında bağlantı gerekiyorsa, hub'ı Yönlendirme ve trafik hub'ına iletmek için uç Udr'ler kullanarak için Azure güvenlik duvarı veya bir NVA'ı dağıtmayı göz önünde bulundurun.If you require connectivity between spokes, consider deploying Azure Firewall or an NVA for routing in the hub, and using UDRs in the spoke to forward traffic to the hub. Dağıtım adımları, bu yapılandırmasını ayarlar isteğe bağlı bir adım içerir.The deployment steps below include an optional step that sets up this configuration.

22

Bu senaryoda eşleme bağlantılarını iletilen trafiğe izin verecek şekilde yapılandırmalısınız.In this scenario, you must configure the peering connections to allow forwarded traffic.

Ayrıca, merkezin daha çok sayıda uç için ölçeklendirilebileceğinden emin olmak için merkezde paylaşılan hizmetleri düşünün.Also consider what services are shared in the hub, to ensure the hub scales for a larger number of spokes. Örneğin, merkeziniz güvenlik duvarı hizmetleri sağlıyorsa birden fazla uç eklerken güvenlik duvarı çözümünüzün bant genişliği sınırlarını düşünün.For instance, if your hub provides firewall services, consider the bandwidth limits of your firewall solution when adding multiple spokes. Bu paylaşılan hizmetlerin bazılarını ikinci düzeyde bir grup merkeze taşımak isteyebilirsiniz.You might want to move some of these shared services to a second level of hubs.

Çözümü dağıtmaDeploy the solution

GitHub’da bu mimariye yönelik bir dağıtıma ulaşılabilir.A deployment for this architecture is available on GitHub. VM'ler, bağlantıyı test etmek için her bir sanal ağ kullanır.It uses VMs in each VNet to test connectivity. Merkez sanal ağdaki paylaşılan hizmetler alt ağında gerçekten barındırılan bir hizmet yoktur.There are no actual services hosted in the shared-services subnet in the hub VNet.

Dağıtım, aboneliğinizde aşağıdaki kaynak gruplarını oluşturur:The deployment creates the following resource groups in your subscription:

  • hub-vnet-rghub-vnet-rg
  • Şirket içi jb rgonprem-jb-rg
  • Şirket içi-vnet-rgonprem-vnet-rg
  • 1-vnet-rgspoke1-vnet-rg
  • spoke2 havalandırma rgspoke2-vent-rg

Şablon parametre dosyaları bu adlara işaret eder. Bunları değiştirirseniz parametre dosyalarını bunlarla eşleşecek şekilde güncelleştirin.The template parameter files refer to these names, so if you change them, update the parameter files to match.

ÖnkoşullarPrerequisites

  1. Başvuru mimarileri GitHub deposuna ait zip dosyasını kopyalayın, indirin veya bu dosya için bir çatal oluşturun.Clone, fork, or download the zip file for the reference architectures GitHub repository.

  2. Azure CLI 2.0'ı yükleyin.Install Azure CLI 2.0.

  3. Node ve NPM'yi yükleyin.Install Node and NPM

  4. Azure yapı taşları npm paketini yükleyin.Install the Azure building blocks npm package.

    npm install -g @mspnp/azure-building-blocks
    
  5. Komut isteminden, bash isteminden veya PowerShell isteminden Azure hesabınızda aşağıda gösterildiği gibi oturum açın:From a command prompt, bash prompt, or PowerShell prompt, sign into your Azure account as follows:

    az login
    

Simülasyonu yapılmış şirket içi veri merkezini dağıtmaDeploy the simulated on-premises datacenter

Simülasyonu yapılmış şirket içi veri merkezini bir Azure sanal ağı olarak dağıtmak için aşağıdaki adımları izleyin:To deploy the simulated on-premises datacenter as an Azure VNet, follow these steps:

  1. Gidin hybrid-networking/hub-spoke başvuru mimarileri depo klasörü.Navigate to the hybrid-networking/hub-spoke folder of the reference architectures repository.

  2. onprem.json dosyasını açın.Open the onprem.json file. Değerleri Değiştir adminUsername ve adminPassword.Replace the values for adminUsername and adminPassword.

    "adminUsername": "<user name>",
    "adminPassword": "<password>",
    
  3. (İsteğe bağlı) Bir Linux dağıtımı için ayarlanmış osType için Linux.(Optional) For a Linux deployment, set osType to Linux.

  4. Şu komutu çalıştırın:Run the following command:

    azbb -s <subscription_id> -g onprem-vnet-rg -l <location> -p onprem.json --deploy
    
  5. Dağıtımın bitmesini bekleyin.Wait for the deployment to finish. Bu dağıtım, bir sanal ağ, sanal makine ve bir VPN ağ geçidi oluşturur.This deployment creates a virtual network, a virtual machine, and a VPN gateway. VPN ağ geçidi oluşturmak yaklaşık 40 dakika sürebilir.It can take about 40 minutes to create the VPN gateway.

Merkez sanal ağa dağıtmaDeploy the hub VNet

Merkez sanal ağı dağıtmak için aşağıdaki adımları gerçekleştirin.To deploy the hub VNet, perform the following steps.

  1. hub-vnet.json dosyasını açın.Open the hub-vnet.json file. Değerleri Değiştir adminUsername ve adminPassword.Replace the values for adminUsername and adminPassword.

    "adminUsername": "<user name>",
    "adminPassword": "<password>",
    
  2. (İsteğe bağlı) Bir Linux dağıtımı için ayarlanmış osType için Linux.(Optional) For a Linux deployment, set osType to Linux.

  3. Her iki örneklerini Bul sharedKey ve VPN bağlantısı için paylaşılan bir anahtar girin.Find both instances of sharedKey and enter a shared key for the VPN connection. Değerler eşleşmelidir.The values must match.

    "sharedKey": "",
    
  4. Şu komutu çalıştırın:Run the following command:

    azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-vnet.json --deploy
    
  5. Dağıtımın bitmesini bekleyin.Wait for the deployment to finish. Bu dağıtım, bir sanal ağ, sanal makine, bir VPN ağ geçidi ve ağ geçidine bir bağlantı oluşturur.This deployment creates a virtual network, a virtual machine, a VPN gateway, and a connection to the gateway. VPN ağ geçidi oluşturmak yaklaşık 40 dakika sürebilir.It can take about 40 minutes to create the VPN gateway.

Merkez sanal ağa bağlantısını test — Windows DağıtımTest connectivity to the hub VNet — Windows deployment

Simülasyonu yapılmış şirket içi ortamdan merkez sanal ağa Windows Vm'leri kullanarak bağlanabilirliği test etmek için şu adımları izleyin:To test connectivity from the simulated on-premises environment to the hub VNet using Windows VMs, follow these steps:

  1. onprem-jb-rg kaynak grubunda jb-vm1 adlı bir sanal makine bulmak için Azure portalını kullanın.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Sanal makineye uzak masaüstü oturumu açmak için Connect öğesine tıklayın.Click Connect to open a remote desktop session to the VM. onprem.json parametre dosyasında belirttiğiniz parolayı kullanın.Use the password that you specified in the onprem.json parameter file.

  3. Bir PowerShell konsolu açın ve kullanmak Test-NetConnection cmdlet'ini merkez sanal ağdaki VM Sıçrama kutusu bağlanabildiğini doğrulayın.Open a PowerShell console in the VM, and use the Test-NetConnection cmdlet to verify that you can connect to the jumpbox VM in the hub VNet.

    Test-NetConnection 10.0.0.68 -CommonTCPPort RDP
    

Çıktı aşağıdakine benzer görünmelidir:The output should look similar to the following:

ComputerName     : 10.0.0.68
RemoteAddress    : 10.0.0.68
RemotePort       : 3389
InterfaceAlias   : Ethernet 2
SourceAddress    : 192.168.1.000
TcpTestSucceeded : True

Not

Varsayılan olarak, Windows Server Vm'lerinin ICMP yanıt Azure'da izin vermez.By default, Windows Server VMs do not allow ICMP responses in Azure. Kullanmak istiyorsanız ping bağlantısını test etmek için her VM için Windows Gelişmiş Güvenlik duvarında ICMP trafiğine etkinleştirmeniz gerekir.If you want to use ping to test connectivity, you need to enable ICMP traffic in the Windows Advanced Firewall for each VM.

Merkez sanal ağa bağlantısını test — Linux dağıtımıTest connectivity to the hub VNet — Linux deployment

Simülasyonu yapılmış şirket içi ortamdan merkez sanal ağa Linux Vm'leri kullanarak bağlanabilirliği test etmek için şu adımları izleyin:To test connectivity from the simulated on-premises environment to the hub VNet using Linux VMs, follow these steps:

  1. onprem-jb-rg kaynak grubunda jb-vm1 adlı bir sanal makine bulmak için Azure portalını kullanın.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Tıklayın Connect ve kopyalama ssh portalda gösterilen komutu.Click Connect and copy the ssh command shown in the portal.

  3. Bir Linux istemiyle çalıştırılabilen ssh simülasyonu yapılmış şirket içi ortama bağlanmak için.From a Linux prompt, run ssh to connect to the simulated on-premises environment. onprem.json parametre dosyasında belirttiğiniz parolayı kullanın.Use the password that you specified in the onprem.json parameter file.

  4. Kullanım ping merkez sanal ağda VM Sıçrama kutusu bağlanabilirliği test etmek için komut:Use the ping command to test connectivity to the jumpbox VM in the hub VNet:

    ping 10.0.0.68
    

Uç sanal ağlarını dağıtmaDeploy the spoke VNets

Uç sanal ağlarını dağıtmak için aşağıdaki adımları gerçekleştirin.To deploy the spoke VNets, perform the following steps.

  1. spoke1.json dosyasını açın.Open the spoke1.json file. Değerleri Değiştir adminUsername ve adminPassword.Replace the values for adminUsername and adminPassword.

    "adminUsername": "<user name>",
    "adminPassword": "<password>",
    
  2. (İsteğe bağlı) Bir Linux dağıtımı için ayarlanmış osType için Linux.(Optional) For a Linux deployment, set osType to Linux.

  3. Şu komutu çalıştırın:Run the following command:

    azbb -s <subscription_id> -g spoke1-vnet-rg -l <location> -p spoke1.json --deploy
    
  4. 1-2 için adımları yineleyin spoke2.json dosya.Repeat steps 1-2 for the spoke2.json file.

  5. Şu komutu çalıştırın:Run the following command:

    azbb -s <subscription_id> -g spoke2-vnet-rg -l <location> -p spoke2.json --deploy
    
  6. Şu komutu çalıştırın:Run the following command:

    azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-vnet-peering.json --deploy
    

Uç sanal ağlarını bağlantısını test — Windows DağıtımTest connectivity to the spoke VNets — Windows deployment

Simülasyonu yapılmış şirket içi ortamdan uç sanal ağlarını Windows Vm'leri kullanarak bağlanabilirliği test etmek için aşağıdaki adımları gerçekleştirin:To test connectivity from the simulated on-premises environment to the spoke VNets using Windows VMs, perform the following steps:

  1. onprem-jb-rg kaynak grubunda jb-vm1 adlı bir sanal makine bulmak için Azure portalını kullanın.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Sanal makineye uzak masaüstü oturumu açmak için Connect öğesine tıklayın.Click Connect to open a remote desktop session to the VM. onprem.json parametre dosyasında belirttiğiniz parolayı kullanın.Use the password that you specified in the onprem.json parameter file.

  3. Bir PowerShell konsolu açın ve kullanmak Test-NetConnection cmdlet'ini uç sanal ağlarını ağındaki Sıçrama kutusu Vm'leri bağlanabildiğini doğrulayın.Open a PowerShell console in the VM, and use the Test-NetConnection cmdlet to verify that you can connect to the jumpbox VMs in the spoke VNets.

    Test-NetConnection 10.1.0.68 -CommonTCPPort RDP
    Test-NetConnection 10.2.0.68 -CommonTCPPort RDP
    

Uç sanal ağlarını bağlantısını test — Linux dağıtımıTest connectivity to the spoke VNets — Linux deployment

Simülasyonu yapılmış şirket içi ortamdan uç sanal ağlarını Linux Vm'leri kullanarak bağlanabilirliği test etmek için aşağıdaki adımları gerçekleştirin:To test connectivity from the simulated on-premises environment to the spoke VNets using Linux VMs, perform the following steps:

  1. onprem-jb-rg kaynak grubunda jb-vm1 adlı bir sanal makine bulmak için Azure portalını kullanın.Use the Azure portal to find the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Tıklayın Connect ve kopyalama ssh portalda gösterilen komutu.Click Connect and copy the ssh command shown in the portal.

  3. Bir Linux istemiyle çalıştırılabilen ssh simülasyonu yapılmış şirket içi ortama bağlanmak için.From a Linux prompt, run ssh to connect to the simulated on-premises environment. onprem.json parametre dosyasında belirttiğiniz parolayı kullanın.Use the password that you specified in the onprem.json parameter file.

  4. Kullanım ping komutu her bir uçtaki Vm'lere Sıçrama kutusu bağlanabilirliği test etmek için:Use the ping command to test connectivity to the jumpbox VMs in each spoke:

    ping 10.1.0.68
    ping 10.2.0.68
    

Uçlar arasında bağlantı eklemeAdd connectivity between spokes

Bu adım isteğe bağlıdır.This step is optional. Uçların birbirine kullanmak istiyorsanız Azure Güvenlik Duvarı trafiği için başka bir uç bağlanmaya çalışırken uçlardan yönlendiriciye zorlamak için.If you want to allow spokes to connect to each other, use Azure Firewall to force traffic from spokes to the router when trying to connect to another spoke. Azure güvenlik duvarı dağıtmak için uç sanal ağları, bağlanmak, aşağıdaki adımları gerçekleştirmek için kullanıcı tanımlı yollar (Udr) iki izni birlikte:To deploy Azure Firewall, along with user-defined routes (UDRs) to allow the two spoke VNets to connect, perform the following steps:

  1. Bir alt ağ için Azure güvenlik duvarı merkez sanal ağa ekleyin.Add a subnet for Azure Firewall to the hub virtual network.

    az network vnet subnet create -g hub-vnet-rg --vnet-name hub-vnet -n AzureFirewallSubnet --address-prefixes 10.0.0.128/26
    
  2. Azure güvenlik duvarı dağıtın:Deploy Azure Firewall:

    az group deployment create -g hub-vnet-rg --template-file hub-firewall.json
    
  3. 2. adımda oluşturduğunuz Güvenlik Duvarı'nın Privateıpaddress almak için aşağıdaki komutu çalıştırın:Run the following command to get the privateIPAddress of the firewall created in step 2:

    az resource show -g hub-vnet-rg -n hub-firewall --resource-type Microsoft.Network/azureFirewalls --query properties.ipConfigurations[0].properties.privateIPAddress
    
  4. Hub güvenlik duvarı routes.json dosyasını düzenleyin ve tüm tekrarlamalarını <azure_firewall_private_ip> önceki komutta alınan IP adresine sahip.Edit the hub-firewall-routes.json file and replace all occurrences of <azure_firewall_private_ip> with the IP Address from the previous command. Hub güvenlik duvarı routes.json kaydedin ve ardından aşağıdaki komutu çalıştırın.Save hub-firewall-routes.json and then run the following command.

    azbb -s <subscription_id> -g hub-vnet-rg -l <location> -p hub-firewall-routes.json --deploy
    
  5. Uç alt ağlarla ilişkili rota tabloları için BGP yolu yayılmasını devre dışı bırakmak için aşağıdaki komutu çalıştırın:Run the following command to disable BGP route propagation for the route tables associated with the spoke subnets:

    az network route-table update -g hub-vnet-rg -n spoke1-rt --disable-bgp-route-propagation true
    az network route-table update -g hub-vnet-rg -n spoke2-rt --disable-bgp-route-propagation true
    

Bağlantıyı doğrulamak için aşağıdaki adımları gerçekleştirin:To verify connectivity, perform the following steps:

  1. Adlı bir sanal makine oturum jb-vm1 içinde onprem-jb-rg kaynak grubu.Log into the VM named jb-vm1 in the onprem-jb-rg resource group.

  2. Bu oturum açma oturumunda Sıçrama kutusu VM uç-1 için'oturum açın.From this login session, log into the jumpbox VM for spoke-1. Özel IP adresini 10.1.0.68 ' dir.The private IP address is 10.1.0.68.

  3. Kullanım Test-NetConnection cmdlet (Windows) veya ping uç 2 Sıçrama kutusu VM olduğu 10.2.0.68, bağlantıyı test etmek için (Linux) komutunu.Use the Test-NetConnection cmdlet (Windows) or ping command (Linux) to test connectivity to 10.2.0.68, which is the jumpbox VM for spoke-2.