Konfigurowanie sieci VPN typu lokacja-lokacja za pośrednictwem komunikacji równorzędnej usługi ExpressRoute firmy Microsoft
Ten artykuł pomaga skonfigurować bezpieczną zaszyfrowaną łączność między siecią lokalną a sieciami wirtualnymi platformy Azure za pośrednictwem połączenia prywatnego usługi ExpressRoute. Za pomocą komunikacji równorzędnej firmy Microsoft można ustanowić tunel vpn IPsec/IKE typu lokacja-lokacja między wybranymi sieciami lokalnymi i sieciami wirtualnymi platformy Azure. Skonfigurowanie bezpiecznego tunelu za pośrednictwem usługi ExpressRoute umożliwia wymianę danych z poufnością, antyodtwarzaniem, autentycznością i integralnością.
Uwaga
Podczas konfigurowania sieci VPN typu lokacja-lokacja za pośrednictwem komunikacji równorzędnej firmy Microsoft są naliczane opłaty za bramę sieci VPN i ruch wychodzący sieci VPN. Aby uzyskać więcej informacji, zobacz Cennik usługi VPN Gateway.
Kroki i przykłady w tym artykule korzystają z modułów Az programu Azure PowerShell. Aby zainstalować moduły Az lokalnie na komputerze, zobacz Instalowanie programu Azure PowerShell. Aby dowiedzieć się więcej na temat nowego modułu Az, zobacz Wprowadzenie do nowego modułu Az programu Azure PowerShell. Polecenia cmdlet programu PowerShell są często aktualizowane. Jeśli nie używasz najnowszej wersji, wartości określone w instrukcjach mogą zakończyć się niepowodzeniem. Aby znaleźć zainstalowane wersje programu PowerShell w systemie, użyj Get-Module -ListAvailable Az polecenia cmdlet .
Architektura
W celu zapewnienia wysokiej dostępności i nadmiarowości można skonfigurować wiele tuneli w dwóch parach MSEE-PE obwodu usługi ExpressRoute i włączyć równoważenie obciążenia między tunelami.
Tunele sieci VPN za pośrednictwem komunikacji równorzędnej firmy Microsoft można zakończyć za pomocą bramy sieci VPN lub za pomocą odpowiedniego wirtualnego urządzenia sieciowego dostępnego w witrynie Azure Marketplace. Trasy można wymieniać statycznie lub dynamicznie za pośrednictwem zaszyfrowanych tuneli bez uwidaczniania wymiany tras do bazowej komunikacji równorzędnej firmy Microsoft. W przykładach w tym artykule protokół BGP (różni się od sesji BGP używanej do tworzenia komunikacji równorzędnej firmy Microsoft) jest używany do dynamicznej wymiany prefiksów za pośrednictwem zaszyfrowanych tuneli.
Ważne
Po stronie lokalnej zazwyczaj komunikacja równorzędna firmy Microsoft jest przerywana w strefie DMZ, a prywatna komunikacja równorzędna jest przerywana w podstawowej strefie sieciowej. Dwie strefy byłyby segregowane przy użyciu zapór. Jeśli konfigurujesz komunikację równorzędną firmy Microsoft wyłącznie pod kątem włączania bezpiecznego tunelowania za pośrednictwem usługi ExpressRoute, pamiętaj, aby filtrować tylko publiczne adresy IP, które są reklamowane za pośrednictwem komunikacji równorzędnej firmy Microsoft.
Przepływ pracy
- Skonfiguruj komunikację równorzędną firmy Microsoft dla obwodu usługi ExpressRoute.
- Anonsuj wybrane regionalne prefiksy publiczne platformy Azure do sieci lokalnej za pośrednictwem komunikacji równorzędnej firmy Microsoft.
- Konfigurowanie bramy sieci VPN i ustanawianie tuneli IPsec
- Skonfiguruj lokalne urządzenie sieci VPN.
- Utwórz połączenie IPsec/IKE typu lokacja-lokacja.
- (Opcjonalnie) Skonfiguruj zapory/filtrowanie na lokalnym urządzeniu sieci VPN.
- Przetestuj i zweryfikuj komunikację IPsec za pośrednictwem obwodu usługi ExpressRoute.
1. Konfigurowanie komunikacji równorzędnej firmy Microsoft
Aby skonfigurować połączenie sieci VPN typu lokacja-lokacja za pośrednictwem usługi ExpressRoute, należy użyć komunikacji równorzędnej firmy Microsoft usługi ExpressRoute.
Aby skonfigurować nowy obwód usługi ExpressRoute, zacznij od artykułu Wymagania wstępne usługi ExpressRoute, a następnie utwórz i zmodyfikuj obwód usługi ExpressRoute.
Jeśli masz już obwód usługi ExpressRoute, ale nie skonfigurowano komunikacji równorzędnej firmy Microsoft, skonfiguruj komunikację równorzędną firmy Microsoft przy użyciu artykułu Tworzenie i modyfikowanie komunikacji równorzędnej dla obwodu usługi ExpressRoute.
Po skonfigurowaniu obwodu i komunikacji równorzędnej firmy Microsoft można go łatwo wyświetlić przy użyciu strony Przegląd w witrynie Azure Portal.
2. Konfigurowanie filtrów tras
Filtr tras umożliwia zidentyfikowanie usług, które mają być używane za pośrednictwem komunikacji równorzędnej firmy Microsoft w ramach obwodu usługi ExpressRoute. Jest to zasadniczo lista dozwolonych wszystkich wartości społeczności protokołu BGP.
W tym przykładzie wdrożenie znajduje się tylko w regionie Azure West US 2 . Dodano regułę filtru tras, aby zezwolić tylko na anonsowanie prefiksów regionalnych zachodnie stany USA 2 platformy Azure, które mają wartość społeczności protokołu BGP 12076:51026. Należy określić regionalne prefiksy, które mają być dozwolone, wybierając pozycję Zarządzaj regułą.
W filtrze trasy należy również wybrać obwody usługi ExpressRoute, dla których ma zastosowanie filtr trasy. Możesz wybrać obwody usługi ExpressRoute, wybierając pozycję Dodaj obwód. Na poprzedniej ilustracji filtr trasy jest skojarzony z przykładowym obwodem usługi ExpressRoute.
2.1. Konfigurowanie filtru trasy
Konfigurowanie filtru tras. Aby uzyskać instrukcje, zobacz Konfigurowanie filtrów tras dla komunikacji równorzędnej firmy Microsoft.
2.2 Weryfikowanie tras protokołu BGP
Po pomyślnym utworzeniu komunikacji równorzędnej firmy Microsoft za pośrednictwem obwodu usługi ExpressRoute i skojarzeniu filtru trasy z obwodem można sprawdzić trasy protokołu BGP odebrane z przeglądarki Microsoft Enterprise Edge (MSEE) na urządzeniach PE, które są komunikacji równorzędnej z środowiskami MSEE. Polecenie weryfikacji różni się w zależności od systemu operacyjnego urządzeń PE.
Przykłady aplikacji Cisco
W tym przykładzie użyto polecenia Cisco IOS-XE. W tym przykładzie wystąpienie wirtualnego routingu i przekazywania (VRF) służy do izolowania ruchu komunikacji równorzędnej.
show ip bgp vpnv4 vrf 10 summary
Następujące częściowe dane wyjściowe pokazują, że 68 prefiksów zostało odebranych od sąsiada *.243.229.34 z numerem systemu autonomicznego (ASN) 12076 (MSEE):
...
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
X.243.229.34 4 12076 17671 17650 25228 0 0 1w4d 68
Aby wyświetlić listę prefiksów odebranych od sąsiada, użyj następującego przykładu:
sh ip bgp vpnv4 vrf 10 neighbors X.243.229.34 received-routes
Aby potwierdzić, że otrzymujesz poprawny zestaw prefiksów, możesz sprawdzić krzyżowo. Następujące dane wyjściowe polecenia programu Azure PowerShell zawierają prefiksy anonsowane za pośrednictwem komunikacji równorzędnej firmy Microsoft dla każdej z usług i dla każdego regionu świadczenia usługi Azure:
Get-AzBgpServiceCommunity
3. Konfigurowanie bramy sieci VPN i tuneli IPsec
W tej sekcji tunele sieci VPN protokołu IPsec są tworzone między bramą sieci VPN platformy Azure i lokalnym urządzeniem sieci VPN. W przykładach użyto urządzeń sieci VPN Cisco Cloud Service Router (CSR1000).
Na poniższym diagramie przedstawiono tunele sieci VPN IPsec ustanowione między lokalnym urządzeniem sieci VPN 1 i parą wystąpień bramy sieci VPN platformy Azure. Na diagramie nie przedstawiono dwóch tuneli sieci VPN protokołu IPsec ustanowionych między lokalnym urządzeniem sieci VPN 2 i parą wystąpień bramy sieci VPN platformy Azure. Szczegóły konfiguracji nie są wymienione. Jednak posiadanie większej liczby tuneli SIECI VPN zwiększa wysoką dostępność.
W ramach pary tunelu IPsec zostanie ustanowiona sesja protokołu eBGP w celu wymiany tras sieci prywatnej. Na poniższym diagramie przedstawiono sesję protokołu eBGP ustanowioną za pośrednictwem pary tunelu IPsec:
Na poniższym diagramie przedstawiono abstrakcyjne omówienie przykładowej sieci:
Przykłady szablonów usługi Azure Resource Manager — informacje
W przykładach brama sieci VPN i zakończenia tunelu IPsec są konfigurowane przy użyciu szablonu usługi Azure Resource Manager. Jeśli dopiero zaczynasz używać szablonów usługi Resource Manager lub poznasz podstawy szablonu usługi Resource Manager, zobacz Omówienie struktury i składni szablonów usługi Azure Resource Manager. Szablon w tej sekcji tworzy zielone pole środowiska platformy Azure (sieć wirtualna). Jeśli jednak masz istniejącą sieć wirtualną, możesz odwołać się do niej w szablonie. Jeśli nie znasz konfiguracji lokacja-lokacja bramy sieci VPN z protokołem IPsec/IKE, zobacz Tworzenie połączenia typu lokacja-lokacja.
Uwaga
Aby utworzyć tę konfigurację, nie trzeba używać szablonów usługi Azure Resource Manager. Tę konfigurację można utworzyć przy użyciu witryny Azure Portal lub programu PowerShell.
3.1 Deklarowanie zmiennych
W tym przykładzie deklaracje zmiennych odpowiadają przykładowej sieci. Podczas deklarowania zmiennych zmodyfikuj tę sekcję, aby odzwierciedlić środowisko.
- Zmienna localAddressPrefix to tablica lokalnych adresów IP do zakończenia tuneli IPsec.
- GatewaySku określa przepływność sieci VPN. Aby uzyskać więcej informacji na temat parametrów gatewaySku i vpnType, zobacz Ustawienia konfiguracji usługi VPN Gateway. Aby uzyskać informacje o cenach, zobacz Cennik usługi VPN Gateway.
- Ustaw wartość vpnType na RouteBased.
"variables": {
"virtualNetworkName": "SecureVNet", // Name of the Azure VNet
"azureVNetAddressPrefix": "10.2.0.0/24", // Address space assigned to the VNet
"subnetName": "Tenant", // subnet name in which tenants exists
"subnetPrefix": "10.2.0.0/25", // address space of the tenant subnet
"gatewaySubnetPrefix": "10.2.0.224/27", // address space of the gateway subnet
"localGatewayName": "localGW1", // name of remote gateway (on-premises)
"localGatewayIpAddress": "X.243.229.110", // public IP address of the on-premises VPN device
"localAddressPrefix": [
"172.16.0.1/32", // termination of IPsec tunnel-1 on-premises
"172.16.0.2/32" // termination of IPsec tunnel-2 on-premises
],
"gatewayPublicIPName1": "vpnGwVIP1", // Public address name of the first VPN gateway instance
"gatewayPublicIPName2": "vpnGwVIP2", // Public address name of the second VPN gateway instance
"gatewayName": "vpnGw", // Name of the Azure VPN gateway
"gatewaySku": "VpnGw1", // Azure VPN gateway SKU
"vpnType": "RouteBased", // type of VPN gateway
"sharedKey": "string", // shared secret needs to match with on-premises configuration
"asnVpnGateway": 65000, // BGP Autonomous System number assigned to the VPN Gateway
"asnRemote": 65010, // BGP Autonmous Syste number assigned to the on-premises device
"bgpPeeringAddress": "172.16.0.3", // IP address of the remote BGP peer on-premises
"connectionName": "vpn2local1",
"vnetID": "[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]",
"gatewaySubnetRef": "[concat(variables('vnetID'),'/subnets/','GatewaySubnet')]",
"subnetRef": "[concat(variables('vnetID'),'/subnets/',variables('subnetName'))]",
"api-version": "2017-06-01"
},
3.2 Tworzenie sieci wirtualnej (sieć wirtualna)
Jeśli kojarzysz istniejącą sieć wirtualną z tunelami sieci VPN, możesz pominąć ten krok.
{
"apiVersion": "[variables('api-version')]",
"type": "Microsoft.Network/virtualNetworks",
"name": "[variables('virtualNetworkName')]",
"location": "[resourceGroup().location]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('azureVNetAddressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]"
}
},
{
"name": "GatewaySubnet",
"properties": {
"addressPrefix": "[variables('gatewaySubnetPrefix')]"
}
}
]
},
"comments": "Create a Virtual Network with Subnet1 and Gatewaysubnet"
},
3.3 Przypisywanie publicznych adresów IP do wystąpień bramy sieci VPN
Przypisz publiczny adres IP dla każdego wystąpienia bramy sieci VPN.
{
"apiVersion": "[variables('api-version')]",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[variables('gatewayPublicIPName1')]",
"location": "[resourceGroup().location]",
"properties": {
"publicIPAllocationMethod": "Static"
},
"comments": "Public IP for the first instance of the VPN gateway"
},
{
"apiVersion": "[variables('api-version')]",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[variables('gatewayPublicIPName2')]",
"location": "[resourceGroup().location]",
"properties": {
"publicIPAllocationMethod": "Static"
},
"comments": "Public IP for the second instance of the VPN gateway"
},
3.4 Określ zakończenie tunelu sieci VPN w środowisku lokalnym (brama sieci lokalnej)
Lokalne urządzenia sieci VPN są określane jako brama sieci lokalnej. Poniższy fragment kodu json określa również szczegóły zdalnej komunikacji równorzędnej BGP:
{
"apiVersion": "[variables('api-version')]",
"type": "Microsoft.Network/localNetworkGateways",
"name": "[variables('localGatewayName')]",
"location": "[resourceGroup().location]",
"properties": {
"localNetworkAddressSpace": {
"addressPrefixes": "[variables('localAddressPrefix')]"
},
"gatewayIpAddress": "[variables('localGatewayIpAddress')]",
"bgpSettings": {
"asn": "[variables('asnRemote')]",
"bgpPeeringAddress": "[variables('bgpPeeringAddress')]",
"peerWeight": 0
}
},
"comments": "Local Network Gateway (referred to your on-premises location) with IP address of remote tunnel peering and IP address of remote BGP peer"
},
3.5 Tworzenie bramy sieci VPN
Ta sekcja szablonu umożliwia skonfigurowanie bramy sieci VPN z wymaganymi ustawieniami konfiguracji aktywne-aktywne. Należy pamiętać o następujących wymaganiach:
- Utwórz bramę sieci VPN z wartością "RouteBased" VpnType. To ustawienie jest obowiązkowe, jeśli chcesz włączyć routing protokołu BGP między bramą sieci VPN i lokalną siecią VPN.
- Aby ustanowić tunele sieci VPN między dwoma wystąpieniami bramy sieci VPN i danym urządzeniem lokalnym w trybie aktywny-aktywny, parametr "activeActive" jest ustawiony na wartość true w szablonie usługi Resource Manager. Aby dowiedzieć się więcej na temat bram sieci VPN o wysokiej dostępności, zobacz Łączność bramy sieci VPN o wysokiej dostępności.
- Aby skonfigurować sesje protokołu eBGP między tunelami sieci VPN, należy określić dwie różne sieci ASN po obu stronach. Zaleca się określenie prywatnych numerów ASN. Aby uzyskać więcej informacji, zobacz Omówienie bram protokołu BGP i bram sieci VPN platformy Azure.
{
"apiVersion": "[variables('api-version')]",
"type": "Microsoft.Network/virtualNetworkGateways",
"name": "[variables('gatewayName')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Network/publicIPAddresses/', variables('gatewayPublicIPName1'))]",
"[concat('Microsoft.Network/publicIPAddresses/', variables('gatewayPublicIPName2'))]",
"[concat('Microsoft.Network/virtualNetworks/', variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"properties": {
"privateIPAllocationMethod": "Static",
"subnet": {
"id": "[variables('gatewaySubnetRef')]"
},
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('gatewayPublicIPName1'))]"
}
},
"name": "vnetGtwConfig1"
},
{
"properties": {
"privateIPAllocationMethod": "Static",
"subnet": {
"id": "[variables('gatewaySubnetRef')]"
},
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('gatewayPublicIPName2'))]"
}
},
"name": "vnetGtwConfig2"
}
],
"sku": {
"name": "[variables('gatewaySku')]",
"tier": "[variables('gatewaySku')]"
},
"gatewayType": "Vpn",
"vpnType": "[variables('vpnType')]",
"enableBgp": true,
"activeActive": true,
"bgpSettings": {
"asn": "[variables('asnVpnGateway')]"
}
},
"comments": "VPN Gateway in active-active configuration with BGP support"
},
3.6 Ustanawianie tuneli IPsec
Ostateczna akcja skryptu tworzy tunele IPsec między bramą sieci VPN platformy Azure i lokalnym urządzeniem sieci VPN.
{
"apiVersion": "[variables('api-version')]",
"name": "[variables('connectionName')]",
"type": "Microsoft.Network/connections",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Network/virtualNetworkGateways/', variables('gatewayName'))]",
"[concat('Microsoft.Network/localNetworkGateways/', variables('localGatewayName'))]"
],
"properties": {
"virtualNetworkGateway1": {
"id": "[resourceId('Microsoft.Network/virtualNetworkGateways', variables('gatewayName'))]"
},
"localNetworkGateway2": {
"id": "[resourceId('Microsoft.Network/localNetworkGateways', variables('localGatewayName'))]"
},
"connectionType": "IPsec",
"routingWeight": 0,
"sharedKey": "[variables('sharedKey')]",
"enableBGP": "true"
},
"comments": "Create a Connection type site-to-site (IPsec) between the Azure VPN Gateway and the VPN device on-premises"
}
4. Konfigurowanie lokalnego urządzenia sieci VPN
Brama sieci VPN platformy Azure jest zgodna z wieloma urządzeniami sieci VPN od różnych dostawców. Aby uzyskać informacje o konfiguracji i urządzeniach zweryfikowanych do pracy z bramą sieci VPN, zobacz Informacje o urządzeniach sieci VPN.
Podczas konfigurowania urządzenia sieci VPN potrzebne są następujące elementy:
- Klucz wspólny. Ta wartość jest tym samym kluczem udostępnionym określonym podczas tworzenia połączenia sieci VPN typu lokacja-lokacja. W przykładach użyto podstawowego klucza wspólnego. Zalecamy, aby do użycia wygenerować bardziej złożony klucz.
- Publiczny adres IP bramy sieci VPN. Publiczny adres IP można wyświetlić za pomocą witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia. Aby znaleźć publiczny adres IP bramy sieci VPN przy użyciu witryny Azure Portal, przejdź do pozycji Bramy sieci wirtualnej, a następnie wybierz nazwę bramy.
Zazwyczaj równorzędne elementy równorzędne protokołu eBGP są bezpośrednio połączone (często za pośrednictwem połączenia sieci WAN). Jednak podczas konfigurowania protokołu eBGP za pośrednictwem tuneli sieci VPN protokołu IPsec za pośrednictwem komunikacji równorzędnej firmy Microsoft usługi ExpressRoute istnieje wiele domen routingu między elementami równorzędnymi eBGP. Użyj polecenia ebgp-multihop, aby ustanowić relację sąsiada eBGP między dwoma niezwiązanymi bezpośrednio elementami równorzędnymi. Liczba całkowita zgodna z poleceniem ebgp-multihop określa wartość czasu wygaśnięcia (TTL) w pakietach BGP. Polecenie maximum-paths ebigp 2 umożliwia równoważenie obciążenia ruchu między dwoma ścieżkami protokołu BGP.
Przykład aplikacji Cisco CSR1000
W poniższym przykładzie przedstawiono konfigurację aplikacji Cisco CSR1000 na maszynie wirtualnej funkcji Hyper-V jako lokalnego urządzenia sieci VPN:
!
crypto ikev2 proposal az-PROPOSAL
encryption aes-cbc-256 aes-cbc-128 3des
integrity sha1
group 2
!
crypto ikev2 policy az-POLICY
proposal az-PROPOSAL
!
crypto ikev2 keyring key-peer1
peer azvpn1
address 52.175.253.112
pre-shared-key secret*1234
!
!
crypto ikev2 keyring key-peer2
peer azvpn2
address 52.175.250.191
pre-shared-key secret*1234
!
!
!
crypto ikev2 profile az-PROFILE1
match address local interface GigabitEthernet1
match identity remote address 52.175.253.112 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local key-peer1
!
crypto ikev2 profile az-PROFILE2
match address local interface GigabitEthernet1
match identity remote address 52.175.250.191 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local key-peer2
!
crypto ikev2 dpd 10 2 on-demand
!
!
crypto ipsec transform-set az-IPSEC-PROPOSAL-SET esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile az-VTI1
set transform-set az-IPSEC-PROPOSAL-SET
set ikev2-profile az-PROFILE1
!
crypto ipsec profile az-VTI2
set transform-set az-IPSEC-PROPOSAL-SET
set ikev2-profile az-PROFILE2
!
!
interface Loopback0
ip address 172.16.0.3 255.255.255.255
!
interface Tunnel0
ip address 172.16.0.1 255.255.255.255
ip tcp adjust-mss 1350
tunnel source GigabitEthernet1
tunnel mode ipsec ipv4
tunnel destination 52.175.253.112
tunnel protection ipsec profile az-VTI1
!
interface Tunnel1
ip address 172.16.0.2 255.255.255.255
ip tcp adjust-mss 1350
tunnel source GigabitEthernet1
tunnel mode ipsec ipv4
tunnel destination 52.175.250.191
tunnel protection ipsec profile az-VTI2
!
interface GigabitEthernet1
description External interface
ip address x.243.229.110 255.255.255.252
negotiation auto
no mop enabled
no mop sysid
!
interface GigabitEthernet2
ip address 10.0.0.1 255.255.255.0
negotiation auto
no mop enabled
no mop sysid
!
router bgp 65010
bgp router-id interface Loopback0
bgp log-neighbor-changes
network 10.0.0.0 mask 255.255.255.0
network 10.1.10.0 mask 255.255.255.128
neighbor 10.2.0.228 remote-as 65000
neighbor 10.2.0.228 ebgp-multihop 5
neighbor 10.2.0.228 update-source Loopback0
neighbor 10.2.0.228 soft-reconfiguration inbound
neighbor 10.2.0.228 filter-list 10 out
neighbor 10.2.0.229 remote-as 65000
neighbor 10.2.0.229 ebgp-multihop 5
neighbor 10.2.0.229 update-source Loopback0
neighbor 10.2.0.229 soft-reconfiguration inbound
maximum-paths eibgp 2
!
ip route 0.0.0.0 0.0.0.0 10.1.10.1
ip route 10.2.0.228 255.255.255.255 Tunnel0
ip route 10.2.0.229 255.255.255.255 Tunnel1
!
5. Konfigurowanie filtrowania i zapór urządzeń sieci VPN (opcjonalnie)
Skonfiguruj zaporę i filtrowanie zgodnie z wymaganiami.
6. Testowanie i weryfikowanie tunelu IPsec
Stan tuneli IPsec można zweryfikować w bramie sieci VPN platformy Azure za pomocą poleceń programu PowerShell:
Get-AzVirtualNetworkGatewayConnection -Name vpn2local1 -ResourceGroupName myRG | Select-Object ConnectionStatus,EgressBytesTransferred,IngressBytesTransferred | fl
Przykładowe wyjście:
ConnectionStatus : Connected
EgressBytesTransferred : 17734660
IngressBytesTransferred : 10538211
Aby niezależnie sprawdzić stan tuneli w wystąpieniach bramy sieci VPN platformy Azure, użyj następującego przykładu:
Get-AzVirtualNetworkGatewayConnection -Name vpn2local1 -ResourceGroupName myRG | Select-Object -ExpandProperty TunnelConnectionStatus
Przykładowe wyjście:
Tunnel : vpn2local1_52.175.250.191
ConnectionStatus : Connected
IngressBytesTransferred : 4877438
EgressBytesTransferred : 8754071
LastConnectionEstablishedUtcTime : 11/04/2017 17:03:30
Tunnel : vpn2local1_52.175.253.112
ConnectionStatus : Connected
IngressBytesTransferred : 5660773
EgressBytesTransferred : 8980589
LastConnectionEstablishedUtcTime : 11/04/2017 17:03:13
Możesz również sprawdzić stan tunelu na lokalnym urządzeniu sieci VPN.
Przykład CSR1000 cisco:
show crypto session detail
show crypto ikev2 sa
show crypto ikev2 session detail
show crypto ipsec sa
Przykładowe wyjście:
csr1#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
R - IKE Auto Reconnect
Interface: Tunnel1
Profile: az-PROFILE2
Uptime: 00:52:46
Session status: UP-ACTIVE
Peer: 52.175.250.191 port 4500 fvrf: (none) ivrf: (none)
Phase1_id: 52.175.250.191
Desc: (none)
Session ID: 3
IKEv2 SA: local 10.1.10.50/4500 remote 52.175.250.191/4500 Active
Capabilities:DN connid:3 lifetime:23:07:14
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 279 drop 0 life (KB/Sec) 4607976/433
Outbound: #pkts enc'ed 164 drop 0 life (KB/Sec) 4607992/433
Interface: Tunnel0
Profile: az-PROFILE1
Uptime: 00:52:43
Session status: UP-ACTIVE
Peer: 52.175.253.112 port 4500 fvrf: (none) ivrf: (none)
Phase1_id: 52.175.253.112
Desc: (none)
Session ID: 2
IKEv2 SA: local 10.1.10.50/4500 remote 52.175.253.112/4500 Active
Capabilities:DN connid:2 lifetime:23:07:17
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 668 drop 0 life (KB/Sec) 4607926/437
Outbound: #pkts enc'ed 477 drop 0 life (KB/Sec) 4607953/437
Protokół liniowy w interfejsie wirtualnego tunelu (VTI) nie zmienia się na "w górę", dopóki nie zakończy się faza 2 IKE. Następujące polecenie weryfikuje skojarzenie zabezpieczeń:
csr1#show crypto ikev2 sa
IPv4 Crypto IKEv2 SA
Tunnel-id Local Remote fvrf/ivrf Status
2 10.1.10.50/4500 52.175.253.112/4500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA1, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/3277 sec
Tunnel-id Local Remote fvrf/ivrf Status
3 10.1.10.50/4500 52.175.250.191/4500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA1, Hash: SHA96, DH Grp:2, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/3280 sec
IPv6 Crypto IKEv2 SA
csr1#show crypto ipsec sa | inc encaps|decaps
#pkts encaps: 177, #pkts encrypt: 177, #pkts digest: 177
#pkts decaps: 296, #pkts decrypt: 296, #pkts verify: 296
#pkts encaps: 554, #pkts encrypt: 554, #pkts digest: 554
#pkts decaps: 746, #pkts decrypt: 746, #pkts verify: 746
Weryfikowanie kompleksowej łączności między siecią lokalną i siecią wirtualną platformy Azure
Jeśli tunele IPsec są skonfigurowane i trasy statyczne są poprawnie ustawione, powinno być możliwe wykonanie polecenia ping do adresu IP zdalnego elementu równorzędnego protokołu BGP:
csr1#ping 10.2.0.228
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.228, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/5 ms
#ping 10.2.0.229
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.229, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
Weryfikowanie sesji protokołu BGP za pośrednictwem protokołu IPsec
W bramie sieci VPN platformy Azure sprawdź stan elementu równorzędnego protokołu BGP:
Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName vpnGtw -ResourceGroupName SEA-C1-VPN-ER | ft
Przykładowe wyjście:
Asn ConnectedDuration LocalAddress MessagesReceived MessagesSent Neighbor RoutesReceived State
--- ----------------- ------------ ---------------- ------------ -------- -------------- -----
65010 00:57:19.9003584 10.2.0.228 68 72 172.16.0.10 2 Connected
65000 10.2.0.228 0 0 10.2.0.228 0 Unknown
65000 07:13:51.0109601 10.2.0.228 507 500 10.2.0.229 6 Connected
Aby sprawdzić listę prefiksów sieci odebranych za pośrednictwem protokołu eBGP z lokalnego koncentratora sieci VPN, możesz filtrować według atrybutu "Origin":
Get-AzVirtualNetworkGatewayLearnedRoute -VirtualNetworkGatewayName vpnGtw -ResourceGroupName myRG | Where-Object Origin -eq "EBgp" |ft
W przykładowych danych wyjściowych numer ASN 65010 jest numerem systemu autonomicznego BGP w lokalnej sieci VPN.
AsPath LocalAddress Network NextHop Origin SourcePeer Weight
------ ------------ ------- ------- ------ ---------- ------
65010 10.2.0.228 10.1.10.0/25 172.16.0.10 EBgp 172.16.0.10 32768
65010 10.2.0.228 10.0.0.0/24 172.16.0.10 EBgp 172.16.0.10 32768
Aby wyświetlić listę anonsowanych tras:
Get-AzVirtualNetworkGatewayAdvertisedRoute -VirtualNetworkGatewayName vpnGtw -ResourceGroupName myRG -Peer 10.2.0.228 | ft
Przykładowe wyjście:
AsPath LocalAddress Network NextHop Origin SourcePeer Weight
------ ------------ ------- ------- ------ ---------- ------
10.2.0.229 10.2.0.0/24 10.2.0.229 Igp 0
10.2.0.229 172.16.0.10/32 10.2.0.229 Igp 0
10.2.0.229 172.16.0.5/32 10.2.0.229 Igp 0
10.2.0.229 172.16.0.1/32 10.2.0.229 Igp 0
65010 10.2.0.229 10.1.10.0/25 10.2.0.229 Igp 0
65010 10.2.0.229 10.0.0.0/24 10.2.0.229 Igp 0
Przykład dla lokalnego CSR1000 Cisco:
csr1#show ip bgp neighbors 10.2.0.228 routes
BGP table version is 7, local router ID is 172.16.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.2.0.0/24 10.2.0.228 0 65000 i
r> 172.16.0.1/32 10.2.0.228 0 65000 i
r> 172.16.0.2/32 10.2.0.228 0 65000 i
r> 172.16.0.3/32 10.2.0.228 0 65000 i
Total number of prefixes 4
Listę sieci anonsowanych z lokalnego CSR1000 Cisco do bramy sieci VPN platformy Azure można wyświetlić przy użyciu następującego polecenia:
csr1#show ip bgp neighbors 10.2.0.228 advertised-routes
BGP table version is 7, local router ID is 172.16.0.10
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0/24 0.0.0.0 0 32768 i
*> 10.1.10.0/25 0.0.0.0 0 32768 i
Total number of prefixes 2