ついにこの時が来ました。Avi Load Balancer導入記、最終回です。
第1回でメモリ枯渇に怯えながらSE（Service Engine）をデプロイし、第2回でMTUの壁に阻まれてVyOSを緊急投入し、第3回でWAFによる鉄壁の防御を手に入れました。
物理・仮想・オーバーレイが繋がり、セキュリティも確保された今、最後に残された課題は「運用」です。
「新しいWebサーバーを公開したい」と思った時、VS（仮想サービス）を作ってVIPを払い出すまではAviがやってくれます。
しかし、そのIPアドレス（例：192.168.49.101）を、手動でDNSサーバーに登録しに行っていませんか？
今回は、Aviの「DNSプロバイダー機能」を有効化し、「ロードバランサの設定を入れたら、勝手に名前解決できるようになっている」という、夢のような自動化環境を構築してシリーズを締めくくります。
DNSレコード登録からの脱却
これまでの検証では、Webブラウザに http://192.168.49.100 のようにIP直打ちでアクセスしていました。
検証ならそれで良いですが、本番運用（ホームラボ的な意味で）では、やはり https://wordpress.avi.lab.local のようなFQDNでアクセスしたいものです。
しかし、VSを追加するたびに、既存のDNSサーバー（ADやBind）の設定ファイルを書き換えてAレコードを追加するのは非常に面倒です。
「AviでVIPを作った瞬間に、DNSレコードも自動で生成してほしい」
これを実現するのが、AviのIPAM/DNS連携機能です。
Aviを「権威DNSサーバー」にする
Aviは単なるロードバランサではなく、高機能なDNSサーバーとしても動作します。
今回は、Avi自身に特定のサブドメイン（例：*.avi.lab.local）の管理を任せる設定を行います。
Step 1：DNS VIPの作成
DNS VSを作成するためのVIPを作成します。
Applications> VS VIPsからCREATEをクリックします。
CloudでHomelab、VRF ContextでT1-GW-01をセットし、VIPsのADDをクリックします。
EDIT VIPにて、以下の設定を行いSAVEをクリックします。
- Enable VIP：チェックを入れる
- Private IP：Static
- IPv4 Address：192.168.49.53（わかりやすいようにポート番号とあわせました）
VIPsに反映されたことを確認してSAVEをクリックします。
Step 2：DNSサービスの作成
続いて、DNSリクエストを待ち受けるための仮想サービス（DNS VS）を作ります。
Applications> Virtual Services からCREATE VIRTUAL SERVICEのAdvanced Setupをクリックします。
Select CloudでHomelab、Select VRF ContextでT1-GW-01を選択します。
以下の内容で設定しNextをクリックします。
- Name：Avi-DNS-Service
- VS VIP：DNS-VIP
- TCP/UDP Profile：System-UDP-Per-Pkt
- Application Profile：System-DNS
- Services：53
- Pool：なし
Service Engine Groupで、Homelab-Groupを選択し、Nextをクリックします。
あとはデフォルトのままSAVEをクリックするとDNS VSができます。
これで、AviがDNSパケットを喋れるようになりました。IPアドレス（192.168.40.53）を控えておきます。
Step 3：DNS Profileの定義
続いて「どのドメインをAviが管理するか」を定義します。
Templates > Profiles > IPAM/DNS Profiles で DNS Profile をクリックします。
以下の情報を入力しSAVEをクリックします。
- Name：HomeLab-DNS-Profile
- Type：Avi Vantage DNS
- Domain Name：avi.lab.local（ホームラボのサブドメインとします）
- Override Record TTL：60（ラボ用なので短めに）
プロファイルも作成できました。
既存DNS (Bind) との連携
ここで一つの疑問が浮かびます。
「クライアントPCは既存のDNSサーバー（Bind: 192.168.10.9）を見ているのに、どうやってAviのレコードを引くの？」
答えは「フォワーディング（転送）」です。
既存のDNSサーバーに、「avi.lab.local への問い合わせが来たら、Avi (192.168.40.50) に転送してね」と教えるだけでOKです。
Bindの設定追加 (named.conf.local)
【追加】の部分から追加します。
hisato@dns09:~$ cat /etc/bind/named.conf.local // 正引きゾーン zone "lab.local" { type master; file "/etc/bind/lab.local.zone"; }; // 逆引きゾーン (192.168.10.x なので 10.168.192.in-addr.arpa) zone "10.168.192.in-addr.arpa" { type master; file "/etc/bind/lab.local.zone.rev"; }; // 【追加】avi.lab.local は Avi DNS (192.168.49.53) へフォワード zone "avi.lab.local" { type forward; forward only; forwarders { 192.168.49.53; }; // Avi DNS VSのIP }; hisato@dns09:~$
これで、既存の環境を壊すことなく、Aviの管理領域だけを切り出すことができます。
DNSSECの無効化
プライベートIPアドレス（192.168.x.x）を持つAviへの転送を成功させるため、DNSSEC検証を無効化します。
hisato@dns09:~$ cat /etc/bind/named.conf.options
acl internal-network {
192.168.0.0/16;
10.0.0.0/8;
localhost;
};
options {
directory "/var/cache/bind";
# 問い合わせを受け付ける範囲
allow-query { internal-network; };
# 再帰問い合わせ（インターネットへの転送）を許可
recursion yes;
# 上位DNSサーバー（Google DNSなど）
forwarders {
8.8.8.8;
};
# Ubuntu標準の設定
dnssec-validation no; //ここを追加
listen-on-v6 { any; };
# IPv4のリスン設定 (any または自身のIP)
listen-on port 53 { any; };
};
bindを再起動して反映
sudo systemctl restart bind9
sudo rndc flush # キャッシュクリアも忘れずに
VSを作るだけで名前解決
最後はVSの作成します。
いつもと手順が異なるのは、VS VIPの作成部分です。
ここで、FQDNを記載していくので見ていきます。
VIPsでのFQDN登録
VS VIPの作成画面で、VIPsをAuto-Allocateで設定したら、その下にDNSの項目があるのでADDをクリックします。
Application Domainの項目で希望するホスト名（ここでは：www）を入力しました。
後ろのサブドメインはあから締め表示されています。（avi.lab.local）
TTLは60としてSAVEをクリックします。
「www.abi.lab.local」のFQDNが反映されたことを確認してSAVEをクリックします。
実際に新しい仮想サービスを作ってみましょう。
VSの作成手順はいつも通り、VIP、Pool、Profileの紐づけを行うだけなので割愛します。
すべての設定が完了しSAVEをクリックします。
この瞬間、裏側で何が起きているかというと...
動作確認
手元のPCから nslookup してみます。
PS C:\Users\hisato> nslookup www.avi.lab.local. 192.168.10.9 サーバー: dns09.lab.local Address: 192.168.10.9 権限のない回答: 名前: www.avi.lab.local Address: 192.168.49.104 PS C:\Users\hisato> <-- 引けた！！
ブラウザからもアクセスしてみましょう。
感動です。
VIPは自動的に採番されるようになっているので、採番された情報とFQDNを自動的にレコード登録してくれるので、DNSサーバーの設定ファイルをいじる必要はありません。
Aviでサービスを作れば、即座に名前でアクセスできるようになります。
これが Software-Defined Load Balancing の真価です。
Avi導入シリーズ：総まとめ
全4回にわたるAvi Load Balancer導入の旅、いかがでしたでしょうか。
最後に、構築した「最強のホームラボLB基盤」のポイントを振り返ります。
第1回：リソースとの戦い
- 課題：デフォルト設定だとSE（Service Engine）がメモリを100%予約してしまい、ESXiが枯渇する。
- 解決：「SE Group」のチューニングを実施。メモリ予約を解除し、ラボ用にスペックを絞ることで、省エネ運用を実現しました。
第2回：見えない壁（MTU）との戦い
第3回：鉄壁の守り
- 課題：公開サーバーへの攻撃が怖い。
- 解決：「iWAF」をワンクリックで有効化。SQLインジェクションなどの攻撃をエッジで遮断し、可視化する環境を整えました。
