Azure Route Server を利用することで BGP にて任意のアドレス空間をオンプレ側に広報できるようになります。
オンプレ側から Azure の PaaS へアクセスする方法としては以下のような方法があります。
- Internet 経由
- VPN 経由 (Private Endpoint)
- Azure Peering Service 経由
- ExpressRoute 経由 (Microsoft Peering)
- ExpressRoute 経由 (Private Peering + Private Endpoint)
- ExpressRoute 経由 (Private Peering + Route Server ［または VWAN］による経路の広報 )
6 点目の構成はあまり知られていない構成となり、実現可否も不明でしたので、以下のような構成にて実際に Linux にて NVA を構築し、デフォルトルート (0.0.0.0/0) を広報して検証した際の手順と結果を以下に記載します。
※デフォルトルートを広報する場合、サポートされていないサービス (代表例：Application Gateway) がありますので、事前にサポート状況を確認したほうが良いかもしれません。
1. ネットワーク環境の事前準備
以下の記事を参考に、VNet と ExpressRoute を接続し、Route Server をデプロイし、ブランチ間のトラフィックを許可しておきます。今回の構成では VPN Gateway の作成は不要です。
https://qiita.com/Isato-Hiyama/items/2a138cfc6019abf1d8ad
2. NVA のデプロイ
以下の公開ドキュメントを参考に Ubuntu で VM を作成します。
https://azure.microsoft.com/ja-jp/resources/templates/route-server-quagga/
以下のような構成でデプロイしました。サブネットについては NVA 用のサブネットを用意しました。
※ルーティングの検証用途のため、シングルかつスペック低めの構成としています。運用環境では NVA の可用性やパフォーマンス、サポート、SNAT ポート等を考慮したほうがよいです。
3. NVA の設定 (Azure)
3-1. IP 転送有効化
デプロイ後に NIC の IP 転送を有効化します。
3-2. ルートテーブルの適用
デフォルトルートを Route Server 経由で広報すると NVA から外部への接続も切断されてしまうため、以下のようなルートテーブルを NVA 用のサブネットに適用します。
3-3. NSG の受信規則追加
既定のルール 65000 にある VirtualNetwork to VirtualNetwork だと OCI 側からきた Ineternet 宛ての通信が拒否されるため、Virtual Network to Any の許可規則を受信規則に追加します。
上記の手順を実施してもうまくいかない場合、以下を参照するとうまくいくかもしれません。構成によっては NVA 内で SNAT の設定が必要です。
[ネットワーク仮想アプライアンス(NVA)経由で通信できない時のチェックポイント] (https://jpaztech1.z11.web.core.windows.net/ネットワーク仮想アプライアンス(NVA)経由で通信できない時のチェックポイント.html)
3-4. WebApps を作成し、NVA 用サブネットからサービスエンドポイントによるアクセスを許可 (オプション)
4. NVA の設定 (Quaaga)
VM にログインし、sudo -i で root ユーザーになります。
以下にある NVA 構築用テンプレート内のスクリプトの内容をコピペします。
https://github.com/Azure/azure-quickstart-templates/blob/master/quickstarts/microsoft.network/route-server-quagga/scripts/quaggadeploy.sh
アドレス空間、ASN、IP アドレスが異なるので Change と書いてある部分のみ修正します。
#!/bin/bash
## NOTE:
## before running the script, customize the values of variables suitable for your deployment.
## asn_quagga: Autonomous system number assigned to quagga
## bgp_routerId: IP address of quagga VM
## bgp_network1: first network advertised from quagga to the router server (inclusive of subnetmask)
## bgp_network2: second network advertised from quagga to the router server (inclusive of subnetmask)
## bgp_network3: third network advertised from quagga to the router server (inclusive of subnetmask)
## routeserver_IP1: first IP address of the router server
## routeserver_IP2: second IP address of the router server
#############Change#############
asn_quagga=65514
bgp_routerId=10.10.3.4
bgp_network1=0.0.0.0/0
routeserver_IP1=10.10.2.4
routeserver_IP2=10.10.2.5
################################
sudo apt-get -y update
## Install the Quagga routing daemon
echo "Installing quagga"
sudo apt-get -y install quagga
## run the updates and ensure the packages are up to date and there is no new version available for the packages
sudo apt-get -y update --fix-missing
## Enable IPv4 forwarding
echo "net.ipv4.conf.all.forwarding=1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.conf.default.forwarding=1" | sudo tee -a /etc/sysctl.conf
sysctl -p
## Create a folder for the quagga logs
echo "creating folder for quagga logs"
sudo mkdir -p /var/log/quagga && sudo chown quagga:quagga /var/log/quagga
sudo touch /var/log/zebra.log
sudo chown quagga:quagga /var/log/zebra.log
## Create the configuration files for Quagga daemon
echo "creating empty quagga config files"
sudo touch /etc/quagga/babeld.conf
sudo touch /etc/quagga/bgpd.conf
sudo touch /etc/quagga/isisd.conf
sudo touch /etc/quagga/ospf6d.conf
sudo touch /etc/quagga/ospfd.conf
sudo touch /etc/quagga/ripd.conf
sudo touch /etc/quagga/ripngd.conf
sudo touch /etc/quagga/vtysh.conf
sudo touch /etc/quagga/zebra.conf
## Change the ownership and permission for configuration files, under /etc/quagga folder
echo "assign to quagga user the ownership of config files"
sudo chown quagga:quagga /etc/quagga/babeld.conf && sudo chmod 640 /etc/quagga/babeld.conf
sudo chown quagga:quagga /etc/quagga/bgpd.conf && sudo chmod 640 /etc/quagga/bgpd.conf
sudo chown quagga:quagga /etc/quagga/isisd.conf && sudo chmod 640 /etc/quagga/isisd.conf
sudo chown quagga:quagga /etc/quagga/ospf6d.conf && sudo chmod 640 /etc/quagga/ospf6d.conf
sudo chown quagga:quagga /etc/quagga/ospfd.conf && sudo chmod 640 /etc/quagga/ospfd.conf
sudo chown quagga:quagga /etc/quagga/ripd.conf && sudo chmod 640 /etc/quagga/ripd.conf
sudo chown quagga:quagga /etc/quagga/ripngd.conf && sudo chmod 640 /etc/quagga/ripngd.conf
sudo chown quagga:quaggavty /etc/quagga/vtysh.conf && sudo chmod 660 /etc/quagga/vtysh.conf
sudo chown quagga:quagga /etc/quagga/zebra.conf && sudo chmod 640 /etc/quagga/zebra.conf
## initial startup configuration for Quagga daemons are required
echo "Setting up daemon startup config"
echo 'zebra=yes' > /etc/quagga/daemons
echo 'bgpd=yes' >> /etc/quagga/daemons
echo 'ospfd=no' >> /etc/quagga/daemons
echo 'ospf6d=no' >> /etc/quagga/daemons
echo 'ripd=no' >> /etc/quagga/daemons
echo 'ripngd=no' >> /etc/quagga/daemons
echo 'isisd=no' >> /etc/quagga/daemons
echo 'babeld=no' >> /etc/quagga/daemons
echo "add zebra config"
cat <<EOF > /etc/quagga/zebra.conf
!
interface eth0
!
interface lo
!
ip forwarding
!
line vty
!
EOF
echo "add quagga config"
cat <<EOF > /etc/quagga/bgpd.conf
!
router bgp $asn_quagga
bgp router-id $bgp_routerId
#############Change#############
network $bgp_network1
################################
neighbor $routeserver_IP1 remote-as 65515
neighbor $routeserver_IP1 soft-reconfiguration inbound
neighbor $routeserver_IP2 remote-as 65515
neighbor $routeserver_IP2 soft-reconfiguration inbound
!
address-family ipv6
exit-address-family
exit
!
line vty
!
EOF
## to start daemons at system startup
echo "enable zebra and quagga daemons at system startup"
systemctl enable zebra.service
systemctl enable bgpd.service
## run the daemons
echo "start zebra and quagga daemons"
systemctl start zebra
systemctl start bgpd
スクリプトに実行権限を付与して、実行します。エラーが出た場合、スクリプトに誤りがありますので確認します。
root@NVA1:~# chmod +x quaggadeploy.sh
root@NVA1:~# ./quaggadeploy.sh
5. Route Server とのピアリング
以下のような Azure CLI コマンドにて NVA と Route Server のピアリングを作成します。
az network routeserver peering create --routeserver RouteServer -g EREastUS --peer-ip "10.10.3.4" --peer-asn "65514" -n "NVA1"
6. BGP の確認
NVA にて以下を実施します。
Quaaga にログインします。
root@NVA1:~# vtysh
Hello, this is Quagga (version 1.2.4).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
BGP のネイバーが確立されていることを確認できます。
NVA1# show ip bgp summary
BGP router identifier 10.10.3.4, local AS number 65514
RIB entries 10, using 1120 bytes of memory
Peers 2, using 18 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.2.4 4 65515 96 90 0 0 0 01:19:35 5
10.10.2.5 4 65515 95 90 0 0 0 01:19:35 5
Total number of neighbors 2
Total num. Established sessions 2
Total num. of routes received 10
経路の状況確認します。
NVA1# show ip bgp
BGP table version is 0, local router ID is 10.10.3.4
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 0.0.0.0 0 32768 i
10.1.0.0/25 10.10.2.4 0 65515 i
10.10.2.5 0 65515 i
10.1.0.128/25 10.10.2.4 0 65515 i
10.10.2.5 0 65515 i
10.10.0.0/16 10.10.2.4 0 65515 i
10.10.2.5 0 65515 i
10.20.0.0/16 10.10.2.4 0 65515 65512 i
10.10.2.5 0 65515 65512 i
10.100.0.0/24 10.10.2.4 0 65515 12076 31898 i
10.10.2.5 0 65515 12076 31898 i
Displayed 6 out of 11 total prefixes
7. 動作確認
OCI 側から WebApps に接続できることを確認します。デフォルトルートを広報する前は Status 403 で拒否されていました。
[opc@oci-vm2 ~]$ curl -v http://ervpntestwebsite.azurewebsites.net
* About to connect() to ervpntestwebsite.azurewebsites.net port 80 (#0)
* Trying 20.49.104.54...
* Connected to ervpntestwebsite.azurewebsites.net (20.49.104.54) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: ervpntestwebsite.azurewebsites.net
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 3499
< Content-Type: text/html
< Last-Modified: Wed, 24 Nov 2021 01:10:30 GMT
< Accept-Ranges: bytes
< ETag: "cc65513d0e0d71:0"
< Server: Microsoft-IIS/10.0
< X-Powered-By: ASP.NET
< Set-Cookie: ARRAffinity=24410e45ca5e57f20082acb1c6e848971a37deecc97f93db2394281f8d4f09c7;Path=/;HttpOnly;Domain=ervpntestwebsite.azurewebsites.net
< Date: Wed, 24 Nov 2021 11:12:12 GMT
OCI 側から WebApps の IP へ traceroute を実行し、ER プライベートピアリングのプライマリサブネット (10.150.0.20/30) の IP アドレス "10.150.0.22" と NVA の IP アドレス "10.10.3.4" が表示されることを確認します。
[opc@oci-vm2 ~]$ traceroute 20.49.104.54
traceroute to 20.49.104.54 (20.49.104.54), 30 hops max, 60 byte packets
1 140.91.197.4 (140.91.197.4) 0.134 ms 140.91.196.118 (140.91.196.118) 0.100 ms 140.91.196.154 (140.91.196.154) 0.111 ms
2 10.150.0.22 (10.150.0.22) 0.510 ms 0.499 ms 0.461 ms
3 * * *
4 10.10.3.4 (10.10.3.4) 3.099 ms 3.037 ms 3.038 ms
5 * * *
NVA でのパケットキャプチャにて 上記の OCI 側からきた通信が NVA を経由してることを確認します。
11:12:13.085932 IP (tos 0x0, ttl 61, id 23841, offset 0, flags [DF], proto TCP (6), length 150)
10.100.0.221.40088 > 20.49.104.54.80: Flags [P.], cksum 0x4e4e (correct), seq 1:99, ack 1, win 490, options [nop,nop,TS val 2774476394 ecr 330607874], length 98: HTTP, length: 98
GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: ervpntestwebsite.azurewebsites.net
Accept: */*
11:12:13.085943 IP (tos 0x0, ttl 60, id 23840, offset 0, flags [DF], proto TCP (6), length 52)
10.100.0.221.40088 > 20.49.104.54.80: Flags [.], cksum 0xc67a (correct), seq 1, ack 1, win 490, options [nop,nop,TS val 2774476394 ecr 330607874], length 0
11:12:13.101699 IP (tos 0x0, ttl 127, id 174, offset 0, flags [none], proto TCP (6), length 3947)
20.49.104.54.80 > 10.100.0.221.40088: Flags [P.], cksum 0x9705 (incorrect -> 0xad77), seq 1:3896, ack 99, win 1026, options [nop,nop,TS val 330607892 ecr 2774476394], length 3895: HTTP, length: 3895
HTTP/1.1 200 OK
Content-Length: 3499
Content-Type: text/html
Last-Modified: Wed, 24 Nov 2021 01:10:30 GMT
Accept-Ranges: bytes
ETag: "cc65513d0e0d71:0"
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Set-Cookie: ARRAffinity=24410e45ca5e57f20082acb1c6e848971a37deecc97f93db2394281f8d4f09c7;Path=/;HttpOnly;Domain=ervpntestwebsite.azurewebsites.net
Date: Wed, 24 Nov 2021 11:12:12 GMT
OCI 側の有効なルートの確認方法がわからなかったので、以下のような構成で VNet をもう一つ ER に接続し有効なルートを確認してみました。
ちゃんと 0.0.0.0/0 が ExpressRoute 経由で広報されてました。
