サポートエンジニアが Azure Networking をじっくりたっぷり語りつくす会

日本マイクロソフト株式会社
カスタマーサービス＆サポート
サポートエンジニア
宇田周平
サポートエンジニアが
Azure Networking を
じっくりたっぷり語りつくす会

About me
PS C:> Get-Profile -Name “Shuhei Uda” | Format-List
名前 : 宇田周平
職種 : サポートエンジニア
2015/12 – 現在
Azure (IaaS / Networking)
2013/06 – 2015/11
Windows (Hyper-V / RDS / Performance)

https://thinkit.co.jp/article/13243

• Azure Networking Overview
• Virtual Filtering Platform
• Load Balancer
========== (休憩) ==========
• Routing
• VPN
• ExpressRoute
本日のお品書き

• 最新の情報に基づいてお話しますが、将来的に動作が変わる可能性が
あります。
• 本セッションは L300 – 400 程度 (中～上級者向け) です。
• Azure とネットワークをある程度知っている前提でお話します。
• 質問は休憩時間やセッションの最後、もしくは Twitter で
@syuheiuda まで。
• スライドの右下に参考情報を載せていますので、詳細はリンク先を読
んでください。
本題に入る前に
参考リンク: https://www.syuheiuda.com

United States
United States
Canada
Mexico
Venezuela
Colombia
Peru
Bolivia
Brazil
Argentina
Atlanta Ocean
Algeria
Mali
Niger
Nigeria
Chad
Libya Egypt
Sudan
Ethiopia
Dr Congo
Angola
Zambia
Nambia
South
Africa
Greenland
Svalbard
Sweden
Norway
United
Kingdom
France
Poland
Ukraine
Turkey
Saudi
Arabia
Iran
Kazakistan
India
Russia
China
Myanmar
(Burma)
Indian Ocean
Indonesia
Australia
Pacific Ocean
Pacific Ocean
Data centerOwned capacity
Future capacity
Leased capacity
Edge site
Microsoft の Backbone Network

• Software WAN
• Subsea Cables
• Terrestrial Fiber
• National
Clouds
WAN backbone
• SmartNIC/FPGA
• SONiC
DC hardware
• Virtual Networks
• Load Balancing
• VPN Services
• Firewall
• DDoS Protection
• DNS and Traffic
Management
Services
Azure region ‘B’
Azure region ‘A’
• Internet Peering
• ExpressRoute
Edge and
ExpressRoute
• Acceleration
for applications
and content
CDN
CDN
Edge
ExpressRoute
Microsoft
WAN
• DC Networks
• Regional
Networks
• Optical
Modules
Intra-region
Regional
network
Regional
network
Regional
network
Regional
network
Internet
exchanges
Carrier
Cable
• E2E monitoring
(Network Watcher,
Network
Performance
Monitoring)
Last mile
Consumers
Enterprise,
SMB, mobile
Enterprise DC/
Corpnet
各リージョンは Microsoft WAN, RNG にぶら下がってい
ます

On-
Premises
Azure Networking の全体像
https://www.syuheiuda.com/?p=4296
Azure VNET 外
(Public IP)
Azure 外
Azure 基盤
Azure VNET
(Private IP)
Microsoft Peering
Private Peering
Internet
VPN (S2S / P2S)
Public IP

Azure データセンターの Public IP アドレスは、JSON 形式で公開されて
います。
• Azure IP Ranges and Service Tags – Public Cloud
https://www.microsoft.com/en-us/download/details.aspx?id=56519
• Azure IP Ranges and Service Tags – US Government Cloud
• Azure IP Ranges and Service Tags – Germany Cloud
• Azure IP Ranges and Service Tags – China Cloud
Azure リソースが使用している Public IP アドレス

