Azure ExpressRouteプライベート接続で痛い目を見た

はじめに

AzureとオンプレミスをExpressRouteのプライベート接続で通信検証を実施した際に、オンプレミスと通信ができなかった事象が発生しました。
そこで何が原因であるかを紐解いてたどり着いた話を書いております。

前提

以下のリソースは設定済みとしております。
【Azure】
・ExpressRoute回線
・仮想ネットワークゲートウェイ
・接続

構成

・VNet1：172.16.0.0/16
・VNet2：10.0.0.0/24
・オンプレミス：17.16.50.0/24

何があったか

まず大前提としてネットワーク重複していることはわかった上で検証していました。
オンプレミスとの通信はルーティングのロンゲストマッチで問題ないであろう、という固定概念ですね。

この構成でオンプレミスのサーバーからAzure VMにping疎通できませんでした。
Azure VMからオンプレミスのサーバ宛ても当然疎通できません。

まず通信に影響が出そうな箇所を確認してみます。

• オンプレミスのサーバ側のルート情報は問題なし（デフォルトルートのNext-hopはL3SW）
• NW機器とExpressRoute間のBGPネイバーも問題なし
• NW機器側のルートテーブルにもAzure VNetのルートがあるので問題なし
• Azureへオンプレミスのルート広報も問題なし
• ネットワークセキュリテグループも制限していないので問題なし

どこまでping疎通できているかわからない。
ということで、Azure VM側でtcpdumpを打って確認してみました。

root@DEVLINUX:~# tcpdump src host 10.0.0.5 | grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:16:30.468597 IP devlinux.internal.cloudapp.net > 172.16.50.10: ICMP echo reply, id 6220, seq 1, length 64
07:16:31.468175 IP devlinux.internal.cloudapp.net > 172.16.50.10: ICMP echo reply, id 6220, seq 2, length 64
07:16:32.468155 IP devlinux.internal.cloudapp.net > 172.16.50.10: ICMP echo reply, id 6220, seq 3, length 64
07:16:33.468032 IP devlinux.internal.cloudapp.net > 172.16.50.10: ICMP echo reply, id 6220, seq 4, length 64
07:16:34.467977 IP devlinux.internal.cloudapp.net > 172.16.50.10: ICMP echo reply, id 6220, seq 5, length 64

echo replyは返しているのに、オンプレミスのサーバには返されていない・・・
一応、VNetピアリングを削除してみました。ここは関係ないよな・・・

ぎゃー！！ping通った！！

結論

答えはココにありました。

注意
仮想ネットワーク、仮想ネットワークのピアリング、または仮想ネットワーク サービス エンドポイントに関連したトラフィックに使用されるシステム ルートは、BGP のルートの方が具体的であったとしても、優先されるルートとなります。

AzureではBGPで広報された具体的なルート情報があってもVNetピアリング側を優先するとのことです。
重複したネットワークでもルーティングのロンゲストマッチングでオンプレミス側に通信できるだろうと甘い考えで検証をした結果、痛い目を見ました。

AWSの挙動は？

AWSの場合はロンゲストマッチとなったルートが参照されるみたいです。
そのため、VPCピアリング接続しているVPCとDirectConnect接続の場合は今回の事象は発生しなかったということですね。

仮想プライベートゲートウェイを VPC にアタッチし、サブネットルートテーブルでルート伝達を有効にしている場合は、Site-to-Site VPN 接続を表すルートが伝達済みルートとしてルートテーブルに自動的に表示されます。伝達されたルートが静的ルートと重複し、最長プレフィクス一致を適用できない場合、伝達されたルートよりも静的ルートが優先されます。

回避方法の模索

一応、回避できるか方法を探ってみました。
カスタムルートテーブルを作成して、ユーザ定義でオンプレミスのルートをオーバーライドしてしまう方法をまず思い浮かんだ。
ドキュメントを参照してみると・・・

[仮想ネットワーク ゲートウェイ] :特定のアドレス プレフィックス宛てのトラフィックを仮想ネットワーク ゲートウェイにルーティングする場合に指定します。 種類が VPN の仮想ネットワーク ゲートウェイを作成する必要があります。 ExpressRoute では、カスタム ルートに BGP を使用する必要があるため、種類が ExpressRoute として作成された仮想ネットワーク ゲートウェイをユーザー定義ルートで指定することはできません。

はい、ダメでした。
ExpressRouteで使用の仮想ネットワークゲートウェイは、ユーザー定義ルートで指定できません。
ちなみにですが、ユーザ定義でオンプレミスのルートを仮想ネットワークゲートウェイに向けた設定を入れてみましたが、通信できませんでした。

AWSでもAzureでもネットワーク重複しないのが一番ということですね。（当たり前）