はじめに
前回のエントリでは、Virtual WAN の基本的な動作とルーティングの優先順位を試しました。
Virtual WAN のルーティングと向き合う（基本的な動作とルーティングの優先順位編）
今回はルートテーブルを試します。
検証環境
前回と同様、東日本リージョンと西日本リージョンに Virtual Hub を用意して、それぞれの Virtual Hub に2つの VNet を接続します。また、オンプレとの経路のやり取りを再現するために、Ubuntu + Libreswan + frr な仮想マシンを用意して、両 Virtual Hub と BGP over S2S VPN で接続します。10.1と10.3で始まる経路が東日本、10.2と10.4で始まる経路が西日本、192.168で始まる経路がオンプレミスです。
検証環境のイメージ
1つの機器で複数のルートテーブルを持つ技術
ネットワーク機器には、1つの機器で複数の独立したルートテーブルを持つ機能があります。たとえば、Cisco ルータの VRF（Virtual Routing and Forwarding）や FortiGate の vdom（Virtual Domain）などです。この機能を使うことで、1つの機器を複数の用途で利用できます。例えば、通信キャリアの IP-VPN サービスにおいて1つの物理ルータ上に複数の顧客のネットワークを構築したり、企業内ネットワークに設置された複数のファイアウォールを1つに集約できたりします。1つの機器をマルチテナント用に利用できるわけです。
Virtual WAN にも同様の機能があります。初期状態では Default というルートテーブルを利用しますが、利用者は任意のルートテーブルを作成できます。
ルートテーブルの設定画面
Azure 内に閉じたマルチテナントな Virtual WAN
検証環境を利用して、Virtual WAN でマルチテナントの通信を実現します。イメージは次の通りです。第三オクテットが奇数同士の VNet だけが通信できるネットワークと、偶数同士の VNet だけが通信できるネットワークを作ります。
マルチテナント環境のイメージ
ルートテーブルの作成
4つの VNet を1つのルートテーブルに「関連付け」「伝達」すると、みんな仲良く経路を学習・広報するので、みんな仲良く通信できてしまいます。ですので、まずは奇数な VNet 用ネットワークを実現するルートテーブルと偶数な VNet 用ネットワークを実現するルートテーブルを作成します。ルートテーブルはハブ上のリソースになるので、各ハブに奇数用のルートテーブル「tenant1」と偶数用のルートテーブル「tenant2」を作成します。
ルートテーブルとの「関連付け」「伝達」
準備ができたので、各 VNet をルートテーブルに関連付け・伝達してきます。まずは東日本の2つの VNet を東日本の各テナント用のルートテーブルに関連付け・伝達します。
リージョン内の関連付けのイメージ
この状態でのルートテーブルは次の通りです。
東日本の je-vnet1
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jevnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.3.1.0/24} VnetLocal {} Active
{10.1.0.0/16} VNetPeering {} Active
{0.0.0.0/0} Internet {} Active
東日本のルートテーブル「tenant1」にルートを広報している VNet が自分自身だけのため、他の VNet のアドレス帯のルーティングが存在しません。
東日本の je-vnet2
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jevnet2vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.3.2.0/24} VnetLocal {} Active
{10.1.0.0/16} VNetPeering {} Active
{0.0.0.0/0} Internet {} Active
東日本のルートテーブル「tenant2」にルートを広報している VNet が自分自身だけのため、他の VNet のアドレス帯のルーティングが存在しません。
東日本 の Virtual Hub
デフォルト
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName defaultRouteTable
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjehub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjehub
asPath : 65147
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
addressPrefixes : {10.4.2.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
addressPrefixes : {10.3.2.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet2
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet2
asPath :
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath :
不思議なことに、東日本の VNet はデフォルトのルートテーブルに経路を広報していないにもかかわらず、そのアドレス帯のルーティングがデフォルトのルーティングテーブルに存在しています。これはデフォで設定されているラベルの影響です。ラベルとはルートテーブルをグループ化する機能です。ラベルに伝達すると、グルーピングされているルートテーブルに経路が広報されます。“default” のラベルは東日本と西日本の Virtual Hub に存在するデフォルトのルートテーブルをグルーピングしているため、“default” のラベルに伝達すると東西のデフォルトのルートテーブルに経路が注入されます。
各 VNet は独自のルートテーブルを使うことになっているので、デフォルトのルートテーブルに経路が存在していても問題はありません。ですが、気持悪いのも事実です。デフォルトのラベルへの伝達を止めれば、デフォルトのルートテーブルから経路も消えます。
ラベルへの伝達を止める設定
東日本 の Virtual Hub
デフォルト
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName defaultRouteTable
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjehub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjehub
asPath : 65147
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
addressPrefixes : {10.4.2.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
東日本の VNet のルーティングが消えました
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName tenant1
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath :
テナント1用ルートテーブルに紐づけた VNet のアドレスのみがルーティングとして存在します。
tenant2
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName tenant2
addressPrefixes : {10.3.2.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet2
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet2
asPath :
テナント2用ルートテーブルに紐づけた VNet のアドレスのみがルーティングとして存在します。
西日本の jw-vnet1
東日本の VNet がデフォルトのルートテーブルとデフォルトのラベルに経路を広報しなくなったので、デフォルトのルートテーブルを参照している西日本の仮想ネットワークからも東日本の VNet のアドレス帯のルーティングが消えます。
> Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jwvnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.4.1.0/24} VnetLocal {} Active
{10.2.0.0/16} VNetPeering {} Active
{10.4.2.0/24} VirtualNetworkGateway {20.210.174.1} Active
{192.168.1.0/26} VirtualNetworkGateway {10.2.0.13} Active
{192.168.1.0/26} VirtualNetworkGateway {10.2.0.12} Active
{0.0.0.0/0} Internet {} Active
西日本の jw-vnet2
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jwvnet2vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.4.2.0/24} VnetLocal {} Active
{10.2.0.0/16} VNetPeering {} Active
{10.4.1.0/24} VirtualNetworkGateway {20.210.174.1} Active
{192.168.1.0/26} VirtualNetworkGateway {10.2.0.13} Active
{192.168.1.0/26} VirtualNetworkGateway {10.2.0.12} Active
{0.0.0.0/0} Internet {} Active
西日本 の Virtual Hub
デフォルト
同様に、西日本の Virtual Hub のデフォルトのルートテーブルからも東日本の VNet のアドレス帯のルーティングが消えます。
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName defaultRouteTable
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath :
addressPrefixes : {10.4.2.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet2
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet2
asPath :
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjwhub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjwhub
asPath : 65147
西日本の両テナント用ルートテーブルにはまだどの VNet も経路を広報していないので、ルーティングは空です。
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName tenant1
tenant2
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName tenant2
ここまでの設定結果は次の通りです。東日本の VNet のみ東日本の Virtual Hub に存在する自分のテナント用ルートテーブルに関連付け・伝達しています。
ここまでの設定結果
同じ要領で西日本の2つの VNet も西日本の各テナント用のルートテーブルに関連付けます。
西日本含めた最終的な状態
そうすると次の箇所のルーティングが変わります。
東日本 の Virtual Hub
デフォルト
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName defaultRouteTable
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjehub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjehub
asPath : 65147
どの VNet もデフォルトのルートテーブルに経路を広報しなくなったので、東日本の Virtual Hub のルートテーブルには、自分自身の S2S ゲートウェイが BGP で学習するオンプレミスの経路のみが存在します。
西日本の je-vnet1
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jwvnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.4.1.0/24} VnetLocal {} Active
{10.2.0.0/16} VNetPeering {} Active
{0.0.0.0/0} Internet {} Active
西日本のルートテーブル「tenant1」にルートを広報している VNet が自分自身のみのため、他の VNet のアドレス帯のルーティングが存在しません。
西日本の je-vnet2
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jwvnet2vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.4.2.0/24} VnetLocal {} Active
{10.2.0.0/16} VNetPeering {} Active
{0.0.0.0/0} Internet {} Active
西日本のルートテーブル「tenant2」にルートを広報している VNet が自分自身のみのため、他の VNet のアドレス帯のルーティングが存在しません。
西日本 の Virtual Hub
デフォルト
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName defaultRouteTable
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjwhub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjwhub
asPath : 65147
どの VNet もデフォルトのルートテーブルに経路を広報しなくなったので、西日本の Virtual Hub のルートテーブルには、自分自身の S2S ゲートウェイが BGP で学習するオンプレミスの経路のみが存在します。
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName tenant1
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath :
西日本のルートテーブル「tenant1」に経路を広報する jw-vnet1 のアドレス帯のみが存在します。
tenant2
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName tenant2
addressPrefixes : {10.4.2.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet2
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet2
asPath :
西日本のルートテーブル「tenant2」に経路を広報する jw-vnet2 のアドレス帯のみが存在します。
マルチテナントなリージョン間通信の実現
上記の設定により、リージョン内通信はマルチテナントになりました。東日本の奇数の VNet は東日本の偶数の VNet 宛てのルートテーブルを知らないので通信できません。逆もまたしかりです。東日本の偶数の VNet は東日本の奇数の VNet 宛てのルートテーブルを知らないので通信できません。
ですが、このままだと、東日本の奇数 VNet と西日本の奇数 VNet が通信できません。そこで、東日本の VNet から西のルートテーブルに経路を伝達、西日本の VNetから東のルーティングに経路を伝達します。
リージョン間の伝達
関連付けるルートテーブルは自分が接続している Virtual Hub のものしか選べませんが、伝達するルートテーブルは Virtual WAN 内に存在する全ての Virtual Hub が持つルートテーブルを選べます。そこで、伝達先のルートテーブルに別リージョンのルートテーブルを追加します。
異なる Virtual Hub のルートテーブルを選択できる
ここまでの設定を図示したものが次になります。赤線が関連付け（＝経路の受信）で青線が伝達（＝経路の広報）です。
ここまでの関連付けと伝達のイメージ
この作業の結果、各ポイントのルートテーブルは次のようになります。
東日本の je-vnet1
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jevnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.3.1.0/24} VnetLocal {} Active
{10.1.0.0/16} VNetPeering {} Active
{10.4.1.0/24} VirtualNetworkGateway {20.89.190.139} Active
{0.0.0.0/0} Internet {} Active
東日本のルートテーブル「tenant1」に西日本の奇数の VNet が経路を広報し始めたので、ルーティングが増えました。
東日本 の Virtual Hub
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName tenant1
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath :
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
東日本のルートテーブル「tenant1」に西日本の奇数の VNet が経路を広報し始めたので、ルーティングが増えました。
西日本の jw-vnet1
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jwvnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.4.1.0/24} VnetLocal {} Active
{10.2.0.0/16} VNetPeering {} Active
{10.3.1.0/24} VirtualNetworkGateway {20.210.174.1} Active
{0.0.0.0/0} Internet {} Active
西日本のルートテーブル「tenant1」に東日本の奇数の VNet が経路を広報し始めたので、ルーティングが増えました。
西日本 の Virtual Hub
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName tenant1
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath :
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/je-vhub
asPath : 65520-65520
西日本のルートテーブル「tenant1」に東日本の奇数の VNet が経路を広報し始めたので、ルーティングが増えました。
疎通確認
これで奇数 VNet はリージョン間のルーティングが整いました。結果として、東日本の奇数 VNet 内の仮想マシンから、西日本の奇数 VNet 内の仮想マシンに対して Ping が飛びます。
root@jevnet1vm:~# ping 10.4.1.4
PING 10.4.1.4 (10.4.1.4) 56(84) bytes of data.
64 bytes from 10.4.1.4: icmp_seq=1 ttl=62 time=14.6 ms
64 bytes from 10.4.1.4: icmp_seq=2 ttl=62 time=22.1 ms
^C
--- 10.4.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 14.649/18.408/22.167/3.759 ms
一方で、同じ Virtul WAN 内の Virtual Hub に接続しているにもかかわらず、東日本の奇数 VNet 内仮想マシンから東日本の偶数 VNet 内仮想マシンへの Ping や、東日本の奇数 VNet 内仮想マシンから西日本の偶数 VNet 内仮想マシンへの Ping は失敗します。ルートテーブルを利用した Virtual WAN のマルチテナント化が上手く行っています。
root@jevnet1vm:~# ping 10.4.2.4
PING 10.4.2.4 (10.4.2.4) 56(84) bytes of data.
^C
--- 10.4.2.4 ping statistics ---
1372 packets transmitted, 0 received, 100% packet loss, time 1403881ms
root@jevnet1vm:~# ping 10.3.2.4
PING 10.3.2.4 (10.3.2.4) 56(84) bytes of data.
^C
--- 10.3.2.4 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5116ms
奇数 VNet で実施したルートテーブルの設定を偶数 VNet でも実施すれば、偶数 VNet 間だけが通信できるネットワークも Virtual WAN 上に構築できます。
オンプレの状態
VNet が default ルートテーブルを使っていない状態でのオンプレのルーティングは次の通りです。
show bgp ipv4 unicast
BGP table version is 59, local router ID is 192.168.1.4, vrf id 0
Default local pref 100, local AS 65147
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
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.1.0.0/16 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.2.0.0/16 10.2.0.13 0 65515 i
*> 10.2.0.12 0 65515 i
*= 10.3.1.0/24 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.3.2.0/24 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.4.1.0/24 10.2.0.13 0 65515 i
*> 10.2.0.12 0 65515 i
*= 10.4.2.0/24 10.2.0.13 0 65515 i
*> 10.2.0.12 0 65515 i
*> 192.168.1.0/26 0.0.0.0 0 32768 i
Displayed 7 routes and 13 total paths
omprevnet2vm# show bgp ipv4 unicast summary
BGP router identifier 192.168.1.4, local AS number 65147 vrf-id 0
BGP table version 59
RIB entries 13, using 2496 bytes of memory
Peers 4, using 2898 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt Desc
10.1.0.12 4 65515 286 252 0 0 0 00:02:27 3 1 N/A
10.1.0.13 4 65515 278 244 0 0 0 00:02:26 3 1 N/A
10.2.0.12 4 65515 285 253 0 0 0 00:02:27 3 1 N/A
10.2.0.13 4 65515 293 258 0 0 0 00:02:24 3 1 N/A
Virtual WAN の仕様上、オンプレ接続は必ず デフォルトのルートテーブルと関連付ける必要があります。
すべてのブランチ接続 (ポイント対サイト、サイト間、および ExpressRoute) が既定のルート テーブルに関連付けられている必要があります。 これにより、すべてのブランチが同じプレフィックスを学習します。
なのでオンプレ接続は デフォルトのルートテーブルと関連づいています。ですがなぜか デフォルトのルートテーブルを利用していない各 VNet のアドレス帯が聞こえてきています。よく見ると、リモートハブ経由での経路が存在しないので、おそらく Virtual Hub に直接接続されている VNet のアドレス帯は勝手に広報されるのかもしれません。要調査。
オンプレとの接続
さて、現時点では Virtual WAN 上の奇数用 VNet と偶数 VNet はオンプレミスと通信できません。なぜなら、各 VNet 側のルートテーブルにオンプレミス宛てのルーティングが存在しないからです。VNet にオンプレミス宛てのルートテーブルを注入するために、オンプレ接続からそれぞれのルートテーブルに対して経路を広報します。
まずは、オンプレ接続から東日本の Virtual Hub 上のルートテーブル「tenant1」に経路を広報します。
オンプレ接続からルートテーブルへの伝達の設定
するとルーティングは次のようになります。
東日本の je-vnet1
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jevnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.3.1.0/24} VnetLocal {} Active
{10.1.0.0/16} VNetPeering {} Active
{192.168.1.0/26} VirtualNetworkGateway {10.1.0.13} Active
{192.168.1.0/26} VirtualNetworkGateway {10.1.0.12} Active
{10.4.1.0/24} VirtualNetworkGateway {20.89.190.139} Active
{0.0.0.0/0} Internet {} Active
東日本のルートテーブル「tenant1」にオンプレ接続が経路を広報しはじめた結果、オンプレミス宛てのルーティングが増えました。
東日本 の Virtual Hub
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName tenant1
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjehub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjehub
asPath : 65147
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath :
東日本のルートテーブル「tenant1」にオンプレ接続が経路を広報しはじめた結果、オンプレミス宛てのルーティングが増えました。
西日本の jw-vnet1
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jwvnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.4.1.0/24} VnetLocal {} Active
{10.2.0.0/16} VNetPeering {} Active
{10.3.1.0/24} VirtualNetworkGateway {20.210.174.1} Active
{0.0.0.0/0} Internet {} Active
オンプレ接続が経路を広報したのは東日本のルートテーブル「tenant1」なので、西日本のルートテーブル「tenant1」に関連づいている西日本の VNet はオンプレの経路を学習できません。
西日本 の Virtual Hub
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName tenant1
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath :
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/je-vhub
asPath : 65520-65520
ここにもオンプレの経路は存在しません。オンプレ接続が経路を広報したのは東日本のルートテーブル「tenant1」です。ルートテーブルは Virtual Hub ごとのリソースのため、東日本のルートテーブルに広報した内容が自動的に西日本のルートテーブルに伝達されたりはしません。
それでは、オンプレ接続から西日本のルートテーブル「tenant1」に経路を広報します。するとルーティングは次のようになります。
東日本の je-vnet1
et-AzEffectiveRouteTable -NetworkInterfaceName nic-jevnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.3.1.0/24} VnetLocal {} Active
{10.1.0.0/16} VNetPeering {} Active
{192.168.1.0/26} VirtualNetworkGateway {10.1.0.13} Active
{192.168.1.0/26} VirtualNetworkGateway {10.1.0.12} Active
{10.4.1.0/24} VirtualNetworkGateway {20.89.190.139} Active
{0.0.0.0/0} Internet {} Active
変化なしです。
東日本 の Virtual Hub
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName tenant1
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjehub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjehub
asPath : 65147
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath :
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
変化なしです
西日本の jw-vnet1
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-jwvnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.4.1.0/24} VnetLocal {} Active
{10.2.0.0/16} VNetPeering {} Active
{192.168.1.0/26} VirtualNetworkGateway {10.2.0.12} Active
{192.168.1.0/26} VirtualNetworkGateway {10.2.0.13} Active
{10.3.1.0/24} VirtualNetworkGateway {20.210.174.1} Active
{0.0.0.0/0} Internet {} Active
西日本のルートテーブル「tenant1」にオンプレ接続が経路を広報しはじめた結果、オンプレミス宛てのルーティングが増えました。
西日本 の Virtual Hub
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName tenant1
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjwhub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjwhub
asPath : 65147
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/je-vhub
asPath : 65520-65520
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath :
西日本のルートテーブル「tenant1」にオンプレ接続が経路を広報しはじめた結果、オンプレミス宛てのルーティングが増えました。
ここまでの設定のイメージは次の通りです。
伝達と関連付けの図
動作確認
オンプレミスとのルーティングが整ったので、オンプレミスの VPN ルータから奇数 VNet 内の仮想マシンにのみ Ping が飛びます。
omprevnet2vm# ping 10.3.1.4
PING 10.3.1.4 (10.3.1.4) 56(84) bytes of data.
64 bytes from 10.3.1.4: icmp_seq=1 ttl=64 time=3.87 ms
64 bytes from 10.3.1.4: icmp_seq=2 ttl=64 time=3.65 ms
64 bytes from 10.3.1.4: icmp_seq=3 ttl=64 time=3.34 ms
64 bytes from 10.3.1.4: icmp_seq=4 ttl=64 time=3.43 ms
^C
--- 10.3.1.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 3.340/3.577/3.876/0.207 ms
omprevnet2vm# ping 10.4.1.4
PING 10.4.1.4 (10.4.1.4) 56(84) bytes of data.
64 bytes from 10.4.1.4: icmp_seq=1 ttl=64 time=10.1 ms
64 bytes from 10.4.1.4: icmp_seq=2 ttl=64 time=9.47 ms
64 bytes from 10.4.1.4: icmp_seq=3 ttl=64 time=10.1 ms
64 bytes from 10.4.1.4: icmp_seq=4 ttl=64 time=9.12 ms
^C
--- 10.4.1.4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 9.129/9.719/10.150/0.436 ms
オンプレミスとのルートテーブルが整っていない偶数 VNet 内の仮想マシンには Ping が飛びません。
omprevnet2vm# ping 10.3.2.4
PING 10.3.2.4 (10.3.2.4) 56(84) bytes of data.
^C
--- 10.3.2.4 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3073ms
omprevnet2vm# ping 10.4.2.4
PING 10.4.2.4 (10.4.2.4) 56(84) bytes of data.
^C
--- 10.4.2.4 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3056ms
注意点
一見よさそうなこのマルチテナントですが、1点だけ罠があります。それがオンプレミス側の可用性です。この状態のオンプレミスは、東日本の Virtual Hub から東日本の VNet のアドレスのみを、西日本の Virtual Hub から西日本の VNet のアドレスのみを学習しています。
show bgp ipv4 unicast
BGP table version is 77, local router ID is 192.168.1.4, vrf id 0
Default local pref 100, local AS 65147
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
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.1.0.0/16 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.2.0.0/16 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*= 10.3.1.0/24 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.3.2.0/24 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.4.1.0/24 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*= 10.4.2.0/24 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*> 192.168.1.0/26 0.0.0.0 0 32768 i
そのため、例えば東日本の Virtual Hub との S2S 接続や BGP による経路交換が停止した場合、オンプレが学習できる経路は西日本の VNet のみとなってしまいます。その結果、西日本の VNet にはアクセスできるが東日本の VNet にはアクセスできなくなってしまいます。
この問題の原因は、オンプレ接続が関連付けられるルートテーブルはデフォルトのみ（＝オンプレはデフォルトのルートテーブルからのみ経路を学習できる）という仕様にあります。仕方がないので、オンプレミスの経路の冗長性を担保するためだけに、VNet から デフォルトのルートテーブルに経路を伝達します。
デフォルトに関連付けしてはなりません。関連付けしてしまうと全 VNet がデフォルトのルートテーブルに広報した経路を学習してしまい、マルチテナントではなくなってしまいます。
ここまでのイメージ図は次の通りです。青線が伝達（＝経路の広報）、赤線が関連付け（＝経路の学習）です。線がごちゃごちゃするので、図中では 東日本の VNet 1つだけにしましたが、実際には西日本の VNet も同じ設定にする必要があります。
伝達と関連付けのイメージ
tenant1 の東西 VNet のみ 東西のデフォルトのルートテーブルに経路を広報します。
伝達と関連付けの設定
その結果のルートテーブルは次の通りです。
東日本 の Virtual Hub
default
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName defaultRouteTable
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjehub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjehub
asPath : 65147
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath :
関連付けた奇数の VNet のルーティングが増えました。
西日本 の Virtual Hub
default
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName jw-vhub -rtName defaultRouteTable
addressPrefixes : {192.168.1.0/26}
nextHops : vpnGateways/vpngwjwhub
nextHopType : VPN_S2S_Gateway
routeOrigin : vpnGateways/vpngwjwhub
asPath : 65147
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/jw-vhub/hubVirtualNetworkConnections/vnetconnBetweenJwvhubAndJwvnet1
asPath :
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/je-vhub
asPath : 65520-65520
関連付けた奇数の VNet のルーティングが増えました。
オンプレミス
show bgp ipv4 unicast
BGP table version is 77, local router ID is 192.168.1.4, vrf id 0
Default local pref 100, local AS 65147
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
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.1.0.0/16 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.2.0.0/16 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
* 10.3.1.0/24 10.2.0.13 0 65515 65520 65520 e
* 10.2.0.12 0 65515 65520 65520 e
*= 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
*= 10.3.2.0/24 10.1.0.13 0 65515 i
*> 10.1.0.12 0 65515 i
* 10.4.1.0/24 10.1.0.13 0 65515 65520 65520 e
* 10.1.0.12 0 65515 65520 65520 e
*= 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*= 10.4.2.0/24 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*> 192.168.1.0/26 0.0.0.0 0 32768 i
デフォルトに関連付けた奇数の VNet のみ、東西の Virtual Hub から経路が聞こえてくるようになりました。
動作確認
実際に経路が冗長化されているかを試すために、東日本の Virtual Hub 向けの BGP をシャットダウンして経路を学習しないようにします。
作業前の Ping の結果は次の通りです。東西の両仮想マシンに Ping が飛びます。
omprevnet2vm# ping 10.3.1.4
PING 10.3.1.4 (10.3.1.4) 56(84) bytes of data.
64 bytes from 10.3.1.4: icmp_seq=1 ttl=64 time=4.27 ms
^C
--- 10.3.1.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.272/4.272/4.272/0.000 ms
omprevnet2vm# ping 10.3.2.4
PING 10.3.2.4 (10.3.2.4) 56(84) bytes of data.
64 bytes from 10.3.2.4: icmp_seq=1 ttl=64 time=4.00 ms
64 bytes from 10.3.2.4: icmp_seq=2 ttl=64 time=3.46 ms
^C
--- 10.3.2.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 3.467/3.736/4.005/0.269 ms
omprevnet2vm#
東日本の Virtual Hub との BGP 接続をシャットダウンします。
router bgp 65147
bgp router-id 192.168.1.4
bgp log-neighbor-changes
no bgp ebgp-requires-policy
neighbor 10.1.0.12 remote-as 65515
neighbor 10.1.0.12 shutdown
neighbor 10.1.0.12 ebgp-multihop
neighbor 10.1.0.13 remote-as 65515
neighbor 10.1.0.13 shutdown
neighbor 10.1.0.13 ebgp-multihop
neighbor 10.2.0.12 remote-as 65515
neighbor 10.2.0.12 ebgp-multihop
neighbor 10.2.0.13 remote-as 65515
neighbor 10.2.0.13 ebgp-multihop
!
address-family ipv4 unicast
network 192.168.1.0/26
neighbor 10.1.0.12 next-hop-self
neighbor 10.1.0.12 distribute-list 1 out
neighbor 10.1.0.13 next-hop-self
neighbor 10.1.0.13 distribute-list 1 out
neighbor 10.2.0.12 next-hop-self
neighbor 10.2.0.12 distribute-list 1 out
neighbor 10.2.0.13 next-hop-self
neighbor 10.2.0.13 distribute-list 1 out
exit-address-family
exit
!
すると、東日本の Virtual Hub から経路を学習しなくなります。
show bgp ipv4 unicast
BGP table version is 83, local router ID is 192.168.1.4, vrf id 0
Default local pref 100, local AS 65147
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
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/16 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*= 10.3.1.0/24 10.2.0.13 0 65515 65520 65520 e
*> 10.2.0.12 0 65515 65520 65520 e
*= 10.4.1.0/24 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*= 10.4.2.0/24 10.2.0.12 0 65515 i
*> 10.2.0.13 0 65515 i
*> 192.168.1.0/26 0.0.0.0 0 32768 i
Displayed 5 routes and 9 total paths
オンプレのルートテーブルには、西日本の Virtual Hub をネクストホップとする東日本の奇数 VNet 宛てのルーティングが残っています。
ですが、東日本の奇数 VNet には Ping は飛びません。。。。
omprevnet2vm# ping 10.3.1.4
PING 10.3.1.4 (10.3.1.4) 56(84) bytes of data.
^C
--- 10.3.1.4 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3059ms
omprevnet2vm# ping 10.4.1.4
PING 10.4.1.4 (10.4.1.4) 56(84) bytes of data.
64 bytes from 10.4.1.4: icmp_seq=1 ttl=64 time=12.3 ms
64 bytes from 10.4.1.4: icmp_seq=2 ttl=64 time=9.58 ms
^C
--- 10.4.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 9.582/10.947/12.313/1.369 ms
omprevnet2vm#
良く見てみると、東日本の奇数 VNet と東日本の Virtual Hub からオンプレミスのルーティングが消失しています。
東日本 の je-vnet1
et-AzEffectiveRouteTable -NetworkInterfaceName nic-jevnet1vm -ResourceGroupName vwaneval | Select-Object AddressPrefix,NextHopType,NextHopIpAddress,State
AddressPrefix NextHopType NextHopIpAddress State
------------- ----------- ---------------- -----
{10.3.1.0/24} VnetLocal {} Active
{10.1.0.0/16} VNetPeering {} Active
{10.4.1.0/24} VirtualNetworkGateway {20.89.190.139} Active
{0.0.0.0/0} Internet {} Active
西日本 の Virtual Hub
tenant1
Get-AzVhubEffectiveRoutes -subId MY-SUB-ID -vhubRgName vwaneval -vhubName je-vhub -rtName tenant1
addressPrefixes : {10.4.1.0/24}
nextHops : virtualHubs/jw-vhub
nextHopType : Remote Hub
routeOrigin : virtualHubs/jw-vhub
asPath : 65520-65520
addressPrefixes : {10.3.1.0/24}
nextHops : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
nextHopType : Virtual Network Connection
routeOrigin : virtualHubs/je-vhub/hubVirtualNetworkConnections/vnetconnBetweenJevhubAndJevnet1
asPath :
障害発生中の関連付けと伝達の状況は以下の通りです。青線が伝達（＝経路の広報）、赤線が関連付け（＝経路の学習）です。東日本の奇数 VNET が経路を学習する東日本のルートテーブル「tenant1」に対して、誰もオンプレの経路を伝達していません。障害時に経路を冗長化するためには青点線（西日本のオンプレ接続と東日本のテナント1用テーブル）の伝達が必要になります。
伝達と関連付けの図
「じゃあ、青点線を引こう。西日本のオンプレ接続を西日本のルートテーブル「tenant1」だけでなく東日本のルートテーブル「tenant1」にも伝達しよう」となるのですが、Virtual WAN の仕様上、オンプレ接続が伝達できるルートテーブルは接続先の Virtual Hub に存在するルートテーブルのみです。別リージョンのルートテーブルには伝達できません。
ここまでいろいろ頑張ってみましたが、マルチテナントな Virtual WAN 環境でオンプレミス含めたリージョン間冗長を実現するためにはルートテーブルだけでは力不足です。これを解決するのがラベルのはずです。これは次回に。
まとめ
Virtual WAN のルートテーブルを利用して、1つの Virtual WAN 上にマルチテナントなネットワークを構築しました。小規模なネットワークであればルートテーブルを利用して1つの Virtual WAN 上に複数のネットワークを構築できそうです。ですが、Virtual WAN がそもそも想定している大規模・複数リージョンなネットワーク上に複数のネットワークを作ろうとするとルートテーブルだけだときつそうです。次回のラベルに期待。
Note
- 当サイトは個人のブログです。このブログに示されている見解や意見は個人的なものであり、所属組織の見解や意見を表明するものではありません。
- 公開情報を踏まえて正確な情報を掲載するよう努めますが、その内容の完全性や正確性、有用性、安全性、最新性について一切保証しません。
- 添付文章やリンク先などを含む本サイトの内容は作成時点でのものであり、予告なく変更される場合があります。