{
"name": "AzureCloud.japaneast",
"id": "AzureCloud.japaneast",
"properties": {
"changeNumber": 18,
"region": "japaneast",
"platform": "Azure",
"systemService": "",
"addressPrefixes": [
"13.71.128.0/19",
"13.73.0.0/19",
"13.78.0.0/17",
"20.37.96.0/19",
"20.38.116.0/23",
"20.40.88.0/21",
"20.40.96.0/21",
"20.43.64.0/19",
"20.44.128.0/18",
リージョン単位、サービス単位で IP アドレスの内訳が
確認できます {
"name": "Storage.JapanEast",
"id": "Storage.JapanEast",
"properties": {
"changeNumber": 2,
"region": "japaneast",
"platform": "Azure",
"systemService": "AzureStorage",
"addressPrefixes": [
"13.73.8.16/28",
"13.73.8.32/28",
"20.38.116.0/23",
"23.98.57.64/26",
"40.115.169.32/28",
"40.115.175.16/28",
"40.115.175.32/28",
"40.115.227.80/28",
"40.115.229.16/28",

Detailes 欄に記載の通り、毎週チェックして反映を！

オンプレミスの Firewall 設定とかを自動化する際にご利用ください
• REST API
https://management.azure.com/subscriptions/{subscriptionId}/providers/Micros
oft.Network/locations/{location}/serviceTags?api-version=2019-06-01
• PowerShell
Get-AzNetworkServiceTag -Location JapanEast
• CLI
az network list-service-tags --location JapanEast
同等の情報が REST API 等でも提供されるようになりま
した
https://docs.microsoft.com/ja-jp/azure/virtual-network/security-overview#service-tags-in-on-premises

ちなみに、古いほう (xml 版) は 2020/06/30 廃止予定で
す

VNET
(オーバーレイ)
• Azure VNET には実体なんて存在しません。
(Azure VM と、物理サーバーの集合体にすぎません。)
• デフォルトゲートウェイもありません。
(あえて言うなら、物理サーバー上の VFP です。)
そもそも Azure VNET って？
Azure 基盤
(アンダーレイ)
192.0.2.2
10.0.0.5
VNET A
P
VM (OS) としては Azure を意識せず、
ルーティングテーブルにしたがって
(デフォルトゲートウェイに対して)
パケットを出しているだけ。
物理サーバー上の VFP のレイヤーで
宛先 IP アドレスなどに基づいて
ルーティングしてくれているだけ。

皆さん、VFP の論文は読んでますよね？
https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/#!publications

VFP を制すものは Azure Networking を制す！といっても過言ではありま
せん。
Azure の SDN は、Hyper-V の仮想スイッチ上の VFP によって成り立って
います。
VFP は Azure Networking の要

VFP は Azure の SDN を支える様々な機能が実装されています。
Azure の SDN で悩んだら、まずはパケットと VFP の気持ちになって考
えましょう。
VFP の担っている処理
Billing / Metric
NSG
Public IP / LB
Routing
P

Azure 基盤
VNET
192.0.2.1 192.0.2.2
10.0.0.4 10.0.0.5
VNET A
Src: 10.0.0.4
-> Dst: 10.0.0.5
Src: 192.0.2.1
-> Dst: 192.0.2.2
Src:10.0.0.4
-> Dst: 10.0.0.5
Src: 10.0.0.4
-> Dst: 10.0.0.5
Src: 192.0.2.1
-> Dst: 192.0.2.2
Src:10.0.0.4
-> Dst: 10.0.0.5
VM 間の通信
VNET (encap)
NAT (Public IP / LB)
ACLs (NSG)
NSG の送信規則に基づいて評価を行います
NAT の処理については後で説明するので省略
オーバーレイからのパケットをカプセル化し、
宛先 IP にある 10.0.0.5 の VM をホストしている
物理サーバーの PA (192.0.2.2) 宛に投げます
P

VNET
Azure 基盤
192.0.2.1 192.0.2.2
VNET A
Src: 10.0.0.4
-> Dst: 10.0.0.5
Src: 192.0.2.1
-> Dst: 192.0.2.2
Src:10.0.0.4
-> Dst: 10.0.0.5
Src: 10.0.0.4
-> Dst: 10.0.0.5
Src: 192.0.2.1
-> Dst: 192.0.2.2
Src:10.0.0.4
-> Dst: 10.0.0.5
10.0.0.4 10.0.0.5
VM 間の通信
VNET (decap)
ACLs (NSG)
NSG の受信規則に基づいて評価を行います
NAT の処理については後で説明するので省略
オーバーレイからのパケットのカプセルを解除
P

VNET
Azure 基盤
192.0.2.2
VNET A
Src: 203.0.113.4
-> Dst: 10.0.0.5
Src: 203.0.113.4
-> Dst: 13.78.x.xInternet
13.78.x.x
10.0.0.5
VNET (decap)
ACLs (NSG)
Public IP 宛の通信は Private IP に DNAT されます
(Dst を 13.78.x.x から 10.0.0.5 へ NAT)
NSG は DNAT 後のPrivate IP で評価されます
From Internet
P

VNET
Azure 基盤
192.0.2.2
VNET A
Src: 10.0.0.5
-> Dst: 203.0.113.4
Src: 13.78.x.x
-> Dst: 203.0.113.4Internet
13.78.x.x
10.0.0.5
VNET (encap)
ACLs (NSG)
戻りの通信は、逆に SNAT されて出ていきます
(Src を 10.0.0.5 から 13.78.x.x へ NAT)
NSG は SNAT 前のPrivate IP で評価されます
To Internet
P

• 2019/06/24発売
• Windows Server 2016/2019で搭載された
Microsoft SDN v2（a.k.a HNV v2）を徹底解説
• Windows Server における実装、実際の環境展開
とオペレーションをコマンドレットレベルで解説
• 既存ネットワークへの展開も含めた考慮点と
注意点も併せて紹介
• Microsoft Azure StackでのSDNの立ち位置も紹介
さっぱり分からん？そんな方におすすめの本があります！

Hardware LB では要件に見合わなかったため、
Azure 独自の Software LB を実装しています。
2013 年に公開された論文の設計時点で
• 1 つのパブリック IP あたり 100 Gbps 以上
• 複数のインスタンスで 1Tbps 以上にスケール可能
を前提としていたと明記されています。
Ananta の論文も、読んでますよね？
http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p207.pdf

• Ananta Manager
管理用コンポーネント
• Ananta Mux (Multi-plexer)
通信を振り分ける BGP ルーター
• Host Agent
VM が稼働する物理サーバー上で
decap や NAT を行うコンポーネント
SLB は 3 つのコンポーネントによって構成されています

VNET
Azure 基盤
192.0.2.2
VNET A
10.0.0.5
LB が通信を振り分ける流れ (行き)
Router
Internet
MUX
13.78.x.x
2. BGP で経路広報 Ananta
Manager
1. LB の設定を MUX と Host Agent に反映
P
3. 学習した経路に
基づきルーティング
4. ハッシュを計算し
振り分け先を決定
(Destination NAT)
P
5. カプセル化を実施
6. Host Agent にて
カプセル化を解除
P

VNET
Azure 基盤
192.0.2.2
VNET A
10.0.0.5
LB が通信を振り分ける流れ (戻り)
Router
Internet
MUX
13.78.x.x
Ananta
Manager
P
1. Host Agent にて
Source NAT を実施
2. 負荷軽減のために
MUX を介さず戻る

4 種類の Load Balancer
https://docs.microsoft.com/ja-jp/azure/load-balancer/load-balancer-overview#skus
Basic ALB Basic ILB Standard ALB Standard ILB
値段無償無償有償有償
バックエンドの台数 100 VM まで
(単一可用性セット)
100 VM まで
(単一可用性セット)
1000 VM まで
(複数可用性セット)
1000 VM まで
(複数可用性セット)
Availability Zone 未対応未対応対応 (Zone 冗長) 対応 (Zone 冗長)
ログ診断ログのみ未対応メトリックの機能で
詳細なログが確認可
メトリックの機能で
詳細なログが確認可
HA ポート
(全ポートの振り分け)
未対応未対応未対応対応
(NVA 構築時に活躍)
セキュリティ
(NSG の強制)
NSG なしの VM は
既定で許可状態
NSG なしの VM は
既定で許可状態
NSG で明示的に許可
するまでは疎通不可
NSG で明示的に許可
するまでは疎通不可
Internet 接続
(SNAT Port 割り当て)
単一 Public IP で提供
(Max 1024 Port /VM)
提供なし
(リージョン内の任意
の Public IP で提供)
複数 Public IP 使用可
(SNAT Port の調整可)
提供なし
(VM の Public IP か
ALB の紐づけが必要)
SLA なし (無償なので
返金するものがない)
なし (無償なので
返金するものがない)
ありあり

とても大事な SNAT の話 (Internet 接続時の割当 Port の
話)
Public IP がある場合
VM の Public IP で
SNAT されます
(64k Port)
外部 LB に紐づく場合
LB の Public IP で
SNAT されます
(Basic LB: 1024 Port
Standard LB: 調整可)
Public IP を持たず外部 LB にも紐づかない場合
任意の Public IP で SNAT されます
(Basic LB: 1024 Port
Standard LB: 提供なし)

apt install hping3 -y
hping3 -S -i u100 -p 65000 <xx.xx.xx.xx>
len=46 ip=xx.xx.xx.xx ttl=57 DF id=0 sport=65000 flags=SA seq=1011 win=29200 rtt=30.4 ms
^C
--- xx.xx.xx.xx hping statistic ---
21434 packets transmitted, 1024 packets received, 96% packet loss
round-trip min/avg/max = 3.5/9.2/32.9 ms
1024 セッションで Internet 宛の通信ができなくなりま
す

SNAT Port が枯渇した際のメトリックグラフ

# 既存の LB の設定を取得
$LB = Get-AzLoadBalancer -ResourceGroupName SNAT-Test -Name SNAT-Test-StandardLB
# OutboundRule で AllocatedOutboundPort 等のパラメーターを設定
Add-AzLoadBalancerOutboundRuleConfig -LoadBalancer $LB -Name OutboundRule `
-AllocatedOutboundPort 10000 -Protocol All -EnableTcpReset -IdleTimeoutInMinutes 4 `
-FrontendIpConfiguration $LB.FrontendIpConfigurations -BackendAddressPool `
$LB.BackendAddressPools[0]
# LoadBalancingRule による SNAT を無効化 (これを忘れるとエラーになるので注意)
$LB.LoadBalancingRules[0].DisableOutboundSNAT = $true
# 設定を保存
Set-AzLoadBalancer -LoadBalancer $LB
Standard LB なら、SNAT Port の割り当てを調整できま
す

質問あれば声かけてください
あと、お問い合わせや Twitter で絡んでるものの、リアルでお初な方がいたらご挨拶したいです。
休憩 (10 min)

VNET
• Azure VNET には実体なんて存在しません。
(Azure VM と、物理サーバーの集合体にすぎません。)
• デフォルトゲートウェイもありません。
(あえて言うなら、物理サーバー上の VFP です。)
そもそも Azure VNET って？(再掲)
Azure 基盤
192.0.2.2
10.0.0.5
VNET A
P
VM (OS) としては Azure を意識せず、
ルーティングテーブルにしたがって
(デフォルトゲートウェイに対して)
パケットを出しているだけ。
物理サーバー上の VFP のレイヤーで
宛先 IP アドレスなどに基づいて
ルーティングしてくれているだけ。

Azure では 2 つのルーティングを意識しましょう
Azure 基盤
VNET
192.0.2.1 192.0.2.2
10.0.0.4 10.0.0.5
VNET A
Azure 側のルーティング
• VNET, VNET Peering
• Service Endpoint
• VPN / ExpressRoute
• UDR
• etc…
OS 内のルーティング

VM に紐付く NIC で、[有効なルート] からルーティングテーブルが確認
できます。
Azure VNET (VM) は、既定の状態だとこんな感じ
https://docs.microsoft.com/ja-jp/azure/network-watcher/diagnose-vm-network-routing-problem#view-details-of-a-route

内部的には Azure 基盤向けのルートも含まれていたりします。
もうちょっと厳密にいえば
VNET
Azure 基盤
192.0.2.2
10.0.0.5
VNET A
Address Prefix Next Hop
0.0.0.0/0 Internet
VNET のアドレス空間 VNET
168.63.129.16/32 (DHCP Server, DNS resolver, etc…) Azure 基盤
169.254.169.254/32 (Instance Metadata Service) Azure 基盤

VNET Peering, S2S, P2S, ExpressRoute, Service Endpoint, UDR を構成する
と
さらに、Azure の各種ネットワーク機能を構成するとこ
んな感じ
VNET
Azure 基盤
192.0.2.2
10.0.0.5
VNET A
0.0.0.0/0 Internet
VNET のアドレス空間 VNET
168.63.129.16/32 (DHCP Server, DNS resolver, etc…) Azure 基盤
169.254.169.254/32 (Instance Metadata Service) Azure 基盤
Peering した VNET のアドレス空間 VNET Peering
Local Network Gateway に定義したアドレス空間 VPN Gateway
P2S VPN のクライアント用アドレス空間 VPN Gateway
BGP で受け取ったアドレス空間 VPN Gateway
Service Endpoint で接続したサービスのアドレス空間 Azure 基盤
UDR で定義したアドレス空間 UDR の NextHop

以下のような優先順位になっているはずです。
• VNET Local
• Longest Match (10.0.0.0/24 > 10.0.0.0/16 > 10.0.0.0/8 > 0.0.0.0/0)
(Longest Match で等価の場合)
• UDR
• BGP (ExpressRoute > VPN)
• System Route
経路の優先順位は？
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-udr-overview

Longest Match では等価ですが、UDR の方が優先されます。
例えば、強制トンネリングを UDR で打ち消した場合…
UDR で設定した 0.0.0.0/0 Internet
ExpressRoute (BGP) から受け取った 0.0.0.0/0 VPN Gateway
Azure 既定の 0.0.0.0/0 Internet
Provider Edge
(PE)
OnPremisesProviderAzure
Edge Router
(MSEE)
VNET
Gateway
ExpressRoute
Internet
UDR

Longest Match で等価な場合でも、ExpressRoute の方が優先されます。
ExpressRoute と S2S VPN で同一拠点と冗長接続した場
合…
Provider Edge
(PE)
Edge Router
(MSEE)
VNET
Gateway
ExpressRoute
S2S VPN
S2S VPN (BGP) から受け取った 172.16.0.0/24 VPN Gateway

Longest Match で S2S VPN 側が勝つように経路広報しましょう。
あえて S2S VPN を優先させたい場合…
Provider Edge
(PE)
Edge Router
(MSEE)
VNET
Gateway
ExpressRoute
S2S VPN

マルチ NIC 構成の場合は、オーバーレイ側のルーティ
ングにも注意
Azure 基盤
VNET
192.0.2.1 192.0.2.2
10.0.0.4 (Primary)
10.0.1.4 (Seconday) 10.0.0.5
VNET A
10.0.0.0/24
10.0.1.0/24
OS 内のルーティング
(既定の状態)
• Destination -> Interface
• 0.0.0.0/0 -> 10.0.0.4
• 10.0.0.0/24 -> 10.0.0.4
• 10.0.1.0/24 -> 10.0.1.4
10.0.0.5 から 10.0.1.4 に通信が来ても、
10.0.1.4 側からは戻せるルートがない。
Azure 側のルーティング
Azure VNET としてはサブネット間は
適宜ルーティングしてくれる状態の為
特に気にする必要はない。
P

オンプレミスと Azure の接続方法 (おさらい)
Azure VNET 外
(Public IP)
Azure 外
Azure 基盤
Azure VNET
(Private IP)
Microsoft Peering
Private Peering
Internet
VPN (S2S / P2S)
Public IP
On-
Premises

基本的に IKEv2 (Route Based) 対応機器での構成が推奨。
IKEv1 のみ対応の機器を使ってる場合は、リプレースしたほうが吉。
サイト対サイト接続 (S2S VPN) のおさらい
https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways
IKEv1 (Policy Based) IKEv2 (Route Based)
接続拠点数 1 拠点のみ最大 30 拠点
帯域幅 100 Mbps (Basic SKU のみ) 最大 1.25 Gbps (VpnGw3 SKU 利用時)
P2S VPN との共存未対応対応
ExpressRoute との共存未対応対応
Active / Active 構成未対応対応
BGP 未対応対応
ゾーン冗長未対応対応 (VpnGw1, 2, 3 SKU 利用時)

未検証デバイスの場合、
• サンプルコンフィグがない
• 接続できない
• 接続できても安定しない
などのトラブルに見舞われることが多々。
自力でデバッグや対処できる人以外は
検証済みデバイスにリプレースが吉。
Azure として検証済みの機器、ファームウェアを使いま
しょう
https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpn-devices

S2S VPN の繋ぎ方あれこれ
https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-highlyavailable

Cisco / Juniper / FortiGate くらい揃ってますよね？
あと、固定 IP も複数もってますよね？
みなさん、検証機お持ちですよね？

一般のご家庭でも、Act / Act + BGP で相互接続検証でき
ます

VPN Gateway 作成時 Act / Act にチェックし、BGP の AS 番号を設定する
と、
Public IP を 2 つ持った状態でデプロイされます。
Act / Act + BGP の構成方法 (1. VPN Gateway の作成)

構成画面に、VPN Gateway の BGP Peer IP が 2 つ表示されています。
(後ほど、オンプレミス側の構成時に使用)
Act / Act + BGP の構成方法 (2. BGP Peer IP の確認)

ローカルネットワークゲートウェイをオンプレミスの VPN デバイスの
台数だけ作成します。
この際、[アドレス空間] はオンプレミスのアドレス空間 (172.16.0.0/16
等) ではなく、
VPN デバイスの BGP Peer IP を /32 で設定します。
Act / Act + BGP の構成方法 (3. Local Gateway の作成)

接続リソースを作成する際も、BGP の有効化を忘れずに。
Act / Act + BGP の構成方法 (4. Connection の作成)

ここまでで Azure 側の構成は完了です

Act / Act + BGP の構成方法 (5. VPN デバイスの設定)
オンプレミスの VPN デバイスから、VPN Gateway の 2 つの Public IP に
接続します

# BGP を喋る loopback Interface を作成
config system interface
edit "BGPloopback"
set vdom "root"
set ip 172.16.255.254 255.255.255.255
set type loopback
next
Act / Act + BGP の構成方法 (5. VPN デバイスの設定)
# 自身の AS を 65521、Azure 側の AS を 65516 に設定
config router bgp
set as 65521
set network-import-check disable
config neighbor
edit "10.0.255.4"
set ebgp-enforce-multihop enable
set next-hop-self enable
set soft-reconfiguration enable
set remote-as 65516
set update-source "BGPloopback"
next
edit "10.0.255.5"
set ebgp-enforce-multihop enable
set next-hop-self enable
set soft-reconfiguration enable
set remote-as 65516
set update-source "BGPloopback"
next
end
config network
edit 1
set prefix 172.16.0.0 255.255.0.0
next
end
VPN デバイスで BGP 設定を行います。
• 自身の AS 番号を設定
• Peer の IP や AS 番号を設定
• eBGP Multihop を有効化
• オンプレミスから経路を広報

Azure 側は KeepaliveTimer が 60 秒、HoldTimer が 180 秒となっていま
す。
もっと早く経路を切り替えたい場合は、オンプレミス側で調整してくだ
さい。
【余談】 BGP の Timer の話
FG100E # get router info bgp neighbors
BGP neighbor is 10.0.255.4, remote AS 65516, local AS 65521, external link
BGP version 4, remote router ID 10.0.255.4
BGP state = Established, up for 00:00:10
Last read 00:00:08, hold time is 180, keepalive interval is 60 seconds //実際に採用された値
Configured hold time is 180, keepalive interval is 60 seconds //設定値 (未設定なので FortiGate の規定値)
Neighbor capabilities:
Route refresh: advertised and received (new)
Address family IPv4 Unicast: advertised and received
Address family IPv6 Unicast: advertised and received
Received 41770 messages, 0 notifications, 0 in queue
Sent 41829 messages, 16 notifications, 0 in queue
Route refresh request: received 0, sent 0
Minimum time between advertisement runs is 30 seconds
Update source is BGPloopback

完成

診断設定の画面からどうぞ。
実は VPN Gateway の診断ログが取れます

サポートに問い合わせる前に、TunnelDiagnosticLog を確認しましょう。
• DPD timed out: Dead Peer Detection にオンプレミス側が応答しな
かった。
• RemotelyTriggered: オンプレミス側の機器から要求があった。
=> これらの場合、オンプレミス側が疑わしい。
【事象 1】正常に接続されていた VPN が突然切断され
た

IKEDiagnosticLog を確認し、Phase1 (Main Mode), Phase2 (Quick Mode)
のどの処理で問題が発生しているかを確認しましょう。
くわえて、オンプレミス側の VPN デバイスでも IKE のデバッグログを
確認しましょう。
(双方でログを確認するのが大事！)
【事象 2】 VPN 接続しようとしたら、そもそもうまく
繋がらない

• IKE のバージョン (v1 / v2) の不一致
• 事前共有キー (PSK) の不一致
• 暗号化・ハッシュアルゴリズムの不一致
• Traffic Selector の不一致
つまり、オンプレミス側の VPN デバイスのコンフィグに何らかの誤りが
あるために、
Azure VPN Gateway がサポートするパラメーターと一致していない場合
が多数。
(詳細はドキュメント参照)
VPN 接続がうまくいかない場合のチェックポイント
https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpn-devices#ipsec

IKEv2 での S2S VPN の接続フロー (概要)
INFORMATIONAL
INFORMATIONAL

IKEv2 での S2S VPN の接続フロー (SA_INIT)
SA_INIT
iCookie: 0xXXXXX, rCookie: 0x0,
AES-CBC-256 SHA1 Dh2,
3DES SHA1 Dh2,
AES-CBC-256 SHA256 Dh2
SA_INIT
iCookie: 0xXXXXX, rCookie: 0xYYYYY,
AES-CBC-256 SHA1 Dh2
Initiator が、自身の対応する Policy
(暗号化・ハッシュアルゴリズム等)を
複数提示します。
Responder は、提示されたものから
自身が対応できるものを 1 つ採用し、
応答を返します。
対応する Policy がない場合には、
Policy Mismatch のエラーを返します。

(Azure が対応しない Policy を提示された場合)
[RECEIVED][SA_INIT] Received SA INIT iCookie 0xBB55EA3EE69D3264 and rCookie 0x3161AA0707EE371D
[RECEIVED]Received Ike payload: Policy1:Cipher=DESSHA1 Integrity=SHA1 DhGroup=DhGroup2
[SEND][NOTIFY] Sending Notify Message - Policy Mismatch
(DhGroup がおかしい場合)
[RECEIVED][SA_INIT] Received SA INIT iCookie 0x4299DB80E926DDCD and rCookie 0xB1BACDD817A0972
[RECEIVED]Received Ike payload: Policy1:Cipher=AES-CBC-256 SHA1 Integrity=SHA1 DhGroup=Unknown
Policy2:Cipher=3DES SHA1 Integrity=SHA1 DhGroup=Unknown Policy3:Cipher=AES-CBC-256 SHA256
Integrity=SHA256 DhGroup=Unknown
[SEND][NOTIFY] Sending Notify Message - Policy Mismatch
Policy Mismatch の時のログ (抜粋)

IKEv2 での S2S VPN の接続フロー (SA_AUTH)
Traffic Selector は、VPN トンネル内に
どのアドレス同士の通信を許可するか
という設定。
Azure としては Any (0.0.0.0/0) のため、
オンプレミス側が TS を絞っていると、
Mismatch が発生して、エラーになる。

SA の有効期限が切れるタイミングで鍵の更新 (rekey) が行われますが、
プロトコルの解釈や実装の違いでうまくネゴシエーションできないこと
があります。
(オンプレミス側の機器が、何らかの理由で rekey を受け入れない場合な
ど)
【事象 3】数時間おきに VPN が切断される
そろそろ鍵の更新しよう？
SA_INIT (新しく接続しよう？)
沈黙
オンプレミス側がなぜ応答しないかは
デバイスベンダーまでお問い合わせを。

VPN Gateway のメンテナンスが行われると、Active / Standby が入れ替
わり、
再度 SA_INIT から接続を試みます。その際に、オンプレミス側の VPN デ
バイスが
古い SA を使いまわそうとして、再接続が完了しない場合があります。
【事象 4】 VPN Gateway のメンテナンス後に再接続さ
れない
SA_INIT (新しく SA を作って接続しようよ)
沈黙 or 拒否 (古い SA を使いたいな)
オンプレミス側での調査や対処方法は、
デバイスベンダーまでお問い合わせを。
SA_INIT (新しく SA を作って接続しようよ)
沈黙 or 拒否 (古い SA を使いたいな)

2 系統の冗長化された回線と、3 種類の Peering で構成される閉域接続
です。
• Private Peering
• Public Peering
• Microsoft Peering
ExpressRoute のおさらい
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-circuit-peerings

• 2014 年 02 月: Azure 日本リージョン提供開始
• 2014 年下旬: 国内で ExpressRoute 提供開始
• 2016 年 04 月: クラシック環境から ARM 環境への移行機能を提供開
始
• 2016 年 10 月: Basic SKU の Gateway 新設終了 (可用性担保のため)
• 2017 年 03 月: クラシック環境での ExpressRoute 新設終了
• 2017 年 08 月: 新設した Microsoft Peering でルートフィルター適用が
必須に
• 2018 年 04 月: Public Peering の新設終了 (Microsoft Peering へ統合)
ExpressRoute の歴史
https://blogs.technet.microsoft.com/jpaztech/2016/04/14/move-expressroute-to-arm/
https://blogs.technet.microsoft.com/jpaztech/2016/12/08/expressroute-basic-gateway-eol/
https://blogs.technet.microsoft.com/jpaztech/2017/02/02/announcement-about-expressroute-deployment-model/
https://docs.microsoft.com/ja-jp/azure/expressroute/how-to-routefilter-powershell
https://blogs.technet.microsoft.com/jpaztech/2018/03/02/expressroute-announcement-march-2018/

サポートの中の人は、いつ頃作成された、どのパターンに該当する
ExpressRoute かを踏まえてお問い合わせに対応しています。
• 未だにクラシック環境のままの ExpressRoute 回線
-> ごく稀に見かけます。そろそろ ARM 環境に移行しませんか･･･？
• Public Peering が残っている ExpressRoute 回線
(Microsoft Peering を 2017 年 08 月より前に構築した ExpressRoute 回
線)
-> Microsoft Peering にルートフィルターが未適応の状態であっても、
Office 365 の全経路が広報されています。(Azure の経路は未広報)
• Microsoft Peering を 2017 年 08 月以降に構築した ExpressRoute 回線
-> ルートフィルター未適応では Azure / Office 365 の経路が広報され
ません。
こういった経緯があり、実は様々な ExpressRoute が存
在します

NAT する箇所が違うため、Storage や SQL の Firewall 設定に注意が必要
です。
• Public Peering: MSEE で SNAT を実施。
• Microsoft Peering: PE で SNAT を実施。
Public Peering と Microsoft Peering の細かな違い
Provider Edge
(PE)
On-PremisesProvider
Public Peering 経由
Edge Router
(MSEE)
Microsoft Peering 経由
Edge Router
(MSEE)
Microsoft Peering は PE 側で NAT しています。
(セッション数が多い場合など、NAT IP を増強可能)
Public Peering は MSEE 側で NAT しています。
(ExpressRoute 回線毎に一意な 2 つの Public IP を使用)

Private Peering につなぐと NIC の [有効なルート] で、10.20.88.xx が表示
されます。
【余談】 ExpressRoute につなぐと、Next Hop に見知ら
ぬ IP が

負荷軽減のため、VM から Gateway を介さず MSEE へルーティングされ
ています。
先の 10.20.88.xx は、この影響によるものなので、無視してください。
ExpressRoute も LB と同様に非対称ルーティングです
Azure On-Premises
VNET1 10.0.0.0/16
VNET
Gateway
Edge Router
(MSEE)
Provider Edge
(PE)
Provider

Azure -> On-Premises 方向は、優先度を下げたい側に AS-Path を追加し
て、
遠回りに見せる (AS-Path Prepend) ことで制御可能です。(MED は未サ
ポート。)
On-Premises -> Azure 方向は、オンプレミス側でよしなに対応ください。
【よくある質問 1.】 ExpressRoute の片系に通信を寄せ
たい
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-optimize-routing
Azure (Japan West)
Vnet2 10.1.0.0/16
VNET
Gateway
On-Premises
(Osaka)
Provider
(Osaka)
Provider Edge
(PE)
MSEE
(Osaka)
172.16.0.0/16 (AS-Path: 65521, 65521)
172.16.0.0/16 (AS-Path: 65521)

Basic SKU 以外の Gateway を利用すれば、共存構成が可能です。
Longest Match で等価な経路を持つ場合には、ExpressRoute 側が優先。
【よくある質問 2.】 ExpressRoute と S2S VPN で冗長化
したい
https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-howto-coexist-resource-manager
Azure (Japan East)
On-Premises
(Tokyo)
Vnet1 10.0.0.0/16
Provider
(Tokyo)
Provider Edge
(PE)
VNET
Gateway
MSEE
(Tokyo)
VNET
Gateway
On-Premises
(Osaka)
Internet

東京・大阪で ExpressRoute を用意し、東日本・西日本の VNET に接続が
可能。
(ExpressRoute と VNET Gateway の接続をメッシュで 4 つ作成すれば
OK。 )
【よくある質問 3.】 ExpressRoute 自体も冗長化したい
https://blogs.technet.microsoft.com/jpaztech/2018/11/20/expressroute-deep-dive-part4/
Azure (Japan East)
On-Premises
(Tokyo)
Vnet1 10.0.0.0/16
Provider
(Tokyo)
Provider Edge
(PE)
VNET
Gateway
MSEE
(Tokyo)
Azure (Japan West)
Vnet2 10.1.0.0/16
VNET
Gateway
On-Premises
(Osaka)
Provider
(Osaka)
Provider Edge
(PE)
MSEE
(Osaka)

(注意点)
往路と復路で経路が異なる非対称ルーティングとなっている場合には、
経路上で NAT や ACL で制御をしていると、通信できない場合があるの
で要注意。
(対処策)
複数の ExpressRoute 回線がある場合、以下の方法で経路制御できます。
• AS-Path Prepend
• Longest Match
• 接続リソースの重みづけ
【よくある質問 3.】 ExpressRoute 自体も冗長化したい
(Cont’d)
https://docs.microsoft.com/ja-jp/azure/expressroute/designing-for-disaster-recovery-with-expressroute-privatepeering

• 2019/06/24発売
• Windows Server 2016/2019で搭載された
Microsoft SDN v2（a.k.a HNV v2）を徹底解説
• Windows Server における実装、実際の環境展開
とオペレーションをコマンドレットレベルで解説
• 既存ネットワークへの展開も含めた考慮点と
注意点も併せて紹介
• Microsoft Azure StackでのSDNの立ち位置も紹介
そろそろ忘れた頃だと思うので再掲。是非お買い求めを。

• VFP と契約して、パケットの気持ちになってよ！
(パケットの気持ちになれない時は、Azure サポートへ。)
• 本日のセッションは、NAWA Channel で配信されます。
https://www.youtube.com/channel/UCixN3wDYC3QRsmtfiBRETBQ
• その他の細かな情報は、公式・非公式ブログをどうぞ。
http://aka.ms/jpaztech (https://blogs.technet.Microsoft.com/jpaztech/)
https://www.syuheiuda.com/
まとめ

サポートエンジニアが Azure Networking をじっくりたっぷり語りつくす会

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to サポートエンジニアが Azure Networking をじっくりたっぷり語りつくす会

Similar to サポートエンジニアが Azure Networking をじっくりたっぷり語りつくす会 (20)

Recently uploaded

Recently uploaded (10)